Борьба с TDF, оптимизации задержек при передачи данных Опции

[void F()]

Добрый день, уважаемые.
При проектировании довольно сложных схем для потоковой передачи данных, возникает большая задержка (TDF) между входом и выходом, особенно если используется несколько ПЛИС. С записью данных (в память) проблем нет, но возникают сложности при чтении: данные приходят не сразу, а через несколько тактов. На потоковое чтение это почти не влияет, а при единичном доступе к определенному адресу серьезно падает скорость.
Как решается этот вопрос? Есть ли такие проблемы в современных системах?

Прошу простить за возможные неточности.
Заранее спасибо.

[void F()]

1) тактовая частота 125 МГц ?
2) В CPLD шины адреса, данных и т.п. просто скоммутированы с входа на выход, без защелкивания в тригерах?

1) Да, MCU работает на 125. Но, но чтение и запись происходят на 125/2.
2) Да, все летит напрямую.

Задеожка в 2 такта не задаётся внутренним клоком ПЛИС?

Да, почти напрямую коммутируется дальше.

Вы вот SDC констрейны какие задали для SP&R проекта?

Упс. Я их вообще не указывал.

И на всякий случай уточню - какая задержка распространения сигнала от пина ПЛИС до внутреннего гейта и от гейта на пин.
И как учтено время распространения сигнала от входного пина до выходного на ПЛИС в вашей системе? Мне вот 4-12нс на CPLD не кажется чем-то неожиданным....

Задержка pin_to_pin: 8ns, а про pin_to_gate, к сожалению, ничего сказать не могу. Кстати ПЛИС - EPM570.
А сигнал проходит еще через мультиплексор внутри ПЛИС; я задумал еще через пару лог.элементов пропустить.

[DuHast]

Да, почти напрямую коммутируется дальше.

Я бы защелкнул сигнал в ПЛИС, как минимум на входе и на выходе. Тогда задержка в ПЛИС будет составлять заранее известное(а не как у Вас, случайно получившееся) число тактов.
А дальше строил бы алгоритм работы MCU с учетом этой известной задержки.

Да и вообще не понятно, зачем у Вас на схеме CPLD. Пинов не хватает?

[Torpeda]

Я бы защелкнул сигнал в ПЛИС, как минимум на входе и на выходе. Тогда задержка в ПЛИС будет составлять заранее известное(а не как у Вас, случайно получившееся) число тактов.

Задержки в ПЛИС определяются исключительно констрейнами SDC, хоть явно заданными, хоть неявно (как у автора), а не случайно (неожиданно для автора, который использовал дефолтные значения) и тем более не от наличия\отсутствия тригеров.

К примеру, если задержка будет 16-32ns, это нормально для высокопроизводительной системы?

Это некоректно спрашивать.
Для той схемы и того шинного протокола что вы реализуете это нормально? Сколько вам надо?
вообщето, при скорости чтения 125\2=16нс это выглядит многовато при отсутствии конвеерного доступа к памяти. Это просто понижение производительности в 2 раза. Тут мож имеет смысл понизить скорость до 125\4, зачем по плате гонять высокую частоту...

[DuHast]

Задержки в ПЛИС определяются исключительно констрейнами SDC, хоть явно заданными, хоть неявно (как у автора), а не случайно (неожиданно для автора, который использовал дефолтные значения) и тем более не от наличия\отсутствия тригеров.

Когда используется тригир и в SDC задана Fmax, результат понятен. Если фиттер справился - задержка известна с точностью до такта.
А по поводу задания констрейна для схемы без тактового сигнала, я что-то не совсем в курсе о чем Вы пишете. Объясните на пожалуйста на примере.
Пусть есть простая схема pinout_a<=not pin_b. Какие констрейны я могу задать для этой схемы и что мне скажет фиттер, если не сможет их выполнить?

[Torpeda]

Когда используется тригир и в SDC задана Fmax, результат понятен. Если фиттер справился - задержка известна с точностью до такта.
А по поводу задания констрейна для схемы без тактового сигнала, я что-то не совсем в курсе о чем Вы пишете. Объясните на пожалуйста на примере.
Пусть есть простая схема pinout_a<=not pin_b. Какие констрейны я могу задать для этой схемы и что мне скажет фиттер, если не сможет их выполнить?

Fmax

[DuHast]

Fmax

Период Fmax не должен быть меньше времени распространения сигнала по логике между триггерами? И, если на самой ПЛИС реализована только логика, то в качестве выходного триггера выступает MCU, а в качестве входного SRAM.
Думаю, я Вас правильно понял.
Тогда ещё надо будет задать задержки pinMCU-to-pinCPLD и pinCPLD-to-pinSRAM, но, что-то мне подсказывает, что ТС их не знает, а если и знает, то не справится фиттер и всё равно придется ставить триггеры в ПЛИС

[Torpeda]

Период Fmax не должен быть меньше времени распространения сигнала по логике между триггерами? И, если на самой ПЛИС реализована только логика, то в качестве выходного триггера выступает MCU, а в качестве входного SRAM.
Думаю, я Вас правильно понял.
Тогда ещё надо будет задать задержки pinMCU-to-pinCPLD и pinCPLD-to-pinSRAM, но, что-то мне подсказывает, что ТС их не знает, а если и знает, то не справится фиттер и всё равно придется ставить триггеры в ПЛИС

Тулза нипрокакие тригеры в MCU\SRAM не знает
Если у вас нету тригеров в дизайне - тулза всё равно остаётся "синхронной тулзой"
При этом, как вы догадались наверное, в качестве "синхронных тригеров" выступают теже тригера что и при задании "in\out delay" - т.е. виртуалтьные.

Насчёт учёта внешних PCB задержек pinMCU-to-pinCPLD и pinCPLD-to-pinSRAM в вашем дизайне...вообщето конечно надо и их учитывать ...если конечно вы их знаете
Если при таких констрейнах SP&R не справится - так оно и работать не будет как и у автора этого топика

[DuHast]

т.е. виртуалтьные.

Ага, вспомнил, читал.

Если при таких констрейнах SP&R не справится - так оно и работать не будет как и у автора этого топика

Таким образом, что мы имеем? У TC 2 варианта:

1) попробовать при помощи констрейнов сделать задержку распространения сигналов через два CPLD меньше периода тактовой частоты
2) если пункт первый выполнить не удастся, менять алгоритм чтения/записи, конечно же с потерей производительности.

По поводу 2-го варианта у меня есть мысли, но, думаю, надо дождаться результатов по 1-му пункту.

[Torpeda]

2) если пункт первый выполнить не удастся, менять алгоритм чтения/записи, конечно же с потерей производительности.

Надо конечно цифры...но...
Когда речь пошла о наносекундах то, задержки внутри гейтов ПЛИС можно и не учитывать пока (если их правильно законстрейнить то вполне можно сделать меньше CLK), ибо задержки на гейт-пин куда больше (площадь пина 1000мкм, а гейта 500нм соотв. RC в сотни раз больше), а задержки в разёмах и разводке PCB есчё больше.
Нужно бюджет задержек считать......
Может тут реализация на PCB не имеет смысла?
--------------
PS Навсякий случай напомню, что для измерения задержек в пределах +\-1нс полоса осцилографа должна быть 1ГГц ...