Перейти к содержанию
    

Dantist2k17

Участник
  • Постов

    69
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Dantist2k17

  • Звание
    Участник
    Участник

Посетители профиля

1 562 просмотра профиля
  1. Значения получаю корректные. Сами ячейки вставляются куда нужно. Вопрос в том почему при размещении я вижу предупреждение о том, что в регионе совсем нет места и поэтому тул меняет его тип на guide. Хотя места полным полно. innovus 19> dbGet [dbGet top.fPlan.groups.name -p mod_a/mod_b/mod_c].boxes {{4448.68 1256.8 5416.36 1312.8}} innovus 20> lindex [dbGet [dbGet top.fPlan.groups.name -p mod_a/mod_b/mod_c].boxes] 0 0 4448.68 1256.8 5416.36 1312.8
  2. Приветствую. Прошу помощи разобраться со следующей проблемой. Что я делаю: 1. Создаю регион для InstGroup (mod_a/mod_b/mod_c). createRegion mod_a/mod_b/mod_c $pt_x [expr "$pt_y + $sy"] [expr "$pt_x + $sx"] [expr "$pt_y + $sy + 56.0"] 2. Размещаю ячейки для замыкания охранных колец в пределах региона. addWellTap -cell tapx2 -cellInterval 23.04 -area [lindex [dbGet [dbGet top.fPlan.groups.name -p mod_a/mod_b/mod_c].boxes] 0 0] -prefix WellTap_ 3. На всякий случай, добавляю созданные ячейки к указанной InstGroup (mod_a/mod_b/mod_c). Пробовал делать и без этого шага. addInstToInstGroup mod_a/mod_b/mod_c mod_a/mod_b/mod_c/WellTap_* 4. Запускаю размещение и наблюдаю следующее: **WARN: (IMPSP-450): Failed to set density for module 'mod_a/mod_b/mod_c' because the available area (0.00) is smaller than the total instance area (61372.00). The module 'mod_a/mod_b/mod_c' will be converted to a guide. To fix this problem, you can enlarge the module area for 'mod_a/mod_b/mod_c' or move away any module that is overlapped with module 'mod_a/mod_b/mod_c'. Change HInst mod_a/mod_b/mod_c constraint to a Guide. Если не делать addWellTap, то такого предупреждения не возникает. Не понятно почему доступная площадь обозначена равной 0.00. При этом плотность заполнения в gui отображается равно 4.3 %.
  3. Я подразумеваю set_clock_latency с опцией -source. У меня сложилось следующее понимание (возможно ошибочное), CTS latency состоит из source latency и network latency. Network latency есть реальная задержка клока, которая становится не нулевой после CTS. Реальная задержка реального дерева. Source latency есть задержка от источника (например кварца на плате) до точки определения clock, и синтезатор выбирает это source latency, в моем представлении, это все равно что на моделировании менять фазу клока (двигать его относительно других сигналов). Интерфейсы есть, но их взаимодействие с остальными частями проекта выполнено через асинхронные fifo или одиночные синхронизаторы типа hand shake. Нашел команду reportDelayCalculation.
  4. Спасибо что "не прошли" мимо. Я и не заметил разницы между отчетами в пути клока. Не корректно сравнивать эти два отчета. Сразу после 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, с целью отвязаться от входа.
  5. С защелкой нету, 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 | +------------------------------------------------------------------------------------------+
  6. Прошу пояснить чем и как определяется значение 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] | | | | | | | +--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
  7. Я тоже не делал и не видел, но судя по информации из LEF/DEF Languafe Reference такое возможно. Это я для примера накидал ячейку. Никто не мешает размечать ядро какими угодно SITE, стыковка ячеек и согласование с шагом разводки это задача тех, кто ячейки рисует (с этим проблем нет). В соотношении 2 к 1 есть какой-то сакральный смысл? Я придерживаюсь того мнения, что оно условно (в разумных пределах). Я экспериментирую, сам же делаю и tech_lef и ячейки, по размерам все согласовано. Но placer не использует не задействованную площадь внутри ячейки, в том и проблема. К сожалению нагуглить по этому поводу ничего не получилось. Возможно я не правильно понял информацию изложенную в LEF/DEF Languafe Reference.
  8. Наоборот. Граница ячейки прямоугольная, иначе ее и не задать. А вот физически (по shape) ячейка буквой L. Получается, что в пределах границ ячейки (Boundary box) имеется свободное место, в которое могут быть размещены другие ячейки (Available for placement). Ячейки многоэтажные, но с этим нет проблемы. Проблема в том, при place автоматически задействовать эти свободные места. Сам синтезатор это не делает, но вот если руками вставить в свободное место ячейку, то checkPlace проходит без проблем. В LEF/DEF Language Reference есть абзац про Rectilinear Blocks: Так же есть информация следующего содержания (прикрепляю скрин). Пробовал оба варианта как вместе так и по отдельности, безрезультатно.
  9. Спасибо, посмотрю. Процесс 65 нм. Я спросил о том, как при размещении ячеек не прямоугольной формы вставлять в незадействованные их области другие ячейки.
  10. Приветствую. Озадачился размещением ячеек не стандартной (L-образной) формы. Вычитал о слое OVERLAP. LAYER OVERLAP TYPE OVERLAP ; END OVERLAP В LEF файле на ячейку прописал: OBS LAYER M1 ; RECT .... ; RECT .... ; LAYER OVERLAP ; RECT 0 0 5.76 2.8 ; RECT 2.4 2.8 5.76 5.6 ; END В результате placeDesign encounter/innovus автоматически не вставляют в незадействованные места другие (обычные прямоугольные) ячейки, а лепят их друг на друга. При этом, если ручками поставить прямоугольные ячейки в незадействованные области L-образных ячеек, то checkPlace проходит без ошибок. Среди ключей команд placeDesign и setPlaceMode подходящего не нашел. На что обратить внимание?
  11. Речь о физ синтезе. Максимальная для setup, минимальная для hold.
  12. В том и загвоздка, что ячейки называются одинаково, т.к. это одни и те же ячейки (физически), просто отхарактеризованны на разных частотах. А каким образом указать синтезатору на то, с какими корнерами работать в определенных частях проекта. Впервые столкнулся с подобной необходимостью. Обычно все по накатанной схеме: create_library_set -name 065_wc -timing lib/lib_wcs_fast.lib create_library_set -name 065_bc -timing lib/lib_bcs_fast.lib create_constraint_mode -name my_constraint_mode -sdc_files sdc/main.sdc create_rc_corner -name my_rc_corner_wc \ -T 85.0 \ -cap_table file_name_worst.captable \ -qx_tech_file file_name create_rc_corner -name my_rc_corner_bc \ -T -65.0 \ -cap_table file_name_best.captable \ -qx_tech_file file_name create_delay_corner -name my_delay_corner_max -library_set 065_wc -rc_corner my_rc_corner_wc create_delay_corner -name my_delay_corner_min -library_set 065_bc -rc_corner my_rc_corner_bc create_analysis_view -name my_analysis_view_setup -constraint_mode my_constraint_mode -delay_corner my_delay_corner_max create_analysis_view -name my_analysis_view_hold -constraint_mode my_constraint_mode -delay_corner my_delay_corner_min init_design -setup my_analysis_view_setup -hold my_analysis_view_hold
  13. Не уверен что подберет. Warning : Multiply-defined library cell. [LBR-22] : Library-cell name collision (LIB1/AND2 and LIB2/AND2). Deleting (LIB2/AND21).
  14. Требований по раздельной реализации нет. Не подумал я о том, что синтезатор сам разрулит. А про CPF надо будет почитать, не знаком. Спасибо.
×
×
  • Создать...