Борьба с 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, зачем по плате гонять высокую частоту...

[void F()]

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

В конец я запутался. Необходимо подумать... а так: сделаю небольшой кэш внутри MCU и DMA, починю констрейны.

Сообщение отредактировал void F() - Sep 15 2014, 11:35