ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Суббота
18 мая
158494
Evgeny_CD, Архитектор (07.06.2009 13:24, просмотров: 2940)
SDRAM <-> FLASH: новый виток спирали? Предыдущие обсуждения по теме http://caxapa.ru/139200.html - хороший тред на тему перспектив Embedded SDRAM http://caxapa.ru/157408.html - продвинутые системы управления памятью http://caxapa.ru/156168.html - размышлизма об эконом использовании памяти http://caxapa.ru/158014.html - ставшая уже знаменитой размылизма о линуксоидах как жрецах 21 века. http://caxapa.ru/156787.html - продвинутые кооперативные ОСи Попалось на глаза упомнинание про адаптер Моксы http://caxapa.ru/158440.html По фотке видно - платка там махонькая, места для кристалла SDRAM попросту нет. Далее. Думаю, что же за кристалл они туда поставили 32 Mbit SDRAM? Актиквариат какой-то. Сейчас уже 64 Мбит почти никто не выпускает. Стал гуглить на тему SDRAM 32mbit и вот что сразу нагуглил :) http://www.eetasia …499486_NP_13119e02.HTM
Inapac Technology Inc., a provider of IP-based DRAM solutions for system-in-package (SiP) and multichip-package (MCP) devices, has rolled out a new 32Mbit SDRAM design to its family of products. The new 32Mbit SDRAM design is characterized for production on the ProMOS Technology Inc.'s 0.12µm manufacturing process. IP-based provider Inapac estimates that the total cost of incorporating the 32Mbit DRAM die into a SiP/MCP solution will be less than 60 cents in volume production in 2008. ''This new 32Mbit design makes it easier and more cost-efficient to create SiPs for a new generation of mobile handset applications,'' said Naresh Baliga, VP of marketing for Inapac. The chip design is based on Inapac's SiPFLOW platform, which incorporates a design-for-test (DFT) architecture and production methodology that enables SiP/MCP suppliers to minimize costs, according to the firm.
Сам сайт это интересной конторы http://www.inapac.com не фурычит. Но контора жива 100% - Rambus Acquires Inapac Patents http://www.rambus. …eases/2009/090407.html Суть вот в чем. Как только появились embedded 32 битные процы с FLASH, меня начал мучить вопрос - а чего в них так RAM мало? Типичная конфигуцрация 256 FLASH/16, иногда 32 RAM. Я в то время грезил eCos, RTEMS, смотрел в сторону Linux и никак не мог догнать - как же это можно сделать что-то серьезное на 16 к памяти? Спустя мнго лет пришло просветление - что конфигурация 256 FLASH/16RAM вполне адеватная, если использовать правильные подходы к программированию и управлению памятью. Если же есть хотя бы кусочек двухпортового ОЗУ на кристалле (DMA без блокировки проца, можно шинный коммутатор какой продвинутый), DMA и небыстрая внешнаяя память (SDRAM без кеша), то при помощи такого контроллера можно сделать вообще все, если подумать. И тогда мне стало понятно, почему же микроконтроллеры пошли по такому пути развития. Где-то на уровне 2000 года, видимо, была диллема - что делать - FLASH или SDRAM на кристалле? Технологически можно было сделать 2-4 мбайта SDRAM на кристалле, бутиться из SPI FLASH, и жить в мире больших ОСей. Но победил FLASH. Ибо SDRAM сам по себе имеет много гемороя в виде всяких sleep мод с авторефрешем, ну и технологически, видимо, SDRAM был гемороен. При наличии большого FLASH на кристалле, быстрого проца с хорошей архитектурой, небольшого ОЗУ и мозгах программиста, свободных от догм типа "настоящие пацаны делают POSIX тред ка каждый IO пин проца!" фсе получается. Но задачу больших буферов в программах, особенно коммуникационных, никто никто не отменял. Как я уже писал, не обязательно все тело пакета хранить в быстром ОЗУ, достаточно дексрипторную часть хранить там, а сами данные могут жить в более медленном ОЗУ, например, внешнем SDRAM без кеша и перекачиваться по DMA. Одновременно силами сото и навигационно делателей были хороо освоены технологии SiP (по объективным причинам - в навигационном применике RF и цифровой кристалл делают по разным технологиям, и все попытки сделать монокристалл заканчивались всегда пшиком). И тут, народ, очевидно, достал из чулана наработки по небольшим чипам SDRAM и решил прикрутить их в одном корпусе к ARM*. Итак, дрим контроллер тяжелого класса 2010 года выглядит примерно так: * ARM чего-то там с плавучкой, 64...128 К ОЗУ на кристалле, шинный коммутатор, SDRAM контроллер, можно без кеша, DMA, куча периферийных последовательных интерфейсов, контроллер SD карт обязательно * SDRAM 32 мбита (4 Мбайта) * FLASH 2..4 Мбайта * LDO/DC-DC для ядра контроллера Все это упаковано в компактный корпус типа QFN100. Никаких внешних параллельних шин :) А внутри достаточно ресурсов для решения сложных задач под продвинутыми осями (но без Линукс фанатизма). Вообще, стратегически, параллельные шины за пределами корпуса - это неправильно. Все надо паковать на одну подложку в QFN. Кстати, чиповые компании типа PGC http://www.pgc.com.tw очень любят QFN и готовы паковать в них кристаллы порядка 0.5$ за корпус вместе со стоимостью корпуса и работами. Ну а снаружи такого дрим чипа мириады SPI сопроцессоров делают всю периферийную работу.