В чем отличие памяти DDR от DDR2?

[В чем отличие памяти DDR от DDR2?]

странно, а что же тогда латекс заявляет что они сделали самый быстрый вендорный DDR2 контроллер для своих фпга семейств :)

Только что, между делом, посмотрел на реализацию их контроллера - активировали строку, записали/прочитали, закрыли строку. Так чему же здесь работать медленно? Они не перекрывают транзакции и не делают попыток прятать активации с пречарджами внутрь записей и чтений. А еще они работают внутрях на удвоеном клоке по захвату данных. А еще, меленьким шрифтом внизу тонко подмечают, что "For LatticeXP2, Clock Frequency for DDR1/2 SDRAM is 200 MHz, Pin Throughput of 400 Mbps".

[В чем отличие памяти DDR от DDR2?]

на тот момент когда я хотел попользовать эту память цена девайса была не важна, на фоне стоимости програмного обеспечения :)

Видимо, вам повезло поработать над мелкосерийным проектом.

если я не ошибаюсь практически все современные видекарты.

Видюхи много чего поддерживают и много чего могут. А я говорю о FPGA. Для FPGA даже первый DDR выглядит избыточным. Потому думаю, что еще на долгое время SDR и DDR-1 будут единственными типами памяти, подключаемыми к FPGA.

[В чем отличие памяти DDR от DDR2?]

а что касаеться альтернативной памяти мне больше понравилась RLDRAM II и работать с ней проще, задержки доступа меньше и контроллер получаеться достаточно простой.

А как вам понравилась ее цена :07: Посмотрев на даташит, я тоже сначала решил - вот оно - счастье, потом пошел на e-find и посмотрел на цены :crying: Конечно, можно найти применение 32 мегам памяти за "жалкие" $33 за корпус, но начальство меня совсем даже и не поймет :crying:

 

DDR3 симпотичнее

А кто поддерживает на данный момент его сигнальный протокол? А где бы надыбать на нее нечто вразумительное с принципами функционирования?

[Перевод с английского]

Разница с оплаченным переводом будет состоять в том, что фактически перевод текста наберете вы сами, мы просто проясним непонятные места и поможем в понимании общего смысла. Думаю, что это будет наиболее эффективный подход к этому вопросу, если не найдется желающий в одиночку выполнить всю работу в предложенном вами изначально порядке.

[В чем отличие памяти DDR от DDR2?]

Чем отличаются памяти DDR стандарта и памяти стагдарта DDR2 кроме стандарта выходного напряжения и рабочей частоты?

 

Если в DDR команды идут на частоте в 100MHz, то данные тактируются теми же 100MHz, но захватываются по обоим фронтам. Судя по названию DDR2 - было предположение о удвоении частоты данных до 200MHz и захвата их по обоим фронтам. Однако после изучения даташита от Micron на MT47H32M16 получилось, что картина с командами и данными абсолютно аналогична DDR :( Таким образом, применение микросхем DDR2 не принесет никакого увеличения пропускной способности подсистемы памяти за исключением работы самого интерфейса на более высокой частоте?

 

Вопрос возникает потому, что нечто более сложное, нежели сдвиговый регистр запустить в дешевых FPGA типа Cyclone II или Spartan 3 на частотах выше 166MHz уже весьма проблематично. Таким образом, сильно постаравшись, можно получить в FPGA "жалкие" 333MHz :( Похоже, что для более "взрослых" по памяти приложений надо делать либо широкую шину, либо ставить более дорогой чип?

[Перевод с английского]

Из простых решений - прикрепите сюда документ и задавайте вопросы по неочевидным местам. Думаю, сообща все форумом переведем, потому как не столько переводить сколько набирать 40 страниц текста будет просто до-о-олго. Ну, редки среди нас индивидуумы, владеющие десятипалцевым скоростным методом печати

[altera ddr2 sdram controller]

Интересно было бы померить пропускную способность именно на рандомных адресах/бурстах и последовательносях read->write )

Если есть интерес, то могу скомпилить до EDIF'а наше ядро под CL=3, написать под него небольшой тестбенч в качестве хелпа и выложить здесь для посмотрения :)

 

Мы тестировали его характеристики прямо в железе. На тот момент у нас еще не было широких познаний в написании тестбенчей, потому просто ставили некий генератор заданий, некий счетчик циклов и счетчик трансферов. Потом стопили после некоторого времени и считывали показания счетчиков. Мож, конечно, в тестах адреса с бурстами получались и ограниченной рандомности :)

[написание PCI драйвера под Win2K/XP/Vista]

