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

На мультиплексорах, разумеется. Иного решения и не вижу, потому что в Альтере внутри нет "третьего состояния".


Формально, сдвигатель на мультиплексорах содержит Log₂N мультиплексоров 2->1 на всю ширину N, t.e. грубо говоря, NLog₂N логических ячеек (для Альтеры, для Ксайлинкса, думаю, почти то же самое)

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

Очень нересурсоемко, в объеме штук логических ячеек (при их количестве в тысячах). С однобитовой версией можно не завязываться, ресурсов вполне хватит и на нормальную сеть вычислительных устройств. Что до двунаправленности, то это не совсем тот вопрос, над которым нужно отдельно задумываться. VHDL/Verilog позволяют вести поведенческое описание схем, т.е. как это сделать в железе - голова болит у САПР ПЛИС.

К примеру, вот кусок описания процессора, у которого опкод 23 выполняет add ra, rb, rc

[/code]

Я знаком а AHDL.
И у меня создалось впечатление, что лучше такого, как приведено выше не делать, а расписать в цикле по lcell-ам с учетом связей заема-переноса и пр.
Но вопрос в другом. Как обычно выглядит эта самая транспортная сеть ( с однобитными устройствами понятно) ну, например я имею 16 исполнительных устройств и хочу, чтобы комутационных шин хватало на то,что бы связать друг с другмо 5 устройств одновременно. Так вот, сколко мне потребуется дешифраторов и на сколько они мне затормозят время передачи данных из одного исполнительного блока в другой, чем если бы я жестко зафиксировал пути и направления.?

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

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



Очевидно, 5. Но вопрос я не совсем понял. Задержки существенно зависят от двух вещей: числа logic levels (это регулируется как раз сложностью схемы) и трассировкой. Прямого способа выиграть пару наносекунд обычно нет, потому что получается бегание за соринками в грязной комнате. Гораздо эффективнее "повышать общую культуру проекта", кодируя в подходящем стиле. Тогда все транспортные сети получатся сами собой, в процессе реализации синтезатором соответствующего поведения схемы.

На проектах с подпредельной частотой таким не редко приходится заниматься. И тут принцип "Хвост вытащу - нос увязнет, нос вытащу - хвост увязнет" действует в полную силу. Критические места не редко приходится не только по LCELL-ам расписывать, но и ручками эти LCELL-ы на флоорплане расставлять, подбирая эти самые наносекнды так, как нужно.

Радикальный способ увеличения скорости - это переход на другой speed-grade, но и он не гарантирует, от того, что автомат намутит разводку ПЛИС-а так, что все времянки разъедутся.

Последние версии очень хорошо автоматизируют этот процесс. Конечно, можно лезть и на floorplan, но надо очень хорошо представлять, куда и зачем. А еще есть PlanAhead, хорошо избавляющий от беготни за Cell-ами. Если руками все делать, очень быстро надоест, рассеется внимание, и общий результат окажется хуже, чем мог бы. И в любом случае, основа для дальнейшего улучшения лежит в сфере поведенческого описания. Просто невозможно держать в голове все тонкости конкретного семейства ПЛИС, и список ресурсов, которые в ней есть. Автоматический переход от behavioral к RTL позволяет САПР выбрать именно то, что решает "шаблонные" задачи наилучшим образом. А попытка руками описать цепи переноса приведет к бестолковой, большой и тормозной схеме, работающей чисто на LUT. То же с мультиплексорами, кстати, которые в последних семействах есть в избытке, причем способы их использования оказываются самые неожиданные. Если их попытаться расставить руками по ячейкам, половину не заметим.

Руками я стараюсь расставлять только то, что сильно критично. Например, проводку CLK со входа через LCELL-ы на выход, когда надо, чтобы его фаза была совершенно четкой и не менялась при перекомпиляции. Плюс расставленные по другим выходам периферийны I/O триггеры, и проблемы с "разбеганием" времянок почти пропадают.

С Квартусом, кстати, проблема еще в том, что он все ручные расстановки LCELL-ов в проекте игнорирует, в результате получается невесть что с неизвестными параметрами. Из-за этого я в MAX-Plus-е отключал разводку в режиме Квартуса (есть у него в последних версиях такое, типа "рекламной акции", которая для меня стала фактически антирекламной).

P.S. Что-то мы тут совсем в оффтопик ударились...
("железная" тема выделена и перенесена)

Проблема с clk сейчас в основном одна - не забыть поставить Digital Clock Manager. Клок раздается специальными линиями, джиттер при этом измеряется сотнями пикосекунд. Триггеры в I/O аналогично - пакуются везде, где это возможно. Главное, вдумчиво покопаться в настройках синтеза.

До проблем с джиттером у меня как-то не доходило
Клок один на всю схему, подается с генератора на глобальный вход и как бы "по идее" должен быть высоко стабильный.
А внутри ПЛИС-а для него отдельная общая разводка, которая не допускает лишней разности фаз. Фазы набегают только если клок со входа ПЛИС на выход подается. SD-RAM у меня клок берет с ПЛИС-а, чтобы не возиться с длинной ВЧ-разводкой от генератора, не ловить лишние наводки на клок и не иметь неконтролируемую разность фаз между клоком на памяти и клоком внутри ПЛИС-а...


Кстати, к "фишкам" работы с ПЛИС можно отнести такой прием работы с клоком:
1. Выход клока на память объявляется трехстабильным.
2. Выводится клок через трехстабильный буфер, включенный на постоянно.
3. Клок для защелкивания данных с памяти берется с этого же вывода, и он физически оказывается подключенным именно с него, в результате, нет лишней беготни за фазами сигналов.

В DCM есть специальный вход CLKFB (feedback), на который требуется заводить сигнал для синхронизации. Можно завести выход самого блока, тогда будет выравниваться фаза тактового сигнала по кристаллу. Но можно вывести clk наружу, к памяти, потом вернуть в ПЛИС, и в этом случае внутренний clk будет синхронизироваться с внешним.

Наверно, это (DCM) все же фишка Ксайлинкса, а не Альтеры. Или в Альтере она только в более поздних ПЛИСах нежели ACEX, с которыми я сейчас работаю.

P.S. Кстати, Cyclone-II есть в продаже в фирме Эфо, я недавно получил ответ на вопрос по ним и ценники вполне терпимые. начиная от 18$...
Только прямо на складе их сейчас нет, а поставка - 3-4 недели. Сижу и думаю, какой заказывать. 208-выводный минимальный или по максимуму, что в 240-выводном есть.

Да, в Альтере это должно быть где-то в Циклонах и дальше.



О, наконец-то! А поменьше корпусов там не бывает? Только 208 и 240?