Dantist2k17
-
Постов
70 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные Dantist2k17
-
-
2 hours ago, Aleх said:
Судя по тексту ворнинга и площади (0) у вас перекрытие с другим фенсом
Буду смотреть конечно еще раз, но не должно там быть перекрытия.
-
19 hours ago, Nick_K said:
Смутный вызов. У Вас регион квадратный? Если да, тогда возьмите просто вызовите через dbGet top.fPlan.box. Ну или так же задать:
addWellTap... -area $pt_x [expr "$pt_y + $sy"] [expr "$pt_x + $sx"] [expr "$pt_y + $sy + 56.0"]
P.S. чтобы понимать что происходит, вбейте вышеуказанную команду после выполнения первого шага и посмотрите возвращаемые значения. Самое банальное - значения представлены не в виде списка, а в виде коллекции. В таком случае нужно преобразовать collection в list.
Значения получаю корректные. Сами ячейки вставляются куда нужно. Вопрос в том почему при размещении я вижу предупреждение о том, что в регионе совсем нет места и поэтому тул меняет его тип на 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
-
Приветствую. Прошу помощи разобраться со следующей проблемой.
Что я делаю:
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 %.
-
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.
-
Опубликовано · Изменено пользователем Dantist2k17 · Пожаловаться
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 то вот возможное объяснение почему исершин делей разное:
У вас как вообще клок три построены?
----
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, с целью отвязаться от входа.
-
Опубликовано · Изменено пользователем Dantist2k17 · Пожаловаться
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 | +------------------------------------------------------------------------------------------+
-
Прошу пояснить чем и как определяется значение 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] | | | | | | | +--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-
27 minutes ago, Aleх said:
Я такого никогда не делал, и даже ничего подобного не видел. Это альфачип такое чудо выдумал?
Вот, заметил:
LAYER OVERLAP ; RECT 0 0 5.76 2.8 ; RECT 2.4 2.8 5.76 5.6 ;
У вас высота селлов кратна 5.76? Тогда откуда цифра 2.8? Должны отличаться в два раза. Просто, если вы хоть чуть чуть залезете на площадь для размещения других селлов, плейсер не будет эту площадь использовать. Проверьте всю геометрию в лефе, соответствия питчам в теч лефе
Я тоже не делал и не видел, но судя по информации из LEF/DEF Languafe Reference такое возможно.
Это я для примера накидал ячейку. Никто не мешает размечать ядро какими угодно SITE, стыковка ячеек и согласование с шагом разводки это задача тех, кто ячейки рисует (с этим проблем нет).
В соотношении 2 к 1 есть какой-то сакральный смысл? Я придерживаюсь того мнения, что оно условно (в разумных пределах).
Я экспериментирую, сам же делаю и tech_lef и ячейки, по размерам все согласовано. Но placer не использует не задействованную площадь внутри ячейки, в том и проблема. К сожалению нагуглить по этому поводу ничего не получилось. Возможно я не правильно понял информацию изложенную в LEF/DEF Languafe Reference.
-
Опубликовано · Изменено пользователем Dantist2k17 · Пожаловаться
13 hours ago, Aleх said:У вас за границы селла что то торчит? Т.е. гемеотрия макро в лефе - одна, а внутренние шейпы выпирают наружу, за пределы макро?
Если наружу что то неважное торчит, и вы хотите избежать drc, то надо это в obstruction перевести в лефе. А если важное, то лучше размеры селла увеличить. Или использовать команды, что я привел выше.
p.s. ааа.. может, у вас селлы многоэтажные? или речь вообще не о стандартных селлах, а о макроблоках?
Наоборот. Граница ячейки прямоугольная, иначе ее и не задать. А вот физически (по shape) ячейка буквой L.
Получается, что в пределах границ ячейки (Boundary box) имеется свободное место, в которое могут быть размещены другие ячейки (Available for placement).
Ячейки многоэтажные, но с этим нет проблемы.
Проблема в том, при place автоматически задействовать эти свободные места. Сам синтезатор это не делает, но вот если руками вставить в свободное место ячейку, то checkPlace проходит без проблем.
В LEF/DEF Language Reference есть абзац про Rectilinear Blocks:QuoteRectilinear Blocks
Normally, footprint descriptions in LEF are rectangular. However, it is possible to describe rectilinear footprints using an overlap layer. The overlap layer is defined specifically for this purpose and does not contain any routing. Describe a rectilinear footprint by setting the SIZE of the macro as a whole to a rectangular bounding box, then defining obstructions within the bounding box on the overlap layer. The obstructions on the overlap layer indicate areas within the bounding box which no other macro should overlap. The obstructions should completely cover the rectilinear shape of the macro, but not the portion of the bounding box that might overlap with other macros during placement. Note: Specify the overlaps for the macro using the OBS statement. To do this, specify a layer of type OVERLAP and then give the overlap geometries, as shown in Figure 1-83 on page 193.
Так же есть информация следующего содержания (прикрепляю скрин).
Пробовал оба варианта как вместе так и по отдельности, безрезультатно.
-
9 minutes ago, Aleх said:
Я не очень понял, о чем вы пишете, но на тонких процессах часто селлы сделаны так, что ставить их слитно (без зазора) нельзя. В этом случае создаются группы селлов, и специальные правила, как плейсить рядом селлы из разных групп - с каким зазором и т.д. Для референса даю команды specifyCellEdgeSpacing и specifyCellEdgeType, почитайте в мануале. Надеюсь, это то самое, о чем вы спросили :-)
Спасибо, посмотрю.
Процесс 65 нм.
Я спросил о том, как при размещении ячеек не прямоугольной формы вставлять в незадействованные их области другие ячейки.
-
Приветствую.
Озадачился размещением ячеек не стандартной (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 hours ago, Aleх said:
На вскидку (доки под рукой нет) выглядит правильно, разве что пропущено set_analysis_view
Но хочу заметить, что для синтеза достаочно только рассматривать углы с максимальными задержками, а поскольку на 65 нм такой угол скорее всего один, то можно было ограничиться только wc либой, без введения mmmc с кучей корнеров.
Речь о физ синтезе. Максимальная для setup, минимальная для hold.
-
3 hours ago, Aleх said:
Почему в обеих либах селлы называются одинаково? Если это одна и та же (физически) либа, но под разные PVT корнера, то надо вводить эти самые корнера.
В том и загвоздка, что ячейки называются одинаково, т.к. это одни и те же ячейки (физически), просто отхарактеризованны на разных частотах.
А каким образом указать синтезатору на то, с какими корнерами работать в определенных частях проекта.
Впервые столкнулся с подобной необходимостью. Обычно все по накатанной схеме:
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
-
2 hours ago, Aleх said:
Цель какая?
Если разные модули доложны быть физически реализованы на разных библиотеках, то нужно писать спецификацию CPF и проектировать по маршруту low power
А если можно смешивать либы, то синтезатор сам подберет оптималлный микс из селлов.
Не уверен что подберет.
Warning : Multiply-defined library cell. [LBR-22]
: Library-cell name collision (LIB1/AND2 and LIB2/AND2). Deleting (LIB2/AND21). -
28 minutes ago, Aleх said:
Цель какая?
Если разные модули доложны быть физически реализованы на разных библиотеках, то нужно писать спецификацию CPF и проектировать по маршруту low power
А если можно смешивать либы, то синтезатор сам подберет оптималлный микс из селлов.
Требований по раздельной реализации нет. Не подумал я о том, что синтезатор сам разрулит. А про CPF надо будет почитать, не знаком. Спасибо.
-
-
Приветствую.
Есть дизайн, модули в котором должны работать на разных частотах (50 МГц и 1250 МГц). Есть две библиотеки, отхарактеризованные на соответствующие частоты.
Вопрос: как объяснить innovus-у, чтобы он работал с разными библиотеками при физическом синтезе соответствующих модулей?
В genus-е использовал create_library_domain, альтернативу для innovus найти не смог.
-
On 4/24/2020 at 5:27 AM, lexx said:
Для уточнения: ячейка называется clock_enable, clock_gating технология автоматической вставки латчей в clock порт регистра.
Если же у вас именно clock_gating, то зачем его вставлять руками?
Отключение блоков с последующим сбросом в зависимости от режима работы. Схема небольшая, но частота высокая, поэтому все в ручном режиме.
-
Добрый день. Помогите разобраться c STA.
Имеется модуль на verilog, прикрепляю структурную схему.
В модуль "руками" вставлена библиотечная ячейка clock gate. Логический синтез провожу в DC.
Задаю следующие SDC:
set period 0.8
create_clock -name pll_clk -period $period [get_ports pll_clk]
create_generated_clock -name clk_div10 -source [get_ports pll_clk] -edges {10 20 30} [get_ports div10/clk_out]В report_timing наблюдаю:
Startpoint: register_en_clk_reg[3] (rising edge-triggered flip-flop clocked by pll_clk) Endpoint: counter_clk10_reg[0] (rising edge-triggered flip-flop clocked by clk_div10') Path Group: clk_div10 Path Type: max Point Incr Path -------------------------------------------------------------------------- clock pll_clk (rise edge) 7.20 7.20 clock network delay (ideal) 0.00 7.20 register_en_clk_reg[3]/C (FDCEX1) 0.00 7.20 r register_en_clk_reg[3]/QB (FDCEX1) 0.64 7.84 f U23/O (INVGX2) 0.07 7.91 r U27/O (XOR2X2) 0.23 8.14 f counter_clk10_reg[0]/D (FDCX1) 0.00 8.14 f data arrival time 8.14 clock clk_div10' (rise edge) 7.60 7.60 clock network delay (ideal) 0.00 7.60 counter_clk10_reg[0]/C (FDCX1) 0.00 7.60 r library setup time -0.27 7.33 data required time 7.33 -------------------------------------------------------------------------- data required time 7.33 data arrival time -8.14 -------------------------------------------------------------------------- slack (VIOLATED) -0.81
Мой вопрос заключается в следующем: почему я не вижу в report_timing задержку на clock gate ячейке?
Ведь clk_div10 = clk_gate(clk_div10_int)
Это связано с тем что нет clock tree и не установлен set_propagated_clock?
В случае установки set_propagated_clock [all_clocks] появляется задержка clock network delay (propagated) = 0.86, но чем конкретно она сформирована не указывается.
-
12 minutes ago, RobFPGA said:
Приветствую!
"...каждого с каждым..."? 
`define MAX(a,b) ((a)>(b) ? (a) : (b))
localparam MAX_VAL = `MAX(`MAX(val_a , val_b), val_c) .......;
Удачи! Rob.
Спокойствие, спасибо.
-
1 minute ago, RobFPGA said:
Приветствую!
И в чем вы тут видите сложность?
Удачи! Rob.
Я не вижу вариантов кроме банального сравнения каждого с каждым.
-
Приветствую. Прошу совета в решении следующей задачки.
Имеется модуль с несколькими параметрами, количество параметров произвольное, необходимо выбрать максимальный из них по значению.
module main #( parameter TW1 = 100, parameter TW2 = 80, parameter TW3 = 8, parameter TW4 = 534 )( output a, output b, output c, input d, input e); endmodule
-
12 hours ago, Aleх said:
Флоп с разрешением имеет две схемы замещения - флоп с мультиплексором в обратной связи, и флоп с клок-гатором в цепи управления. Поэтому если не поддерживаются формулы в next_state, можете попробовать вставить формулу в clocked_on
clocked_on : "CLK * EN";
а еще лучше, купите DC.
Спасибо, попробую.
Про DC не поспоришь.
-
17 hours ago, MickeyMouse said:
А что там в это Yosys какие-то особенные либы нужны?
Если речь идет об формате liberty то хорошие примеры можно найти в стандарте:
Была (есть) проблема, связанная с тем, что Yosys ругался на lib триггера, в котором при описании ff (IQ,IQB) { ... } next_state определяется выражением, например:
next_state: (CE*D + !CE*IQ);
а не просто как: next_state: D;
Как мне рассказали программисты, проанализировавшие исходный код Yosys, там явно указано о том, что подобные выражения текущая версия не поддерживает, мол в разработке.
Так что судя по всему дело не в либах.
Однако сам Yosys имеет на вооружении команду dff2dffe, которая оптимизирует схему, выявляя ff с мультиплексорами в обратной связи и заменяя их на ffe. При этом в выходной netlist пишутся примитивы \$_DFFE_PP_.
Всегда можно сделать автозамену, но это как-то...
RTL designer (Зеленоград)
в Предлагаю работу
Опубликовано · Пожаловаться
Отдел интегральных микросхем компании НПК «Технологический центр» в поиске сотрудника.
Чем предстоит заниматься:
Мы предлагаем:
Требования:
Дополнительно приветствуется:
Контактная информация: