Dantist2k17 0 24 февраля, 2021 Опубликовано 24 февраля, 2021 · Жалоба Прошу пояснить чем и как определяется значение 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] | | | | | | | +--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Avex 1 24 февраля, 2021 Опубликовано 24 февраля, 2021 · Жалоба У вас там клокгаторы (комб. клок гейты) в цепи клока. С ними часто бывают проблемы, поскольку тул не понимает как правильно считать фазы клока, отсюда и фэйз шифты и инсершн делэи. Прежде чем разбираться с клокгаторами, выясните - не ошибка ли это в ртл, и если не ошибка, то почему не поставили нормальный (с защелкой) клок гейт. И если в ртл все правильно, и нужны именно клокгаторы - разберитесь что на них правильно подается управление (тактируется инверсным клоком). По моему опыту, в 99% здесь кривой ртл. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dantist2k17 0 24 февраля, 2021 Опубликовано 24 февраля, 2021 (изменено) · Жалоба 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 | +------------------------------------------------------------------------------------------+ Изменено 24 февраля, 2021 пользователем Dantist2k17 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Avex 1 24 февраля, 2021 Опубликовано 24 февраля, 2021 · Жалоба Клокгаторы (clockgator) надо писать очень аккуратно, сводя вмешательство в цепь клока к минимуму. Основное правило - управление формируется инверсным клоком. Если клокгатор написан правильно, тул должен определить его как OR- тип или AND-тип. Если этого не произошло, есть спец констрейнты для указания на клокгатор в проекте. Отличие клокгатора от клокгейта (на защелке) - тайминг самого клокгатора зажат с двух сторон, меньше гибкости для построения дерева. Попробуйте поэкспериментировать сначала с одним клокгатором в дизайне, и таймингом через него. В целом, если клокгейтов в библиотеке нет, я советую использовать просто флопы с разрешением записи (код придется переписать). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Avex 1 25 февраля, 2021 Опубликовано 25 февраля, 2021 (изменено) · Жалоба 17 hours ago, Dantist2k17 said: Но мне не понятно что есть такое "Source Insertion Delay", чем оно определяется Это задержка цепи извне. Складывается из емкости вх. пина/пада, transition, uncertainty, и если были наложены set-clock-latency. В вашем случае, судя по всему, это емкость и транзишн на входе. У кэденса была команда - показать детальный расчет тайм-арки. Что то вроде report arc delay calculation. Там все будет расписано что и как тул считает, взятые цифры из констрейнтов и либов. У синопсиса тоже есть такая команда. Поищите, если интересно p.s. а как видно из первого репорта, если тул хочет сдвинуть расчет на число полупериодов (это число следует из констрейнта формы клока и особенностей дерева - клокгейты и т.д.), тул в это значение задержки добавляет или вычитает нужное число полупериодов. Изменено 25 февраля, 2021 пользователем Aleх Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
topor_topor 0 28 февраля, 2021 Опубликовано 28 февраля, 2021 · Жалоба 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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dantist2k17 0 3 марта, 2021 Опубликовано 3 марта, 2021 (изменено) · Жалоба 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, с целью отвязаться от входа. Изменено 3 марта, 2021 пользователем Dantist2k17 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Avex 1 3 марта, 2021 Опубликовано 3 марта, 2021 (изменено) · Жалоба У вас, до 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 команда, но в кеденсе я точно ей пользовался Изменено 3 марта, 2021 пользователем Aleх Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dantist2k17 0 4 марта, 2021 Опубликовано 4 марта, 2021 · Жалоба 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. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
topor_topor 0 4 марта, 2021 Опубликовано 4 марта, 2021 · Жалоба Ви включили OCV. Кстати зачем? При етом сетап / холд считается для случая "хуже худшего". Для сетапа wc source/bc destination на флопах. Ето обьясняет почему задержки разние в одном репорте. OCV работает правильно при set_propagated_clock. Попробуйте report_timing - view чтоб увидеть какие wc/bc взяти Раз ето asic то тулза сама ниче не подставит в sdc. А как ви sdf записали? Тоже в ocv? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Avex 1 4 марта, 2021 Опубликовано 4 марта, 2021 · Жалоба Не надо использовать set_clock_latency , особенно после CTS. Просто наберите set_propagated_clock и выполните тайм репорт еще раз Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
