cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
3,080 Views
Registered: ‎02-27-2018

Hold slack vivado

Hello,

 

I have an FPGA design that uses 2 outside clocks (INCLK and TXCLK) from an ADC to latch data also coming from an ADC (TXOUT) and a system clock.

A defined INCLK TXCLK and clk_sys as primary clocks in the timing constraints editor.

When i run the timing analysis, it appears that i have old time violation.

1) there a hold time violation for the path between the registers of U3 (LMreceiver) and U2 (capture) so i thought if added some logic between these registers i would solve the problem , but nothing changes.

2) there a hold time violation for paths inside the modules fifo_generator_1, these modules have been generated by the IP catalog so i cannot modify them.. Is there anything i can do?

My understanding of hold time violation is that we can fix them by introducing in the path some logic to delay the signal

 

0 Kudos
15 Replies
Highlighted
Guide
Guide
3,069 Views
Registered: ‎01-23-2009

Re: Hold slack vivado

Most likely your clock and capture architecture are incorrect...

 

Working with a gapped clock is very tricky. You cannot treat this interface as a "normal" ADC interface since the clock is gapped - in a normal ADC interface, all you need is the ADC bitclock (TXCLK in your case) and a frame signal.

 

Since this clock is gapped, you need to work on some other clock domain - the one you show is INCLK. But INCLK and TXCLK are not phase matched - there is a time shown (tDOD) between INCLK and TXCLK - this may be good - tell us the value of this parameter. Unfortunately, the other relationship that would be necessary (from the last rising or falling edge of TXCLK to the rising edge of INCLK) is not shown.

 

Assuming tDOD and this non-specified delay are "large enough", then you can do a synchronous transfer between these two domains. But the constraints for this are complicated; they need to be specified with a set_max_delay (without a datapath_only) to describe the minimum separation of these clock edges at the pins of the FPGA.

 

Without this constraint, the tool assumes these two clocks are synchronous and in-phase at the pins, and (presumably due to the clock architecture) you get hold time violations between them - without the full path report we can't see why - but again, as it is described now, the timing analysis being performed on the path is meaningless.

 

As for clk_sys, we have no idea what that is, nor how it relate to the other clocks, and hence cannot give you any information on the timing associated with this domain.

 

"Real" hold times will be fixed by the tool; there is nothing you can do in your RTL that will affect them. Generally when you have internal  hold time problems (which means they were larger than what the tool can fix), these are false hold requirements created by a bad clock architecture or bad constraints.

 

Avrum

0 Kudos
Highlighted
Explorer
Explorer
3,038 Views
Registered: ‎02-27-2018

Re: Hold slack vivado

Hello avrumw thanks for your clear answer,

Here is a figure that describes the separation between the clock edges.

When you say a synchronous transfer between these two domains do you mean :

latch the data on a shift register of 7 width on every rising edge on TXCLK and the latch the parallelelized 7 word bit on every rising edge of INCLK?

I think it is what i did i join also the code below.

clk_sys is just a clock to clock the module state machine and one side of the asynchronous fifo.

I use an ASYNCHRONOUS FIFO, i write on the FIFO on every rising edge of INCLK and i read the FIFO with a clock called clk_sys.

I also have a state machine that is synchronous to clk_sys.

This state machine is there to reset the fifo and manage the read and write cycle on the FIFO and monitors the empty and full flags of the FIFO.

projet1.png
0 Kudos
Highlighted
Explorer
Explorer
3,036 Views
Registered: ‎02-27-2018

Re: Hold slack vivado

here is the code for the capture of the data on the rising edges of TXCLK and the capture of the parrelel word on the rising edge of INCLK.

0 Kudos
Highlighted
Guide
Guide
3,021 Views
Registered: ‎01-23-2009

Re: Hold slack vivado

(I haven't tried this myself before, but...)

 

With the timing you specified, you have to override the normal setup/hold checks performed on the path between the shift register and the capture flip-flops.

 

This should be done with a set_max_delay command. I am pretty sure the the command would be

 

set_max_delay -from [get_cells <shift_register_ffs>] -to [get_cells <capture_ffs>] <t1>

set_min_delay -from [get_cells <shift_register_ffs>] -to [get_cells <capture_ffs>] -<t2>

 

This basically tells the tool that it has t1 to propagate from the shift registers to the capture FFs. Without the -datapath_only, this means that the tool should include all the clock propagation delays.

 

On the hold, you are saying as long as the minimum propagation is more than -<t2>, there is no hold time failure. This is a significant relaxation of the hold requirement (which is normally 0), and is warranted by the fact that the next edge of TXCLK is long after the edge of INCLK.

 

BUT - you need to come up with correct values for t1 and t2. The relationship shown for T2 is wierd; why would they go from INCLK to DATA and then from DATA to TXCLK. But t2 isn't all that critical, as long as it is more than 1-2ns the tools should be fine. My concern is t1; there is nothing in the diagram you posted that gives you any promise as to the relationship t1; there is no information on the length of the gap. Yes, tQHF shows the hold time with respect to the falling edge TXCLK, and the diagram draws the rising edge of INCLK as happening after that, but there is no timing arc that guarantees that there is a relationship between either the last TXCLK or the last data and the rising edge of INCLK - for all you know it could come significantly before the deassertion of data or the falling edge of TXCLK, or, for that matter, even before the rising edge of TXCLK...

 

Avrum

 

 

Highlighted
Explorer
Explorer
3,015 Views
Registered: ‎02-27-2018

Re: Hold slack vivado

I am trying to set the maximum delay between the TXCLK and INCLK looking at the time diagram: the INCLK can be delayed by a maximum of 7 ns and the TXCLK can be delayed by about 2 ns (t1)

I am not sure that i set the correct path in my set_max_delay instructions.

the sum of the blue path and the green path can be a at a maximum of (2 ns = t1 )of delay.

 

setmaxdelay.png
0 Kudos
Highlighted
Explorer
Explorer
3,013 Views
Registered: ‎02-27-2018

Re: Hold slack vivado

I haven't seen your previous message before posting

0 Kudos
Highlighted
Explorer
Explorer
3,005 Views
Registered: ‎02-27-2018

Re: Hold slack vivado

Thanks for your reply, I will check the correct values for t1 and t2 but i am almost positive that t2 > 7 ns and t1 > 4 ns

The relation for t2 is actually : they go from the rising edge of INCLK to the rising edge of TXFRM and from the rising edge of TXFRM to the rising edge of TXCLK.

 

set_max_delay -from [get_cells <shift_register_ffs>] -to [get_cells <capture_ffs>] <t1>

set_min_delay -from [get_cells <shift_register_ffs>] -to [get_cells <capture_ffs>] -<t2>

 

I understand that these instructions define the maximum and minimum time for the parallel word to travel between the shift register to the capture flip flops, but i have as well to write a constraint on INCLK no? The rising edge of INCLK needs to arrive at flip flops before the next rising of TXCLK, right?

My understand is that i also should write a constraint for the path between the INCLK port and the INCLK pin of the module capture.

 

0 Kudos
Highlighted
Guide
Guide
3,000 Views
Registered: ‎01-23-2009

Re: Hold slack vivado

I understand that these instructions define the maximum and minimum time for the parallel word to travel between the shift register to the capture flip flops, but i have as well to write a constraint on INCLK no?

 

So, yes and no.

 

You need a constraint on INCLK to specify the period - this will be necessary for all the paths from INCLK to INCLK. This would be a simple "create_clock" with the period of INCLK.

 

But as for the relationship between INCLK and TXCLK, there is not really an way to describe the gapped clock. As a result, we cannot constrain the paths between these domains the "normal" way, which is done by describing the clocks. That is why we need to do the set_max_delay/set_min_delay - this overrides the "normal" timing checks on these paths. Assuming these are the only paths between TXCLK and INCLK then the tool knows all it needs to know. Since we have done this, the relative phase of the two clocks is now irrelevant - it would only affect the paths between the two domains, and we are overriding those with an exception (set_min/max_delay).

 

Finally, you need real constraints (set_input_delay) between TXCLK and TXOUT. These are required to ensure that you have designed the capture mechanism properly. This interface is a bit weird since the setup time is described to the rising edge but the hold is described to the falling edge (most modern interfaces don't do that). You can try and do this using the

 

set_input_delay -min -clock_fall ...

 

or you can do the math and figure out the relationship to the next rising edge...

 

Avrum

Highlighted
Explorer
Explorer
2,952 Views
Registered: ‎02-27-2018

Re: Hold slack vivado

Thank you this is way clearer now, i have set an input delay between  TXCLK and TXOUT, should i also define TXCLK like a clock using create clock? (since this signal is gapped i don't know if i should do that)

0 Kudos
Highlighted
Guide
Guide
2,370 Views
Registered: ‎01-23-2009

Re: Hold slack vivado

Thank you this is way clearer now, i have set an input delay between  TXCLK and TXOUT, should i also define TXCLK like a clock using create clock? (since this signal is gapped i don't know if i should do that)

 

You say you defined an input delay on TXOUT. An input delay is specified with respect to a clock not with respect to a port. You seem to imply that you have not created a clock on the TXCLK port - if this is the case, how can you have a set_input_delay?

 

But answering your question - yes, you should have a create clock on the TXCLK - even though it is a gapped clock, and we cannot describe the "gap" to the tools. The clock is required for the input timing relationship of TXOUT and for any logic running on TXCLK - the "shortest" period is what we need to tell the tool. The fact that there are "gaps" where the period will be substantially longer than the normal period is irrelevant to the static timing analysis. The only real impact is the transfer from the TXCLK to INCLK domain - without the gap in the clock, this can't be done the way we have described it. Since we are using the gap for this purpose, we need the exceptions described earlier in this thread.

 

Avrum

Highlighted
Explorer
Explorer
2,312 Views
Registered: ‎02-27-2018

Re: Hold slack vivado

No actually i did define TXCLK as a clock and set the constraint on txout this way :

set_input_delay -clock [get_clocks {TXCLKp[0]}] -min -add_delay 3.030 [get_ports {TXOUT0n[0]}]
set_input_delay -clock [get_clocks {TXCLKp[0]}] -max -add_delay 4.370 [get_ports {TXOUT0n[0]}]
set_input_delay -clock [get_clocks {TXCLKp[1]}] -min -add_delay 3.030 [get_ports {TXOUT0n[1]}]
set_input_delay -clock [get_clocks {TXCLKp[1]}] -max -add_delay 4.370 [get_ports {TXOUT0n[1]}]
set_input_delay -clock [get_clocks {TXCLKp[2]}] -min -add_delay 3.030 [get_ports {TXOUT0n[2]}]
set_input_delay -clock [get_clocks {TXCLKp[2]}] -max -add_delay 4.370 [get_ports {TXOUT0n[2]}]
set_input_delay -clock [get_clocks {TXCLKp[3]}] -min -add_delay 3.030 [get_ports {TXOUT0n[3]}]
set_input_delay -clock [get_clocks {TXCLKp[3]}] -max -add_delay 4.370 [get_ports {TXOUT0n[3]}]
set_input_delay -clock [get_clocks {TXCLKp[4]}] -min -add_delay 3.030 [get_ports {TXOUT0n[4]}]
set_input_delay -clock [get_clocks {TXCLKp[4]}] -max -add_delay 4.370 [get_ports {TXOUT0n[4]}]
set_input_delay -clock [get_clocks {TXCLKp[5]}] -min -add_delay 3.030 [get_ports {TXOUT0n[5]}]
set_input_delay -clock [get_clocks {TXCLKp[5]}] -max -add_delay 4.370 [get_ports {TXOUT0n[5]}]
set_input_delay -clock [get_clocks {TXCLKp[6]}] -min -add_delay 3.030 [get_ports {TXOUT0n[6]}]
set_input_delay -clock [get_clocks {TXCLKp[6]}] -max -add_delay 4.370 [get_ports {TXOUT0n[6]}]
set_input_delay -clock [get_clocks {TXCLKp[7]}] -min -add_delay 3.030 [get_ports {TXOUT0n[7]}]
set_input_delay -clock [get_clocks {TXCLKp[7]}] -max -add_delay 4.370 [get_ports {TXOUT0n[7]}]

0 Kudos
Highlighted
Explorer
Explorer
2,332 Views
Registered: ‎02-27-2018

Re: Hold slack vivado

(I haven't tried this myself before, but...)

 

With the timing you specified, you have to override the normal setup/hold checks performed on the path between the shift register and the capture flip-flops.

 

This should be done with a set_max_delay command. I am pretty sure the the command would be

 

set_max_delay -from [get_cells <shift_register_ffs>] -to [get_cells <capture_ffs>] <t1>

set_min_delay -from [get_cells <shift_register_ffs>] -to [get_cells <capture_ffs>] -<t2>

 

This basically tells the tool that it has t1 to propagate from the shift registers to the capture FFs. Without the -datapath_only, this means that the tool should include all the clock propagation delays.

 

Actually my design has 8 ADC for inputs.

With this new design (i have joined the schematic in pdf) should the command be written like this?

set_max_delay -from [get_cells UUT/U2/U0] -to [get_cells UUT/U2/capture ] <t1>

set_max_delay -from [get_cells UUT/U2/U1] -to [get_cells UUT/U2/capture ] <t1>

set_max_delay -from [get_cells UUT/U2/U2] -to [get_cells UUT/U2/capture ] <t1>

set_max_delay -from [get_cells UUT/U2/U3] -to [get_cells UUT/U2/capture ] <t1>

set_max_delay -from [get_cells UUT/U2/U4] -to [get_cells UUT/U2/capture ] <t1>

set_max_delay -from [get_cells UUT/U2/U5] -to [get_cells UUT/U2/capture ] <t1>

set_max_delay -from [get_cells UUT/U2/U6] -to [get_cells UUT/U2/capture ] <t1>

set_max_delay -from [get_cells UUT/U2/U7] -to [get_cells UUT/U2/capture ] <t1>

 

set_min_delay -from [get_cells UUT/U2/U0] -to [get_cells UUT/U2/capture ] <t2>

set_min_delay -from [get_cells UUT/U2/U1] -to [get_cells UUT/U2/capture ] <t2>

set_min_delay -from [get_cells UUT/U2/U2] -to [get_cells UUT/U2/capture ] <t2>

set_min_delay -from [get_cells UUT/U2/U3] -to [get_cells UUT/U2/capture ] <t2>

set_min_delay -from [get_cells UUT/U2/U4] -to [get_cells UUT/U2/capture ] <t2>

set_min_delay -from [get_cells UUT/U2/U5] -to [get_cells UUT/U2/capture ] <t2>

set_min_delay -from [get_cells UUT/U2/U6] -to [get_cells UUT/U2/capture ] <t2>

set_min_delay -from [get_cells UUT/U2/U7] -to [get_cells UUT/U2/capture ] <t2>

 

Thank you for your help

0 Kudos
Highlighted
Explorer
Explorer
2,288 Views
Registered: ‎02-27-2018

Re: Hold slack vivado

Hello,

 

Sorry to bug you with this again but there is something that i didn't really understand:

Why do we have to set a min_delay between the shift registers and the capture module?

I don't see where would be the problem if there were no delay between them.

Looking at this figure:

If there is no delay than the data would be stable long before the rising edge of INCLK and will still be stable untill the next rising edge of TXCLK;

projet.png
0 Kudos
Highlighted
Guide
Guide
2,278 Views
Registered: ‎01-23-2009

Re: Hold slack vivado

If there is no delay than the data would be stable long before the rising edge of INCLK

 

This is precisely the point of the hold check - to ensure that the minimum delay is no less than MINUS <t2> - go back to the original post and note the minus sign.

 

You are right - if the delay is greater than 0 then it is fine. But 0 is even too tight - as shown here, even if the delay is less than 0, but greater than -t2, then it is still alright.

 

With constraints you never assume anything - even though it may not make sense for the delay to be less than 0, you should still constrain it; the set_min_delay will ensure that even with all the clock skews and clock uncertainties, we never have less than -t2 delay on the path.

 

Avrum

Highlighted
Explorer
Explorer
2,261 Views
Registered: ‎02-27-2018

Re: Hold slack vivado

Ah in fact i haven't seen the minus. It makes sense now. Thank you
0 Kudos