cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
1,430 Views
Registered: ‎12-12-2017

Timing constraints

Jump to solution

Hi,


The following is from timing_summary_routed.rpt (see below)

I want to use a "set_multicycle_path" command to fix this timing violation.

I used the following lines in the *.xdc file

 

set_multicycle_path 2 -setup -from [get_ports sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc_reg[*]] -to [get_clocks VIRTUAL_core_clk_core_xband_mmcm]


set_multicycle_path 1 -hold -end -from [get_ports sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc_reg[*]] -to [get_clocks VIRTUAL_core_clk_core_xband_mmcm]

 

The Vivado tool claims there is no valid -from for these constraints.
So, what shounld the correct constraint commands look like?

 

 

--------------------------------------------------------------------------------------
Slack (VIOLATED) : -0.434ns (required time - arrival time)

Source: sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_reg[120]/C Clock

(rising edge-triggered cell FDRE clocked by core_clk_core_xband_mmcm {rise@0.000ns fall@2.500ns period=5.000ns})


Destination: sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc_reg[41]/D D-input


(rising edge-triggered cell FDRE clocked by core_clk_core_xband_mmcm {rise@0.000ns fall@2.500ns period=5.000ns})


Path Group: core_clk_core_xband_mmcm
Path Type: Setup (Max at Slow Process Corner)
Requirement: 5.000ns (core_clk_core_xband_mmcm rise@5.000ns - core_clk_core_xband_mmcm rise@0.000ns)
Data Path Delay: 5.314ns (logic 1.693ns (31.859%) route 3.621ns (68.141%))
Logic Levels: 9 (LUT2=1 LUT4=1 LUT5=5 LUT6=2)
Clock Path Skew: -0.096ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): -1.237ns = ( 3.763 - 5.000 )
Source Clock Delay (SCD): -0.684ns
Clock Pessimism Removal (CPR): 0.457ns
Clock Uncertainty: 0.087ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
Total System Jitter (TSJ): 0.071ns
Discrete Jitter (DJ): 0.158ns
Phase Error (PE): 0.000ns
Clock Net Delay (Source): 3.576ns (routing 1.483ns, distribution 2.093ns)
Clock Net Delay (Destination): 3.248ns (routing 1.365ns, distribution 1.883ns)

Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock core_clk_core_xband_mmcm rise edge)
0.000 0.000 r
AD30 0.000 0.000 r I_CLK (IN)
net (fo=0) 0.000 0.000 core_xband_mmcm_0/inst/clkin1_ibuf/I
AD30 INBUF (Prop_INBUF_HPIOB_PAD_O)
0.614 0.614 r core_xband_mmcm_0/inst/clkin1_ibuf/INBUF_INST/O
net (fo=1, routed) 0.103 0.717 core_xband_mmcm_0/inst/clkin1_ibuf/OUT
AD30 IBUFCTRL (Prop_IBUFCTRL_HPIOB_I_O)
0.000 0.717 r core_xband_mmcm_0/inst/clkin1_ibuf/IBUFCTRL_INST/O
net (fo=1, routed) 1.075 1.792 core_xband_mmcm_0/inst/clk_in1_core_xband_mmcm
MMCME3_ADV_X0Y4 MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT0)
-6.654 -4.862 r core_xband_mmcm_0/inst/mmcme3_adv_inst/CLKOUT0
net (fo=1, routed) 0.501 -4.361 core_xband_mmcm_0/inst/core_clk_core_xband_mmcm
BUFGCE_X0Y109 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.101 -4.260 r core_xband_mmcm_0/inst/clkout1_buf/O
X1Y2 (CLOCK_ROOT) net (fo=17048, routed) 3.576 -0.684 sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/core_clk
SLICE_X72Y269 FDRE r sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_reg[120]/C
------------------------------------------------------------------- -------------------
SLICE_X72Y269 FDRE (Prop_FFF_SLICEM_C_Q)
0.139 -0.545 r sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_reg[120]/Q
net (fo=2, routed) 0.310 -0.235 sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_sval_reg[127][120]
SLICE_X72Y269 LUT2 (Prop_F5LUT_SLICEM_I1_O)
0.264 0.029 r sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc[76]_i_64/O
net (fo=128, routed) 1.172 1.201 sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/p_0_in377_out[19]
SLICE_X79Y285 LUT4 (Prop_E6LUT_SLICEM_I2_O)
0.090 1.291 r sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc[41]_i_60/O
net (fo=1, routed) 0.565 1.856 sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc[41]_i_60_n_0
SLICE_X84Y288 LUT5 (Prop_G6LUT_SLICEL_I4_O)
0.089 1.945 r sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc[41]_i_56/O
net (fo=1, routed) 0.244 2.189 sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc[41]_i_56_n_0
SLICE_X84Y289 LUT6 (Prop_C6LUT_SLICEL_I0_O)
0.235 2.424 r sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc[41]_i_49/O
net (fo=1, routed) 0.172 2.596 sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc[41]_i_49_n_0
SLICE_X85Y289 LUT5 (Prop_A6LUT_SLICEL_I3_O)
0.218 2.814 r sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc[41]_i_39/O
net (fo=1, routed) 0.171 2.985 sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/z76_in[41]
SLICE_X85Y289 LUT5 (Prop_G6LUT_SLICEL_I1_O)
0.218 3.203 r sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc[41]_i_22/O
net (fo=1, routed) 0.374 3.577 sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/gctr_0/q_h_reg[71]_2
SLICE_X86Y290 LUT6 (Prop_D6LUT_SLICEL_I1_O)
0.238 3.815 r sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/gctr_0/q_hash_calc[41]_i_8/O
net (fo=1, routed) 0.138 3.953 sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/gctr_0/q_hash_calc[41]_i_8_n_0
SLICE_X86Y290 LUT5 (Prop_B6LUT_SLICEL_I0_O)
0.053 4.006 r sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/gctr_0/q_hash_calc[41]_i_4/O
net (fo=1, routed) 0.440 4.446 sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/gctr_0/q_hash_calc[41]_i_4_n_0
SLICE_X81Y292 LUT5 (Prop_D6LUT_SLICEM_I3_O)
0.149 4.595 r sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/gctr_0/q_hash_calc[41]_i_1/O
net (fo=1, routed) 0.035 4.630 sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/D[19]
SLICE_X81Y292 FDRE r sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc_reg[41]/D
------------------------------------------------------------------- -------------------

