Jump to content

    

Recommended Posts

Прошу пояснить чем и как определяется значение source insertion delay?

В report_timng получаю положительный slack в 2.6 нс при периоде в 800 пс...

При моделировании с sdf схема мертва. Грешу на source insertion delay.

Path 3: MET Setup Check with Pin block/mod/gtp_block/gtp_core_block/
gtp_core_one_byte/sipo_sdr/register_shift_flag_input_data_reg[5]/CK 
Endpoint:   block/mod/gtp_block/gtp_core_block/gtp_core_one_byte/
sipo_sdr/register_shift_flag_input_data_reg[5]/D (^) checked with  leading edge 
of 'pll_clkg_out'
Beginpoint: block/mod/gtp_block/gtp_core_block/gtp_core_one_byte/
sipo_sdr/register_shift_flag_input_data_reg[4]/Q (^) triggered by  leading edge 
of 'pll_clkg_out'
Path Groups: {pll_clkg_out}
Analysis View: analysis_view_setup
Other End Arrival Time          1.681
- Setup                         0.074
+ Phase Shift                   0.800
+ CPPR Adjustment               0.000
= Required Time                 2.407
- Arrival Time                 -0.212
= Slack Time                    2.619
     Clock Rise Edge                      0.000
     + Source Insertion Delay            -2.154
     = Beginpoint Arrival Time           -2.154
     Timing Path:
     +--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 
     |                      Instance                      |             Arc             |             Cell             | Delay | Arrival | Required |      Generated Clock      | 
     |                                                    |                             |                              |       |  Time   |   Time   |        Adjustment         | 
     |----------------------------------------------------+-----------------------------+------------------------------+-------+---------+----------+---------------------------| 
     |                                                    | pll_clkg_in ^               |                              |       |  -2.154 |    0.465 |                           | 
     | IO_pll_clkg_in                                     | I ^ -> O ^                  | I25BUF                       | 0.589 |  -1.565 |    1.053 |                           | 
     | LS_pll_clkg_in                                     | IN ^ -> OUT ^               | LS_12_10                     | 0.324 |  -1.241 |    1.377 |                           | 
     | block/mod/CTS_ccl_buf_00182                        | A ^ -> Z ^                  | rh_ckbufx2                   | 0.073 |  -1.169 |    1.450 |                           | 
     | block/mod/CTS_ccl_buf_00180                        | A ^ -> Z ^                  | rh_ckbufx8                   | 0.039 |  -1.130 |    1.489 |                           | 
     | block/mod/CTS_ccl_buf_00178                        | A ^ -> Z ^                  | rh_ckbufx4                   | 0.130 |  -1.000 |    1.618 |                           | 
     | block/mod/CTS_ccl_buf_00176                        | A ^ -> Z ^                  | rh_ckbufx8                   | 0.060 |  -0.940 |    1.678 |                           | 
     | block/mod/CTS_ccl_a_buf_00171                      | A ^ -> Z ^                  | rh_ckbufx16                  | 0.101 |  -0.839 |    1.779 |                           | 
     | block/mod/pll_cdr_1250_top/CDR65STM_625M_          | CLKIN ^ -> PLL_CLK_OUT_LD ^ | CDR65STM_625M_DUAL_LOOP_A_ls | 0.225 |  -0.614 |    2.005 | pll_clkg_out Adj. = 0.000 | 
     | DUAL_LOOP_A                                        |                             |                              |       |         |          |                           | 
     | block/mod/CTS_cmf_buf_17944                        | A ^ -> Z ^                  | rh_ckbufx1                   | 0.025 |  -0.589 |    2.029 |                           | 
     | block/mod/CTS_ccl_buf_00129                        | A ^ -> Z ^                  | rh_ckbufx4                   | 0.037 |  -0.552 |    2.066 |                           | 
     | block/mod/CTS_ccl_a_buf_00124                      | A ^ -> Z ^                  | rh_ckbufx16                  | 0.029 |  -0.523 |    2.096 |                           | 
     | block/mod/gtp_block/gtp_core_block/gtp_            | C ^ -> Z v                  | rh_nand3x2                   | 0.035 |  -0.488 |    2.131 |                           | 
     | core_one_byte/clock_manager/g535__4296             |                             |                              |       |         |          |                           | 
     | block/mod/gtp_block/gtp_core_block/gtp_            | A v -> Z v                  | rh_ckbufx2                   | 0.043 |  -0.445 |    2.174 |                           | 
     | core_one_byte/clock_manager/CTS_cid_buf_18046      |                             |                              |       |         |          |                           | 
     | block/mod/gtp_block/gtp_core_block/gtp_            | A v -> Z ^                  | rh_ckinvx2                   | 0.017 |  -0.428 |    2.191 |                           | 
     | core_one_byte/clock_manager/g530                   |                             |                              |       |         |          |                           | 
     | block/mod/gtp_block/gtp_core_block/gtp_            | A1 ^ -> Z ^                 | rh_ao23x2                    | 0.047 |  -0.381 |    2.237 |                           | 
     | core_one_byte/clock_manager/g516__5795             |                             |                              |       |         |          |                           | 
     | block/mod/gtp_block/gtp_core_block/gtp_            | A ^ -> Z ^                  | rh_ckbufx2                   | 0.038 |  -0.343 |    2.276 |                           | 
     | core_one_byte/sipo_sdr/CTS_ccl_a_buf_00032         |                             |                              |       |         |          |                           | 
     | block/mod/gtp_block/gtp_core_block/gtp_            | CK ^ -> Q ^                 | rh_ffqa01x1                  | 0.081 |  -0.261 |    2.357 |                           | 
     | core_one_byte/sipo_sdr/register_shift_flag_input_d |                             |                              |       |         |          |                           | 
     | ata_reg[4]                                         |                             |                              |       |         |          |                           | 
     | block/mod/gtp_block/gtp_core_block/gtp_            | A ^ -> Z ^                  | rh_minbuf25x1                | 0.049 |  -0.212 |    2.406 |                           | 
     | core_one_byte/sipo_sdr/FE_PHC153745_register_shift |                             |                              |       |         |          |                           | 
     | _flag_input_data_4                                 |                             |                              |       |         |          |                           | 
     | block/mod/gtp_block/gtp_core_block/gtp_            | D ^                         | rh_ffqa01x1                  | 0.000 |  -0.212 |    2.407 |                           | 
     | core_one_byte/sipo_sdr/register_shift_flag_input_d |                             |                              |       |         |          |                           | 
     | ata_reg[5]                                         |                             |                              |       |         |          |                           | 
     +--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 
     Clock Rise Edge                      0.000
     = Beginpoint Arrival Time            0.000
     Other End Path:
     +--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 
     |                      Instance                      |             Arc             |             Cell             | Delay | Arrival | Required |      Generated Clock      | 
     |                                                    |                             |                              |       |  Time   |   Time   |        Adjustment         | 
     |----------------------------------------------------+-----------------------------+------------------------------+-------+---------+----------+---------------------------| 
     |                                                    | pll_clkg_in ^               |                              |       |   0.000 |   -2.619 |                           | 
     | IO_pll_clkg_in                                     | I ^ -> O ^                  | I25BUF                       | 0.588 |   0.588 |   -2.031 |                           | 
     | LS_pll_clkg_in                                     | IN ^ -> OUT ^               | LS_12_10                     | 0.155 |   0.742 |   -1.876 |                           | 
     | block/mod/CTS_ccl_buf_00182                        | A ^ -> Z ^                  | rh_ckbufx2                   | 0.068 |   0.810 |   -1.808 |                           | 
     | block/mod/CTS_ccl_buf_00180                        | A ^ -> Z ^                  | rh_ckbufx8                   | 0.038 |   0.848 |   -1.771 |                           | 
     | block/mod/CTS_ccl_buf_00178                        | A ^ -> Z ^                  | rh_ckbufx4                   | 0.113 |   0.961 |   -1.658 |                           | 
     | block/mod/CTS_ccl_buf_00176                        | A ^ -> Z ^                  | rh_ckbufx8                   | 0.053 |   1.014 |   -1.605 |                           | 
     | block/mod/CTS_ccl_a_buf_00171                      | A ^ -> Z ^                  | rh_ckbufx16                  | 0.083 |   1.097 |   -1.522 |                           | 
     | block/mod/pll_cdr_1250_top/CDR65STM_625M_          | CLKIN ^ -> PLL_CLK_OUT_LD ^ | CDR65STM_625M_DUAL_LOOP_A_ls | 0.225 |   1.322 |   -1.297 | pll_clkg_out Adj. = 0.000 | 
     | DUAL_LOOP_A                                        |                             |                              |       |         |          |                           | 
     | block/mod/CTS_cmf_buf_17944                        | A ^ -> Z ^                  | rh_ckbufx1                   | 0.024 |   1.346 |   -1.273 |                           | 
     | block/mod/CTS_ccl_buf_00129                        | A ^ -> Z ^                  | rh_ckbufx4                   | 0.036 |   1.381 |   -1.237 |                           | 
     | block/mod/CTS_ccl_a_buf_00124                      | A ^ -> Z ^                  | rh_ckbufx16                  | 0.029 |   1.410 |   -1.209 |                           | 
     | block/mod/gtp_block/gtp_core_block/gtp_            | C ^ -> Z v                  | rh_nand3x2                   | 0.035 |   1.444 |   -1.174 |                           | 
     | core_one_byte/clock_manager/g535__4296             |                             |                              |       |         |          |                           | 
     | block/mod/gtp_block/gtp_core_block/gtp_            | A v -> Z v                  | rh_ckbufx2                   | 0.037 |   1.481 |   -1.138 |                           | 
     | core_one_byte/clock_manager/CTS_cid_buf_18046      |                             |                              |       |         |          |                           | 
     | block/mod/gtp_block/gtp_core_block/gtp_            | A v -> Z ^                  | rh_ckinvx2                   | 0.015 |   1.496 |   -1.122 |                           | 
     | core_one_byte/clock_manager/g530                   |                             |                              |       |         |          |                           | 
     | block/mod/gtp_block/gtp_core_block/gtp_            | A1 ^ -> Z ^                 | rh_ao23x2                    | 0.042 |   1.538 |   -1.081 |                           | 
     | core_one_byte/clock_manager/g516__5795             |                             |                              |       |         |          |                           | 
     | block/mod/gtp_block/gtp_core_block/gtp_            | A ^ -> Z ^                  | rh_bufxp3                    | 0.039 |   1.577 |   -1.042 |                           | 
     | core_one_byte/sipo_sdr/CTS_cdb_buf_18598           |                             |                              |       |         |          |                           | 
     | block/mod/gtp_block/gtp_core_block/gtp_            | A ^ -> Z ^                  | rh_ckbufx2                   | 0.101 |   1.678 |   -0.940 |                           | 
     | core_one_byte/sipo_sdr/CTS_ccl_a_buf_00029         |                             |                              |       |         |          |                           | 
     | block/mod/gtp_block/gtp_core_block/gtp_            | CK ^                        | rh_ffqa01x1                  | 0.002 |   1.681 |   -0.938 |                           | 
     | core_one_byte/sipo_sdr/register_shift_flag_input_d |                             |                              |       |         |          |                           | 
     | ata_reg[5]                                         |                             |                              |       |         |          |                           | 
     +--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 

 

