Алтера: описание внешнего такта, TimeQuest, Как корректно описать такт в SDC? Опции

[solidreg]

Нужна помощ с описанием внешнего такта в SDC языке для TimeQuest (Altera)
У меня PLL генерирует 200MHz и 50MHz такты. Этот 200MHz идёт сразу на внешний чип, каторый делит этот такт на два, и через кокое то время (скажем, 3nS) посупает опять на FPGA. И потом этот сигнал пользуется как такт в внутренних цепях.
Нарисовал картинку чтоб было бы ясно.


Написал так:

Код

create_generated_clock -source <..PLL> -name MHz50
create_clock -period 10.000 -name MHz100 [get_ports {Clk2}]

Но как правильно описать эту задержку (фазу)?

[des333]

Если добавить строчку:

Код

set_clock_latency -source 0 [get_clocks {clk100MHz}]

то задержка lcell начнет учитываться.

[des00]

Если добавить строчку:

Код

set_clock_latency -source 0 [get_clocks {clk100MHz}]

то задержка lcell начнет учитываться.

Точно, занятно. Значит таймквест, утвержая

Warning: No paths exist between clock target "iclk100MHz" of clock "clk100MHz" and its clock source. Assuming zero source clock latency.

нагло врет в текстовой форме %)

[des333]

Точно, занятно. Значит таймквест, утвержая
нагло врет в текстовой форме %)

Возможно разработчики имели в виду, что TQ не будет учитывать никакие задержки связанные с источником этого клока.

[SM]

Возможно разработчики имели в виду, что TQ не будет учитывать никакие задержки связанные с источником этого клока.

Разработчики имели в виду, что не будет учитываться задержка от source (указанного ы ключике -source) до таргета, указанного без всяких ключиков в конце команды. Т.е. будет, но она равна нулю, так как ее он сам посчитать не может. Но не никакие - ручная set_clock_latency - будет. Оффсеты и фазы от генерейтед-клока - будут.


ЗЫ. des00 - а почему у вас там все называется TQ для чайников? Когда в реальности это скорее SDC для чайников, с примерами на TQ.

[des333]

Разработчики имели в виду, что не будет учитываться задержка от source (указанного ы ключике -source) до таргета, указанного без всяких ключиков в конце команды. Т.е. будет, но она равна нулю, так как ее он сам посчитать не может. Но не никакие - ручная set_clock_latency - будет. Оффсеты и фазы от генерейтед-клока - будут.

Тогда не понятно, почему добавление lcell'ов при отсутсвии ручной set_clock_latency не влияет на результат, при наличии же

ручной set_clock_latency=0 влияет?

В чем разница автоматического приравнивание к нулю, так как TQ сам ее посчитать не смог и ручного приравнивания к нулю? 

[SM]

В чем разница автоматического приравнивание к нулю, так как TQ сам ее посчитать не смог и ручного приравнивания к нулю? 

Ну я разницы-то не заметил, в моем примере он четко берет фронт выходного клока out_clk с учетом всех его задержек и еще и offset-а. Эти задержки еще второй create_generated_clock рассчитал. Или может не туда смотрел?