[Worldmaster 0]

Здравствуйте.

А есть у кого нибудь ссылочки на отлаженный и рабочий код VHDL для реализации dual clock fifo чтобы были флаги AlmostFull и можно было задать нужный порог.

Встроенная корка GOWIN походу не способна работать на скорости 160mhz. Хочется взять какой нибудь другой аналог фифы и проверить.

Что бы не делал все равно не успевает по фронтам.

[Yaahoo 0]

Dual clock - асинхронные клоки? Если так, то внутри фифо есть CDC и асинхронные пути, для которых нужны соотв. констрейнты. Если фалзпасы не задать, что то подобное (-4нс слэк) и вылезет в тайминге CDC. А еще хуже, когда не вылезает, а просто дизайн не работает, и не знаешь в чем проблема.

[Worldmaster 0]

В 05.06.2024 в 09:12, Yaahoo сказал:

Если фалзпасы не задать, что то подобное (-4нс слэк) и вылезет в тайминге CDC.

Ну если тут прописать то конечно ошибка исчезнет но это же просто маскировка проблемы.

Клоки асинхронные и указаны в CDC, но тут только один клок как видно.

[sazh 5]

В 03.06.2024 в 15:14, Worldmaster сказал:

Здравствуйте.

А есть у кого нибудь ссылочки на отлаженный и рабочий код VHDL для реализации dual clock fifo чтобы были флаги AlmostFull и можно было задать нужный порог.

Встроенная корка GOWIN походу не способна работать на скорости 160mhz. Хочется взять какой нибудь другой аналог фифы и проверить.

Что бы не делал все равно не успевает по фронтам.

Так ведь лучше ip_core не сделать. Создайте проект только фифо. Клоки назовите независимыми. И посмотрите, что скажет временной анализатор. Основа - двухпортовая память.

Проблема может быть в сигналах управления (в корке должна быть возможность задавать стадии синхронизации (3 и более) для лучшей защиты метастабильности и высокой частоты функционирования. В корке по определению правильно формируются сигналы управления при переходе из одного клокового домена в другой. Временной анализатор должен создать две температурных модели. Ведь проект должен работать в n диапазоне температур. Может статься, что выбранное семейство не тянет 160MHz.

Может проект пересобрать. Избавиться от лишних доменов. 50 MHz только на вход pll. На выходе pll 48MHz( в том числе i2c) и 160MHz (Все внутренние клоки от одной pll). 

Работать только по одному фронту клока (мыслить в разах периода клока). Нет смысла что то перезаписывать его инверсией (и напрягать анализатор анализом 2F). Стараться не формировать промежуточные клоки для перезаписи (а формировать импульсы для подачи на вход ce).

Посмотрите в RTL просмотрщике в Ваших модулях , на какой вход триггера поступает сигнал, который Вы пытаетесь описать как асинхронный ресет. При не корректном описании группы триггеров с асинхронным ресетом синтезатор может посадить этот ресет на вход ce.

[Worldmaster 0]

В 05.06.2024 в 23:24, sazh сказал:

(в корке должна быть возможность задавать стадии синхронизации (3 и более)

Что то я такого в параметрах не увидел.

 

В 05.06.2024 в 23:24, sazh сказал:

Избавиться от лишних доменов. 50 MHz только на вход pll. На выходе pll 48MHz( в том числе i2c) и 160MHz

Это конечно классно, но у меня еще есть FIFO для передачи данных на комп и он работает на своей частоте. Конечно можно было бы запитывать от его 100mhz, но эта зараза порой любит лечь спать если бездействует.

К тому же чтобы система оперативно успевала все отработать работу с памятью я вывел до максимума. Чтобы успевало и данные с камер писать в нее и успевало считывать для отправки в комп. если питать сдрам 100мгц то модуль сборки данных не будет успевать.

Вообще проект получается по потолку возможностей плис видимо. 

[sazh 5]

Я только хотел сказать, что если надо использовать 50 МГц, формируйте его на pll 1/1. Что касается фифо, сделайте все регистровое, может поможет. Если конвейер не смущает,

Можно поступить в стиле линка tiger sharc,

an332.pdf Altera. Преобразовать n бит 160 в 2n  bit  на 80, подать на фифо с разной разрядностью по записи и чтению.

[Worldmaster 0]

В 06.06.2024 в 12:41, sazh сказал:

Что касается фифо, сделайте все регистровое, может поможет.

Перепробовал все 3 варианта. Сейчас когда перенес выходное фифо из модуля рамы в основной модуль вроде бы стабилизировалось все.

 

В 06.06.2024 в 12:41, sazh сказал:

Преобразовать n бит 160 в 2n  bit  на 80, подать на фифо с разной разрядностью по записи и чтению.

Чего то не понял. ))) полистал доку но для меня это пока еще какие то магические заклинания. ))

[Flip-fl0p 4]

Присоединяюсь к вопросу. Как констрейнить это поделие ? Для пользователя FIFO закрыто. И в его кишках не покапаешься. Накладывать set_max_delay вообще не вариант, ибо каждый раз после синтеза названия регистров меняются. А возможности TCL у GOWIN мягко говоря очень неочень.

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

Засада....

 

[Worldmaster 0]

В 06.06.2024 в 13:19, Flip-fl0p сказал:

ибо это по большей части маскирует проблему, а не устраняет проблемы....

Так а зачем вообще тогда это придумано если оно не лечит?

[sazh 5]

Физически это двух портовая память.2010_10_54.pdf

[Flip-fl0p 4]

3 часа назад, Worldmaster сказал:

Так а зачем вообще тогда это придумано если оно не лечит?

Оно частично лечит. По сути помещение в клоковую группу отключает проверки между пересечениями между доменов. И там может быть все-что угодно. И если разработчик вдруг, забыл правильно сделать пересечение между доменами - то в отчете о временном анализе он об этом так и не узнает. Еще когда мы передаем группу сигналов (например код Грея для FIFO), в идеале надо указывать еще и максимальную задержку пути от А до Б. Чтобы шина корректно перешла между доменами. 

Для себя я нашел следующий выход:

Собираю проект в Vivado. Все IP блоки у меня как Black_box. Очень, ОЧЕНЬ внимательно описываем все клоки, которые есть в проекте. И разруливаем все пересечения тактовых доменов. А в GOWIN помещаем клоки в клоковые группы) Другого пути я не нашел. Но тут хотя-бы Vivado очень сильно поможет показав ошибки в пересечении CDC

[sazh 5]

 

Временной анализатор позволяет выполнять оценку устойчивости асинхронных передач путем вычисления MTBF метастабильности. Такие фифо строятся на "настоящей"

двух портовой памяти с двумя сигналами синхронизации. Каждый порт двух портовой памяти может функционировать независимо, то есть выполнять любые операции чтения/записи, за исключением одновременной записи в одну и ту же ячейку памяти. В последнем случае содержимое ячейки памяти считается неопределенным (don’t care).

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

Когда на базе такой памяти строим фифо, требуется передать значения указателей из одного клокового домена в другой для определения фифо пусто или фифо полно. Другими словами, в случае равенства указателей wr_ptr и rd_ptr необходимо распознать состояние памяти FIFO: память полная или память пустая. Плюс защита от круговой записи в память.

