[yes 7]

стандартная ситуация - сгенерированный клок с выхода регистра тактируемого мастером

 

вот пример с альтеры

http://www.altera.com/support/examples/tim...ated-clock.html

 

при анализе пути видно, что launch и latch клоки совпадают,

 

то есть мне (вернее апликэйшен инженерам Альтеры) вручную надо было прописать в команде

create_generated_clock -add -source clock \

-name div2clock \

-divide_by 2 \

-master_clock clock_name \

[get_pins div2reg|regout]

 

-offset __CLOCK_TO_DATA__

 

в случае EP2S из примера это __CLOCK_TO_DATA__ = 1.8ns

 

-----------------------

 

правильно или я что-то не понимаю?

может есть какая-то команда типа derive_pll_clock, которая этот offset умеет сама добавить?

 

правильно ли я вычисляю этот офсет, если это надо таки делать вручную? то есть в беру clock|dataout у флипфлопа и задержку LE-вход тактового дерева - в даташите я это не нашел и смотрю либо по чип-планеру, либо по аннотированому технологи-мэппед схематику

 

-----------------------

 

есть дизайн с достаточно жесткими требованиями на пути между такими генеренными клоками и как-то подглюкивает, пытаюсь понять, не облажался ли с констрейнами

 

собственно проблема еще в том, что вторая часть офсета (LE->CT) не постоянна и зависит от трассировки, поэтому уверенности в том, что я правильно ее задам нету

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

[slawikg 0]

-offset __CLOCK_TO_DATA__

 

в случае EP2S из примера это __CLOCK_TO_DATA__ = 1.8ns

 

-----------------------

 

правильно или я что-то не понимаю?

может есть какая-то команда типа derive_pll_clock, которая этот offset умеет сама добавить?

 

 

Внутри кристала задержку рассчитывает сам Квартус

[yes 7]

Внутри кристала задержку рассчитывает сам Квартус

на приложеной картинке видно, какие задержки расчитывает, а какие нет.

Задержка между тактовыми сигналами (LATCH CLOCK и LAUNCH CLOCK) == 0, что не соответствует реальности

 

а рассчитанные задержки "CLOCK DELAY" учитывают задержки тактовых деревьев и не учитывают задержку от тактового входа делителя до тактового дерева сгенеренного такта (которая достаточно большая 1.8нс)

 

по крайней мере я так понял

 

хотелось бы понять, можно ли заставить квартус "сгенерить" правильный констрейн так, как он это делает для derive_pll_clock

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

 

кстати, исполняя derive_pll_clock квартус почестному прописывает -phase или -offset в create_generated_clock

[des00 25]

на приложеной картинке видно, какие задержки расчитывает, а какие нет.

Задержка между тактовыми сигналами (LATCH CLOCK и LAUNCH CLOCK) == 0, что не соответствует реальности

на картинке он никогда явно не рисует эту задержку, она входит в вычисление Data Arrival/Data Required. Если посмотреть на пути, то видно что он сам учитывает задержку сгенерированного клока (рис 1).

 

ЗЫ. Занятно, но на третьем сыклоне, по холду, у меня констрейны не сошлись %)

 

UPD Неужели ква настолько отупел что не может пару LCELL ов вставить что бы путь по данным удлиннить...

 

UPD2 стояло в настройках фиттера Auto Fit (reduce Fitter effort after meeting timing requirements), поставил Standart + Optimize Hold Timing == ALL Paths и у ква получилось свести все хорошо. Странно.

 

UPD3 и в отчетах явно видно что он повел путь по-другому, удлинив его на 1нс (рис 2) %)

 

кстати, исполняя derive_pll_clock квартус почестному прописывает -phase или -offset в create_generated_clock

Кстати в примерах альтеровцы настоятельно забывают про derive_clock_uncertainty или про задание uncertainty внешнего источника. Это все при том, что ква нещадно кричит в случае отсутствия оного %)

[Des333 0]

UPD Неужели ква настолько отупел что не может пару LCELL ов вставить что бы путь по данным удлиннить...

 

Столкнулся тут как-то с интересным фактом.

 

Некоторый модуль собирался в двух вариантах: как топ-левел и как часть более крупного проекта.

 

 

 

 

При этом, когда собирается как топ-левел по констрейнам не укладывается, когда как часть проекта - все в норме.

 

Все дело в том, что в первом случае задержка клока(при одинаковой задержке данных) намного меньше и в итоге все "валится"  :)

[des00 25]

Все дело в том, что в первом случае задержка клока(при одинаковой задержке данных) намного меньше и в итоге все "валится"  :)

занятно, я давно заметил что у ква проблемы с выравниванием именно клока %)

 

