1891ВМ12Я

Пройдет буквально 2-3 года, и Ваши схемы будут настолько сложны, что вопрос, почему даже для тех сравнительно простых схем вот уже 40 лет назад был разработан первый HDL язык... Единственное место где графическое описание имеет хоть какой то смысл, это block design для проектов ПЛИС, но и то - только на самом верхнем уровне, где используется автоматизация подключений шин и их верификация.

Не сочтите за глупость, но... а маркировка на чипах одинаковая? Понимаю что такое редко бывает, но всё же. Сколько вообще чипов у каждой ПЛИС? Совет перепаять всё же очень очень хороший. Рентгеном контролили шарики?

Я бы начинал с изучения HDL языка, например http://www.asic-world.com/verilog/veritut.html Если цель именно процессор, конвейер, кэши и так далее - сначала потребуется освоить HDL язык на достаточном уровне, и тогда работа над процессором пойдет уже мягче и успешнее.

Некий промежуточный модуль, у которого две и более пары SDA/SCL, и вручную явно управлять этими значениями, как одна линия влияет на другую. Еще вот можно встретить что SDA линию разбивают на in/out и на третий сигнал enable, то есть внешний буфер. С целью отладки и для гибкости. Пример нештатный ситуаций, например внезапный обрыв пакета, внезапный repeated start, неверный уход в состояние sda=1 scl=1 не похожее на stop. Как пример.

На первой картинке в этой теме пример шины cq и там поднят tvalid, и данные меняются как раз после опускания tready, и висят в таком состоянии пока не получится следующий tready. Какие правила это нарушило? Добавлено: да, заметил на скриншоте, меняются данные дальше, не висят как должны.

Посмотрел код, поверхностно. Вижу что стандартные блоки BRAM не применяются, просто как массивы регистров, хотя я вериложник и VHDL не сильно понимаю, type mem_array is array - вот это и есть массив памяти? Есть ли возможность нарисовать на бумаге структуру этой разработки и сфотографировать в эту тему (обычно просто на бумаге рисовать удобно и легко фотографировать). Я бы делал 1 центральную часть, и две боковые - одна на стороне записи, вторая чтение. И так, мне видится, пусть было бы не круто как у оригинальных FIFO, с огромным latency, но имея центральную часть на частоте одной из двух частей, было бы сравнительно просто. Склоняюсь к частоте именно со стороне записи, потому что если чтение не получит данные это не беда, а если захлебнется сторона записи - хуже. Я бы нарисовал реально на бумаге структуру, может кто то увидит как всё взаимосвязано и поможет.

Раз уж тема всплыла, я в таких ситуациях очень часто просто делаю комментарии специальные, как был совет выше, и травлю код в питон-скрипт, он меня и разрядности извлечет, и все строки со спец комментом и так далее. Не стесняюсь чуть подзамарать код спец-комментариями ради скриптования :)

Если не секрет, а разве PULLNONE не есть значение по дефолту? Всегда полагал неиспользуемые как z-state.

Тестбенч он как программа, я бы написал свою function swap_endian. Я когда то путал значение термина big/l-endian ведь тут же речь про порядок байтов, а не направление хода битов? Байты переставлять, а не зеркалирование битов? Или я ошибаюсь.

Как невозможно? Давайте делать, попробую подсказать. Надо поставить что то посерединке. Так то если цеплять напрямую, тогда конечно, не увидеть что же задрайвило линию в текущее состояние. Ну и в тестбенче я бы помучил модуль какими то нештатными ситуациями и реакцией на них - сразу вылезет тонна.

Уточните пожалуйста, это самодельный FIFO? Дело в том, что я быть может ошибочно, применяю штатные FIFO ради устранения необходимости писать свои правила XDC. Или у AXI FIFO из стандартного каталога какие то иные условия? Всё же, если речь про самодельный блок, это хотелось бы особо отметить.

Вы правы. Мне удалось найти причину проблем, я отложил это на пол года потому что были более срочные задачи. И вот я, плотно сел за проблему, и нашел причину. Это была неправильная с моей стороны работа в логике приема пакетов, а точнее детектирования прихода нового пакета, и неверный способ throttling-а принимаемых пакетов. В итоге я просто пропускал пакеты, когда они были склеенные, то есть когда изредка прилетало два пакета строго один за другим. Это работало в 99.9% случаев и казалось существующая логика не содержит изъянов. Неверно было понято назначение и принцип работы с сигналом tready, который я бы назвал t_ack.

Какая версия Vivado? Пришлите zip/tar архив с тестовым проектом, в котором наблюдается проблема. Я обычно в таких случаях делаю отдельный проект, чтобы изучить блок. Скажу что симуляция там работает достаточно хорошо, чтобы сожрать в симуляторе поток от JESD из файла, сформированного вообще от передатчика альтеры других ПЛИС

