[javalenok 0]

Я взял модель 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 сзади. Они сами в своей модели не исполняют спецификации!

Изменено 15 мая, 2011 пользователем javalenok

[Kompot 0]

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

 

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

 

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

Вообще говоря,

 

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

 

И напоследок. Чтобы на самом деле была польза от вашей симуляции, не забудьте в тестбенч добавить задержки всех сигналов от контроллера до памяти (сначала промоделировав в HYPERLYNX). Увидите много интересного.

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

 

Удачи.

[javalenok 0]

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

 

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

 

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

 

 

И напоследок. Чтобы на самом деле была польза от вашей симуляции, не забудьте в тестбенч добавить задержки всех сигналов от контроллера до памяти (сначала промоделировав в HYPERLYNX). Увидите много интересного.

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

 

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

 

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

Изменено 15 мая, 2011 пользователем javalenok

[Kompot 0]

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

 

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

 

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

 

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

 

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

 

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

 

 

--данные ловил не по DQS. Скорость была невелика - 100МГц. А вообще моя ФПГА не поддерживала столько внешних клоков.

 

--с удовольствием послушаю, как вы ввели задержку в тестбенче в двунаправленную шину данных на VHDL.

 

-- ограничение снизу на скорость (ДДР - 85 МГц, ДДР2 - кажется 125 МГц и тд) как раз и основано на внутренней PLL.

Можно сконфигурировать память на работу с выключенным PLL, тогда она будет работать на любой (разумно) низкой скорости.

[javalenok 0]

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

А я грешным делом думал что модели от производителей нужны чтобы мы могли подкручивать СВОИ до состояния коммуникации с ними.

 

--данные ловил не по DQS. Скорость была невелика - 100МГц. А вообще моя ФПГА не поддерживала столько внешних клоков.

Подождите. Для схватывания DQ по DQS нужна 1.25 ns задержка на DQS. Какое отношение к этому имеют клоки? В FIFO данные направлять, продолжая использовать DQS как тактовый? Восьми штук (для DIMM больше не надо) хватит?

[javalenok 0]

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

 

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

Изменено 17 августа, 2011 пользователем javalenok