Доброго времени суток!

Мигрировал дизайн с четвёртого Циклона на пятый, и появились recovery violations reset-сигнала... Значит есть два клок домена, один на 250 МГц и второй на 125 МГц, без сдвига по фазе. Reset синхронизируется на 125 МГц и распределяется по обеим доменам. Оба клока и reset проводятся через клок буферы (смотрим картинку). TimeQuest показывает, что reset-сигнал не попадает вовремя на триггера 250 МГц-ного домена. Вижу два варианта:

1. Ввести multicycle constraint на reset в 250 МГц домене в стиле:

set_multicycle_path -setup -from [get_registers *iSysSyncReset*rst[0]] -to [all_registers] 2
set_multicycle_path -hold -from [get_registers *iSysSyncReset*rst[0]] -to [all_registers] 1

2. Для 250 МГц домена генерировать отдельный reset с помощью сдвинутого по фазе 125 МГц клока.

Что вы на эту тему думаете? Заранее спасибо!

в отчете привели бы расшифровку задержки. откуда там 5нс data delay? набрали на clkctrl блочке ?

К сожалению не могу истолковать цепь задержки:

И шо Вы хотели?
Вы привязали reset к 125МГц клоку и подали его асинхронно в 250МГц домен. Оно и в жизни работать не будет нормально...

Объясните мне, как reset может стать асинхронным в одном из доменов если он синхронизируется к одному из клоков которые привязанные друг к другу по фазе?

1) .... Значит есть два клок домена....
Клок домены обычно асинхронны...
2) Так как Вам в репорте тулза и написала.
3) Может Вам эти домены с PLL и не нужны?

Скорее всего это правда, которую синтезатор сам вряд ли поймёт, хотя теоретически косвенно можно было это автоматически определять по настройкам ядер. В чём проблема поставить синхронизаторы на каждый домен? Имхо, может это более избыточное (на 2 триггера!), но более прозрачное решение, чем сложные констрейны и клоки со сдвинутыми фазами..

Кнстрейны ошибки не исправляют, а выявляют

Вы правы отчасти. То, что вы говорите относится к п.2. То, что я - п.1. Среда использует некоторые констрейны, чтобы корректно разложить дизайн по кристаллу.

Timing Constraints Strategies:

1. Allows the software to create a design that meets your requirements.
2. Allows you to compare the constraints to the performance of the resulting design, using the timing reports output by the ISE software. By analyzing the timing reports, you can identify the paths in the design that may require coding modifications, placement directives, or additional constraints to achieve timing closure.

Сделать два ресета, каждый в своем домене под свои клоки...
У Ксайлинкса при установке есть пример, там именно так и сделано...

да...но только там обмен данными между доменами...
На старте надо аккуратно, ато может с 250 пойти в 125, которое есчё в ресете....

Если обмен данными идет с подтверждением, то - не страшно. А если нет, то конечно надо учесть...

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

Так и думал. По толкованию там же написано : 2.385нс сигнал шел до clkctrl (который стоит в углу чипа), на нем задержался на 0.3нс и затем еще ~1.7нс шел до конкретного триггера. поэтому, не смотря на то что клоки синфазны, времянка и валится. Лечить можно убрав ненужные задержки, например сделав сброс локальным (поставить синхронизатор сброса рядом с модулем в домене 250МГц). Двигать фазу 125МГЦ ИМХО абсолютно пустое.

UPD. Мультициклами подобную постоянную задержку тоже можно лечить, но там может нарушение по холду вылезти, когда наоборот задержки будет не хватать.


она абсолютно другое написала. давайте будем внимательнее читать вопрос, перед тем как отвечать

@des00: Спасибо, завтра буду разбираться.

На самом деле мою проблему можно уменьшить до следующей: в пятом Циклоне нельзя сбросить триггеры в дизайне, у которого рабочая частота 250 МГц если сброс синхронизируется к тому же клоку. Все проблемы в задержках clkctrl как правильно заметил des00.

Моё решение заключается в ведении второго 125МГц клока, сдвинутого по фазе с соответствующими multicycles:

create_clock -name clk -period $clk_125M_period [get_ports {clk}]
create_clock -name clk_2x -period $clk_250M_period [get_ports {clk_2x}]
create_clock -name arst_sync_clk -period $clk_125M_period -waveform {6.0 10.0} [get_ports {arst_sync_clk}]

set_clock_groups -asynchronous -group { clk clk_2x arst_sync_clk}

set_multicycle_path -setup -from [get_registers *iSysSyncReset*rst[0]] -to [all_registers] 2
set_multicycle_path -hold -from [get_registers *iSysSyncReset*rst[0]] -to [all_registers] 1

PLL в SDC нет, дабы было более ясно.

Теперь вернёмся к вопросам в стиле: Почему не сделать так как все нормальные люди делают (в Ксайлинксе)?

Сброс в Ксайлинксе (по крайней мере в Спартанах) разводиться не через дерево клока как в Алтере а через general routing resources. Там P&R отвечает за дупликацию последнего триггера синхронизирующего сброс. Получается что-то в стиле сбалансированного по задержкам дерева сброса.

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