Снова потребовалось деление на два xpr+xdc, чтобы ничего вручную не менять (на двухсотый раз может возникнуть ошибка). Оказывается, надежное решение было рядом. Project Settings -> General -> Verilog Options и плюсиком добавить желаемый define с пустым полем value. Таким образом, оно реально понимает это как глобальный define и auto-disable уже не выкидывает файлы и под-модули. Надеюсь кому то пригодится это маленькое открытие. То есть, не synthesys options, а немного в другом месте.

Ох, я давно потерял все доступы, и это пока никак не мешает. Забавно, особенно это. На самом деле если полностью скачать инсталлятор, и не удалять файлы после распаковки, то сайт не требуется для доустановки компонентов. Более того, найдя в каталогах vivado в каком то файле пути, откуда оно хочет файлы для установки, я спустя пару лет вывалил туда файлы и оно снова увидело их для установки без интернета. Проблема конечно когда нужен доступ к документации. Если делиться опытом, то обычно пытаюсь найти на сторонних левых сайтах, обычно документация лежит не только у xilinx. Какой документ нужен автору темы? Установка чего? Vivado/Vitis? У меня интернет открыт и оно ничего все равно не пытается. Нужен полный инсталлятор, где 100% всего есть, всех компонентов.

Я бы использовал Modelsim Altera Starter Edition. Потому что, как верно выше заметили, когда появится элемент памяти для двойной буферизации или большого FIFO, то уже может не получиться подключить модель элемента блочной памяти в Icarus Verilog. Но мысли "а не задействовать ли симулятор" - очень правильные, точно быстро найдете причины проблем, если они в логике а не сбоях модуля камеры как такового.

Почитал что за камера и что выдает https://habr.com/ru/articles/283488/ Мысль номер раз: я бы сделал симуляцию с этим форматом, в точности выставив все тайминги. Такое можно отладить в симуляции, тестбенч генерирует сигнал, и смотрим как отрабатывает модуль в симуляции, правильно он ловит кадры, с какой частотой ловит, успевает ли, есть ли затыки и провалы потока и прочее. Я так SDI отлаживал, а то что на картинке похоже отдаленно на BT-656, но не суть. Тестбенч можно не только для симуляции приспособить, а как встроенный само-тест с теми же самыми полосками, то есть синтезируемый. И переключать между реальным источником из вне и этим встроенным генератором изображения в формате таком же как у OV7670. Ну и счетчики можно кинуть какие нибудь в UART, точно ли между HREF и прочими сигналами нужное время, считать число таких импульсов в секунду и тоже выводить в UART. Я обычно заморачиваюсь на UART и кидаю в него события с некоторыми заголовками через FIFO, что помогает отлаживать всё, в том числе события с timestamp - UART это сила (но можно и signal tap).

Проблема решена!!! Оказалось неверный компонент! Была маркировка d9wfh - искали с коллегами что это может быть, в документации на память пусто, в интернете зацепились что это Micron и что это из серии MT40A***. Чип отличается от того что указан в схеме. Подумали, ну раз заменили, наверное с той же геометрией, иначе ведь нельзя. На сайте пишут: 5 чипов и всего 2.5 гигабайта, то есть 4 гигабита на чип. Ну ясно, подумали, точно заменили на аналог той же геометрии. Лишь потом нашли вот такой раздел сайта: https://www.micron.com/support/tools-and-utilities/fbga?fbga=d9wfh#pnlFBGA и оказалось - а чип то другой, MT40A512M16LY-075 а не MT40A256M16* И уже под конец нашли в документации упоминание MT40A512M16JY-075E, тоже отличается от того что напаяно, но хотя бы геометрия правильная. После этого всё заработало, сотни тысяч циклов и ноль сбоев и ошибок. Однако на самодельной плате хрень какая то остается. Будем на ней высматривать код маркировку и подтверждать. Есть шанс что там геометрия верная но тайминги не те, и поэтому хоть и с гораздо меньшим числом сбоев, но работает. Мораль: не смотреть на схему, не смотреть на сайт, и даже документацию. Смотреть только на реальные маркировки чипов и пытаться их расшифровать по документации или сайту производителя... Стыдно мне.

Разработчики самодельной платы это очень учитывали, моделировали, считали, старались изо всех сил. Раньше это работало, но на новой системе оказалось PCI работает со сбоями уже. То есть, возможность проверки того как было - она трагически оборвалась. Я выяснил новое - у меня всегда проходит калибровка, но когда я стал делать самостоятельные запросы рефреша каждую 512-ю итерацию я смог добраться до пары тысяч итераций без сбоев. Когда я еще больше увеличил итерации и при каждой 256-й рефреш - я смог добраться до 6-8 тысяч итераций без сбоя. Когда не делаю ручные запросы рефреша - сыпятся подтверждения (контроллер сам делает рефреш но почему то говорит мне об этом). Когда я прошу рефреша - sref_ack не приходит вообще ни разу. Но число итераций без ошибок увеличивается. О чем это может говорит - я не знаю. Может паузы добавить. Не должно оно так работать, на Kintex-7 всё было точно так же - калибровка прошла и дальше миллионы и миллиарды циклов без сбоя.

