[dxp 33]

Всем привет!

При сборке проекта всплыл набор предупреждений вида (подформатировал, ибо в оригинале совсем нечитабельно):

Цитата

REQP #1 Warning The RAMB36E1 pcie_port/<...>.bram36_tdp_bl has an input control pin 

pcie_port/<...>.bram36_tdp_bl/ADDRARDADDR[10] (net: pcie_port/<...>use_tdp.ramb36/MIMRXWADDR[6]) 

which is driven by a register 

<...>/queue/U0/inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gl0.rd/gr1.gr1_int.rfwft/empty_fwft_i_reg

that has an active asychronous set or reset. This may cause corruption of the memory contents and/or read values when the set/reset is asserted and is not analyzed by the default static timing analysis. It is suggested to eliminate the use of a set/reset to registers driving this RAMB pin or else use a synchronous reset in which the assertion of the reset is timed by default. 

Суть недовольства САПР в следующем: инстанс корки 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, и варнинг, естественно, не уходит. Так понял, что тип сигнала сброса не влияет на реализацию отдельных логических частей, а влияет только на поведение корки в смысле внешнего ресета.

 

[ViKo 1]

А если Clock Enable асинхронный?

[TRILLER 0]

7 hours ago, dxp said:

Но смотрю, откуда приходит сигнал сброса (пресета), а он приходит с другого флопа, который имеет тип FDRE (D Flip-Flop with Clock Enable and Synchronous Reset), т.е. никаких глитчей быть не может - флоп строго синхронен общему клоку данного домена.

Вопрос: а чего он тогда ругается-то? Или у него просто не хватает глубины анализа?

Вы здесь ошибаетесь. Хоть сигнал сброса и генерируется по клоку, но ведь применяется(так как вход асинхронный) тогда, когда долетел по линии. И это бы ладно, только ведь он и отменяется тоже в произвольный момент времени. Синтезатор прав - это ошибка.

Хотя и индусов понять можно, они-то вынуждены делать "для всех": если сделать синхронный сброс для empty, то есть вероятность, что кто-нибудь этот empty всё таки не сбросит.
Они выбрали меньшее из зол - шанс поймать метастабильность по отмене ресета значительно ниже.

Как бороться? Сделать своё. Фифо применяются часто - не будет пустой тратой времени.

[dxp 33]

7 часов назад, TRILLER сказал:

Вы здесь ошибаетесь. Хоть сигнал сброса и генерируется по клоку, но ведь применяется(так как вход асинхронный) тогда, когда долетел по линии. И это бы ладно, только ведь он и отменяется тоже в произвольный момент времени. Синтезатор прав - это ошибка.

Я бы согласился с вами, если бы между флопом-источником ресета и асинхронным входом сброса флопа-приёмника была бы комбинационная логика, которая, конечно, может порождать глитчи на выходе. Но в данном случае всё "стерильно": сигнал сброса генерируется синхронно и распространяется напрямую без всякой логики. Где тут источник глитчей (или других проблем)? Привожу картинку, как оно реально там синтезировалось:

 

[RobFPGA 27]

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

 

На сколько помню сам Xilinx на форуме  советует забить на этот warning. Так как эта проверка идет по формальному признаку то этот warning просто показывает возможные проблемные места. Убедившись что тут по функционалу ничего страшного (тут пофиг что может corruption - все равно это в ресете, и буфер не содержит данных инициализации) можно отключить этот warning чтобы он не раздражал. Ну или при большом  желании  можно наживную патчить нетлист после синтеза  заменяя триггеры или меня связи 

 

Удачи! Rob.

[TRILLER 0]

4 hours ago, dxp said:

Я бы согласился с вами, если бы между флопом-источником ресета и асинхронным входом сброса флопа-приёмника была бы комбинационная логика, которая, конечно, может порождать глитчи на выходе. Но в данном случае всё "стерильно": сигнал сброса генерируется синхронно и распространяется напрямую без всякой логики. Где тут источник глитчей (или других проблем)? Привожу картинку, как оно реально там синтезировалось:

 

Глитчи это одно, а нарушение setup/hold - другое. Если произойдёт так, что асинхронный ресет будет отменяться(устанавливаться) в момент прихода синхроимпульса на триггер - то он может попасть в метастабильное состояние.

Я лишь хочу сказать, что синтезатор прав, вываливая варнинг и в данном случае я бы последовал совету Роба.

[dxp 33]

3 минуты назад, TRILLER сказал:

Глитчи это одно, а нарушение setup/hold - другое. Если произойдёт так, что асинхронный ресет будет отменяться(устанавливаться) в момент прихода синхроимпульса на триггер - то он может попасть в метастабильное состояние.

Такого не должно быть: в данном случае речь идёт не о setup/hold (как с входом флопа), а recovery/removal анализе, т.к. анализируется сигнал асинхронного сброса/пресета. Этот анализ STA выполняет и все задержки и требования видит и учитывает. Если тут что-то не в порядке, это будет видно в отчёте STA. Опасная ситуация именно с глитчами из-за гонок на комбинационной логике, которые STA не может на 100% просчитать. И именно про глитчи синтезатор предупреждение и выдаёт. 

1 час назад, RobFPGA сказал:

На сколько помню сам Xilinx на форуме  советует забить на этот warning. Так как эта проверка идет по формальному признаку то этот warning просто показывает возможные проблемные места. Убедившись что тут по функционалу ничего страшного (тут пофиг что может corruption - все равно это в ресете, и буфер не содержит данных инициализации) можно отключить этот warning чтобы он не раздражал.

Вот именно так, по ходу, и сделаю.