(clock core_clk_core_xband_mmcm rise edge)
5.000 5.000 r
AD30 0.000 5.000 r I_CLK (IN)
net (fo=0) 0.000 5.000 core_xband_mmcm_0/inst/clkin1_ibuf/I
AD30 INBUF (Prop_INBUF_HPIOB_PAD_O)
0.345 5.345 r core_xband_mmcm_0/inst/clkin1_ibuf/INBUF_INST/O
net (fo=1, routed) 0.053 5.398 core_xband_mmcm_0/inst/clkin1_ibuf/OUT
AD30 IBUFCTRL (Prop_IBUFCTRL_HPIOB_I_O)
0.000 5.398 r core_xband_mmcm_0/inst/clkin1_ibuf/IBUFCTRL_INST/O
net (fo=1, routed) 0.973 6.371 core_xband_mmcm_0/inst/clk_in1_core_xband_mmcm
MMCME3_ADV_X0Y4 MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT0)
-6.369 0.002 r core_xband_mmcm_0/inst/mmcme3_adv_inst/CLKOUT0
net (fo=1, routed) 0.422 0.424 core_xband_mmcm_0/inst/core_clk_core_xband_mmcm
BUFGCE_X0Y109 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.091 0.515 r core_xband_mmcm_0/inst/clkout1_buf/O
X1Y2 (CLOCK_ROOT) net (fo=17048, routed) 3.248 3.763 sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/core_clk
SLICE_X81Y292 FDRE r sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc_reg[41]/C
clock pessimism 0.457 4.219
clock uncertainty -0.087 4.133
SLICE_X81Y292 FDRE (Setup_DFF_SLICEM_C_D)
0.063 4.196 sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc_reg[41]
-------------------------------------------------------------------
required time 4.196
arrival time -4.630
-------------------------------------------------------------------
slack -0.434

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
1,871 Views
Registered: ‎01-23-2009

set_multicycle_path 2 -setup -from [get_ports sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc_reg[*]] -to [get_clocks VIRTUAL_core_clk_core_xband_mmcm]

 

The objects "sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc_reg[*]" are  cells not ports.

 

The Vivado database maintains objects of different types; these objects are separate. As a result, you need to use the correct get_* command for the object you want. This commmand would likely work if you use either

 

[get_cells sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc_reg[*]]

 

or

 

[get_pins sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc_reg[*]/C]

 

However (and forgive me if this is obvious to you) I want to caution you about set_multicycle_path. A multicycle path is a path where it is garanteed that

  - after the startpoint changes, it will not make another change for at least N clocks

  - the endpoint only samples the change at the end of the Nth clock; the capture flip-flops do not update (the CE is disabled, or some equivalent mechanism of preventing the new data from propagating to the flip-flops) during the intervening N-1

 

If (and only if) these two conditions are true, then the path is an N cycle multicycle and can be declared as such.

 

If either of these conditions is not true, then the path is not multicycle.

 

If you do a set_multicycle_path on a path, then the tool will take your word for it; it will synthesize/implement the path differently, and will be less likely to have it as a failing path according to the multicycle constraint.

 