Вы при этом уверены, что Ваши драйвера правильно обрабатывают все требуемые события? PnP? Power? А остановку драйвера для переконфигурирования ресурсов? И делаете это незаметно для клиентов? Ваши драйвера при этом, конечно используют прерывания и DMA?

В сове время я потратил почти месяц на аккуратные разборки и переписывание под мои нужды фрамеворка, предложенного Walter Oney. Многие вещи показались мне у него нерациональными, но основная идея была достаточно простой. С того времени проблем с написанием WDM драйверов у меня особых не возникает.

[написание PCI драйвера под Win2K/XP/Vista]

Конечно, придется. Но IMHO это меньшее зло, чем WDM.

IMHO конечно, но чем вам так WDM технология не нравится? Поначалу мне тоже было несколько сложно с ней разбираться, но сейчас драйвера получаются простыми и понятными :)

[altera ddr2 sdram controller]

Уважаемый v_mirgorodsky, прежде чем делать такие заявления, и засорять мозг участников форума подобными данными, хочется пожелать вам сначала поподробнее изучить принципы работы SDRAM-памяти и разобраться в собственном методе тестирования и подсчета результатов. Тогда вы все-таки поймете, что приведенные вами цифры значительно превосходят теоретически возможные. Надо же все-таки хоть немного задумываться о собственном авторитете, и не кидаться такими непроверенными данными.

Поскольку наш контроллер использует команды авто-рефреша строк памяти, то это время теряется безвозвратно. Была идея прятать рефреш в средину работы активных команд, однако она показалась на тот момент слишком сложной. Просто это разумелась само собой в нашем тестировании, а потому время рефрешей в расчетную полосу и не закладывалась. BTW, время рефрешей составляет около 1% всей полосы работы памяти. Еще момент, при тестировании не менялось направление передачи данных. Вот это единственные неточности и оговорки в этой цифре.

 

Теперь, идем дальше. При случайном наборе адресов/бурстов/банков средняя длинна бурста составляет 8 трансферов данных за команду. Могу вас уверить, что просмотр очереди команд на три команды вглубь дает широчайшие возможности для манипуляций с банками во время активных трансферных операций. В нашем дизайне спрятанные пречрджи/активации банков становятся возможными при длинне непрерывного бурста равным три и более. Как я уже говорил, единственными неприятностями для контроллера являются последовательные доступы в один и тот же банк, но в разные строки. Возможно в нашем тестировании таких случаев было мало.

 

А посему, уважаемый Loki5000, в наших цифрах ничего мистического нет. При дальнейшем желании доказательств могу выложить несколько диаграмм активности интерфейса памяти при работе нашего контроллера.

 

P.S. При определенных прочих равных, если есть гарантия доступа во все строки памяти в пределах окна рефреша и достаточной длинне бурстов (начиная где-то с 8 трансферов за команду) можно получить и все 99.9% утилизации всей теоретической полосы памяти. Без скидки на рефреши. Надо только чтобы направление передачи данных менялось достаточно редко. Или вы снова скажете, что это невозможно?

[написание PCI драйвера под Win2K/XP/Vista]

Заглянул в документацию на последние версии KMDF. Наисано, что можно разрабатывать драйвера под W2K и более поздние версии. Тогда однозначно больше не следует связываться с чистой WDM.

Угу, только под Win2k возможно придется дополнительно устанавливать некий пакет расширений и ядерных библиотек, поскольку в чистом виде KMDF под Win2k может не запуститься. Такое у меня сложилось впечатление после прочтения обзорной статьи Walter Oney о технологии KMDF. Не знаю, может быть впечатление и ошибочное.

[написание PCI драйвера под Win2K/XP/Vista]

В свое время я начинал с двух книг. Первая - Edvard N. Dekker, Joseph M. Newcomer - Developing Windows NT Device Drivers - A Programmer's Handbook. Вторая - Walter Oney - Windows Driver Model - или нечто подобное по названию. Первой книги в электронном виде я не встречал, вторая есть в местных закромах.

 

Теоретически, после прочтения второй книги получится понять в первом приближении как надо писать драйвера и немного зацепить механизмы, приводимые в действие в недрах ОС при выполнении празличных вызовов. Для более глубокого понимания внутренностей рекомендуется прочитать и вторую книгу. Она будет очень полезна для понимая механизмов работы ядра ОС.

 

Есть еще не самая плохая русская книга Солдатова - однако она содержит больше набор готовых рецептов и, IMHO, менее способствует пониманию тонкостей драйверописания.

 

