AVR

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

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

А почему operation == зачем два равно? Еще подозреваю нужно PV а не pv, это может оказаться важным. --operation==pv;vga.pof

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

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

Да, спасибо за ответы. Всё как я и предполагал. А синтезируемость в базисе ПЛИС действительно проверяю на стадии синтеза САПР.

Симуляторы например Modelsim и не только он, позволяют в тестируемом модуле писать хоть #100 хоть a <= 1; a <= 2, но есть ли возможность это как то ограничить? Включить некоторый strict mode? Чтобы начинающие не пытались учиться, вставляя туда черти что, а по факту оно работать не станет в ПЛИС. Или тут надо лишь заставлять компилировать в САПР для некоторой ПЛИС?

Попробуйте без кавычек, это важно.

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

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

Сегодня также осуществил тест на реальной чужой плате, там 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"

А если в текстовом логе посмотреть? Ведь на экране то оно может тереться, а в текстовом логе никуда не денется. Коллеги ниос ковыряют, у них тоже это пропадает, ничего не настраивали чтобы не отображалось.

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

А где именно качать? Я находил темы англоязычные, там пишут типа найди любую модель, выбери ее, оттуда качать zip файл. Но я все вкладки даташиты модели - всё обсмотрел и не вижу verilog модель. Как файл называется, какой раздел?

По идее есть там тестбенч traffic generator, и оно в симуляторе успешно проходит. Однако да, иногда оно фейлится, не проходит свой же тест, но очевидно что это гораздо лучше чем у меня, а может у меня воспроизводится в силу каких то причин. Но сам факт разного прохождения теста от запуска к запуску меня настораживает. Спасибо, это интересная подсказка. В самом деле, я ведь могу вычитать интересующие адреса из модели напрямую, не обращаясь к MIG. Чтобы как минимум узнать, а правильно ли я записал. Пока что не нашел таски для чтения... UPDATE: Таски memory_write и memory_read мне удалось найти лишь в ddr3_model.sv однако ddr4_model зашифровано, и никаких заголовков и документации найти не удалось, буду конечно пытаться предполагать что эти таски совпадают по параметрам с учетом моих настроек и ширин. Как ни странно, я замечал это, но почему то не придал этому значение, попробую пересмотреть, но сначала проверю что записалось. Что интересно, ведь данные то читаются нередко правильно, неужели оно может в тех же условиях записываться правильно, и тут же - не правильно.