Share this post


Link to post
Share on other sites

У вас там клокгаторы (комб. клок гейты) в цепи клока. С ними часто бывают проблемы, поскольку тул не понимает как правильно считать фазы клока, отсюда и фэйз шифты и инсершн делэи. Прежде чем разбираться с клокгаторами, выясните - не ошибка ли это в ртл, и если не ошибка, то почему не поставили нормальный (с защелкой) клок гейт. И если в ртл все правильно, и нужны именно клокгаторы - разберитесь что на них правильно подается управление (тактируется инверсным клоком). По моему опыту, в 99% здесь кривой ртл.

Share this post


Link to post
Share on other sites
1 hour ago, Aleх said:

У вас там клокгаторы (комб. клок гейты) в цепи клока. С ними часто бывают проблемы, поскольку тул не понимает как правильно считать фазы клока, отсюда и фэйз шифты и инсершн делэи. Прежде чем разбираться с клокгаторами, выясните - не ошибка ли это в ртл, и если не ошибка, то почему не поставили нормальный (с защелкой) клок гейт. И если в ртл все правильно, и нужны именно клокгаторы - разберитесь что на них правильно подается управление (тактируется инверсным клоком). По моему опыту, в 99% здесь кривой ртл.

С защелкой нету, rtl мой, управление проверю, спасибо.

 

