[Yuri124 1]

29 minutes ago, zombi said:

100 ps на ~1.0 см ?

По плате где-то около 200 000 км/сек скорость распространения. Зависит от разводки довольно заметно (расстояние от проводков до возвратной земли  + диэлектрическая проницаемость).

[zombi 0]

1 hour ago, Yuri124 said:

По плате где-то около 200 000 км/сек скорость распространения.

Ясно. Буду знать.

1 hour ago, Yuri124 said:

Вот как сделано в том примере:

Вот, вроде сделал как в документе советуют.

sdc поправил и убрал всякие сдвиги фазы (т.е. выход PLL [C0] = [C1]):

create_generated_clock -name  {CK} -source [get_ports {CLK25}] -multiply_by 5 [get_nets {Inst_PLL|altpll_component|auto_generated|wire_pll1_clk[1]}]
set_output_delay -clock {CK} -reference_pin [get_ports {PCK}] 0.8 [get_ports {PRAS PCAS PWE PAA[*] PBA[*] PDQ[*]}]

отчёты :

Вроде всё укладывается, работать должно, но что-то мне не нравится.

На диаграмме setup Data Requred много дальше фронта Latch.

На hold тоже как-то непонятно от чего оно эту задержку 0.8 нс отнимает.

Может я опять чего накосячил с констрейнами?

 

 

[Yuri124 1]

30 minutes ago, zombi said:

setup Data Requred много дальше фронта Latch

смотрите задержку этого клока: 2,953 нс. Это - насколько я понимаю, путь от определенного на выходе PLL generated_clock -name  {CK}до вых пина, относительно которого и считаются setup и hold.

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

ИМХО на диаграмме временных соотношений просто и понятно только то, что относится к launch clock. А с latch clock не наглядно из-за того, что рассчитывает требуемый минимум (или максимум, с какой стороны смотреть) "в обратную сторону" от фронта этого клока. 

[zombi 0]

Агаааааа.... Т.е. реальный фронт Latch на пине где-то там в далеке аж на +2.953 нс!!!

Вот теперь буду спасть спокойно!  СПАСИБО ОГРОМНОЕ!!!

[Yuri124 1]

10 minutes ago, zombi said:

Вот теперь буду спасть спокойно!

Не так сразу. Просмотрите подробный путь. У Дениса Шехалева в примерах был случай, когда квартус рапортовал полный порядок. а на деле, в подробном пути, он по какой-то причине (для меня так толком и оставшейся непонятной, несмотря на все усилия и курение исходного свода команд sdc) пропустил одну заданную в констрейнах задержку.

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

[zombi 0]

2 hours ago, Yuri124 said:

Не так сразу. Просмотрите подробный путь.

Глянул :

Немного выходы переставил, чутка переименовал, в ограничении указал  задержку 1.5 нс.

Но это не важно, ограничение задал правильно.

Но по диаграмме вроде как 2.944 нс, а по path все 4.462 .

Похоже таки квартус 1.5 нс где-то скрысил. 

И в отчётах именно на 1.5 нс не совпадает.

А может я не там смотрю...?

 

[zombi 0]

Гляньте пожалуйста еще ограничение на input.  tAC max 5.4 нс  tOH min 2.5 нс.

На диаграмме CLK - это мой PCK выходной пин плис.

В scd добавил строку:

set_input_delay  -clock CK -reference_pin [get_ports PCK] [expr 5.4-8.0] [get_ports PDQ[*]]

5.4 это tAC, 8.0 - период clk.

Защёлкиваю шину DQ клоком плис clk на один такт позже (не на фронте T3 а на T4),

т.к. (задержка клока (PCK) 3.463) + (tAC 5.4) + (задержка входа плис 3.859)=12.722 нс, что уже больше периода clk.

Вот отчёт :

Подскажите всё ли нормально?

Я эти констрейны input_delay первый раз в жизни пишу, впрочем как и все другие констрейны тоже. 

[Yuri124 1]

On 7/31/2020 at 6:39 PM, zombi said:

по диаграмме вроде как 2.944 нс, а по path все 4.462 .

Похоже таки квартус 1.5 нс где-то скрысил

В отчете показан реальный путь сигнала CK, на диаграмме - рассчитанное максимально допустимое время прихода данных - с учетом 1,5 нс в констрейне.