If you do a set_multicycle_path on a path that isn't multicycle, then the results you get from the tool will simply be incorrect. The timing report may be clean (there are no violations), but the system will not work or will be unreliable over process/temperature/voltage. Nothing in the "normal" verification mechanisms will protect against this;

  - RTL simulations will pass

  - Static timing (both as part of implementation and afterwards) will pass

 

You may (but only may) see failures if you do full timing post-implementation netlist simulation, but that is not commonly done (and this kind of simulation is so slow that it is difficult to get any kind of confidence that you have excited the potentially wrong paths).

 

Therefore, the only result you will get is a system (in the lab or in the field) that either doesn't work, or only works intermittently. And when you get a system like this, it is extremely difficult to trace back the root cause to an incorrect set_multicycle_path command.

 

So, in general be very sure and very careful about declaring a path multicycle. If you are wrong, you are opening yourself up to a very long and painful debug process...

 

Avrum

View solution in original post

3 Replies
Highlighted
Explorer
Explorer
1,412 Views
Registered: ‎10-05-2010

You need the curly braces:

 [get_ports {sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc_reg[*]}] 

 

The [] brackets invoke command substitution, so TCL wanted to evaluate [*]. The curly braces pass the entire sfx_formatter_0...[*] to get_ports without trying to evaluate [*].

 

You see this kind of syntax a lot when setting up IO constraints for buses. - get_ports {data_out[0]}

---

Joe

Tags (2)
Highlighted
Guide
Guide
1,872 Views
Registered: ‎01-23-2009

set_multicycle_path 2 -setup -from [get_ports sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc_reg[*]] -to [get_clocks VIRTUAL_core_clk_core_xband_mmcm]

 

The objects "sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc_reg[*]" are  cells not ports.

 

The Vivado database maintains objects of different types; these objects are separate. As a result, you need to use the correct get_* command for the object you want. This commmand would likely work if you use either

 

[get_cells sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc_reg[*]]

 

or

 

[get_pins sfx_formatter_0/sfx_encrypt_0/aes_gcm_encrypt_0/ghash_0/q_hash_calc_reg[*]/C]

 

However (and forgive me if this is obvious to you) I want to caution you about set_multicycle_path. A multicycle path is a path where it is garanteed that

  - after the startpoint changes, it will not make another change for at least N clocks

  - the endpoint only samples the change at the end of the Nth clock; the capture flip-flops do not update (the CE is disabled, or some equivalent mechanism of preventing the new data from propagating to the flip-flops) during the intervening N-1

 

If (and only if) these two conditions are true, then the path is an N cycle multicycle and can be declared as such.

 

If either of these conditions is not true, then the path is not multicycle.

 

If you do a set_multicycle_path on a path, then the tool will take your word for it; it will synthesize/implement the path differently, and will be less likely to have it as a failing path according to the multicycle constraint.

 

If you do a set_multicycle_path on a path that isn't multicycle, then the results you get from the tool will simply be incorrect. The timing report may be clean (there are no violations), but the system will not work or will be unreliable over process/temperature/voltage. Nothing in the "normal" verification mechanisms will protect against this;

  - RTL simulations will pass

  - Static timing (both as part of implementation and afterwards) will pass

 

You may (but only may) see failures if you do full timing post-implementation netlist simulation, but that is not commonly done (and this kind of simulation is so slow that it is difficult to get any kind of confidence that you have excited the potentially wrong paths).

 

Therefore, the only result you will get is a system (in the lab or in the field) that either doesn't work, or only works intermittently. And when you get a system like this, it is extremely difficult to trace back the root cause to an incorrect set_multicycle_path command.

 

So, in general be very sure and very careful about declaring a path multicycle. If you are wrong, you are opening yourself up to a very long and painful debug process...

 

Avrum

View solution in original post

Highlighted
Guide
Guide
1,365 Views
Registered: ‎01-23-2009

"The [] brackets invoke command substitution, so TCL wanted to evaluate [*]."

 

Actually, this isn't the case.

 

Tcl commands are a sequence of strings. During the parsing stage, each string is considered to see if it is a commmand or variable that needs substitution; this is determined by the string starting with a $ for a variable, or a [ for a command. In your example, since the [ symbol is in the middle of a string, it is not considered a command.

 

In order to be considered the beginning of a command, the [ needs to be the first character of a string. So the q_hash_calc_reg[*] is considered a regular string for wildcard matching even if it isn't in quotes.

 

And it is worth pointing out that Tcl has two kinds of quotes:

  - {} which are hard quotes - variable and command expansion will not be performed inside these quotes (unless they are part of a command that has an extra parsing phase like an if {} or a while {} or an expr {}...)

  - "" which are soft quotes - variable and command expansion are performed inside soft quotes

 

Avrum

0 Kudos