[1891ВМ12Я 0]

4 hours ago, kamil_yaminov said:

Первая попавшаяся по запросу "micron ddr4 system verilog model" ссылка https://www.micron.com/products/dram/ddr4-sdram/part-catalog/mt40a2g4trf-093e, на странице по ссылке справа вкладка Simulation Models. Но, насколько помню, модель должна поставляться "в комплекте", при генерации example design? По крайней мере так было с DDR3/

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

 

Действительно, зашифрованная модель предоставляется для разных симуляторов, и для Xilinx Vivado симулятора я беру ихнюю модель из example design. Но этот архив как я надеюсь поможет мне немного понять какие есть таски и как они называются, какие параметры, может хэлп какой нибудь там найдется.

[1891ВМ12Я 0]

On 10/12/2021 at 5:27 PM, RobFPGA said:

Вы бы  целиком привели диаграмму записи и последующего чтения с указанием имен сигналов. А то гадай на зеленой гуще что тут и куда  

Сегодня также осуществил тест на реальной чужой плате, там DDR3, тоже странности подобного рода, расхождения числа команд и чтений. Снова вернулся к модели Kintex UltraScale и DDR4. Вот что получается:

Пишутся слова 00000005 06 07 и так далее, начиная с 5. Видно что я подаю данные на запись только тогда, когда контроллер готов принять данные от меня. Тут всё корректно. Пишу 7 слов. Сейчас работаю с 1 чип 16 бит, шина данных 128 бит. А вот что получается при чтении:

Сначала появляется 05, а в конце строб app_rd_data_valid. Затем следующее слово, прекрасно. Выдается слово 09, а затем битое слово из сплошных FF, так модель памяти говорит что ничего никогда не писалось в такую ячейку, но строб валидности есть. А дальше 0A слово, что верно, но оно не на своем месте, оно не правильное, на том месте уже нужно видеть 0B, но его уже не суждено увидеть.

 

Это я уже перешел на 16 битный интерфейс к памяти, чисто на 1 чип, думал это поможет, но всё в точности так же, просто вместо 512 бит я вижу 128. Сбой полностью воспроизводится. Принципиально не понимаю что делают не так, что я мог не соблюсти.

 

pg150-ultrascale-memory-ip.pdf Ориентировался на "Figure 4-4: 4:1 Mode User Interface Back-to-Back Write Commands Timing Diagram (Memory Burst Type = BL8)" и "Figure 4-7: 4:1 Mode User Interface Read Timing Diagram (Memory Burst Type = BL8) #2"

[RobFPGA 27]

Приветствую!

20 minutes ago, AVR said:

Пишутся слова 00000005 06 07 и так далее, начиная с 5 ... 

А калибровка у вас в симе отрабатывает? 

 

Удачи! Rob.

[1891ВМ12Я 0]

8 hours ago, RobFPGA said:

А калибровка у вас в симе отрабатывает? 

Да, калибровка в модели (vivado sim) и на живой плате - всё правильно, статус что калибровка прошла - успешен. Работу с app_ и app_wdf_ как в документации я вроде делаю. Моя аксиома - число N запросов чтения при app_rdy == 1 должно порождать в точности N результатов чтения. Если это не так, тогда мне трудно поверить в этот бред, тогда всё на что я полагаюсь - рушится.

[RobFPGA 27]

Приветствую!

14 hours ago, AVR said:

Моя аксиома - число N запросов чтения при app_rdy == 1 должно порождать в точности N результатов чтения

Ну это как раз и выполняется.  На диаграмме 7 запросов - 7  app_rd_data_vld.    Вопрос лишь в результате чтения 
A тут  скорее  всего  у вас проблемы с записью.  Что  я  вижу на диаграмме -
Первые  5  записей все ок. 
6-я запись, addr=320, команда записи НЕ происходит! - поскольку нет момента кода одновременно и app_en==1 и app_rdy==1. 
НО при этом данные  (0xA) для 6-й команды в буфер данных пишутся!!!  (app_wdf_en==1 && app_wdf_rdy==1)
7-я  запись идет уже по адресу 384 но при этом данные (0xA) берутся от предыдущей записи !!  Так как буфер  данных это FIFO. 

Вот и получается что при чтении первые 5 слов читаются нормально, 6-чтение 0xFF.. так как записи по этому адресу не было! 
Ну а 7-м чтением читаются вроде как "неправильное" значение 0xA..
И еще  при этом у вас в буфере данных записи осталось "лишнее" слово от 7-й записи которое будет давать ошибку (сдвиг данных) для всех последующих  записей.  

И ни каких  чудес ... 
  
Удачи! Rob.

[1891ВМ12Я 0]

On 10/16/2021 at 12:46 AM, RobFPGA said:

6-я запись, addr=320, команда записи НЕ происходит! - поскольку нет момента кода одновременно и app_en==1 и app_rdy==1

Это иллюзия, создаваемая симулятором, на самом деле, в момент когда решается записывать или нет, срабатывает условие app_rdy & app_wdf_rdy. В том то и беда, я всё делаю правильно.

[RobFPGA 27]

Приветствую!

5 hours ago, AVR said:

Это иллюзия, создаваемая симулятором, на самом деле, в момент когда решается записывать или нет, срабатывает условие app_rdy & app_wdf_rdy.

  При  чем тут сигнал готовности принять команду (app_rdy)  к сигналу готовности принять данные записи (app_wdf_rdy)? 

Это 2 независимых канала  -  app_en && app_rdy  канал команд,  app_wdf_wren && app_wdf_rdy  канал данных для записи.   
Единственна связь между ними так это то что данные  для записи должны быть записаны в буферное FIFO  раньше, одновременно или не позже чем 1 такт (или 2 такта сейчас не помню точно) соответствующей команды записи. И только.
Но все каналы работают только когда оба соответствующих каналу управляющих сигнала равны 1-це. 
 

Поэтому странно слышать про какую-то "иллюзию". 

Удачи! Rob.

[1891ВМ12Я 0]

1 hour ago, RobFPGA said:

Это 2 независимых канала  -  app_en && app_rdy  канал команд,  app_wdf_wren && app_wdf_rdy  канал данных для записи

Да, это понятно.

1 hour ago, RobFPGA said:

Но все каналы работают только когда оба соответствующих каналу управляющих сигнала равны 1-це

Завтра выложу код. Смотрите, когда мы переключаемся на адрес 320 - значит app_rdy было равно 1 и оно успешно скушало 0A. Но к следующему циклу app_rdy был не готов 2 такта и оно ждало. Затем за 1 такт до 0B, когда контроллер памяти что то отработал внутри себя, он вдруг стал готов, и к следующему моменту оно успешно отработало запись 0A и переключилось на 0B. Затем 0B был готов и успешно записался, и уже после записи 0B контроллер сказал что он снова не может больше, но там уже не важно.

[RobFPGA 27]

Приветствую!

19 hours ago, AVR said:

Смотрите, когда мы переключаемся на адрес 320 - значит app_rdy было равно 1 и оно успешно скушало 0A.

Еще раз  - причем app_rdy  к данным? 

  
В момент переключения на адрес 320 (надеюсь положительным фронтом clk) происходит запись предыдущей команды - 
app_cmd = 0x0, app_addr=256, app_en && app_rdy,   app_wdf_data=0x9,  app_wdf_wern && app_wdf_rdy. После записи этой команды app_rdy  снимается. 
Вы выставляете следующую команду  app_addr=320, app_en=1,   app_wdf_data=0xA,  app_wdf_wern=1.
На следующем фронте clk  данные  пишутся (app_wdf_wern && app_wdf_rdy), а вот команда нет!.  Вы видя что app_rdy ==0  должны были удерживать значение  app_cmd,  app_add,  app_en=1  и ждать когда эта команда  подтвердится app_rdy=1.

 

Эта  "секретная" комбинация описана например в PG150 UltraScale Architecture-Based FPGAs Memory IP v1.4   
И даже словами объяснили как трактовать  комбинацию  app_en и app_rdy 

Удачи! Rob.

[1891ВМ12Я 0]

2 minutes ago, RobFPGA said:

Вы видя что app_rdy ==0  вы должны были удерживать значение  app_cmd,  app_add,  app_en=1  и ждать когда эта команда  подтвердится app_rdy=1

Кажется до меня дошло, благодарю за Ваше терпение! Завтра утром проверю!

[1891ВМ12Я 0]

On 10/17/2021 at 6:00 PM, RobFPGA said:

Эта  "секретная" комбинация описана например в PG150 UltraScale Architecture-Based FPGAs Memory IP v1.4 И даже словами объяснили как трактовать  комбинацию  app_en и app_rdy 

Огромное Вам космическое спасибо, применил эту логику для записи и для чтения (там тоже потребовалось так подтверждать команды). Это конечно кривовато всё кажется, не правильно. Тем не менее, я добился 100% надежной записи и чтения, всё совпадает и по числу команд и результатов, и вообще всё надежно. Получается я зря напраслину гнал на микроновскую модель...

А вот app_wdf_rdy похоже всё таки сигнал готовности "здорового человека", но если будут и с ним проблемы, то я тоже буду внимательно тайминги изучать.

[RobFPGA 27]

Приветствую!

1 hour ago, AVR said:

Это конечно кривовато всё кажется, не правильно.

Что ж здесь кривоватого? Есть возможность принять команду - app_rdy=1, если нет то =0.  Еще прямее уже и не сделать.  

1 hour ago, AVR said:

А вот app_wdf_rdy похоже всё таки сигнал готовности "здорового человека"

Тут та же логика что и для app_rdy - просто глубина FIFO данных больше чем для команд,  да и команды тормозятся в основном чаще из за невозможности выполнения их в данный момент, а не по заполнению. Начните  записывать данные в буфер без выдачи команд записи и тоже увидите app_wdf_rdy=0. 

1 hour ago, AVR said:

... то я тоже буду внимательно тайминги изучать.

Тайминги изучать надо до возникновения проблем  

 

Удачи! Rob.

[1891ВМ12Я 0]

  

8 hours ago, RobFPGA said:

Есть возможность принять команду - app_rdy=1, если нет то =0.  Еще прямее уже и не сделать

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

 

8 hours ago, RobFPGA said:

app_wdf_rdy

Спасибо, обращу на это внимание. Почему то из документации показалось, что для этого сигнала логика иная, там не написано про retry в таблице. Ну пусть, предупрежден - вооружен.