[zombi 0]

Т.е. как я понял, однозначного ответа нет, и каждый как хочет так и интерпретирует эту величину.

Шикарно!

[Yuri124 1]

В том же документе 

Quote

The maximum input delay (-max) is used for clock setup checks or recovery checks and the minimum input delay (-min) is used for clock hold checks or removal checks

Как я понимаю - при этом предполагается, что данные существуют всё время до следующего фронта, а не в окне, привязанном к клоку.

Т.е. уже начал сомневаться относительно правильности предыдущих команд...

10 minutes ago, zombi said:

однозначного ответа нет, и каждый как хочет так и интерпретирует

А Вы как интерпретируете и понимаете?

В обычном интерфейсе данные существуют в пределах периода клока, лишь могут быть сдвинуты относительно него. Только так я могу объяснить, что по max вычисляется setup, например. 

 

 

[andrew_b 14]

Вот какой шаблон есть в Вивадо:

# Center-Aligned Double Data Rate Source Synchronous Inputs 
#
# For a center-aligned Source Synchronous interface, the clock
# transition is aligned with the center of the data valid window.
# The same clock edge is used for launching and capturing the
# data. The constraints below rely on the default timing
# analysis (setup = 1/2 cycle, hold = 0 cycle).
#
# input                  ____________________
# clock    _____________|                    |_____________
#                       |                    |                 
#                dv_bre | dv_are      dv_bfe | dv_afe
#               <------>|<------>    <------>|<------>
#          _    ________|________    ________|________    _
# data     _XXXX____Rise_Data____XXXX____Fall_Data____XXXX_
#

set input_clock         <clock_name>;      # Name of input clock
set input_clock_period  <period_value>;    # Period of input clock (full-period)
set dv_bre              0.000;             # Data valid before the rising clock edge
set dv_are              0.000;             # Data valid after the rising clock edge
set dv_bfe              0.000;             # Data valid before the falling clock edge
set dv_afe              0.000;             # Data valid after the falling clock edge
set input_ports         <input_ports>;     # List of input ports

# Input Delay Constraint
set_input_delay -clock $input_clock -max [expr $input_clock_period/2 - $dv_bfe] [get_ports $input_ports];
set_input_delay -clock $input_clock -min $dv_are                                [get_ports $input_ports];
set_input_delay -clock $input_clock -max [expr $input_clock_period/2 - $dv_bre] [get_ports $input_ports] -clock_fall -add_delay;
set_input_delay -clock $input_clock -min $dv_afe                                [get_ports $input_ports] -clock_fall -add_delay;

# Report Timing Template
# report_timing -rise_from [get_ports $input_ports] -max_paths 20 -nworst 2 -delay_type min_max -name src_sync_cntr_ddr_in_rise  -file src_sync_cntr_ddr_in_rise.txt;
# report_timing -fall_from [get_ports $input_ports] -max_paths 20 -nworst 2 -delay_type min_max -name src_sync_cntr_ddr_in_fall  -file src_sync_cntr_ddr_in_fall.txt;

 

[zombi 0]

13 minutes ago, Yuri124 said:

А Вы как интерпретируете и понимаете?

Как я интерпретирую видно на моих констрейнах - там где 40 широко по Вашему.

Но какая разница как я это понимаю?

Я спросил то именно потому что не уверен.

Думал умные дядьки помогут, подскажут.

 

set_input_delay -clock $input_clock -max [expr $input_clock_period/2 - $dv_bfe] [get_ports $input_ports];

Получается что -max 40.0 таки правильно у меня?!

[Yuri124 1]

8 minutes ago, andrew_b said:

Вот какой шаблон есть в Вивадо

Спасибо! Похоже - на входе клока определяется расчетная виртуальная частота исходя из реального периода, деленного на 2 (т.к. DDR) и временного окна, когда данные валидны.

Т.е. ТС должен заявить не 12 МГц, а что-то в 100МГц (исходя из 10 нс жизни данных)?

[zombi 0]

14 minutes ago, Yuri124 said:

Т.е. ТС должен заявить не 12 МГц, а что-то в 100МГц (исходя из 10 нс жизни данных)?

Почему я должен заявлять 100? есть реальная частота и она равна 12.

Если быть точным - период 90 нс частота 11111111 Гц

 