У меня вот другая проблема была с Cyclone V. Altera Blaster первый работал только с одного компьютера в офисе, операционная система оказалась ни при чем. Когда купили Blaster V2 - сразу стало нормально шить. А ранее - не определялось даже или определялось раза с 30-го, причем схема была на 100% верная. Вряд ли банк сгорел

Температура низкая - ниже 40 градусов, проект заполнен на 5%, беру от мощного источника питания где 6-pin разъем для видеокарты - он превышает потребность отладочной платы при ее максимальной загрузке. Я обнаружил парадоксальную вещь в тесте ddr (стандартный), я его уже обложил светодиодами и UARTами, как только число итераций теста превосходит 740 и становится 750 - всё, идет сбой теста. У меня возникает подозрение что несмотря на опору на ready сигналы, случается рефреш и всё валится. Пробовал ставить manual refresh и соотвественно тест управляет этим сам. Завтра попробую изменить хотя бы немного, сделать это чаще, найти место где управляется manual refresh через специальный порт. Я всегда полагался что рефреш делается сам, и когда оно занято этим, то я просто не получаю свои рэдики и всё становится на паузу пока не отрефрешится. Ранее меня это не подводило, но я уже подозреваю именно рефреш, очень подозрительно точная граница числа тестов с ошибками и без, но радует что все эти 740 транзакций проходят без сбоев, а там много циклов по 512 бит полных. Хоть 20 хоть 30 раз делаю сброс - оно калибруется и запускает тест заново - все 30 раз оно пройдет тест с 740 циклами. А например 750 уже нет хоть 20-30 раз сбрасывать. Вероятно существует плавающая граница между 740 и 750 числом итераций теста.

Сейчас я пытаюсь работать с максимально облегченным проектом. И тогда и сейчас стандартный ddr example (генерируется ядром) берет не более 5% ресурсов. Я заметил что если оставить стандартные для теста 100 итераций или даже сделать 500 итераций (вижу что там есть лимит счетчика, его легко можно расширить до 32 бит) - вот 100 и 500 итераций - тест проходит. Заливаю заново - снова тест прошел. Проблема начинается тогда когда итераций несколько тысяч, при том что в симуляции мой тест может успешно пройти все эти, скажем 125 тысяч итераций, стало быть логика верна, а реальная память такой тест не проходит. Даже если делать 16 битный интерфейс (чипы по 16 бит), похоже все микросхемы DDR4 памяти ведут себя одинаково. Понижение частоты не помогает, тайминги и так занижены до невозможности, задержки не помогают. Вот мысль - корректно ли создать свои параметры для памяти? Custom, я уже изучал их формат это CSV файлы. Что если задать больше задержки и больше паузы? Или память не примет что либо, выходящее за ее рамки, заданные в даташитах? Очень боюсь внести путаницу, отладочная плата HTG-800 проверялась только стандартным тестом - калибровка проходила и малое число итераций не выдает ошибки, проблема когда итераций много, значит стандартный тест ложный, не выдерживает буквально несколько тысяч чтений (а мне надо миллиарды). Впрочем и сейчас, даже в штатном проекте, когда мало итераций - все записи и чтения могут быть без ошибок. Вся беда в стабильности работы. Тесты - они быстрее пересобираются, и выявляют те же проблемы. Попробую собрать старый проект и вернуть программную часть. Однако в рабочем проекте по этой части ничего не менялось. И боюсь что проблема проекта уже в PCI - там тоже проблема с которой я бьюсь, на новом процессорном модуле стал шалить PCI и я не могу работать по старому и не могу работать со старым битстримом. Самодельной платы у меня нет, ее забрали как раз. Проверить старое рабочее это правильная идея, но и она проблематична из за других сбоев и из за сбоев аналогичных в памяти. Я не могу там UART попросить подключить для отладки - там невозможно. Плохо...