1 час назад, RobFPGA сказал:

Ну или при большом  желании  можно наживную патчить нетлист после синтеза  заменяя триггеры или меня связи 

Ну, это уже для настоящих ковбоев. 

[TRILLER 0]

16 minutes ago, dxp said:

Такого не должно быть: в данном случае речь идёт не о setup/hold (как с входом флопа), а recovery/removal анализе, т.к. анализируется сигнал асинхронного сброса/пресета. Этот анализ STA выполняет и все задержки и требования видит и учитывает. Если тут что-то не в порядке, это будет видно в отчёте STA. Опасная ситуация именно с глитчами из-за гонок на комбинационной логике, которые STA не может на 100% просчитать. И именно про глитчи синтезатор предупреждение и выдаёт. 

Ну, если анализирует времянку, тогда действительно не важно. Наверное, перестраховались.

[RobFPGA 27]

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

Вот напоролся я на источник этой ругани:

On 11/29/2018 at 4:41 PM, dxp said:

... that has an active asychronous set or reset. This may cause corruption of the memory contents and/or read values when the set/reset is asserted and is not analyzed by the default static timing analysis. It is suggested to eliminate the use of a set/reset to registers driving this RAMB pin or else use a synchronous reset in which the assertion of the reset is timed by default. 

Проект на Virtex7. В дизайне модуль в котором  16 штук одинаковых FFT параллельно-последовательно жуют поток от 2 каналов ADC.  Модуль уже работал в другом проекте так что проблем не ожидал - и вдруг выходе одного из FFT наблюдаю что то похожее на забор соседа на даче, а не одинокую палку.  Все времянки после P&R ок. Прогнал пост P&R функционал и timig симуляцию для этого модуля - все ок. Что за чертовщина?  Полез дебажить через ECO моде. Последовательно цепляя пробники по пути сигнала вычислил что глючить ... ROM таблица поворотов (просто BRAM)  в одном из stage FFT.  Причем там никакой асинхроннщины нет и в помине! Прошивка  только что загружена через JTAG! Неужели Pentek подсунул мне битые FPGA? 

Немного остыв  начал смотреть в чем разница с предыдущим проектом. А  разница в том что в текущем проекте частота ADC программируется  и софт сначала меняет частоту внешнего синтезатора а потом меняет настройки внутреннего PLL  от которого питается FFT. И все это на лету - без остановки FFT модуля!. Потом ясное дело ресетится весь блок обработки и все. Поэтому как пить дать происходить кратковременное нарушение времянок на адресной шине ROM - а это чревато:

The setup time of the block RAM address and write enable pins must not be violated.
Violating the address setup time (even if write enable is Low) can corrupt the data
contents of the block RAM.

Теперь вот надо думать как с этим бороться. Понятно что сначала надо избить поговорить с программистами. А потом решать как уйти от этой зависимости непосредственно в железе. 

Удачи! Rob.

[dxp 33]

16 часов назад, RobFPGA сказал:

разница в том что в текущем проекте частота ADC программируется  и софт сначала меняет частоту внешнего синтезатора а потом меняет настройки внутреннего PLL  от которого питается FFT. И все это на лету - без остановки FFT модуля!. Потом ясное дело ресетится весь блок обработки и все. Поэтому как пить дать происходить кратковременное нарушение времянок на адресной шине ROM - а это чревато:

А что, разве ресет не подсинхронизован к клоку? Если ресет отпускается синхронно по клоку (и STA может проверить removal time), то отчего возникает проблема? В этом случае всё должно стартовать корректно. Разве нет?

[RobFPGA 27]

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

2 hours ago, dxp said:

А что, разве ресет не подсинхронизован к клоку? Если ресет отпускается синхронно по клоку (и STA может проверить removal time), то отчего возникает проблема? В этом случае всё должно стартовать корректно. Разве нет?

Ресет синхронный  -  проблема скорее все в другом -  софт начинает менять частоту тактовой не останавливая наглухо перед этим блок обработки. Соответственно на переходных процессах и вылазит timing vialtion портящий содержимое ROM.  Потом после смены тактовой и ресета все стартует корректно но табличка то в BRAM уже  порченная .  

Удачи! Rob.

[dxp 33]

Теперь понятно. А в чём препятствие останавливать блок обработки на время смены тактовой?

[RobFPGA 27]

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

2 minutes ago, dxp said:

Теперь понятно. А в чём препятствие останавливать блок обработки на время смены тактовой?

В данной случае - желании  программистов читать спеки  Было же им писано - "остановить обработку, смени частоту, сделать ресет" -  они это поняли как "сменю и ресет сделаю". Ну и немножко в моей лени  - надо было сразу делать обработку на независимом от ADC клоке. 

Но  вся "прелесть" такой ситуации в том что  если  например  нет возможности на 100% контролировать качество тактовой - например клок внешний и с ним может случится что-то в любой момент -  то ставить на такой клок обработку с ROM на BRAM  очень рискованно 

Удачи! Rob.

[dxp 33]

2 минуты назад, RobFPGA сказал:

Но  вся "прелесть" такой ситуации в том что  если  например  нет возможности на 100% контролировать качество тактовой - например клок внешний и с ним может случится что-то в любой момент -  то ставить на такой клок обработку с ROM на BRAM  очень рискованно 

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

[ViKo 1]

1 час назад, RobFPGA сказал:

Соответственно на переходных процессах и вылазит timing vialtion портящий содержимое ROM.

А как эта память портится? У вас сброс есть, например, при потере захвата PLL? Вам же из таблицы только читать нужно, а записали только раз при конфигурации.