Dantist2k17 0 4 февраля, 2019 Опубликовано 4 февраля, 2019 (изменено) · Жалоба Приветствую. Имеется verilog, в общих чертах выглядит следующим образом. Исходный код выкладывать не стал дабы не нагружать восприятие. reg [31:0] data_a; reg [31:0] data_b; reg [3:0] flag; //счетчие в коде 1 из N always@(posedge clk or negedge rst) begin if(!rst) flag <= 4'd1; else flag <= flag << 1 | flag[3]; end //данные обновляются раз в 4 такта, т.е. на функцию по факту отводится 4 периода тактовой частоты //о чем я сообщаю синтезатору посредством //set_multicycle_path 4 -end -setup -from {data_a[*]} -to {data[*]} //set_multicycle_path 4 -end -setup -from {data_b[*]} -to {data[*]} assign function = комбинационная функция от(data_a, data_b); always@(posedge clk or negedge rst) begin if(!rst) data <= 1'b0; else data <= data | flag[3] & function; end В результате синтеза получаем следующий путь. flag_reg_0_/C (FDP) flag_reg_0_/Q (FDP) U212/O (NOR3B3) U213/O (O21AI1) U214/O (AND2B2) U5/O (NAN3B1) U215/O (AND2B2) U216/O (OR2) data/D (FDC) Однако по пути от flag до data я планировал увидеть что-то вроде этого. flag_reg_0_/C (FDP) flag_reg_0_/Q (FDP) U212/O (AND2) U213/O (OR2) data/D (FDC) Как я понимаю синтезатор просто замешивает flag_reg в логику формирования функции в процессе оптимизации, вот только с какой целью, делал синтез на разных частотах, результат не меняется, наличие/отсутствие multicycle_path в sdc тоже влияния не оказывает. В данном случае принципиально, чтобы по данному пути было минимальное количество элементов. Пробовал записывать function предварительно в триггер, при этом изменив multicycle_path с 4 на 3, это исправило ситуацию, однако зачем ставить дополнительный триггер, если можно обойтись без него (теоретически). Но на практике это сделать не получается, что посоветуете? Изменено 4 февраля, 2019 пользователем Dantist2k17 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 4 февраля, 2019 Опубликовано 4 февраля, 2019 · Жалоба Приветствую! Вам не нравится как синтезатор на кирпичики вашу логику разложил или он не то синтезирует функционально? Основная задача синтезатора реализовать функционал так чтобы он лег на имеющиеся примитивы и уложился в пользовательские constarints. А как это будет выглядеть на "схематике" не важно. Если есть возможность объединить несколько функций в одном LUT и времянки выполняются то почему надо размазывать это на несколько LUT? Если же нужна "красота" или это необходимо для дизайна то всегда можно придушить самостоятельность синтезатора используя constarints синтеза например (* keep =1 *) wire flag_f = flag[3] & function; data <= data | flag_f; Или вручную добавляя в код соответствующие примитивы. Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dantist2k17 0 4 февраля, 2019 Опубликовано 4 февраля, 2019 · Жалоба 11 minutes ago, RobFPGA said: Приветствую! Вам не нравится как синтезатор на кирпичики вашу логику разложил или он не то синтезирует функционально? Основная задача синтезатора реализовать функционал так чтобы он лег на имеющиеся примитивы и уложился в пользовательские constarints. А как это будет выглядеть на "схематике" не важно. Если есть возможность объединить несколько функций в одном LUT и времянки выполняются то почему надо размазывать это на несколько LUT? Если же нужна "красота" или это необходимо для дизайна то всегда можно придушить самостоятельность синтезатора используя constarints синтеза например (* keep =1 *) wire flag_f = flag[3] & function; data <= data | flag_f; Или вручную добавляя в код соответствующие примитивы. Удачи! Rob. Мне не нравится как он разложил, функционально все верно. Просто в данном случае я очень сильно зажат по быстродействию, и на путь от data_a до data есть multicycle_path которого хватает чтобы получить положительный slack, а по пути от flag до data всего один период, которого к сожалению не хватает при такой результирующей схеме, однако вполне будет хватать если схема будет в таком виде, как я ожидаю увидеть. Я разрабатываю под ASIC, синтез через DC. Добавить в код соответствующие примитивы конечно можно, но хотелось бы поизящней что ли. По-поводу (* keep =1 *) wire flag_f = flag[3] & function; не понимаю что вы подразумеваете под (* keep =1 *), добавлять в код промежуточный wire не пробовал. Спасибо за совет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 4 февраля, 2019 Опубликовано 4 февраля, 2019 · Жалоба Приветствую! 41 minutes ago, Dantist2k17 said: (* keep =1 *) wire flag_f = flag[3] & function; не понимаю что вы подразумеваете под (* keep =1 *), добавлять в код промежуточный wire не пробовал. Это из жизни FPGAшника :) Этот код говорит синтезатору что при синтезе не оптимизировать (сделать как есть) цепь flag_f. Так что с большой вероятность flag[3] не будет втянут в логику function. Для ASIC под DC не скажу - не мой профиль. Но может быть что-то похожее типа syn_keep, syn_noprune, syn_preserve, ... P.S. Все же лучше было бы keep повесит на function - ( (* keep *) wire function;) тогда точно flag[3] в function не попадет ни как. Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Avex 1 4 февраля, 2019 Опубликовано 4 февраля, 2019 (изменено) · Жалоба Синтезатор все верно сделал, если использован констрейнт multicycle 4. Этот констрейнт накладывает лимит по сетапу 4 такта, а по холду 3 такта. Вот у Вас синтезатор и вытянул (попытался) эти 3 такта по холду, напихав лишних задержек в виде дополнительной логики. Подумайте, нужен ли Вам здесь малтисайкл. Констрейнты не обязаны повторять особенности интерфейса, они предназначены для временных ограничений, задавать которые можно разными способами. Если логики по входу мало, то лучше малтисайкл не использовать. Малтисайкл вообще лучше не использовать, т.к. он привязывает дизайн к фиксированой частоте. Т.е. дизайн без малтисайкла будет работать на частоте от 0 до Fmax, а с малтисайклом только в небольшом окне частот вблизи Fmax. Зависит от задачи, конечно. В некоторых случаях без малтисайкла никак. Но недостатки такого решения надо знать. Изменено 4 февраля, 2019 пользователем Aleх Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dvlwork 0 5 февраля, 2019 Опубликовано 5 февраля, 2019 · Жалоба Ну здесь наверное подразумевалось: set_multicycle_path 4 -setup set_multicycle_path 3 -hold Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dantist2k17 0 5 февраля, 2019 Опубликовано 5 февраля, 2019 (изменено) · Жалоба 18 hours ago, Aleх said: Синтезатор все верно сделал, если использован констрейнт multicycle 4. Этот констрейнт накладывает лимит по сетапу 4 такта, а по холду 3 такта. Вот у Вас синтезатор и вытянул (попытался) эти 3 такта по холду, напихав лишних задержек в виде дополнительной логики. Подумайте, нужен ли Вам здесь малтисайкл. Констрейнты не обязаны повторять особенности интерфейса, они предназначены для временных ограничений, задавать которые можно разными способами. Если логики по входу мало, то лучше малтисайкл не использовать. Малтисайкл вообще лучше не использовать, т.к. он привязывает дизайн к фиксированой частоте. Т.е. дизайн без малтисайкла будет работать на частоте от 0 до Fmax, а с малтисайклом только в небольшом окне частот вблизи Fmax. Зависит от задачи, конечно. В некоторых случаях без малтисайкла никак. Но недостатки такого решения надо знать. В данном случае без него никак. Если убрать multicycle то логическая схема получается абсолютно такой же как и при его наличии. Я могу заблуждаться, но не могу согласиться с какой-либо оптимизацией по hold time, так как на данном этапе синтеза нет никакого clock tree, идет оценка только по setup time. Логики по входу мало, но она не способна отработать на требуемой частоте за один период, задача из разряда "впихнуть невпихуемое". За недостаток спасибо, на этапе физ синтеза необходимо будет задавать ограничения и на hold. Как я понимаю, задача multicycle указать синтезатору места, в которых у логики есть больше одного такта на обработку, дабы он не занимался оптимизацией там, где это не столь критично (с учетом увеличенных запасов по времени, которые определяются схемотехникой/verilog описанием). Изменено 5 февраля, 2019 пользователем Dantist2k17 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dantist2k17 0 5 февраля, 2019 Опубликовано 5 февраля, 2019 (изменено) · Жалоба 2 hours ago, dvlwork said: Ну здесь наверное подразумевалось: set_multicycle_path 4 -setup set_multicycle_path 3 -hold multicycle_path по hold_time не указывал, речь идет про логический синтез без clock tree, анализа и оптимизации по времени удержания не происходит Изменено 5 февраля, 2019 пользователем Dantist2k17 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FatRobot 0 5 февраля, 2019 Опубликовано 5 февраля, 2019 · Жалоба Оформите нужный вам функционал (AND, OR, регистры flag и data) в отдельный модуль, а при синтезе отмените для него ungroup и cross-boundary optimization или синтезируйте получившийся модуль отдельно, а потом вставьте как black box Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dantist2k17 0 6 февраля, 2019 Опубликовано 6 февраля, 2019 · Жалоба 10 hours ago, Fat Robot said: Оформите нужный вам функционал (AND, OR, регистры flag и data) в отдельный модуль, а при синтезе отмените для него ungroup и cross-boundary optimization или синтезируйте получившийся модуль отдельно, а потом вставьте как black box Спасибо, такой подход имеет право на жизнь, однако подобными костылями не хочется пользоваться. Если не смогу разобраться то просто вынесу формирование функции в отдельный модуль при поведенческом описании. На синтез запускаю командой compile_ultra -no_autoungroup -no_boundary_optimization. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
honinbo 1 8 февраля, 2019 Опубликовано 8 февраля, 2019 · Жалоба On 2/4/2019 at 1:42 PM, Dantist2k17 said: On 2/4/2019 at 2:42 PM, Dantist2k17 said: . Я разрабатываю под ASIC, синтез через DC. Как я понимаю синтезатор просто замешивает flag_reg в логику формирования функции в процессе оптимизации, вот только с какой целью, делал синтез на разных частотах, результат не меняется, наличие/отсутствие multicycle_path в sdc тоже влияния не оказывает. В данном случае принципиально, чтобы по данному пути было минимальное количество элементов. Раз нет разницы с multicycle_path и без него логичен вопрос - А multicycle_path применился ли вообще так ка ВЫ задумали? Что в логе по этому поводу? Можно еще командой report_timing_requarements явно посмотреть. Провел эксперимент ради спортивного интереса. Все нормально отработало в DC 2016.03. Задираешь частоту - логика примешивается к flag, чтобы слэк негативный уменьшить. Применяешь multicycle_path - все становится на свои места: и констрейны выполняются, и лишней логики нет от flag к data. Только multicycle_path я задавал так (как у Вас - DC говорит: Can't find object ...): create_clock -name clk ... [get_port clk] set_multicycle_path 4 -end -setup -from clk -to clk -thr {\data_a_reg*} Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dvlwork 0 8 февраля, 2019 Опубликовано 8 февраля, 2019 · Жалоба но без set_multicycle_path 3 -hold это ж дичь будет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
honinbo 1 8 февраля, 2019 Опубликовано 8 февраля, 2019 · Жалоба виноват, у меня без ключа -setup было. По умолчанию это 4 для setup и 3 для hold. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dantist2k17 0 8 февраля, 2019 Опубликовано 8 февраля, 2019 · Жалоба 43 minutes ago, honinbo said: Раз нет разницы с multicycle_path и без него логичен вопрос - А multicycle_path применился ли вообще так ка ВЫ задумали? Что в логе по этому поводу? Можно еще командой report_timing_requarements явно посмотреть. Провел эксперимент ради спортивного интереса. Все нормально отработало в DC 2016.03. Задираешь частоту - логика примешивается к flag, чтобы слэк негативный уменьшить. Применяешь multicycle_path - все становится на свои места: и констрейны выполняются, и лишней логики нет от flag к data. Только multicycle_path я задавал так (как у Вас - DC говорит: Can't find object ...): create_clock -name clk ... [get_port clk] set_multicycle_path 4 -end -setup -from clk -to clk -thr {\data_a_reg*} Я работаю в DC 2014.09. От частоты зависимости не наблюдаю, также как и от наличия multicycle_path (схема выглядит примерно одинаково). multicycle_path применился, расчет timing по пути, осуществляется на 4 периодах. Сейчас проделал тоже самое в DC 2010.12 все аналогично, чудес не бывает, видимо что-то делаю не так. Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
honinbo 1 8 февраля, 2019 Опубликовано 8 февраля, 2019 · Жалоба Раз уж ввязался - вот полный отчет об эксперименте. DC 2014.09 Spoiler Исходный код: `timescale 1ns/10ps module test ( input clk, input rst, input [31:0] a, input [31:0] b, output d ); reg [31:0] data_a; reg [31:0] data_b; reg [3:0] flag; reg data; wire f; always@(posedge clk or negedge rst) begin if(!rst) begin data_a <= 32'h00000000; data_b <= 32'h00000000; end else begin data_a <= a; data_b <= b; end end assign d = data; //счетчие в коде 1 из N always@(posedge clk or negedge rst) begin if(!rst) flag <= 4'd1; else flag <= flag << 1 | flag[3]; end assign f = (data_a == data_b); always@(posedge clk or negedge rst) begin if(!rst) data <= 1'b0; else data <= data | flag[3] & f; end endmodule Репорт без multi_cycle_path **************************************** Report : timing -path full -delay max -max_paths 1 Design : test Version: J-2014.09-SP3 Date : Fri Feb 8 15:01:51 2019 **************************************** Operating Conditions: slow Library: BMK_040_slow Wire Load Model Mode: top Startpoint: flag_reg[3] (rising edge-triggered flip-flop clocked by CLK) Endpoint: data_reg (rising edge-triggered flip-flop clocked by CLK) Path Group: CLK Path Type: max Point Incr Path ----------------------------------------------------------- clock CLK (rise edge) 0.00 0.00 clock network delay (propagated) 0.00 0.00 flag_reg[3]/c (dfrrqx1) 0.00 0.00 r flag_reg[3]/q (dfrrqx1) <- 1.40 1.40 r U45/q (inx1) 0.18 1.59 f U43/q (inx1) 0.15 1.74 r U42/q (no2i1x1) 0.36 2.09 r U41/q (na2x1) 0.30 2.39 f U46/q (na2i1x1) 0.21 2.60 r data_reg/d (dfrrqx1) 0.00 2.60 r data arrival time 2.60 clock CLK (rise edge) 4.00 4.00 clock network delay (propagated) 0.00 4.00 data_reg/c (dfrrqx1) 0.00 4.00 r library setup time -0.29 3.71 data required time 3.71 ----------------------------------------------------------- data required time 3.71 data arrival time -2.60 ----------------------------------------------------------- slack (MET) 1.10 1 report_timing -to data_reg/d -from *data_a_reg[3]/q **************************************** Report : timing -path full -delay max -max_paths 1 Design : test Version: J-2014.09-SP3 Date : Fri Feb 8 15:01:51 2019 **************************************** Operating Conditions: slow Library: BMK_040_slow Wire Load Model Mode: top Startpoint: data_a_reg[3] (rising edge-triggered flip-flop clocked by CLK) Endpoint: data_reg (rising edge-triggered flip-flop clocked by CLK) Path Group: CLK Path Type: max Point Incr Path ----------------------------------------------------------- clock CLK (rise edge) 0.00 0.00 clock network delay (propagated) 0.00 0.00 data_a_reg[3]/c (dfrrqx1) 0.00 0.00 r data_a_reg[3]/q (dfrrqx1) <- 1.62 1.62 f U22/q (eo2x1) 0.45 2.07 f U30/q (or8x1) 0.95 3.03 f U44/q (no2x1) 0.33 3.36 r U41/q (na2x1) 0.30 3.66 f U46/q (na2i1x1) 0.21 3.87 r data_reg/d (dfrrqx1) 0.00 3.87 r data arrival time 3.87 clock CLK (rise edge) 4.00 4.00 clock network delay (propagated) 0.00 4.00 data_reg/c (dfrrqx1) 0.00 4.00 r library setup time -0.29 3.71 data required time 3.71 ----------------------------------------------------------- data required time 3.71 data arrival time -3.87 ----------------------------------------------------------- slack (VIOLATED) -0.16 1 Репорт с multicycle_path create_clock -name CLK -period 4 -waveform "0 2" [get_ports clk] 1 set_input_delay -max -clock CLK 1 [remove_from_collection [all_inputs] [get_ports "clk"]] 1 set_input_delay -min -clock CLK 0 [remove_from_collection [all_inputs] [get_ports "clk"]] 1 set_output_delay -max -clock CLK 1 [all_outputs] 1 set_input_transition -max 2 [all_inputs] 1 set_input_transition -min 0 [all_inputs] 1 set_load 0.4 [all_outputs] 1 set_multicycle_path 4 -end -setup -from CLK -thr {\data_a_reg*} -to CLK 1 set_multicycle_path 4 -end -setup -from CLK -thr {\data_b_reg*} -to CLK 1 set_multicycle_path 3 -end -hold -from CLK -thr {\data_a_reg*} -to CLK 1 set_multicycle_path 3 -end -hold -from CLK -thr {\data_b_reg*} -to CLK 1 set_propagated_clock [all_clocks] Information: set_input_delay values are added to the propagated clock skew. (TIM-113) 1 compile -map_effort high -incr ... Optimization Complete --------------------- 1 report_timing -to data_reg/d -from *flag_reg[3]/q **************************************** Report : timing -path full -delay max -max_paths 1 Design : test Version: J-2014.09-SP3 Date : Fri Feb 8 15:04:02 2019 **************************************** Operating Conditions: slow Library: BMK_040_slow Wire Load Model Mode: top Startpoint: flag_reg[3] (rising edge-triggered flip-flop clocked by CLK) Endpoint: data_reg (rising edge-triggered flip-flop clocked by CLK) Path Group: CLK Path Type: max Point Incr Path ----------------------------------------------------------- clock CLK (rise edge) 0.00 0.00 clock network delay (propagated) 0.00 0.00 flag_reg[3]/c (dfrrqx1) 0.00 0.00 r flag_reg[3]/q (dfrrqx1) <- 1.40 1.40 r C164/q (and2x1) 0.44 1.84 r C163/q (or2x1) 0.31 2.15 r data_reg/d (dfrrqx4) 0.00 2.15 r data arrival time 2.15 clock CLK (rise edge) 4.00 4.00 clock network delay (propagated) 0.00 4.00 data_reg/c (dfrrqx4) 0.00 4.00 r library setup time -0.29 3.71 data required time 3.71 ----------------------------------------------------------- data required time 3.71 data arrival time -2.15 ----------------------------------------------------------- slack (MET) 1.56 1 report_timing -to data_reg/d -from *data_a_reg[3]/q **************************************** Report : timing -path full -delay max -max_paths 1 Design : test Version: J-2014.09-SP3 Date : Fri Feb 8 15:04:02 2019 **************************************** Operating Conditions: slow Library: BMK_040_slow Wire Load Model Mode: top Startpoint: data_a_reg[3] (rising edge-triggered flip-flop clocked by CLK) Endpoint: data_reg (rising edge-triggered flip-flop clocked by CLK) Path Group: CLK Path Type: max Point Incr Path ----------------------------------------------------------- clock CLK (rise edge) 0.00 0.00 clock network delay (propagated) 0.00 0.00 data_a_reg[3]/c (dfrrqx1) 0.00 0.00 r data_a_reg[3]/q (dfrrqx1) <- 1.62 1.62 f U22/q (eo2x1) 0.45 2.07 f U30/q (or8x1) 0.96 3.03 f U40/q (no3x1) 0.47 3.50 r C164/q (and2x1) 0.47 3.97 r C163/q (or2x1) 0.31 4.28 r data_reg/d (dfrrqx4) 0.00 4.28 r data arrival time 4.28 clock CLK (rise edge) 16.00 16.00 clock network delay (propagated) 0.00 16.00 data_reg/c (dfrrqx4) 0.00 16.00 r library setup time -0.29 15.71 data required time 15.71 ----------------------------------------------------------- data required time 15.71 data arrival time -4.28 ----------------------------------------------------------- slack (MET) 11.43 1 Репорт с пониженной частотой create_clock -name CLK -period 8 -waveform "0 4" [get_ports clk] 1 set_input_delay -max -clock CLK 1 [remove_from_collection [all_inputs] [get_ports "clk"]] 1 set_input_delay -min -clock CLK 0 [remove_from_collection [all_inputs] [get_ports "clk"]] 1 set_output_delay -max -clock CLK 1 [all_outputs] 1 set_input_transition -max 2 [all_inputs] 1 set_input_transition -min 0 [all_inputs] 1 set_load 0.4 [all_outputs] 1 #set_multicycle_path 4 -end -setup -from CLK -thr {\data_a_reg*} -to CLK #set_multicycle_path 4 -end -setup -from CLK -thr {\data_b_reg*} -to CLK #set_multicycle_path 3 -end -hold -from CLK -thr {\data_a_reg*} -to CLK #set_multicycle_path 3 -end -hold -from CLK -thr {\data_b_reg*} -to CLK set_propagated_clock [all_clocks] Information: set_input_delay values are added to the propagated clock skew. (TIM-113) 1 compile -map_effort high -incr Optimization Complete --------------------- 1 report_timing -to data_reg/d -from *flag_reg[3]/q Information: Updating design information... (UID-85) Information: Input delay ('fall') on clock port 'CLK' will be added to the clock's propagated skew. (TIM-112) Information: Input delay ('rise') on clock port 'CLK' will be added to the clock's propagated skew. (TIM-112) **************************************** Report : timing -path full -delay max -max_paths 1 Design : test Version: J-2014.09-SP3 Date : Fri Feb 8 15:22:41 2019 **************************************** Operating Conditions: slow Library: BMK_040_slow Wire Load Model Mode: top Startpoint: flag_reg[3] (rising edge-triggered flip-flop clocked by CLK) Endpoint: data_reg (rising edge-triggered flip-flop clocked by CLK) Path Group: CLK Path Type: max Point Incr Path ----------------------------------------------------------- clock CLK (rise edge) 0.00 0.00 clock network delay (propagated) 0.00 0.00 flag_reg[3]/c (dfrrqx1) 0.00 0.00 r flag_reg[3]/q (dfrrqx1) <- 1.40 1.40 r C164/q (and2x1) 0.44 1.84 r C163/q (or2x1) 0.31 2.15 r data_reg/d (dfrrqx4) 0.00 2.15 r data arrival time 2.15 clock CLK (rise edge) 8.00 8.00 clock network delay (propagated) 0.00 8.00 data_reg/c (dfrrqx4) 0.00 8.00 r library setup time -0.29 7.71 data required time 7.71 ----------------------------------------------------------- data required time 7.71 data arrival time -2.15 ----------------------------------------------------------- slack (MET) 5.56 1 report_timing -to data_reg/d -from *data_a_reg[3]/q **************************************** Report : timing -path full -delay max -max_paths 1 Design : test Version: J-2014.09-SP3 Date : Fri Feb 8 15:22:41 2019 **************************************** Operating Conditions: slow Library: BMK_040_slow Wire Load Model Mode: top Startpoint: data_a_reg[3] (rising edge-triggered flip-flop clocked by CLK) Endpoint: data_reg (rising edge-triggered flip-flop clocked by CLK) Path Group: CLK Path Type: max Point Incr Path ----------------------------------------------------------- clock CLK (rise edge) 0.00 0.00 clock network delay (propagated) 0.00 0.00 data_a_reg[3]/c (dfrrqx1) 0.00 0.00 r data_a_reg[3]/q (dfrrqx1) <- 1.62 1.62 f U22/q (eo2x1) 0.45 2.07 f U30/q (or8x1) 0.96 3.03 f U40/q (no3x1) 0.47 3.50 r C164/q (and2x1) 0.47 3.97 r C163/q (or2x1) 0.31 4.28 r data_reg/d (dfrrqx4) 0.00 4.28 r data arrival time 4.28 clock CLK (rise edge) 8.00 8.00 clock network delay (propagated) 0.00 8.00 data_reg/c (dfrrqx4) 0.00 8.00 r library setup time -0.29 7.71 data required time 7.71 ----------------------------------------------------------- data required time 7.71 data arrival time -4.28 ----------------------------------------------------------- slack (MET) 3.43 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