24 minutes ago, andrew_b said:

Вот какой шаблон есть в Вивадо:

А для SDR режима есть такой же шаблон?

[Yuri124 1]

11 minutes ago, zombi said:

Если быть точным - период 90 нс частота 11111111 Гц

Да, если такая частота точно - то Ваши и 5  и 40 нс - действительно, правильны, сыплю пепел на голову.

Если Квартус правильно поймет, что захват произойдет следующим фронтом.

Я было подумал сделать такой ход - поскольку данные валидны в течение 10 нс , то можно попробовать заявить период клока 10 нс (т.е. 100МГц), и относительно него задержку данных вот эти +-5 нс и указать. Т.е. чтобы вычислять захват данных не следующим фронтом, а текущим.

[andrew_b 14]

24 минуты назад, zombi сказал:

А для SDR режима есть такой же шаблон?

Аж два.

# Center-Aligned Rising Edge Source Synchronous Inputs 
#
# For a center-aligned Source Synchronous interface, the clock
# transition is aligned with the center of the data valid window.
# The same clock edge is used for launching and capturing the
# data. The constraints below rely on the default timing
# analysis (setup = 1 cycle, hold = 0 cycle).
#
# input    ____           __________    
# clock        |_________|          |_____
#                        |                 
#                 dv_bre | dv_are    
#                <------>|<------>  
#          __    ________|________    __
# data     __XXXX____Rise_Data____XXXX__
#

set input_clock         <clock_name>;      # Name of input clock
set input_clock_period  <period_value>;    # Period of input clock
set dv_bre              0.000;             # Data valid before the rising clock edge
set dv_are              0.000;             # Data valid after the rising clock edge
set input_ports         <input_ports>;     # List of input ports

# Input Delay Constraint
set_input_delay -clock $input_clock -max [expr $input_clock_period - $dv_bre] [get_ports $input_ports];
set_input_delay -clock $input_clock -min $dv_are                              [get_ports $input_ports];

# Report Timing Template
# report_timing -from [get_ports $input_ports] -max_paths 20 -nworst 1 -delay_type min_max -name src_sync_cntr_rise_in  -file src_sync_cntr_rise_in.txt;

 

# Center-Aligned Falling Edge Source Synchronous Inputs 
#
# For a center-aligned Source Synchronous interface, the clock
# transition is aligned with the center of the data valid window.
# The same clock edge is used for launching and capturing the
# data. The constraints below rely on the default timing
# analysis (setup = 1 cycle, hold = 0 cycle).
#
# input         _________           ____
# clock    ____|         |_________|   
#                        |                 
#                 dv_bfe | dv_afe    
#                <------>|<------>  
#          __    ________|________    __
# data     __XXXX____Fall_Data____XXXX__
#

set input_clock         <clock_name>;      # Name of input clock
set input_clock_period  <period_value>;    # Period of input clock
set dv_bfe              0.000;             # Data valid before the falling clock edge
set dv_afe              0.000;             # Data valid after the falling clock edge
set input_ports         <input_ports>;     # List of input ports

# Input Delay Constraint
set_input_delay -clock $input_clock -max [expr $input_clock_period - $dv_bfe] [get_ports $input_ports] -clock_fall;
set_input_delay -clock $input_clock -min $dv_afe                              [get_ports $input_ports] -clock_fall;

# Report Timing Template
# report_timing -from [get_ports $input_ports] -max_paths 20 -nworst 1 -delay_type min_max -name src_sync_cntr_neg_in  -file src_sync_cntr_neg_in.txt;

 

[zombi 0]

21 minutes ago, Yuri124 said:

заявить период клока 10 нс (т.е. 100МГц), и относительно него задержку данных вот эти +-5 нс и указать. Т.е. чтобы вычислять захват данных не следующим фронтом, а текущим.

Можно конечно попробовать, но зачем мне это всё выдумывать?

Есть же спец программы которые всё считают, всё учитывают и формируют репорты.

Главное им правильно сообщить о том что за ерунда происходит на входных пинах плиса, ничего не придумывая.

5 minutes ago, andrew_b said:

Аж два.

О спасибо. А то AlteraIntel не порадовал своих юзверей такими красивыми шаблонами!

[Yuri124 1]

13 minutes ago, zombi said:

правильно сообщить о том что за ерунда происходит на входных пинах плиса