С этого можно начать. Дальше есть конференции на Google, посвященные именно вопросу разработки драйверов под различные версии NT систем.

 

С точки зрения фреймворка - здесь руководствуйтесь собственным вкусом и наличным временем. С Jungo вы сможете написать нечто работоспособное уже через пару недель разборок. Numega, возможно, даст еще более быстрый старт, но она, судя по всему, уже не поддерживается. Чистый DDK имеет смысл учить только в том случае, если вы собираетесь и дальше заниматься написанием драйверов, поскольку нечто вменяемое на чистом DDK получится не ранее, чем месяца через три. KMDF - это дальнейшее расширение технологии WDM, а в своей базе просто еще один фрамеворк от производителя ОС. С ним я еще не работал, но судя по отзывам - очень неплохая штука. Возможно вам можно начать с нее, если найдете достаточно информации по ней. UMDF - совсем ничего не знаю о ней. Мож дойдут руки - посмотрю.

[altera ddr2 sdram controller]

Сечас исследую возможности конвейера комманд СДРАМ, и делаю поведенческое описание контроллера, потом перетяну его на РТЛ с использованием МПА. Пока по прикидкам все должно уместиться на 1МПА на блочной памяти (!!!).

Была и у нас и такая идея - в самом начале, но в конце пришлось все же делать на дискретных FSM, поскольку не обеспечивался требуемый уровень гибкости и быстродействия всей системы.

[altera ddr2 sdram controller]

tras + twr и возможный t_bta. Из за этого необходимо вставлять дополнительные выравнивающие nop в командах со сменой адресса колонки и перехода от чтения к записи.

Я не зря сказал о просмотре очереди команд на три команды в глубину. Если необходима активация неактивной строки, то она прячется внутри бурстов, выполняемых в данный момент. Неприятность представляют только запросы идущие в один банк и в разные строки. Однако и здесь мы немного схитрили, использовав по возможности команды записи/чтения с активированным автопречарджем.

 

дополнительные выравнивающие nop в командах со сменой адресса колонки и перехода от чтения к записи.

А по этому поводу я говорил, что дата машины могут продолжать бурсты друг друга. Таким образом смена адреса колонки в активной строке и сохранении направления передачи даных вообще не требует ни одного лишнего такта. Контроллер учтет все необходимые задержки распространения по тактам и выйдет на шину в строго детерминированный момент. Немного хуже обстоят дела с изменением направления передачи даных, однако и это ограничивается только возможностями протокола самой памяти.

 

Вообще говоря, под функциональными блоками самой памяти лежит блок моделирования контекста памяти, который вырабатывает разрешения на каждую конкретную операцию в каждый конкретный момент. Потому логика работы контроллера в подавляющем большинстве случаев ограничивается только протоколом работы памяти. Есть только одно место, сейчас уже точно не вспомню какое, которое можно было бы сделать на такт быстрее, но у нас не получилось - слишком длинными становились ассинхронные пути разрешения операций с блока физического моделлирования контекста памяти.

 

Ориентируюсь на CL = 1..3, burst = 4 (для совместимости конвейера комманд с DDR/DDR2), не использование burst_terminate(все на масках).

В нашем дизайне мы использовали burst_terminate и совсем не использовали маски. Теперь есть небольшие проблемы, поскольку такая модель совсем не ложится под DDR/DDR2 :( Под новую разработку придется некоторые вещи переделывать.

[altera ddr2 sdram controller]

des00

 

Какие знакомые и приятные темы :) Мы с товарищем делали подобное чудо и держали открытыми ВСЕ четыре банка памяти. Немного поделюсь опытом :) Мож будет интересно.

 

Короче, в нашем случае наш контроллер SDRAM при случайном наборе адресов/бурстов/банков обеспечивал утилизацию полосы памяти выше 99%. Все было завязано на командную систему по принципу "выстрелил и забыл" - в команде указывался адрес, количество даных на чтение/запись и уникальный идентификатор команды. В ответ контроллер выставлял на шину идентификаторов предварительно сохраненыый идентификатор и данные, сопровождая их сигналом "валид". Это чудо поддерживает бурсты от 1 до 16 слов за команду, конфигурируемо в момент запуска команды и внутренне работает с памятью с бурстом 8. Поддержисает любые CL, параметры рефрешей и все остальное.

 

