Здрасте.
Достался мне в наследство проект системы на Cyclone2 имеющий общую шину (16бит) с обычным управлением подобно интерфейсу SRAM (Adres, CS, WR, OE). На шине навешаны регистры управляющие работой системы. Регистры как записываются так и читаются по етой общей шине - для етого их выходы выставляются на нее через tribuf - буферы. И ква эту шину нормально конвертит в мультиплексор.
беда моя началась после добавления к шине очередного регистра - тайминг анализ стал показывать что выход одного регистра до входа другого не укладывается в тактовую шины.

Глобально ломать тайминги шины нехочется ибо придется перепиливать проекты других устройств сопряженных с проблемным.
Есть надежда что если я както сумею разделить пути: от шины ко входам регистров и от выходов к шине то уложусь в тактовую.
Еще есть одна надежда:
у меня 1 такт шины занят выставлением адреса перед чтением\записью - этот такт можно былобы использовать для синхронного мультиплексора, если бы я сам делал его, но он синтезируется самим квартусом;
или можно попробовать обконстрейнить мультиклок, одна беда узлов больше полусотни, я заколебусь это делать.

Вобчем ищу умного совета, как организовывать большую шину и как возможно проще поправить то что есть?

1) Какая тактовая шины?
2) Недопонял - шина соединяет внутренние блоки одной ПЛИС, и/или эту ПЛИС с еще чем-то?

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

Тактовая 50 МГц
Шина соединяет кучу узлов - регистров в плисе и выставляет их наружу - другая плиса их считывает\пишет по етой шине.



непрокатит - я поддерживаю рабочий проект, изделия уже работают, их не поменять

Дайте временную диаграмму работы шины.

по масочке и TCL циклом %)

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

Надо разгрузить мультиплексор. Сделать ревизию, выбросить ненужное.
А что если договориться с программистом, чтобы чтение регистров нового блока предварялось записью индекса читаемого регистра?
Такое было в старых видеоплатах.

В такой шине есть два узких места.
Первое - это мультиплексор данных от каждого регистра на общую шину. Впорое - это селектор адреса.

С первым - можно бороться так: если известно, что например в регистре готовности читаются только 2 бита из 16-ти, то можно сделать остальные входы оп нулям, а не коммутировать всю шину. И далее, если что-то есть байтное, то тоже написать, что коммутируем байт, а остальное - нули...

Со вторым - делается частичная дешифрация. Т.е. в идеале для дешифрации адреса регистра берутся только 2 или 3 старших адреса. Это тоже помогает сократить дешифратор...

Далее идет косвенная адресация, как тут уде было сказано.
Потом - вставление NOP перед чтением и т.д.

Удачи!

как правило младшие биты регистров используются полюбому, так что разгрузить получится только мультиплексоры старших битов



очень трудно будет уговорить программиста использовать косвенную адресацию, ето в 2 раза нагрузит канал обмена с хостовым компом, а он и так нагружен понемогуй, и там есть потери, а делать индексную адресацию плисой другой я запарюсь.



есть возможность ввести как раз лишний такт на адресацию задержкой сигнала HOLDACK - подтвержение захвата шины\он же опознавание наличия узла.
но ето ведь только решение половины проблемы, надо же еще както конвейеризовать сам мультиплескор для того чтобы данные не разваливались.
неужели такой проблемы невозникает нигде? должнож быть какоето стандартное и приемлемое решение.


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

Придется переписать.
Непонятно, почему не успеваете. Да и мультиплексирование получается, если шины по z состоянию без выхода на внешние пины реализованы.

А частичную дешифрацию адресов?

Может быть есть сигнал "готовности"? Если так, то все просто...

а чего просто то? мультиплексор то ведь никуда не девается, по нему данные от регистров должны както пролезть.
у меня ведь еще и пакетные передачи активно используются.

с сигналом готовности можно будет мультицикл использовать.


лучше используйте более быструю плис, для вас это самый простой выход.

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

шины с нормальным handshake + дробление на сегменты с мостами между сегментами.

ЗЫ. скорость != частота это большое ФПГАшное заблуждение.

наверно буду дробить на сегменты

У меня есть функционально похожий проект. В конечном счёте на выход поставил блок внутреннего ОЗУ, куда через мультиплексор складываются данные от разных внутренних источников, а внешняя шина совершенно прозрачным образом читает эти данные уже из этого буферного ОЗУ.

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

Складываю данные специальным автоматом, по сути делаю тоже самое, что Вы сейчас пытаетесь сделать для внешней шины, но во внутреннюю память. У меня период между внешними запросами гораздо длиннее длительности запроса, соответственно проблема внешних таймингов не волнует.
Это, конечно, усложняет задачу, добавляя необходимость разруливать очередность внутренних записей, но зато с внешними запросами всё просто.
Даже при таком подходе можно сделать мультиплексор на выходе, переключающийся между несколькими источниками. Вы просто посмотрите - в какой очередности заполняются ваши регистры, может быть их можно, действительно, отражать в ОЗУ.