Поиск

В аппаратно-программной системе проблема при подаче питания. Требуется отладка. Но отладчик STM32CubeIDE отваливается при снятии с STM32 питания. Как быть?

Всем доброго времени суток, Возникла проблема с работой платы с XC7A25T-1CSG325 на материнских платах с интеловскими чипсетами 3хх и 4хх серий в слоте x16 (подключен напрямую к процессору) после ресета по кнопке. Т.е. сразу после включения питания плата определяется, линк есть, регистры платы пишутся и читаются без каких-либо ошибок и сбоев, но сразу после ресета системы по кнопке Reset или после перезагрузки системы через меню операционной системы линк пропадает и плата больше не определяется до следующего выключения/включения. При этом на той же материнской плате эта плата прекрасно работает в других слотах. Ещё более интересно, что такое странное поведение наблюдается только на одной из пяти одинаковых по схемотехнике и топологии плат, взятых из одной партии. Остальные четыре платы запускаются/работают и после ресета. При этом сбоящая плата чудит только в материнских платах фирмы MSI, в аналогичных платах на 3хх и 4хх чипсетах других производителей (например, Asus) она работает. Инструкция Xilinx по отладке проблем с PCI-E изучена от корки до корки, но никаких результатов это не принесло. С физикой проблем нет, т.к. на других мат.платах сбоящая плата работает даже через удлинитель, сделанный из кабеля USB 3.0 длиной около полуметра. Пробовал ресетить плату в проблемном слоте вручную, замыкая PERST# на землю и сразу после ресета линк пропадает и далее успешно восстанавливается. Однако если в процессе или после "ручного" ресета отресетить систему, то линк пропадает окончательно и бесповоротно. Дальнейшие ручные ресеты уже ничего не дают. Ядро сконфигурировано в режиме Gen1 (2.5 GT/s). В BIOS для слота x16 выбран режим Gen1. Это не помогает. Что ещё стоит попробовать, куда еще можно посмотреть (какие сигналы ядра)?

Доброго времени суток всем участникам, Попытавшись разместить выходные регистры данных и управления OEN в ячейках ввода/вывода у Gowin GW2A (используется Gowin_V1.9.9Beta-1 и пробовал Gowin_V1.9.8.11) я столкнулся с рядом проблем: Отсутствуют констрейнты, которые бы позволяли на уровне исходника на Verilog говорить среде, что синтезируемый триггер (регистр) необходимо разместить во встроенном в ячейку ВВ триггере. В описании архитектуры GW2A приводится следующая иллюстрация: Но при этом в библиотеке примитивов отсутствуют соответствующие примитивы для OREG/TRIREG. Есть, правда ODDR, но к нему есть свои вопросы и о них ниже. Для режима SDR ниже приводится более детальная иллюстрация структуры ячейки: При этом для входов сброса есть следующее примечание: "Local set/reset signal O_SR and I_SR can be either synchronized reset, synchronized set, asynchronous reset, asynchronous set, or no-function;". Т.е. должны поддерживаться все возможные режимы сброса (вполне ожидаемо, на первый взгляд). Однако из-за отсутствия в библиотеке соответствующих примитивов на практике в этом убедиться затруднительно. При этом у приведенных в описании архитектуры триггеров для режима DDR вход сброса отсутствует. С другой стороны в документе "Gowin FPGA Primitive User Guide", где казалось бы должны были быть описаны указанные в описании архитектуры элементы (триггеры) есть только описание регистров DDR: Причём, что очень странно, в описании портов ODDRC, для входа CLEAR указана поддержка только асинхронного режима: После выполнения PnR с настройками размещения регистров в IOB в результатах бэканнотации (нетлист, генерируемый после PnR) у триггеров, которые я считал должны были быть размещены в ячейках ВВ, я вижу инстанцирование DFFR с очень подозрительным недокументированным аттрибутом: (*gowin_io_reg = "FALSE" *) DFFR ... Найти описание этого gowin_io_reg я нигде не смог, гугл про него не знает. Как можно проконтролировать, какие регистры попали в триггера ячеек ВВ, а какие нет? Ни в одном репорте этих данных нет. Собственно вопрос: какие есть варианты управления размещением триггеров для надежного их размещения в ячейках ВВ? Пока в голову приходит только один вариант: явно инстанцировать ODDRC в режиме SDR (подавать на оба входа один и тот же сигнал) и полагаться на него. Но это выглядит крайне кривой затеей, т.к. исходя из описания архитектуры должны быть возможности как минимум использовать синхронных сброс триггеров в ячейках ВВ. PS: Похоже, что та же проблема и с входными регистрами (триггерами). Однако с ними всё-таки немного проще и, надеюсь, решение для выходов будет вполне применимо и для входов. PPS: Выяснилось, что для размещения регистров управления третьим состоянием выходов в ячейках ВВ важна полярность. Т.е. если активный уровень сигнала управления будет 1, то между этим регистром и входом OEN на буфере ВВ синтезатор добавит инвертор и это не позволит PnR разместить соответствующий триггер в ячейке ВВ. Поэтому необходимо учитывать эту особенность и правильно выбирать активный уровень этих сигналов в проекте (должен быть active-low).

Всем привет! При сборке проекта всплыл набор предупреждений вида (подформатировал, ибо в оригинале совсем нечитабельно): Суть недовольства САПР в следующем: инстанс корки PCIe содержит внутри блочную память, на входы блоков которой приходит сигнал из недр другой корки - сигнал empty прокинут (через логику) из FIFO, при этом флоп, с которого выходит этот empty, имеет тип FDPE, что в переводе на русский означает, что этот флоп типа "D Flip-Flop with Clock Enable and Asynchronous Preset", и это сильно не нравится синтезатору, о чём он сообщает. Формально он прав - нехорошо, когда асинхронный сброс (пресет) используется - вдруг глитч на сигнале сброса... со всеми вытекающими. Но смотрю, откуда приходит сигнал сброса (пресета), а он приходит с другого флопа, который имеет тип FDRE (D Flip-Flop with Clock Enable and Synchronous Reset), т.е. никаких глитчей быть не может - флоп строго синхронен общему клоку данного домена. Вопрос: а чего он тогда ругается-то? Или у него просто не хватает глубины анализа? И второй вопрос: как быть? Оставить, как есть? Вроде оно безопасно, но неприятный варнинг портит настроение. Или всё же есть способ забороть корректно? P.S. Корка FIFO по умолчанию имеет настройку параметра Reset Type как Asynchronous. Попытался изменить на синхронный тип, появились два раздельных входа ресета (для обоих тактовых доменов - FIFO сконфигурировано с независимыми клоками), но картина не поменялась. Внутри корки флоп сигнала empty по-прежнему имеет тип FDPE, и варнинг, естественно, не уходит. Так понял, что тип сигнала сброса не влияет на реализацию отдельных логических частей, а влияет только на поведение корки в смысле внешнего ресета.