DDR SDRAM: Тайминги чтения сильно отличаются от спецификации Опции

[javalenok]

Я взял модель DDR400 у самсунг. Она восприняла мой write правильно. На всех частотах. Я вижу что и данные в read выходят правильные вместе с DQS. Однако когдА они выходят!

Я ожидаю что-то вроде этого


После периода RD, идёт низкий строб. Это два периода. После них, вместе с появлением данных, строб начинает повторять clock. Видите?

У меня тоже CL=2. Однако в симуляции строб опережает свой такт


Вместо периода ожидания через 4 ns после RD начинается вывод данных. Период ожидания начинается не после того как мы клокнем команду RD передним фронтом, а более чем за пол такта до того. Как работать с такой фигнёй? Тут даже частоту не снизишь!?

PS! Когда всюду и у них в модели я вижу что DQS не должен убегать от CLK:

Код

`define tAC         0.7    // Output data access time from CK/CKB (min:-0.7, max:+0.7)

Модель показывает 4 ns спереди и соотв-но 6 ns сзади. Они сами в своей модели не исполняют спецификации!

Сообщение отредактировал javalenok - May 15 2011, 13:50

[Kompot]

Я взял модель... Она восприняла мой write правильно. На всех частотах. Я вижу что и данные в read выходят правильные вместе с DQS. Однако когдА они выходят!

Все упирается в достоверность моделей и вашего тестбенча.

В даташите - правильно. Ибо DQS при чтении точно повторяют входной клок - там в микросхеме памяти встроенная PLL есть. А на вашей симуляции он раньше появляется ИЗ памяти. Вот и покопайте вашу модель от Самсунга на предмет как там НА САМОМ деле генерируется DQS.
Вообще говоря,

А вот то, что данные появляются выровненными с DQS - это хорошо.

И напоследок. Чтобы на самом деле была польза от вашей симуляции, не забудьте в тестбенч добавить задержки всех сигналов от контроллера до памяти (сначала промоделировав в HYPERLYNX). Увидите много интересного.
И напоследок. Особое внимание уделите симуляции задержи ОБРАТНОГО сигнала (от памяти до контроллера). Я так и не осилил. Пришлось вводить параллельный однонаправленный канал данных и DQS на чтение, делать в нем after 2nS, а коммутацию шины данных осуществлять внешним "лишним" сигналом. Вот так вот.

Удачи.

[javalenok]

У меня на 200 МГц нормально работает, даже без DLL (хотя с ДЛЛ на 20% окно валидности шире). Просто откалибровал его положение (три отдельных домена - сперва отдельно чтение, адрес с командами, потом запись) и самплю в наилучший момент. Никаких стробов на приём действительно не нужно. Зачем они предлагают читать по DQS во всех своих аппнотах? Вот например знаменитый PLB Double Data Rate (DDR) Synchronous DRAM (SDRAM) Controller. И стробы и внешняя ОС для клока. Я где не срашивал, мне везде отвечали "это важно использовать чтобы meet timing". Никто похоже не знает.

С VHDL действительно проблема в двустороннюю линию задержку ввести. Просимулировать удалось переключением напарвлений сперва прослушиванием команды (чтение или запись), а затем автоматически, при помощи такого вот хитроумного коммутатора, который направление сам определяет. Во время z-состояния на линии смотрит куда ветер подует, в том направлении и берётся ретранслировать с задержкой, пока источник не утихнет. Это работает поскольку любое переключение направления должно сопровождаться перерывом, когда оба драйвера молчат.

Сообщение отредактировал javalenok - Aug 17 2011, 06:16