Всем доброго времени суток.

Собственно вопрос простой: как правильно ( ну или кто как делает) выдавать и защелкивать данные в синхронной схеме? По одному фронту или по разным?

Вопрос конечно общий, но проблема у меня по нему весьма конкретная. Делал проекты для Cyclone III,IV под квартусом. Все время ставил разные запускающие и защелкивающие фронты. Проекты были низкочастотные (до 100 МГц), поэтому ухудшающийся setup time меня особо не волновал, зато hold time автоматом выходил примерно в районе setup time - c запасом. TimeQuest вообще не использовал.

Сейчас решил сделать "как все нормальные люди" по одному фронту. И, как я и ожидал, воткнулся со временем удержания(hold time). Причем даже там, где время удержания укладывается в допустимые рамки, укладывается оно на тоненького - slack около 0.7 - 1нс. Задержка данных - около 6нс. Соответственно, клоки разбегаются примерно на столько же. Клоки висят на глобальных шинах, т.е. по идее разбег должен быть минимальным ( когда убрал global clock логично стало еще хуже - slack ухудшился примерно на 0.8нс). Я не пойму, толи данные так мало задерживаются ( в это с трудом верится - 6нс по-моему самая обычная задержка), толи клоки необычно сильно разбегаются ( в это верится гораздо сильнее).

На сколько вообще такая картина нормальна при работе по одному фронту? Поделитесь соображениями.

Работа по одному фронту - единственно правильный вариант для тригерных схем.
(к специальным примитивам типа DDR тригер это не относится).

если учесть что th для триггеров того же сыклона отрицательный, то запас в 0.5 - 1нс более чем %)

Так то оно так, вот только я с этим "единственно правильным вариантом" получил hold time violation, проблему которой раньше у меня не существовало в принципе.

Хрен с ним уже с зазором в 0.5-1нс (там по крайней мере все формально укладывается). Основная проблема в том, что hold time violations появляются иногда при переразводке. Я честно говоря не знаю даже как с ними бороться. Задержки что ли на данные ставить? Я бы и поставил (хотя это дебилизмом отдает), да только нет гарантии, что они не исчезнут после синтеза. Самое интересное, что сам Quartus эти задержки не добавляет, точнее добавляет, но недостаточно. Пишет "routing delays are added to meet hold timing", но при этом в конце компиляции пишет отрицательный slack (зеленым цветом - якобы все нормально), а TimeQuest выдает hold time violation. Это тоже кстати непонятно..

Почитал альтеру, пишут дескать если gated клоки не использовать, возможность hold time violation исключена, т.е. клоки на глобальной шине не разбегаются совсем:-) Нет, частично они конечно правы, у меня violations возникали на RAM-блоках, к ним читающие и пишущие клоки через мультиплексор идут (чтобы режимы доступа переключать) оттуда и дополнительная задержка. Ну да ладно, бог с ними с RAM-блоками, у меня при анализе обычных регистров (где нет gated клоков) TimeQuest показывает разбег клоков в районе 1.2 нс. Это называется "не разбегаются совсем" надо думать)) Задержка данных при этом 1.3 нс. Получается, что очень даже разбегаются!)

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

Ну 1.2 меньше чем 1,3. Значит, с достаточной степенью не разбегаются. А эти числа из TimeQuest - для худшего случая, в реальности микросхемы обычно несколько лучше.

Не получится наверное. У меня память переключается между внутренним доступом (из логики ПЛИС) и внешней асинхронным интерфейсом процессора.



В общем да, я обычно зазор какой-то ставлю именно на случай дрейфа напряжения, температуры, а в этих цифрах, я так понял, уже все учтено.

Поэкспериментировал с set_min_delay - рабочая вещь. Я поначалу думал, что fitter не особо на нее внимание обращает при разводке, оказалось еще как обращает. Поставил на 1 нс - fitter добросовестно добавил задержки на линии данных, поставил на 2 нс - добавил еще. Единственно где не смог - это когда выход с логической ячейки подается на вход, там время удержания получается примерно 0.6 нс стабильно и не изменяется. Но это судя по всему - выше крыши. Да и учитывая, что на одной логической ячейке разбега клоков по определению быть не может, проблем в таких местах со временем удержания возникнуть не должно.

В общем, я для себя такой вывод сделал: проще всего конечно работать по одному фронту, но тут обязательно надо юзать TimeQuest при любых частотах проекта. Причем подключать sdc-файл к проекту, чтоб разводил соответственно, а то hold violation можно на раз получить. Ну и на крайняк использовать специальные констрейны типа set_min/max_delay- весьма рабочая штука.

При работе по разным фронтам проект конечно криво смотрится, но зато где-то до 60 МГц про TimeQuest можно забыть - все работает как часы. У меня во всяком случае проблем не было никаких (на Cyclone III, IV).

Большое всем спасибо за советы!

Интерфейс процессора настолько быстр, что сделать переход на внутреннюю тактовую не получается?

Системная частота у процессора 120МГц. Длительность сигналов записи и чтения может уменьшаться до длительности одного такого такта, т.е. надо внутреннюю частоту раза в два поднимать, чтоб наверняка. Не очень хочется с этим возиться, тем более что проблема куда проще решается. Не так уж страшен gated clock, как его малюют))

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

Вопрос: у Циклона III же, если не ошибаюсь, должны быть двухпортовые блоки памяти, аналогичные BlockRAM у хилых - там в принципе можно просто подключить двух абонентов в расфазированными клоками (напр. процессор снаружи и логику, сделанную в самом ПЛИС).

Они двухпортовые в смысле отдельный интерфейс на чтение, отдельный на запись. Если записывают два разных источника, все равно приходится их переключать.

Это один из режимов, simple dual port. А ещё есть режим true dual port, когда два порта работают абсолютно независимо, и каждый из них может и читать и писать.

Там общая шина адреса для чтения и записи, т.е. один порт не может независимо писать и читать

Вы что-то путаете
http://www.altera.com/literature/hb/cyc3/cyc3_ciii51004.pdf
Страница 11. Два независимых порта. Из того же хендбука: "True dual-port (one read and one write, two reads, or two writes) operation". То есть можно по двум портам писать одновременно. Естественно не по одному адресу.

А что мешает синхронно переключать режимы чтения и записи? Если не хватает пропускной способности, можно запустить память на двойной частоте, и сделать фиксированное чередование тактов чтения/записи, будет выглядеть как четырёхпортовая.

В общих чертах понял, что вы имеете ввиду. Детально плохо представляю. Так или иначе, просто из общих соображений, идея синхронно переключать асинхронный доступ мне уже не нравится. Это опять же, чтобы все гладко было частоту надо в два раза поднимать т.е. 240МГц. Даже если получится, городить такой огород только ради того, чтобы избавиться от gated clock?)) Как по мне, так мультиплексор куда проще воткнуть.

Интересно, у вас процессор с асинхронным двухпортовым интерфейсом быстрее 100МГц? Это что за зверь такой? Gated clock на асинхронном интерфейсе при необходимости можно использовать, гораздо страшнее асинхронный арбитраж между двумя мастерами, что создаёт возможность защёлкнуть метастабильное состояние на регистрах блочной памяти.

А можно ли настроить какой-нибудь последовательный порт процессора (SSC, SPI и т.п.) на постоянную выдачу системной тактовой? Если да, то завести её на PLL, там получить оптимально сдвинутый по фазе клок для плиски...