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]

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

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

Ковырять недостоверную модель чтобы узнать как на самом деле?

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

Я тоже решил это сделать. Но для платы (XUPV2p) у меня модели нету. Не понял чего конкретно не осилили вы, но я задержики в 3-state шину. Проблема ещё что память оказывается имеет ограничение снизу на скорость. Нельзя слишком медленно запустить, а потом ускроять. Как раз из-за того видимо что она не после CL откликается, а через 4 ns на такт раньше.

А вы как данные ловили - по DQS? Я слышал что до 100 МГц работает простой клок.

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