ну и это еще одно подтверждение что нужно смотреть не только на факт завала констрейнов, но и на то место где именно они валяться и почему %)

[SM 0]

при анализе пути видно, что launch и latch клоки совпадают,

Видимо с анализом что-то не то. Выведите в лог все пути полностью (есть там режим, где все задержки по гейтам и трассам выводятся), и будет видно, что тут не так. Квартус всегда сам рассчитывает все задержки, и это совершенно точно. Единственный вариант, когда нужно ставить оффсет/лэтенси - это если клок выходил на прогулку вне ПЛИСы...

[SM 0]

вот пример:

 

verilog:

module time_test (input clk,
                 input d,
                 output o
                 ) ;


reg clkd;
always @(posedge clk)
 clkd <= ~clkd;

reg ra,rb;
always @(posedge clk)
 ra <= d;

always @(posedge clkd)
 rb <= ra;

assign o = rb;

endmodule

 

SDC:

create_clock -name mclk -period "100 MHz" [get_ports clk]
create_generated_clock -name clkd -source clk -divide_by 2 [get_pins clkd|q]
derive_clock_uncertainty

 

log:

report_timing -from_clock { mclk } -to_clock { clkd } -from [get_keepers {ra}] -to [get_keepers {rb}] -setup -npaths 1 -detail full_path
Info: Report Timing: Found 1 setup paths (0 violated).  Worst case slack is 8.826
   Info: -setup
   Info: -from_clock [get_clocks { mclk }]
   Info: -to_clock [get_clocks { clkd }]
   Info: -from [get_keepers {ra}]
   Info: -to [get_keepers {rb}]
   Info: -npaths 1
   Info: -detail full_path
Info: Path #1: Setup slack is 8.826 
   Info: ===================================================================
   Info: From Node    : ra
   Info: To Node      : rb
   Info: Launch Clock : mclk
   Info: Latch Clock  : clkd
   Info: 
   Info: Data Arrival Path:
   Info: 
   Info: Total (ns)  Incr (ns)     Type  Element
   Info: ==========  ========= ==  ====  ===================================
   Info:     10.000     10.000           launch edge time
   Info:     10.000      0.000           source latency
   Info:     10.000      0.000           clk
   Info:     10.000      0.000 RR    IC  clk~input|i
   Info:     10.791      0.791 RR  CELL  clk~input|o
   Info:     10.997      0.206 RR    IC  clk~inputclkctrl|inclk[0]
   Info:     10.997      0.000 RR  CELL  clk~inputclkctrl|outclk
   Info:     11.880      0.883 RR    IC  ra|clk
   Info:     12.481      0.601 RR  CELL  ra
   Info:     12.713      0.232     uTco  ra
   Info:     12.713      0.000 FF  CELL  ra|q
   Info:     14.119      1.406 FF    IC  rb~feeder|datab
   Info:     14.549      0.430 FF  CELL  rb~feeder|combout
   Info:     14.549      0.000 FF    IC  rb|d
   Info:     14.655      0.106 FF  CELL  rb
   Info: 
   Info: Data Required Path:
   Info: 
   Info: Total (ns)  Incr (ns)     Type  Element
   Info: ==========  ========= ==  ====  ===================================
   Info:     20.000     20.000           latch edge time
   Info:     20.000      0.000           source latency
   Info:     20.000      0.000           clk
   Info:     20.000      0.000 RR    IC  clk~input|i
   Info:     20.791      0.791 RR  CELL  clk~input|o
   Info:     20.989      0.198 RR    IC  clk~inputclkctrl|inclk[0]
   Info:     20.989      0.000 RR  CELL  clk~inputclkctrl|outclk
   Info:     21.836      0.847 RR    IC  clkd|clk
   Info:     22.394      0.558 RR  CELL  clkd
   Info:     22.626      0.232     uTco  clkd
   Info:     22.626      0.000 RR  CELL  clkd|q
   Info:     22.911      0.285 RR    IC  rb|clk
   Info:     23.469      0.558 RR  CELL  rb
   Info:     23.449     -0.020           clock uncertainty
   Info:     23.467      0.018     uTsu  rb
   Info: 
   Info: Data Arrival Time  :    14.655
   Info: Data Required Time :    23.467
   Info: Clock Pessimism    :     0.014
   Info: Slack              :     8.826 
   Info: ===================================================================

 

Как видим - задержка на clkd полностью учтена при рассчете Data required path

[yes 7]

спасибо.

 

был не прав, ввело в заблуждение то, что для PLL-ных клоков таймквест на картинке рисует задержку между launch clock и latch clock

 

у report_timing

есть опция -detail path_and_clock

 

---------

 

derive_clock_uncertainty для 2-го циклона (в поекте, а не в примере) смысла, как я понимаю, не имеет и игнорируется