Немного о реализации. В реализации две (!) дата машины, активационная машина и машина для рефрешей. Контроллер просматривает вперед до трех команд, одна находится на активном исполнении в одной дата машине, вторая готовится к исполнению во второй дата машине, а под третью активационная машина выполняет необходимые активации банков, если это возможно в тот момент. Дата машины немного знают о работе друг друга, а потому могут продолжать бурсты друг друга при необходимости. Занимает это чудо порядка 1000 альтеровских ячеек и работает на частотах порядка 120MHz в самом медленном Cyclone II. Добавляет около четырех тактов задержки к латентности самой памяти, но может брать новую команду каждый такт.

 

Если кто поверит, то это была с товарищем наша самая первая серьезная разработка, написанная на VHDL :07: До этого мы пользовались исключительно схемным вводом и ничего подобного ни по размерам ни по быстродействию не создавали :yeah:

 

Единственное, что могло бы дополнительно ускорить контроллер - это пересортировка записей и чтений, идущих на вход контроллера. Я видел реализацию подобных алгоритмов, но они оказывались слишком сложными и применимыми только для ASIC'ов с их быстродействием.

 

Сейчас уже, с высоты опыта, делали бы немного по другому. Очень большое количество усилий было затрачено именно для поддержки режимов с размером бурста, равным единице. Фактически в этом режиме контроллеру каждым тактом необходимо обновлять адрес на шине и вести синхронную передачу/прием данных. Сейчас в планах есть построение контроллера на DDR2 с похожими принципами работы. Как будет чем похвастаться - обязательно расскажу :)

 

BTW, разработка заняла почти месяц времени :crying: Одной из главных неприятностей была ее полная параметризация под любой тип SDRAM памяти - каждый блок имеет целый список констант на входе.

[Устойчивость связи на USB]

Такая проблема может возникать если у вашего устройства серьезные аппетиты по потреблению. В этом случае "шина" как бы проседает изредка в процессе работы и само устройство теряется.

[Philips SAA7134 и черно-белое изображение]

Обнаружился еще один очень неприятный глюк в работе DMA SAA7134. Суть его сводится к тому, что при определенных условиях и определенной конфигурации чипа (полностью легальной с точки зрения документации) и нестабильном входном видеосигнале (че нибудь типа пол-поля есть, потом еще поле, потом видеосигнал отсутствует, потом снова есть и так далее) можно добиться того, что DMA перезапишет данные за концом выделенного DMA буфера. Связано это с невозможностью сброса регистров определения DMA. Таким образом запуск видео скалера с неустановленым битом SLCK в определении задачи потенциально опасен для целостности системы.

 

Если есть интерес, могу рассказать более подробно. Такой вот себе замечательный чип.

[tcp/ip]

Уважаемые, встала задача - передать небольшие объемы информации (до сотни) байт через GSM-модем. Обмен двусторонний, время - случайное как в ту, так и в другую сторону. Контроллер АТМЕГА 16 или 32. Подскажите, плиззз, где копать.

Многие GSM модемы имеют встроенный TCP/IP стек. В этом случае задача сводится просто к тому, чтобы проинициализировать модем AT командами и закормить ему необходимые данные. Я пользовал Simcom SIM300A - остались только одни положительные впечатления. Думаю, что для вашего случая такой режим передачи данных будет идеальным.

 

Здесь на форуме активен господин CADiLO - у него можно проконсультироваться более детально, а может даже и попросить документацию.

 

Если у модема встроенного стека нет, то у него по стандарту (?) должен быть эмулятор стека PPP. Вводится он в этот режим чем-то на подобие AT*99#<CR> - в этом случае модем начинает воспринимать входные данные как PPP, выцепляет из него IP трафик и передает уже сами данные через сеть.

 

BTW, для передачи даных по GSM надо сконфигурировать GPRS соединение. В некоторых случаях это может быть несколько сложно.

[Philips SAA7134 и черно-белое изображение]

Есть Philips SAA7134 и есть под него некий драйвер. Сначала при отладке я использовал источники цветного сигнала стандарта PAL - видео декодер всегда генерил прерывание по каждому изменению своих синхронизационных PLL. После того, как вся система начала подавать признаки нормальной жизни я заменил источники цветного сигнала на черно-белые и тут все развалилось. Оказалось, что Philips не генерирует прерываний при захвате черно-белого видео сигнала.

 

Philips support молчит уже неделю. Сначала попытались сказать, типа вы не правильно настраиваете видео декодер. Потом после уточнения значений регистров сказали, что все верно и пообещали передать вопрос по инстанциям. Похоже, ответа от них я не дождусь

 

В принципе, с черно-белым изображением можно работать посредством постоянного опроса статуса чипа - так что-то получается, но несколько падает фпс по сравнению с цветом и изредка наблюдаются сбои в синхронизации. Особенно жестко это проявляется при смешении цветных и черно-белых источников на одном чипе.

 