Действительно - получается ерунда.  Вместо того, чтобы в sdc добавить спец. команду, описывающую валидное окно данных около клока, обманываем программу - якобы захват будет произведен следующим фронтом (спадом).

Я поначалу было подумал, что прога может неправильно посчитать tsetup - скажем, если клок будет задержан относительно начала данных на 11 нс - то это нормальный tsetup (больше - не меньше), а при этом данные уже исчезли с шины.

Но потом вспомнил про thold - он не должен дать так далеко уйти клоку. 

Вот интересно, если указать max= -5 нс, а min = +5 нс   - Квартус и ТаймКвест  это поймут или нет...

Изменено 14 апреля, 2021 пользователем Yuri124

[zombi 0]

16 minutes ago, Yuri124 said:

если указать max= -5 нс ... - Квартус и ТаймКвест  это поймут или нет...

Я конечно далеко не спец, и с таймквестом пользуюсь эпизодически.

Но именно это я попробовал, и это он понимает неправильно.

Он отнимает эту величину от предыдущего фронта.

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

Опять у меня непонятка как у начинающего :

почему для DDR режима max считают как разницу между половиной периода клока и Tsu,

а для SDR - между полным периодом и Tsu?

Ведь в режиме DDR регистры разные, просто работают по разным фронтам.

Ведь для регистра который работает по нарастающему фронту шины DDR и для такого же регистра но для шины SDR  Tsu одинаковое.

[Yuri124 1]

Вот нашел на форуме Xilinx в ответах, и тогда понятно с этими расчетами.

https://forums.xilinx.com/t5/Timing-Analysis/set-input-delay-with-a-negative-min/td-p/1054363

 

Quote

 

max is the value from the launching clock edge to the data valid beginning.

min is the value from the launching clock edge to the (previous) data valid ending.

If the data valid ending is earlier than the launching clock edge, min is positive.

If the data valid ending is later than the launching clock edge, min is negative.

 

 

 

17 minutes ago, zombi said:

почему для DDR режима max считают как разницу между половиной периода клока

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

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

Но при реальной работе ПЛИС - ведь нет разницы, произошел захват фронтом или спадом. Можно условно считать, что так оно и есть на самом деле, чисто для указания программе исходных данных по расчету времянки.

[zombi 0]

11 minutes ago, Yuri124 said:

Вот нашел на форуме Xilinx в ответах, и тогда понятно с этими расчетами.

О, все становится на свои места. И выходит что только min может быть отрицательным.

Но вопрос почему величина -max разная для одинаковых регистров работающих по переднему фронту клока но на шине SDR и DDR,

для меня по прежнему открыт.

[Yuri124 1]

16 minutes ago, zombi said:

почему величина -max разная для одинаковых регистров работающих по переднему фронту клока но на шине SDR и DDR

Так ведь Квартусу нужно просто напросто уложиться в задержку. 

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

Просто sdc указывает

max is the value from the launching clock edge to the data valid beginning.

Но на самом деле - этот фронт (спад) уже защелкивает данные. 

Чисто формальность. Чтобы уложить разводку по кристаллу в тайминги.

Как и указание частоты - create_clock   - ведь ПЛИС не проверяет фактическое значение частоты, просто указывается для вычисления таймингов. 

Скажем, если указать период в 10 нс  и max = 5, то  программа будет понимать так, что когда придет (следующий) latch clock, то данные уже 5 нс валидны.

Но, конечно, Power Estimator будет считать мощность, как будто на входе не 12 МГц, а молотит 100 МГц...

Изменено 14 апреля, 2021 пользователем Yuri124

[alexadmin 0]

39 minutes ago, Yuri124 said:

min is the value from the launching clock edge to the (previous) data valid ending.

If the data valid ending is earlier than the launching clock edge, min is positive.

If the data valid ending is later than the launching clock edge, min is negative.

Погодите. Либо у меня что-то с английским либо с головой.

"Если валидные данные заканчиваются  раньше запускающего фронта тактового сигнала, то min положительный."

"Если валидные данные заканчиваются позже запускающего фронта тактового сигнала, то min отрицательный."

Я считал, что наоборот. Картинка в цитируемом посте выше тоже наоборот. После чего там модертор написав эти слова соглашается, что картинка правильная.