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

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

зависит от объемов памяти с которым необходимо оперировать. Чем больше линейно адресуемый объем - тем больше латентность. с этим сделать принципиально ничего нельзя, здесь всё упирается в предел технологии.
on-chip SRAM, ZBT/noBL, Late write/PBSRAM, QDR/QDR II+ SRAM, RLDRAM, DDR/DDR2/DDR3, SATA-диск наконец - у всех свои задержки на чтение.

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

поток дает возможность замешивать в него в начало/конец/другое определенное место данные для последующей обработки в остальных блоках, и этим надо пользоваться.
использовать по 3 разных вида внешней памяти, общим количеством 10 штук, прицепленных к 3 ПЛИСинам, по одной микросхеме памяти на определенный вид операции - это нормальное явление на сложных потоковых задачах. Правда такое делается только если нужна действительно огромная скорость.

Кэш ?

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

я согласен с тем, что "в среднем по больнице" он может помочь всегда
но при реализации заранее известного алгоритма на ПЛИС.... я думаю что можно и нужно найти более эффективное решение.

Большое спасибо за ответы.

У меня линейно адресуется 2МБ с трех микросхем памяти. Максимальная скорость, при использовании всей ширины шины: 126Мб.сек. Весь поток, грубо говоря, проходит через ПЛИС, которая тормозит его на 16ns и все данные приходят ровно через 1-о чтение.

Что самое интересное, кэш то же проходит через ПЛИС, и последнее так же притормаживает его.
Я заметил странность, когда я жестко конфигурирую ПЛИС на передачу только в одну сторону (чтение или запись), то критичной задержки нет, но стоит мне сделать ее порты двунаправленными - появляется задержка.

Возможно я что-то делаю не так.

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

Для начала - если хотите получить конкретный ответ - задайте вопрос и как можно более полную информацию о системе в которой этот вопрос возникает. В противном случае ответ "используйте кэш" полностью отвечает на ваш вопрос.
А так всем приходится фантазировать на тему а "как же (тип шины, разрядность) передаются данные в Вашей системе... ax, где источник данных... ox, где они хранятся.. ой, как часто обновляются.. ай еще, кто читает эти данные... да-да, каков алгоритм использующие эти данные...ну еще чуть-чуть, ...??? ух-хорошо и покурить "

Любое решение для Вашего случая - кэш, префетч, зеркальный буфер - требует анализа структуры системы в целом.

Успехов! Rob.

16 ns - это несколько тактов тактовой частоты(извините за тавтологию). Для Вас что, ПЛИС - черный ящик и Вы не знаете, что там происходит?

Прикрепил схему. :-)

Организую, наверное, кэш, а еще избавлюсь от одной ПЛИС (в середине схемы). Насчет самой системы, в ней часто будут гоняться пакеты данных размером 16-256байт.

Вы правы, это два такта тактовой частоты, но ПЛИС их не считает. Вопреки всем правилам, все интерфейсы - асинхронные, но я планирую добавить тактовый сигнал.

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

"ПЛИС их не считает" - это как понимать?
Задеожка в 2 такта не задаётся внутренним клоком ПЛИС?

Если ваша ПЛИС внутри описана как комбинаторная схема, без тригеров и клока соотв., то и в этом случае задержки (от входного пина до выходного) никто не отменял.
Особенно никто не гарантировал симетричность и одинаковость схемы по каждому входу-выходу....
Величина этх задержек определяется STA правилами и SDC констрейнами. Вы вот SDC констрейны какие задали для SP&R проекта?
Может "случайно" так и вышло что какая-то там внутренняя задержка равна примерно 2 такта внешнего клока....

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

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

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

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

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

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

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

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

Центральная ПЛИС почти ничего не делает, у нее есть пара узконаправленных функций, которые почти не взаимодействуют с потоком. (ее я уберу). А вот, ПЛИС, которая справа, должна будет не пропускать определенные байты данных в SRAM (компаратор :-)), а также колдовать над адресами.

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

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



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

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

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

Fmax

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

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

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

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



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

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

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

Обнаружились неполадки с тестовыми платами Очень сильно мешают проблемы с механическими соединениями.

Замеры задержек и т.п. постараюсь сделать завтра вечером.

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