Кроме классического метода передачи указателей (бинарный счетчик со слоем логики кода Грея) цепочкой синхронизаторов вряд ли есть другой. Чем длиннее цепочка (в разумных пределах) тем выше устойчивость асинхронной передачи. Временной анализатор создает отчет. По нему и судим, удовлетворяет ли нас переход из одного клокового домена в другой или нет. Что касается повышения f max при увеличении длины цепочки, есть понятия ретайминга регистров (переназначение логики между регистрами таким образом, чтобы уменьшить максимальную задержку сигналов через самый большой фрагмент логики (формирование фифо полное, пустое).

Значит и тут клоки в разных группах (а какие иначе прописать ограничения).

Что Xilinx, что Gowin (его клон), что Altera. Подход одинаковый.

 

 

[Flip-fl0p 4]

9 часов назад, sazh сказал:

 

Временной анализатор позволяет выполнять оценку устойчивости асинхронных передач путем вычисления MTBF метастабильности. Такие фифо строятся на "настоящей"

двух портовой памяти с двумя сигналами синхронизации. Каждый порт двух портовой памяти может функционировать независимо, то есть выполнять любые операции чтения/записи, за исключением одновременной записи в одну и ту же ячейку памяти. В последнем случае содержимое ячейки памяти считается неопределенным (don’t care).

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

Когда на базе такой памяти строим фифо, требуется передать значения указателей из одного клокового домена в другой для определения фифо пусто или фифо полно. Другими словами, в случае равенства указателей wr_ptr и rd_ptr необходимо распознать состояние памяти FIFO: память полная или память пустая. Плюс защита от круговой записи в память.

Кроме классического метода передачи указателей (бинарный счетчик со слоем логики кода Грея) цепочкой синхронизаторов вряд ли есть другой. Чем длиннее цепочка (в разумных пределах) тем выше устойчивость асинхронной передачи. Временной анализатор создает отчет. По нему и судим, удовлетворяет ли нас переход из одного клокового домена в другой или нет. Что касается повышения f max при увеличении длины цепочки, есть понятия ретайминга регистров (переназначение логики между регистрами таким образом, чтобы уменьшить максимальную задержку сигналов через самый большой фрагмент логики (формирование фифо полное, пустое).

Значит и тут клоки в разных группах (а какие иначе прописать ограничения).

Что Xilinx, что Gowin (его клон), что Altera. Подход одинаковый.

 

 

Все абсолютно верно. Но помещая клоки в разные группы мы по сути прописываем false_path между переходом из домена в домен. Вот тут и кроется вся проблема. Мы отключаем ВСЕ переходы из домена в домен. Допустим у нас есть не только переход через FIFO , а еще несколько переходов. Но по какой-то причине мы забыли их правильно перенести через домен. И в случае, когда мы поместили клоки в разные группы, нам временной анализатор не покажет, что у нас есть проблемы. Мы же сами его попросили не анализировать это))) А проблемы будут. И мы про них не узнаем. Можно конечно кидаться тапками в разработчика, но тут никто не застрахован от проблем. Особенно когда у вас может быть несколько разных доменов. Поэтому я считаю применение false_path и set_clock_group очень опасной практикой.

Более того. У нас автоматически появляется еще одна проблема, применяя эти ограничения. В частности, мы, отключив анализ между клоками, дали синтезатору добро размещать шины данных без каких-либо правил. И в коде грея могут быть серьезные проблемы если биты шины данных слишком сильно расползутся по времени. Поэтому правильно ограничить эти шины констрейном set_max_delay (Или же set_bus_skew). Пример правильных констрейнов можно подсмотреть в Vivadо, сгенериров FIFO.

[Worldmaster 0]

В 06.06.2024 в 16:42, Flip-fl0p сказал:

Но тут хотя-бы Vivado очень сильно поможет показав ошибки в пересечении CDC

У меня в проекте участвует модуль SDRAM который вроде как физически распаян на чипе и только GOWIN знает как его надо разводить и формировать под него код.

В 07.06.2024 в 07:53, Flip-fl0p сказал:

Поэтому правильно ограничить эти шины констрейном set_max_delay (Или же set_bus_skew). Пример правильных констрейнов можно подсмотреть в Vivadо, сгенериров FIFO.

А можно какой нибудь примерчик? А то я с вивадой не работал вообще. 

 

И не подскажете, какую надо качать, а то их тут тьма.

Методом проб понял что косяк в Reset. Как только объявляю сигнал сброса то сразу появляются глюки. ((( 

Ну прям засада. 

 

Изменено 7 июня пользователем Worldmaster

[Flip-fl0p 4]

Цитата

У меня в проекте участвует модуль SDRAM который вроде как физически распаян на чипе и только GOWIN знает как его надо разводить и формировать под него код.

Вы сейчас имеете ввиду PSRAM у gowin ? 

set_false_path -from [filter [all_fanout -from [get_ports -scoped_to_current_instance wr_clk] -flat -endpoints_only] IS_LEAF] -to [get_cells -hierarchical -filter {NAME =~ *gdm.dm_gen.dm*/gpr1.dout_i_reg*}]

set_max_delay -datapath_only -from [get_cells src_gray_ff_reg*] -to [get_cells {dest_graysync_ff_reg[0]*}] 1000.0
set_bus_skew -from [get_cells src_gray_ff_reg*] -to [get_cells {dest_graysync_ff_reg[0]*}] 1000.0
set_max_delay -datapath_only -from [get_cells src_gray_ff_reg*] -to [get_cells {dest_graysync_ff_reg[0]*}] 1000.0
set_bus_skew -from [get_cells src_gray_ff_reg*] -to [get_cells {dest_graysync_ff_reg[0]*}] 1000.0

На значение времени не смотрите. Оно потом на стадии имплементации другое становится.