Добрый день, уважаемые.
При проектировании довольно сложных схем для потоковой передачи данных, возникает большая задержка (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 (компаратор :-)), а также колдовать над адресами.

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

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

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



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