Ситуация - классическая. Процессор от TI (C6455) подключен к внешней шине через контроллер, собранный на основе ПЛИС Cyclone III по параллельной шине EMIFA.

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

На практике получается, что для чтения данных мне приходится все больше увеличивать длину сигнала READ (OE) с процессора для нормального чтения (в противном случае в читаемых данных появляются артефакты). При начале разработки она составляла 1+1 такт (12нс). Сегодня я уже вынужден поставить 1+3 такта (24нс).

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

Спасибо!

порезать мультиплексор конвейерами?

Тактируемый выход? Вряд ли его быстродействие будет выше 20нс..
Или я что-то не так понял?

Дело в том, что этот самый мультиплексор создает компилятор сам, без моего указания. Я лишь описал шину с третьим состоянием, выходящую наружу (на процессор) - inout std_bit_vector.
А дальше - детектируя входящий адрес, создаю кучу внутренних CS-ов, умножаю их на сигнал OE (output enable) и по результату уже на внутреннюю шину вывожу требуемые данные.

А как это превращается в мультиплексор - только квартус знает

еще и асинхронный?! ужас

можете посмотреть в чмп-планнере

2 Вовка_Бызов
у данного чипа есть выход клока EMIF-а наружу. Быстрей него работать не будет (если интересно как оно там всё колбасит - читайте SPRU/DS). Потому используйте его и будет вам счастие

А какой смысл в синхронном обмене при работе с регистрами? У меня нет потоковых данных. Шина данных - 32 разряда.

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

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


В курсе. Там у меня 166 МГц. Сам же и настроил. дело в другом. Я на осциллографе вижу, как на шине данных информация появляется с задержкой по отношению к сигналу OE. И задержка существенная (~10..12нс).

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

если читать более одного регистра за раз : синхронный режим + read_latency

не может быть

Мне кажется, что стоит рассмотреть работу EMIF в синхронном режиме и регистр на выходе этого дерева мультиплексоров. Все входные сигналы EMIF тоже синхронизировать. Задержка чтения получится 2 такта.

После этого будет проблема с OE, он медленно идет от TMS, потом через ПЛИС и до буферов. Можно в таком случае попробовать его не использовать, а эмулировать внутри ПЛИС из чипселекта и сигнала чтения/записи.

А сигнал чтения/записи - это кто? Я до сих пор считал, что HaWE - это сигнал записи, а HaOE - сигнал чтения. Оба идут достаточно медленно. Можно, конечно, разнести CS-ы на читаемые и записываемые.. Но тогда - зачем синхронный режим, если и так получается достаточно быстро. Замечу еще раз - у меня достаточно редко читаются регистры.. И уж точно, что у меня нет потока данных из них. А синхронный режим в первую очередь удобен, когда есть постоянный обмен.
Проблема в том, что расширяя OE, я фактически останавливаю на это время процессор.. Пока думаем над ПДП.

А с TimeQust - ну не въезжаю я в логику построения SDC файла. Что туда пихать надо, когда оно берется, когда запускать Analizer.. Те "для чайников" описания, что в гугле лежат - это, может для девочки-третьекурсницы полезно - чтобы не въезжая ответить что-то преподу.. А вот толкового описания сути я так и не нашел

Объясните мне, граждане...
Как такие вопросы можно обсуждать без (блок-)схемы и (желательно)временных диаграмм?

На самом деле, не все так...
1. Синхронный режим нужен для того, чтобы не получить метастабильность... Даже если чтение идет редко, то все равно выигрыш будет. Т.к. при асинхронном чтении один такт всегда надо дать на запас...
2. Попробуйте сделать косвенную адресацию. Из процессора запишите "Адрес" в ПЛИС. И потом читайте "Данные". При этом сделайте так, чтобы получив "Адрес" командоаппарат в ПЛИСе сам записал в буфер обмена нужный пакет. И получив Флаг, можно читать все из ФИФО, не делая дешифрацию. Да, появится задержка. Но ведь можно и команду записи Адреса сдвинуть ВПЕРЕД на нужное количество тактов...

Синхронный режим удобнее тем, что его проще обконстрейнить. Проще же ведь написать один констрейн на клок, чем кучу констрейнов на асинхронную логику?

Метастабильности, по идее, не должно быть исходя из того, что все процессы, относящиеся к вводу/выводу со стороны процессора, тактируются сигналом AECLKOUT (тактовая частота EMIFA). Данные извлекаются из регистров, для которых сигналы записи есть производная от указанного клока.

вы первый с таким отзывом о моих статьях



что там обсуждать то? EMIFA обычная процессорная шина с двунаправленной шиной данных. Асинхронный режим прост, но не удобен. Куда лучше взять синхронный с латентностью.