Но мне не понятно что есть такое "Source Insertion Delay", чем оно определяется. Никаких input output delay на входной клок не задавал, clock_latency не определял (пробовал и определять, нулевым ставить, чуда не случилось).

 

Я и при синтезе тестового проекта, который лишен clock gate наблюдаю source insertion delay

 

Path 1: MET Setup Check with Pin fifo/pointer_write_bin_reg_5_/CK 
Endpoint:   fifo/pointer_write_bin_reg_5_/D (v) checked with  leading edge of 
'clk_data_in'
Beginpoint: fifo/pointer_write_bin_reg_4_/Q (^) triggered by  leading edge of 
'clk_data_in'
Path Groups: {clk_data_in}
Analysis View: analysis_view_setup
Other End Arrival Time         -0.007
- Setup                         0.085
+ Phase Shift                  10.000
= Required Time                 9.908
- Arrival Time                  0.350
= Slack Time                    9.558
     Clock Rise Edge                      0.000
     + Source Insertion Delay            -0.092
     = Beginpoint Arrival Time           -0.092
     Timing Path:
     +------------------------------------------------------------------------------------------+ 
     |           Instance            |      Arc      |    Cell     | Delay | Arrival | Required | 
     |                               |               |             |       |  Time   |   Time   | 
     |-------------------------------+---------------+-------------+-------+---------+----------| 
     |                               | clk_data_in ^ |             |       |  -0.092 |    9.466 | 
     | CTS_ccl_a_buf_00051           | A ^ -> Z ^    | rh_ckbufx32 | 0.034 |  -0.057 |    9.500 | 
     | fifo/CTS_ccl_a_buf_00025      | A ^ -> Z ^    | rh_ckbufx32 | 0.047 |  -0.010 |    9.547 | 
     | fifo/pointer_write_bin_reg_4_ | CK ^ -> Q ^   | rh_ffqa01x1 | 0.155 |   0.144 |    9.702 | 
     | fifo/U194                     | A ^ -> Z v    | rh_nand2x1  | 0.036 |   0.181 |    9.739 | 
     | fifo/U201                     | A v -> Z ^    | rh_invxp3   | 0.063 |   0.243 |    9.801 | 
     | fifo/U202                     | B ^ -> Z v    | rh_nand2x1  | 0.040 |   0.283 |    9.841 | 
     | fifo/U203                     | A v -> Z ^    | rh_oai12x1  | 0.041 |   0.324 |    9.882 | 
     | fifo/U339                     | A2 ^ -> Z v   | rh_aoi22x1  | 0.026 |   0.350 |    9.908 | 
     | fifo/pointer_write_bin_reg_5_ | D v           | rh_ffqa01x1 | 0.000 |   0.350 |    9.908 | 
     +------------------------------------------------------------------------------------------+ 
     Clock Rise Edge                      0.000
     + Source Insertion Delay            -0.092
     = Beginpoint Arrival Time           -0.092
     Other End Path:
     +------------------------------------------------------------------------------------------+ 
     |           Instance            |      Arc      |    Cell     | Delay | Arrival | Required | 
     |                               |               |             |       |  Time   |   Time   | 
     |-------------------------------+---------------+-------------+-------+---------+----------| 
     |                               | clk_data_in ^ |             |       |  -0.092 |   -9.650 | 
     | CTS_ccl_a_buf_00051           | A ^ -> Z ^    | rh_ckbufx32 | 0.034 |  -0.057 |   -9.615 | 
     | fifo/CTS_ccl_a_buf_00025      | A ^ -> Z ^    | rh_ckbufx32 | 0.047 |  -0.010 |   -9.568 | 
     | fifo/pointer_write_bin_reg_5_ | CK ^          | rh_ffqa01x1 | 0.004 |  -0.007 |   -9.564 | 
     +------------------------------------------------------------------------------------------+ 

 