Да, такая комбинация существовала, и для HTG-800 и для самодельной платы, то есть комбинация на которой работало. И я не понимаю почему сейчас перестало, как я подозреваю, читать память без ошибок. Не верю что сразу две платы сломались - это нереально. Пробовал еще сейчас натравить XDC на ddr example сгенерированный - код писали умные люди, а он не заработал на HTG-800 и показал read corrupted на светодиоде. Пробовал делать Block Design с AXI интерфейсом к контроллеру - мало ли я неверно как то работал. Снова не так. Пробовал понижать частоту на самый минимум до 625/633 МГц - не помогло. У меня была еще плата на Kintex 7 официальная, так там была битая память и явно не проходила калибровку - дело ясное. Но у меня сейчас обе платы и HTG-800 и самопальная - обе калибровку проходят. Значит интерфейс верный и рабочий. Тайминги все идеальные, использую FIFO и XPM-CDC а значит задано верно всё везде. Может что то в XDC нужно указать иначе? Попробую тактовый сигнал иной указать как источник для DDR - есть второй генератор 200 на плате. Установил Vivado 2023.1 и его попробую - может вивадо со сбоем что то генерить стала, но я пробовал и вивадо 2018.2/3 на которых когда то работало... Если решу проблему - обязательно тут напишу. Но смущает одно - калибровка то проходит! Где тогда не так, если официальный экзампл даже валится при всей его проходимости калибровке (вижу на светодиоде). P.S. Важно, что на самодельной плате, и 512 бит, максимум ошибок приходится на первые 32 бит в остальные ошибки около нуля - самодельная даже лучше работает если это можно назвать работает. На HTG-800 выбито чуть больше половины шины данных, но в начале и по краям ошибки минимальны. Сколько я ни пытался разводить прошивок - локализация сохраняется. Может надо как то дополнительно навернуть каких то XDC правил?

Делаю тест для двух плат. Первая - отладочная плата HTG-800 трофейная http://www.hitechglobal.com/boards/kintex-ultrascale.htm Вторая плата - уже самодельная. Тоже на Kintex UltraScale На первой покупной были сбои и устранили их тогда, когда осознали что на плате напаяны НЕ ТЕ компоненты что указаны в схеме и используются в тестовом проекте и тогда заработало. На самодельной плате заработало полтора года назад тоже и сразу. То есть схемы проверены. Трагизм ситуации в том, что я не могу понять что я делаю не так, когда переделываю проект заново. Я все уже перебрал варианты. Вижу что записав раз, а потом только читая, я вижу что иногда число ошибок снижается. Значит я точно теряю на чтении. Я нашел что в тестовом примере применяется промежуточный регистр для данных и строба валид - только что проверил с точно таким же дополнительным шагом без дополнительных условий и это не помогло. Сейчас попробую натравить XDC примера на отладочную HTG-800, вдруг я забыл что то делать то, что делает пример. Визуально по коду пока не видна ошибка.

Использую Kintex UltraScale XCKU-040 и -060. На обоих наблюдается проблема, которую я раньше не видел, то есть повреждение памяти физически я пока что исключаю. На обоих платах 64 битная память DDR4 которую я пытаюсь использовать на частоте 625, 666 и 800 МГц, стараюсь брать поменьше частоту. Наблюдаю следующую проблему. Пишу некий паттерн (счетчик) из 32 битных слов, сама шина контроллера памяти wdf (использую native интерфейс) - 512 бит. Слова такие 32'h0016_0000 .. 32'h0016_000F, для следующих 512 бит уже 32'h0017_0000 .. 32'h0017_000F, то есть вижу четко что писал и могу понять верно ли оно просто по адресу. Проблема: как пишется не знаю, но читается не всегда верно, причем из 512 бит шины контроллера native, может быть несколько слов иметь практически всегда ошибочные данные, а некоторые части этих 512 бит имеют наоборот очень низкое число ошибок, но никогда не нулевое. Пробовал не записывать а просто читать записанное, то есть записал 1 раз и далее читать по несколько раз. Удивительно, при повторных чтениях число ошибок может даже уменьшаться, но при чтении результаты в целом повторяются, большинство сбоев локализованы в одних и тех же местах. Вероятно чтение неверное. Документация четко говорит - данные валидны только при app_rd_data_valid - приходит строб и я беру данные по нему. Ошибок таймингов в прошивке нет. Что я пробовал: 1) делать тест с отдельным модулем MIG и простым конечным автоматом читать-писать в цикле и выводом в UART 2) пробовал ставить другие совместимые компоненты памяти не 075 а например 083 и 107 спид грейдом 3) пробовал режимы no dm без маски 4) пробовал понижать частоту памяти 5) пробовал задавать побольше тайминги DDR 6) создал проект на базе microblaze и block design чтобы работать с памятью из microblaze по шине AXI - вдруг причина была в этом 7) пробовал играть с резетами - может это и причина но я упустил что то? Что еще можно попробовать, как устранить проблему что чтение идет со сбоями? Калибровка то проходит успешно, значит явно я делаю что то не так, но я уже несколько недель с этим борюсь и не понимаю почему "раньше я умел" а сейчас талант работы с DDR покинул меня... Тайминги - вручную не баловался не менял, всё через FIFO или XPM_CDC. Планирую еще раз запустить моделирование (давно делал). Посмотреть что с app_wdf_end сигналом - я ставлю 1 при каждой записи - корректно же? Пишу ведь рывками, единичными по 512 бит и не более того.