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

    

Результаты синтеза не соответствуют ожиданиям

Приветствую. 

Имеется 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, это исправило ситуацию, однако зачем ставить дополнительный триггер, если можно обойтись без него (теоретически). Но на практике это сделать не получается, что посоветуете? 

 

Снимок2.JPG

Изменено пользователем Dantist2k17

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!   

Вам не нравится как синтезатор  на кирпичики вашу логику разложил или  он не то синтезирует функционально?

Основная задача синтезатора реализовать функционал  так чтобы он лег на имеющиеся примитивы и уложился в пользовательские constarints. А как это будет выглядеть на "схематике" не важно. Если есть возможность объединить несколько функций в одном LUT и времянки выполняются то почему надо размазывать это на несколько LUT?

Если же нужна "красота" или это необходимо для дизайна то всегда можно  придушить самостоятельность синтезатора  используя constarints синтеза например

(* keep =1 *) wire flag_f = flag[3] & function;

data <= data | flag_f;

Или вручную добавляя в код соответствующие примитивы.

Удачи! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
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 не пробовал.

 

Спасибо за совет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!

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.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Синтезатор все верно сделал, если использован констрейнт multicycle 4. Этот констрейнт накладывает лимит по сетапу 4 такта, а по холду 3 такта. Вот у Вас синтезатор и вытянул (попытался) эти 3 такта по холду, напихав лишних задержек  в виде дополнительной логики. Подумайте, нужен ли Вам здесь малтисайкл.

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

 

Малтисайкл вообще лучше не использовать, т.к. он привязывает дизайн к фиксированой частоте. Т.е. дизайн без малтисайкла будет работать на частоте от 0 до Fmax, а с малтисайклом только в небольшом окне частот вблизи Fmax. Зависит от задачи, конечно. В некоторых случаях без малтисайкла никак. Но недостатки такого решения надо знать.

Изменено пользователем Aleх

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну здесь наверное подразумевалось:

set_multicycle_path 4 -setup
set_multicycle_path 3 -hold

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
18 hours ago, Aleх said:

Синтезатор все верно сделал, если использован констрейнт multicycle 4. Этот констрейнт накладывает лимит по сетапу 4 такта, а по холду 3 такта. Вот у Вас синтезатор и вытянул (попытался) эти 3 такта по холду, напихав лишних задержек  в виде дополнительной логики. Подумайте, нужен ли Вам здесь малтисайкл.

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

 

Малтисайкл вообще лучше не использовать, т.к. он привязывает дизайн к фиксированой частоте. Т.е. дизайн без малтисайкла будет работать на частоте от 0 до Fmax, а с малтисайклом только в небольшом окне частот вблизи Fmax. Зависит от задачи, конечно. В некоторых случаях без малтисайкла никак. Но недостатки такого решения надо знать.

 

В данном случае без него никак.

Если убрать multicycle то логическая схема получается абсолютно такой же как и при его наличии. Я могу заблуждаться, но не могу согласиться с какой-либо оптимизацией по hold time, так как на данном этапе синтеза нет никакого clock tree, идет оценка только по setup time.

Логики по входу мало, но она не способна отработать на требуемой частоте за один период, задача из разряда "впихнуть невпихуемое".

За недостаток спасибо, на этапе физ синтеза необходимо будет задавать ограничения и на hold.  Как я понимаю, задача multicycle указать синтезатору места, в которых у логики есть больше одного такта на обработку, дабы он не занимался оптимизацией там, где это не столь критично (с учетом увеличенных запасов по времени, которые определяются схемотехникой/verilog описанием).

Изменено пользователем Dantist2k17

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
2 hours ago, dvlwork said:

Ну здесь наверное подразумевалось:


set_multicycle_path 4 -setup
set_multicycle_path 3 -hold

multicycle_path по hold_time не указывал, речь идет про логический синтез без clock tree, анализа и оптимизации по времени удержания не происходит

Изменено пользователем Dantist2k17

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Оформите нужный вам функционал (AND, OR, регистры flag и data) в отдельный модуль, а при синтезе отмените для него ungroup и cross-boundary optimization

или синтезируйте получившийся модуль отдельно, а потом вставьте как black box

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
10 hours ago, Fat Robot said:

Оформите нужный вам функционал (AND, OR, регистры flag и data) в отдельный модуль, а при синтезе отмените для него ungroup и cross-boundary optimization

или синтезируйте получившийся модуль отдельно, а потом вставьте как black box

Спасибо, такой подход имеет право на жизнь, однако подобными костылями не хочется пользоваться. Если не смогу разобраться то просто вынесу формирование функции в отдельный модуль при поведенческом описании. На синтез запускаю командой compile_ultra -no_autoungroup -no_boundary_optimization.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
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*}

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

виноват, у меня без ключа -setup было.

По умолчанию это  4 для setup и 3 для hold.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
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 все аналогично, чудес не бывает, видимо что-то делаю не так. Спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Раз уж ввязался - вот полный отчет об эксперименте.

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти
Авторизация