Народ, я что-то не так делаю, или это его фирменный глюк самого SAA7134?

[Ворос про сумматоры]

Стандарт не предусматривает, вся математика в библиотеках, которые вы и подключаете!!!!! кстати рекомендую внимательно прочитать хидеры библиотек STD_LOGIC_ARITH; STD_LOGIC_UNSIGNED; и сравнить их с хидером библиотеки numeric_std. узнаете много нового!

В общем-то я о том же. По вашему совету сравнил хидеры библиотек и значительных различий не нашел. Да, numeric_std имеет более широкий спектр реализуемых операций, возможно и симуляция проекта на основе этой библиотеки будет идти быстрее, однако мне в повседневной жизни хватает этих трех выше означенных. Схемы написанные с их использованием нормально синтезируются как Quartus так и Synplify. А писать CONV_INTEGER() или TO_INTEGER() в общем то дело привычки.

[Ворос про сумматоры]

Стандарт VHDL не предусматривает никаких математических операций над типом std_logic_vector.

Стандарт может и не предусматривает, однако при подключении вышеозначенных трех библиотек и при синтезе Synplify STD_LOGIC_VECTOR's складываются, вычитаются и умножаются просто "на ура".

 

То есть в моем случае для сложения 2-х 8-ми битных числа(они беззнаковые) нужно их "переделать" в два 9-битных с нулем в старшем разряде - я прально понял?

Угу.

[Ворос про сумматоры]

Схеме сумматора абсолютно параллельно какие вы числа складываете. Она, схема, ничего не знает ни о типе ваших данных ни о их разрядности. Потому, если есть возможность получения девятого бита при суммировании, это необходимо учитывать отдельно, дополняя числа с левой стороны знаковым битом для знаковой арифметики или нулем для беззнаковой.

 

Конвертить STD_LOGIC_VECTOR в INTEGER для проведения арифметических операций совсем даже и не обязательно. Подключив нечто из системных библиотек арифметические действия над STD_LOGIC_VECTOR получаются автоматом.

 

И еще вопрос насколько корректно (и эффективно) для синтеза тройное складывание т.е. А<=B+C+D ???

Ответ на вопрос перекликается с первой частью поста. При двух сложениях получится два лишних бита, а это значит, что каждый из операндов надо расширять на два бита. В то же время, если выполнить сначала B+C, а потом к результату добавить D, то первый сумматор будет все же немного короче, а значит быстрее. В то же время с точки зрения синтезатора операция абсолютно корректна и синтезируема.

[Xilinx Spartan 3. Почему?]

А вы в качестве аргумента приведите критерии стоимости чипа, рабочей частоты проекта и разумной достаточности по ресурсам. Думаю, что такое обоснование препода должно устроить.

[Кто в Киеве может паять качественно BGA корпуса?]

Просто любопытно, какие были проблемы, если не секрет?

Да какой из этого может быть секрет? Просто неравномерно нагрели корпус и половина ног имела плохой контакт. Надавить микросхему пальцем - работает, отпустить - не работает или сбоит.

 

А еще заказывали партию обычного монтажа - не BGA. Так они сумели при пайке пожечь танталовые конденсаторы и запаять "по ошибке" PLCC-84 на посадочное место PLCC-48. Я видел эти платы и понять как такое можно было сделать просто не могу.

 

 

Свою отладочную плату паяли на Симметроне - все получилось очень хорошо. Правда не знаю, если они сейчас оказывают такие услуги.

[Деление чисел (VHDL)]

Почитать можно у Уорена младшего - Алгоритмические трюки для программистов. Там более-менее все расписано для 32 битной арифметики. А из собственного опыта - необходимо просто проверить весь диапазон входных чисел на соответствие результатов умножения на обратное результатам деления и все. Если результат не соответствует - просто увеличить разрядную сетку для обратного.

 

BTW, вычисление обратного для случая нормирования в 16-ти разрядной сетке: reciprocal = 65536 / divisor + 1. Без "+1" результат получается неправильным для большинства частных. В результате имеем: A / divisor = A * reciprocal / 65536 = (A * reciprocal) >> 16. При такой замене результат получается точным если A в диапазоне 0..2048 и divisor в диапазоне 1..64. Возможно, я заузил поле точных результатов, просто шире проверять необходимости не было. Хочу еще обратить внимание на такой пустячок - числа должны быть положительными. Для работы с отрицательными числами надо использовать особые премудрости.