Переход шины данных выполняется из домена 275МГц в домен 137,5МГц(децимация после фильтра). Причём STA на эту шину смотрит весьма положительно(см. скриншот). А сигнал-тап показывает в районе курсора явный "выбой" четырёх бит из шины. И по поведению в проекте я вижу что после децимации сигнал очень шумный(полно "иголок"). Сетапы-холды соблюдаются а шина "крошится". Это как? Что посоветуете, коллеги? Вообще-то я всегда доверял STA.

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

1). Здесь data50 в домене 275, а data50r в домене 137,5МГц

2). Вы не правы.

Ставьте через 2 регистра, либо через разноклоковое FIFO, либо рукопожатиями (handshake).

handshake здесь никаким боком. Согласно отчёту STA должно работать и с одним регистром. При нарушениях метастабильности "выбой" бит имеет другой характер.
А насчёт фифо - это версия резервная,уж больно с ресурсами напряг.

Вообще нет смысла гнать всю шину через 2 регистра. Можно это сделать с сигналом "готовность" и по его приходу читать данные...

Не знаю что за оболочка. Но для Xilinx например отлично переход получается если оба клока сгенерены из одного делением на два.

Где глюк если честно по картинкам не понял



iclk2x это 275 МГц? Должна же быть половинная?

все советы для асинхронных доменов

а data50 тикает каждый такт на 275 или через один?
может поэкспериментировать с привязкой этого "через один" - то есть добавить регистр с енабле на 275, а это енабле с т-триггера или его инверсии
ну или фазу этого 137.5 подвигать, они же из одной PLL идут?

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

upd: со STA картинку посмотрел - а с холдами там все хорошо? каким констрейном задано? все-таки multicycle по холдам неочевидно

Вполне возможно
Однако домены то разные могут быть. Могут быть полностью асинхронные и независимые друг другу. Тогда в SDC указывают (во всяком случае я сразу пишу, чтобы Timequest не анализировал эти пути):

Вот в этом случае либо DCFIFO либо Handshake.
А могут быть где частота другого домена, получена делением частоты исходного домена. Как у Вас.
Вот тут уже есть варианты.
1. Частота получена на обычном PLL.
2. Частота получена делением на триггере.
Обязательно должны быть указаны констрейны на эту частоту.
Я ещё применяю в этом случае альтеровский примитив. Хотя вроде Quartus должен его впихнут автоматом. Но это не точно.


А можно просто формировать сигнал валидности данных, и не заморачиваться с клоковым доменом

Ребята, давайте жить дружно... Какая готовность? Шина идёт с выхода фильтра, поток идёт непрерывно.
А второй регистр,согласен, конечно смысла не имеет.


1).data50 тикает каждый такт на 275МГц.
2). Насчёт фазы - есть ещё куча всего разного в этих доменах, стоит 10 раз подумать прежде чем крутить...
3). Я тоже в ступоре... У меня был рабочий проект с банком из пяти фильтров, заказчик попросил добавить ещё один фильтр и пошло-поехало...


Сорри, это я недорассказал...
Intel Quartus
iclk2x - 137,5МГЦ
iclk4x - 275МГЦ (в этом домене порождается шина data50)
Клоки из PLL

А приложите сюда SDC файлик. Дюже интересно посмотреть, что там происходит.

> 1).data50 тикает каждый такт на 275МГц.

еще раз про hold-ы напишу

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

Увы не знаю по этому буду гадать по общей теории.
Вот верно ли учтено их фазовое соотношение на выходе?
Частоты делённые получены делением или тоже с PLL?

Софт из Xilinx делитель понимает сам и никакие времянки уточнять ручками не нужно.

Но были глюки такого плана когда делители на 2 и на 4 запускались не синхронно и прошлось на них заводить сигнал ресет. Возможно у вас тот же глюк.

Виноват, не заметил...

Делители на 2 и на 4 синхронные между собой?

Клок 275МГц используется ещё для приёма данных DDR из АЦП, поэтому режим работы PLL - source-synchronous. Делителей как таковых нет, только PLL.

В смысле две PLLки работают от одной опорной частоты с разными коэффициентами умножения?

Почему две? Одна с выходными клоками 275 и 137,5МГц.

И все-таки по поводу sdc: вы бы привели его здесь.
Там все что нужно прописано? Всякие derive_clock_uncertainty derive_pll_clocks ?

_Anatoliy, если я правильно понял, то вы пытаетесь сделать децимацию просто уменьшив частоту шины в 2 раза. Шина бьётся, поскольку 137.5MHz домен защёлкивает данные которые в этот момент меняются в 275MHz домене:



Решение проблемы очень простое. Нужно саму децимацию сделать в 275MHz домене, просто отбрасывая каждый второй отчёт. Шина данных DATA_DEC будет переключаться в 2 раза медленнее. Теперь можно перепрыгнуть в другой домен (только частоту 137.5MHz на PLL нужно будет инвертировать). Переход будет безопасным, т.к. активный фронт 137.5MHz частоты будет посередине активной фазы на шине данных:



STA надо будет предупредить, чтобы он этот переход не анализировал.

1). Если в задании отсутствует команда derive_clock_uncertainty то Квартус выполняет её автоматически, о чём сообщает в репорте.
2). Я пользуюсь командой derive_pll_clocks однократно - при создании проекта(ну или при полной пересборке). Мне не нравятся имена, которые эта команда присваивает клокам. Предпочитаю сам назначать удобные мне имена.
3). Мультициклы в данном случае объявлять не нужно.
А это описание клоков:



А чем Вам не нравится первая картинка? Если сетапы и холды выдержаны то всё будет работать на ура. STA мне сообщает что выдержаны.
Конечно во втором случае запас по сетапу будет гораздо больше.

Почему? Пусть анализирует. Но в этом случае уже понадобится описание мультициклов.
p.s. После установки полифазного варианта децимирующего фильтра эта проблема ушла.

Верю, что и первый вариант может работать. Просто реализация второго варианта требует всего 21 триггер (20 бит - шина + 1 для enable чёт/нечёт) и инверсию клока 137.5MHz, что практически ничего не стоит по ресурсам. Таким образом компилятор будет меньше напрягаться с выдерживанием строгих таймингов, вы улучшите переносимость кода (будет работать и на медленных ПЛИСах).


Да, согласен, лучше так.

P.S. и да, справедливости ради, товарищ yes первый предложил эту мысль, просто я не внимательно прочитал.

Что ж удобные имена это действительно удобно. Однако, в вашем описании клоков есть -phase 161.98 -phase 80.98. Насколько это верно?
Может имеет смысл попробовать с derive_pll_clocks? Правильно ли вы описали клоки? Если будут отличия - то это и будет вопрос отличий.
Что касается мультициклов, то как я понял, у вас времянка сходится, а работает не так как ожидается. Т.е. мультициклы ни при чем.

На этих клоках ещё много чего работает, фазовый сдвиг для клока 275Мгц выбирался из соображений стыковки с другими блоками. Частоты 275Мгц и 137,5МГц отличаются в два раза, следовательно если сделать сдвиг для 137,5МГц в два раза меньше то разность фаз клоков будет равна нулю.

Отличий быть не может в принципе, т.к. описания клоков я беру из репорта STA при объявленном derive_pll_clocks, потом только меняю имена.


Не понял Вашу логику. Я же выше сказал что мультициклы для моего случая объявлять не нужно.