Edited by Dantist2k17

Share this post


Link to post
Share on other sites

Клокгаторы (clockgator) надо писать очень аккуратно, сводя вмешательство в цепь клока к минимуму. Основное правило - управление формируется инверсным клоком. Если клокгатор написан правильно, тул должен определить его как OR- тип или AND-тип. Если этого не произошло, есть спец констрейнты для указания на клокгатор в проекте. Отличие клокгатора от клокгейта (на защелке) - тайминг самого клокгатора зажат с двух сторон, меньше гибкости для построения дерева. Попробуйте поэкспериментировать сначала с одним клокгатором в дизайне, и таймингом через него.

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

Share this post


Link to post
Share on other sites
17 hours ago, Dantist2k17 said:

Но мне не понятно что есть такое "Source Insertion Delay", чем оно определяется

 


Это задержка цепи извне. Складывается из емкости вх. пина/пада, transition, uncertainty, и если были наложены set-clock-latency. В вашем случае, судя по всему, это емкость и транзишн на входе. У кэденса была команда - показать детальный расчет тайм-арки. Что то вроде report arc delay calculation. Там все будет расписано что и как тул считает, взятые цифры из констрейнтов и либов. У синопсиса тоже есть такая команда. Поищите, если интересно

p.s.

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

Edited by Aleх

