So near, but yet so far...

[FenTiger]

I'm making my first serious attempt to get a non-trivial piece of logic to work at high speed.

After a day or so of adding pipeline stages and juggling things around, I'm getting very close:

Code: [Select]

Max Delay Paths
--------------------------------------------------------------------------------------
Slack (VIOLATED) :        -0.003ns  (required time - arrival time)
  Source:                 foo/p3_trigger_reg/C
                            (rising edge-triggered cell FDRE clocked by i_clk  {rise@0.000ns fall@1.345ns period=2.690ns})
  Destination:            foo/decim_counter_reg_0_15_0_5/RAMA/WE
                            (rising edge-triggered cell RAMD32 clocked by i_clk  {rise@0.000ns fall@1.345ns period=2.690ns})

I've deliberately set the clock constraint a bit faster than my real target, to allow some margin for error, but if I relax it a little, things actually get worse!

Code: [Select]

Max Delay Paths
--------------------------------------------------------------------------------------
Slack (VIOLATED) :        -0.140ns  (required time - arrival time)
  Source:                 foo/p1_channel_reg[2]/C
                            (rising edge-triggered cell FDRE clocked by i_clk  {rise@0.000ns fall@1.347ns period=2.695ns})
  Destination:            foo/p2_decim_counter_reg[1]/D
                            (rising edge-triggered cell FDRE clocked by i_clk  {rise@0.000ns fall@1.347ns period=2.695ns})

I think I should probably keep plugging away at it for a bit longer to get an unambiguous pass, but I'd be curious to hear how the experts would handle a situation like this.

Should I be concerned about a 3ps violation if I know that my real clock will be about 20ps slower than this?

Should I be worried that the results vary so widely with small changes in the clock speed? I'm wondering if I should run the synthesis and implementation at a range of slightly different speeds and only call it "done" when it passes consistently.

What's an appropriate amount of margin to apply to clock constraints? Do the tools (in this case Vivado) add any pessimism of their own?

[MarginallyStable]

Be careful with fudging your clock constraints like this to "add margin". A timing closure at a faster clock may not be acceptable at a slower clock due to setup/hold tradeoffs. The way to do it is increase clock uncertainty or, in the case of actually wanting to support multiple clocks, do multi frequency closure.

 

[Someone]

Xilinx?
UG949, Chapter 6: Design Closure
and/or UG906
or the "cheat sheet version" UG1292

[BrianHG]

Just add a replica logic (make sure your compiler is not set to remove duplicate logic) to spread the fanout load from the source logic cell to multiple destinations, or add an additional pipe stage to that destination.

[FenTiger]

A timing closure at a faster clock may not be acceptable at a slower clock due to setup/hold tradeoffs.

Thanks. That's interesting.

Now you mention it, I remember reading about the "clock uncertainty" thing, but I didn't pay it much attention at the time; I'll go back and take another look.

I think you're saying that Vivado analyses the timing at the specified frequency, not up to the specified frequency (as I'd assumed)?

Just add a replica logic ... or add an additional pipe stage

You could at least ask me to post my code before you start suggesting ways to improve it.

Less snarkily - in the simplest pipelines, each "layer" of flops is driven only from the "layer" before it, which makes it really easy to add more intermediate "layers", because they cost you only a clock of latency.

When I said "non-trivial" I meant that this particular pipeline needs to look ahead in order to avoid certain hazards that can occur when things happen in quick succession.

This means that there are connections back from later stages to earlier ones, and adding more stages means adding more "layers" of lookahead, which means a lot more complexity, both in the code and in its validation.

[radar_macgyver]

Rather than making your PERIOD constraint tighter, add a JITTER clause which will simulate the effects of clock jitter causing random clock periods to be shorter than others. I don't recall why, but I was advised by an FAE that this is somehow 'better' than tightening the PERIOD.

[SiliconWizard]

And uh other than that. A violation of 3 ps? Yeah. Yes internal models are based on worst-case, and frankly, yes we all like our designs to pass without any timing violation. But if this is all violation you have here, I wouldn't be too concerned.

[BrianHG]

I dont know about Xilinx, but with Altera, when I have a problem like this, I either change the 'fitter initial placement seed', or, turn up the fitter's 'placement effort', or 'routing effort'.

[FenTiger]

I don't have a "problem". I just have some questions about how people approach the topic of timing closure.

[hamster_nz]

I don't have a "problem". I just have some questions about how people approach the topic of timing closure.

My rule of thumb is work to analyze and remove one level of logic from your failed path will pay off tenfold. After that, look carefully at high fan-out signals in the critical, or add a stage of pipelining.

When you can't manage to squeeze a level of logic out of it or otherwise improve the routability of the design, you are close to the limits of what your device can do at that clock rate for your design's architecture.

Once you start playing with seeds you are relying on luck to achieve timing closure. Your design becomes fragile - the smallest change can cause timing to fail.