Доборого здаровеца граждане форумчане!!!! стоит задача коммутировать два паралельных потока большей разрядности (до 256 бит) на общий выход (вход массива тригеров) , коммутация происходит в зависимости от состояния однобитного сигнала управления. причем данные с первого входа должны появляться на выходе тригера через 1 такт. Данные же со второго можно задержать на определенное колличество тактов (пропустить через цепочку регистров ). Проблемма в том что при больших разрядностях значительно падает рабочая частота (чего собственно и стояло ожидать при таком включении). Уважаемые гуру может кто знает какие нибудь болеее-менее эфективные комутационные схемы. Поделитесь опытом , пожалуйста.Заранее благодарен!!!!

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

Для уточнения - у вас две шины в 256 бит - и вы коммутируете на вход 256-битного регистра? В этом случае коммутатор получается простейший в каждой ячейке 2-входовый mux и регистр - все летать должно. Падение скорости скорее всего связанно с сигналом управления mux - его ведь придется 256 раз разветвить.

Если структура переключения другая - то надо уточнять - я на телепата только учусь.

Удачи! Rob.

Телепатическими способностями вы обладаете - ФАКТ



Да! именно это я и имел ввиду. А что Вы можете посоветовать чтобы фаноут сигнала управления не так сильно садил рабочую частоту?

Спасибо!

О каких частотах и микросхеме идет речь?
256 подключений - это не так много...
Если действительно проблема - делать регистр на сигнале управления и соответственно на данных например после 100 mux-ов.

це же элементарно, для альтеры 256 муксов лягут в 8 логических блоков по 32 LE. в ручную делаем 8 регистров одного сигнала управления, запрещаем их склеивать и вуаля %)

Начнем с самого начала. Откуда в ПЛИС берутся потоки? По параллельной шине? И куда они потом уходят? И тоже по параллельной шине?

Можно натравить на цепь управления мультиплексором атрибут что-то типа "max_fanout" - тогда умный синтезатор сам задублирует логику, генерящую этот сигнал столько раз, сколько нужно для удовлетворения требования этого атрибута. Правда потом неплохо бы убедиться, что "ещё более умный" маппер не сминимизирует обратно это дублирование.
А вообще, действительно, 256 - не такой уж и большой фанаут чтобы влиять на скорость переключения... Что-то тут нечисто...