Share this post


Link to post
Share on other sites

SOURCE_INSERTION_DELAY это задержка от выхода осцилятора до точки где задан клок (create_clock) - "Clock Latency"

 

Задержка отрицательная, т.к. отсчёт идёт от точки задания клока. 

Негативный инсершин делей возможен, если используется PLL, которая собственно вставляет "негативную задержку" (фазовый сдвиг) так чтобы компенсировать инсершин делей и сделать клок как в декларации.

 

В первом репорте мы видим в соурс дата пасе:

     Clock Rise Edge                      0.000
     + Source Insertion Delay            -2.154
     = Beginpoint Arrival Time           -2.154
     Timing Path:

А в клок пасе:

     Clock Rise Edge                      0.000
     = Beginpoint Arrival Time            0.000
     Other End Path:

Т.е. Source Insertion Delay тут отсутствует. При этом клок пас совпадает до /clock_manager/g516__5795. 

Во втором репорте всё совпадает как и ожидалось (также оно и при моделировании с SDF).

В этом похоже и проблема.

 

Почему так мне трудно ответить... Я не знаю что и из чего ви дизайните.

А из какой тулзы репорты? Если это FPGA, то тул сам подставляет "невидимые задержки" в SDC. Есть конечный SDC?.

 

Если это XILINX то вот возможное объяснение почему исершин делей разное:

This becomes a problem when you want to cross synchronously between a small domain and a large domain - the insertion latencies are different, and hence you get timing problems.

У вас как вообще клок три построены?

 

----

P.S

Задание set_clock_latency не поможет если в SDC стоит set_propagated_clock (вы указали пропагейтид клок в SDC?). Попробуйте задать set_clock_latency -source.

 

В клоковом дереве я вижу два логических гейта. Для ASIC  тулзы это не проблема по дефолту, а вот в FPGA "просто тупо вписать это в RTL" не лучший путь...GATED CLOCK in FPGA

 

Share this post


Link to post
Share on other sites
On 2/28/2021 at 3:48 PM, topor_topor said:

SOURCE_INSERTION_DELAY это задержка от выхода осцилятора до точки где задан клок (create_clock) - "Clock Latency"

 

Задержка отрицательная, т.к. отсчёт идёт от точки задания клока. 

Негативный инсершин делей возможен, если используется PLL, которая собственно вставляет "негативную задержку" (фазовый сдвиг) так чтобы компенсировать инсершин делей и сделать клок как в декларации.

 

В первом репорте мы видим в соурс дата пасе:


     Clock Rise Edge                      0.000
     + Source Insertion Delay            -2.154
     = Beginpoint Arrival Time           -2.154
     Timing Path:

А в клок пасе:


     Clock Rise Edge                      0.000
     = Beginpoint Arrival Time            0.000
     Other End Path:

Т.е. Source Insertion Delay тут отсутствует. При этом клок пас совпадает до /clock_manager/g516__5795. 

Во втором репорте всё совпадает как и ожидалось (также оно и при моделировании с SDF).

В этом похоже и проблема.

 

Почему так мне трудно ответить... Я не знаю что и из чего ви дизайните.

А из какой тулзы репорты? Если это FPGA, то тул сам подставляет "невидимые задержки" в SDC. Есть конечный SDC?.

 

Если это XILINX то вот возможное объяснение почему исершин делей разное:

This becomes a problem when you want to cross synchronously between a small domain and a large domain - the insertion latencies are different, and hence you get timing problems.

У вас как вообще клок три построены?

 

----

P.S

Задание set_clock_latency не поможет если в SDC стоит set_propagated_clock (вы указали пропагейтид клок в SDC?). Попробуйте задать set_clock_latency -source.

 

В клоковом дереве я вижу два логических гейта. Для ASIC  тулзы это не проблема по дефолту, а вот в FPGA "просто тупо вписать это в RTL" не лучший путь...GATED CLOCK in FPGA

 

Спасибо что "не прошли" мимо.

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

Не корректно сравнивать эти два отчета.

 

Сразу после CTS, insertion delay присутствует в пути данных и в пути клока, затем делаю следующее

 

setAnalysisMode -analysisType onChipVariation -cppr both
optDesign -postCTS
optDesign -postCTS -hold

 

И после этого в пути клока insertion delay пропадает. При этом если сделать report_timing -early

то insertion delay нулевой в двух путях

если же сделать report_timing -late

то insertion delay отрицательный в пути данных.

 

Делаю под ASIC, Innovus.

 

PLL в проекте есть, используются для генерации частот, за фазой следить потребности нет.

propogated не указывал, уже занулил set_clock_latency -source и запустил CTS, жду результата.

 

Вход частоты PLL задан через create_geenrated_clock от входной частоты, есть мысль попробовать определить его через create_clock, с целью отвязаться от входа.

Edited by Dantist2k17

Share this post


Link to post
Share on other sites

У вас, до CTS включительно, цепь клока идеальная (задержка 0) до каждого из синков. А после CTS автоматически включается propagate, т.е. все задержки в цепи клока становятся реальные, включая участок До root pin, который вы использовали при констрейнте клока. Этот участок До, и есть insertion delay. Я бы не советовал его перезадавать через set_clock_latency после CTS - это неправильно: set_clock_latency используется в синтезе, плейсе и cts для эмуляции отсуствующего клокового дерева - иногда это позволяет выжать немного больше частоты, особенно в пайплайнах. Но после CTS этот констрейнт надо убирать - его заменяют реальные задержки реального дерева.

 

