[MegaVolt 25]

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

[_sda 0]

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

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

[MegaVolt 25]

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

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

[_sda 0]

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

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

[dvladim 0]

И все-таки по поводу sdc: вы бы привели его здесь.

Там все что нужно прописано? Всякие derive_clock_uncertainty derive_pll_clocks ?

[Inanity 1]

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

 

 

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

 

 

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

Изменено 1 июня, 2018 пользователем Inanity

[_sda 0]

И все-таки по поводу sdc: вы бы привели его здесь.

Там все что нужно прописано? Всякие derive_clock_uncertainty derive_pll_clocks ?

1). Если в задании отсутствует команда derive_clock_uncertainty то Квартус выполняет её автоматически, о чём сообщает в репорте.

2). Я пользуюсь командой derive_pll_clocks однократно - при создании проекта(ну или при полной пересборке). Мне не нравятся имена, которые эта команда присваивает клокам. Предпочитаю сам назначать удобные мне имена.

3). Мультициклы в данном случае объявлять не нужно.

А это описание клоков:

create_generated_clock -source {spll2|pll2_inst|altera_pll_i|general[0].gpll~FRACTIONAL_PLL|refclkin} -divide_by 2 -multiply_by 10 -duty_cycle 50.00 -name {spll2|pll2_inst|altera_pll_i|general[0].gpll~FRACTIONAL_PLL|vcoph[0]} {spll2|pll2_inst|altera_pll_i|general[0].gpll~FRACTIONAL_PLL|vcoph[0]}
create_generated_clock -source {spll2|pll2_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|vco1ph[0]} -divide_by 5 -phase 161.98 -duty_cycle 50.00 -name {clk275} {spll2|pll2_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk}
create_generated_clock -source {spll2|pll2_inst|altera_pll_i|general[2].gpll~PLL_OUTPUT_COUNTER|vco1ph[0]} -divide_by 10 -phase 80.98 -duty_cycle 50.00 -name {clk137_5} {spll2|pll2_inst|altera_pll_i|general[2].gpll~PLL_OUTPUT_COUNTER|divclk}

 

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

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

Конечно во втором случае запас по сетапу будет гораздо больше.

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

Почему? Пусть анализирует. Но в этом случае уже понадобится описание мультициклов.

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

[Inanity 1]

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

Конечно во втором случае запас по сетапу будет гораздо больше.

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

 

Почему? Пусть анализирует. Но в этом случае уже понадобится описание мультициклов.

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

 

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

[dvladim 0]

2). Мне не нравятся имена, которые эта команда присваивает клокам. Предпочитаю сам назначать удобные мне имена.

3). Мультициклы в данном случае объявлять не нужно.

Что ж удобные имена это действительно удобно. Однако, в вашем описании клоков есть -phase 161.98 -phase 80.98. Насколько это верно?

Может имеет смысл попробовать с derive_pll_clocks? Правильно ли вы описали клоки? Если будут отличия - то это и будет вопрос отличий.

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

[_sda 0]

Что ж удобные имена это действительно удобно. Однако, в вашем описании клоков есть -phase 161.98 -phase 80.98. Насколько это верно?

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

Может имеет смысл попробовать с derive_pll_clocks? Правильно ли вы описали клоки? Если будут отличия - то это и будет вопрос отличий.

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

 

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

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