Алтера: описание внешнего такта, 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 рассчитал. Или может не туда смотрел?

[des333]

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

Добавив в ваш код триггер, тактируемый мастер клоком, и несколько lcell, я получил следующее:

Код

`define SEVEN_LCELL

module count (    
  input master_clk,
  output out_clk,
  input ret_clk,
  input d,
  output reg o
);

logic d1;
logic t1, t2, t3, t4, t5 , t6, t7;

`ifdef SEVEN_LCELL

  lcell lcell1 (master_clk, t1);
  lcell lcell2 (t1, t2);
  lcell lcell3 (t2, t3);
  lcell lcell4 (t3, t4);
  lcell lcell5 (t4, t5);
  lcell lcell6 (t5, t6);
  lcell lcell7 (t6, t7);

`else

  lcell lcell1 (master_clk, t1);
  lcell lcell2 (t1, t7);

`endif



assign out_clk = !t7;

always @(posedge ret_clk)
d1 <= d;

always @(posedge master_clk)
o <= d1;

endmodule

При этом .sdc файл остался неизменным:

Код

create_clock -name mclk -period "100 MHz" master_clk
create_generated_clock -name gclk -source master_clk -invert out_clk
create_generated_clock -name rclk -source out_clk -divide_by 2 -offset 1 ret_clk
set_clock_uncertainty -to [get_clocks rclk] 1

На команду:

report_timing -from_clock { rclk } -to_clock { mclk } -setup -npaths 1 -detail path_only -panel_name {Report Timing}

мы получаем следующее результаты.


При 2-х lcell:

Worst case slack is 2.802

При 7-ми lcell:

Worst case slack is 2.802

Если же добавить в .sdc файл строку:

set_clock_latency -source 0 [get_clocks {rclk}]

то результаты будут следующие:



При 2-х lcell:

Worst case slack is -2.211

При 7-ми lcell:

Worst case slack is -4.194

Вопрос:

почему при добавлении вышеуказанной строки появляется разница в задержке при разном количестве lcell, а при отсутствии этой строки количество lcell не задержку никак не влияет?

Сообщение отредактировал des333 - Jan 24 2010, 20:20