Что касается PLL, то здесь весь вопрос в том, есть ли в проекте внешний интерфейс, работающий по входному клоку. Если таких интерфейсов нет, то root pin можно смело задавать с выхода pll.

 

Ну и повторюсь, у кеденса/инновуса есть команда, которая расписывает подробно, как тул считает тайминг в отдельно взятой арке. Какие данные берет из либерти, какие емкости учитываются, какие дерейты, и т.д. - все очень и очень подробно, так чтобы не оставалось вопросов.  Можете взять эту команду и посмотреть как тул считает insertion delay. Команда называется что то вроде report arc delay calculation, поищите, точное название я подзабыл - давно не пользовался.

 

p.s. нагуглил

https://www.micro-ip.com/STA/dictionary_412_17/report_delay_calculation.html

это sdc команда, но в кеденсе я точно ей пользовался

Edited by Aleх

Share this post


Link to post
Share on other sites
9 hours ago, Aleх said:

У вас, до CTS включительно, цепь клока идеальная (задержка 0) до каждого из синков. А после CTS автоматически включается propagate, т.е. все задержки в цепи клока становятся реальные, включая участок До root pin, который вы использовали при констрейнте клока. Этот участок До, и есть insertion delay. Я бы не советовал его перезадавать через set_clock_latency после CTS - это неправильно: set_clock_latency используется в синтезе, плейсе и cts для эмуляции отсуствующего клокового дерева - иногда это позволяет выжать немного больше частоты, особенно в пайплайнах. Но после CTS этот констрейнт надо убирать - его заменяют реальные задержки реального дерева.

 

Что касается PLL, то здесь весь вопрос в том, есть ли в проекте внешний интерфейс, работающий по входному клоку. Если таких интерфейсов нет, то root pin можно смело задавать с выхода pll.

 

Ну и повторюсь, у кеденса/инновуса есть команда, которая расписывает подробно, как тул считает тайминг в отдельно взятой арке. Какие данные берет из либерти, какие емкости учитываются, какие дерейты, и т.д. - все очень и очень подробно, так чтобы не оставалось вопросов.  Можете взять эту команду и посмотреть как тул считает insertion delay. Команда называется что то вроде report arc delay calculation, поищите, точное название я подзабыл - давно не пользовался.

 

p.s. нагуглил

https://www.micro-ip.com/STA/dictionary_412_17/report_delay_calculation.html

это sdc команда, но в кеденсе я точно ей пользовался

 

Я подразумеваю set_clock_latency с опцией -source.

У меня сложилось следующее понимание (возможно ошибочное), CTS latency состоит из source latency и network latency.

Network latency есть реальная задержка клока, которая становится не нулевой после CTS. Реальная задержка реального дерева.

Source latency есть задержка от источника (например кварца на плате) до точки определения clock, и синтезатор выбирает это source latency, в моем представлении, это все равно что на моделировании менять фазу клока (двигать его относительно других сигналов).

 

Интерфейсы есть, но их взаимодействие с остальными частями проекта выполнено через асинхронные fifo или одиночные синхронизаторы типа hand shake.

 

Нашел команду reportDelayCalculation.

Share this post


Link to post
Share on other sites

Ви включили OCV. Кстати зачем? 

При етом сетап / холд считается для случая "хуже худшего". Для сетапа  wc source/bc destination на флопах. Ето обьясняет почему задержки разние в одном репорте. 

OCV работает правильно при set_propagated_clock. 

Попробуйте report_timing - view чтоб увидеть какие wc/bc взяти

Раз ето asic то тулза сама ниче не подставит в sdc. 

А как ви sdf записали? Тоже в ocv? 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this