Вы одно с другим путаете. Может быть в асинхронных магистральных интерфейсах вы и правы. Но тут стоит проц, на его шине висит фпга, Шина параллельная, синхронная, работающая в асинхронном режиме (расстояние между процом и фпга не выше ~10см). CLKOUT определяет на шине все. Если посмотрите внимательно на картинку то видно что проц выдерживает и setup/hold самостоятельно. Еще раз при работе от CLKOUT (source-synchronus) синхронизаторы ставить вообще смысла нет, адрес/данные это мултицикл, нужно только вырезать фазу сигнала записи/чтения. А при работе на клоке фпга в асинхронном режиме, ставить синхронизаторы как это делаете вы тоже смысла не имеет, т.к. проц опять же выдерживает setup/hold. Смысла в синхронизаторах на адресе/данных нет.

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

Я выше написал, что согласен насчет не-нужности двукаскадных схем синхронизаций для УЖЕ синхронного интерфейса. Тем не менее, первый каскад защелок кмк все равно надо ставить, даже если пути - малтисайкл. Точнее не так -
Если исходить из концепции простоты дизайна и нацеливаться на low power asic, то можно сразу ставить защелки с использованием незащелкнутых управляющих сигналов - т.е. делать простой интерфейс "как на россыпи".
Но! Если требуется стабильная и быстродействующая прошивка для ПЛИС, или же мы боремся со снижением нагрузки на цепи в асике, то имеет смысл ставить один(1) каскад d-триггеров на весь входной интерфейс, и уже потом разгребать всю логику внутри. Преимущества уже указаны - снижение нагрузки на цепи. С большой нагрузкой может и мальтисайкл 3 не спасти, а про разброс времянки от_разводки_к_разводке я и вовсе молчу. По крайней мере, отлаживая модель для PCI я добивался большей производительности именно введением дополнительных d-триггеров. Впрочем, в PCI еще и адрес/данные мультиплексированы, немного сложнее ситуация.
Итого, я с самого начала не опровергаю правильность первого кода, просто указал на возможную альтернативу более синхронной реализации, со своими + и - ессно. А картинку смотрел невнимательно, сразу не понял, что интерфейс синхронный, каюсь.

Ну вы бы асики-то не приплетали... Там все на так, как в фпга, и вряд-ли товарищ на них нацелен. Кстати, что касается нагрузки в асиках, тоже все как когда. Бывает лучше триггер на входе посадить, а бывает - дерево буферов раскидать, раз на раз не приходится. Но к фпга это все равно отношения не имеет.

Да в ПЛИС все то же самое, только вариантов влево-право меньше (что хуже, на самом деле). Если забито у цепи 20 нагрузок, то хоть об колено бейся, 21 не получишь(предположим, региональные клоки и пр. заняты). Приходится лишние триггера ставить, где можно. Или представьте, что входная защелка находится прямо в i/o пине и использует в качестве CE (или OE для бидира) внешний же сигнал - это какой route получится? Вот об этом я и писал выше
Да и асик тут очень при чем получается: поскольку, отлаживается он всегда в ПЛИС, а модель писать приходится совсем не с учетом ПЛИСовских фенечек. И проблем решать приходится подчас целых две - чтобы и там и там времянка хорошая была. Тут мое твердое мнение, что модель для асика должна быть прогнана в ПЛИС на 100%, за исключением только лишь заказных блоков. Чем больше мест в коде отличаются дефайнами ПЛИС/асик, тем больше косяков потом может вылезти.

Сообщение отредактировал Shivers - Nov 23 2009, 15:10

Да получишь, без проблем. Ценой наносекунды-другой какой-то. Те же буфера деревом. Но к вопросу, уверен, отношения это ничего не имеет. Товарищу данные просто в массив писать. Там одна проволока до входа блока памяти.

Вот это уж, извините, как раз бред. Для синхронного интерфейса двойная буферизация не нужна, а для асинхронного при таком захватебудет масса проблем.

вот часть дизайна, которая перехватывает обращение к регистрам управления (cs=0, we=0, a=0).
довольно часто происходят ложные срабатывания регистров - к ним не обращались, а они отрабатывают.

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

Делал интерфейс с Блэкфином на Спартан 3. Использовал синхронный вариант + ARDY. Максимально быструю времянку получить цели не было. Что там на плате было не знаю - ваял удаленно, платы в глаза не видел. Претензий от заказчика не было.

В коде из Вашего крайнего поста не совсем понятно, почему данные защелкиваются по спаду WE (или это инвертированный сигнал AWEn?). Также было бы нелишним занести (if CS='0') then в тело (if falling_edge(WE) then) тогда это будет разрешение записи в регистр, а у Вас в терминах ПЛИС это получается непонятно что (весь код не приведен).

Если асинхронно, я бы делал так

Только при желаемых времянках (Tsetup=1clk, Twrite=1 clk, Thold =0 clk) нужно учитывать ИМХО, что например задержки от пинов CS, A, D(15:12) до триггеров должны быть не более 7,5 + (7,5 - 6) + 0,8 ns. Табличка с параметрами:

WE - обычный сигнал стробирования (активный 0)
по фронту WE почему-то некорректно работает - скорее всего из-за того что данные уже недостоверны - нужно увеличивать Hold Time



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



а вот это очень горько хотелось бы Tsetup=1clk @133MHz

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

вот полный процесс(откомментировал).

процесс должен подсчитывать байты и вычислять адрес видеопамяти. увеличение по Х и У. когда A=1
и записывать в регистры когда A=0:



смысл этого процесса в установке прямоугольной области (R_X0,R_Y0,R_X1,R_Y1) на дисплее для того чтобы потом слева-направа сверху-вниз записывать данные

прошу покритиковать или дополнить

Сообщение отредактировал %-) - Nov 24 2009, 02:41

делайте sourse-synchronus интерфейс, по другому на 133МГц при ваших времянках вы не получите стабильной работы. Или снижайте частоту интерфейса.

Еще констрейны покажите. Исходника мало.

а что такое констрейны?

только без смеха - впервые слышу это слово...

Описание требований по временным ограничениям к схеме, располагаемой внутри ПЛИС. Т.е. в Вашем случае должен быть create_clock для WE, раз по его edge работа, ну и всякие тем set_input_delay для остальных сигналов. Если используется timequest. А классик использовать не желательно.

Без четкого обконстреивания и отчета таймквеста о том, что все уложилось, это не заработает вообще.

констрейны - это ограничения, которые требуется выполнить синтезатору - мапперу, при компиляции проекта.
они могут быть :
1. по частоте
2. по физическому местоположению цепи/блока/LE на кристалле
3. по задержке распространения сигнала по цепи

где в Квартусе это указывается?

пока просто создаю проект. пробовал оптимизацию optimal на speed менять - вышло только хуже