UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
392 Views
Registered: ‎12-10-2018

Precise Timing Constraints

Hello everybody!

I want to bring up a general question which I haven't find enough resources for that. Forgive me if this question is an easy one or it has a specific and definite answer in any document. I really do not know the answer and it has become an unsolving problem for me.

I want to know how should we add timing constraints? I mean when we can say a design is constrained enough in timing? I usually add some timing constraints like: clock groups, set max and min delay, set input and output delay, etc. But I really do not know whether my constraints are enough or not. How should we know that our timing constraints are enough and precise?

P.S: A point is that I have had a big design with different clocks and different interfaces which meets my specified timing constraints and after implementation there's no negative setup or hold time. But when I program the FPGA, it does not work and it seems that I have not specified my timing constraints precisely.

Thanks in advance!

0 Kudos
10 Replies
Scholar drjohnsmith
Scholar
381 Views
Registered: ‎07-09-2009

Re: Precise Timing Constraints

why do you say you have not timming constraind correctly ?

have you simulated the RTl code ?

  have you then post synthesis simulated

      have you simulated post P&R

 

If the answer to the first one is no, go back and do that before you even apply timming constraints.

You can not say your desing "works" till you have at least done the first, and inf psoosble timming probelms the last .

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Historian
Historian
368 Views
Registered: ‎01-23-2009

Re: Precise Timing Constraints

(Wow, that's a pretty open question...)

Constraints come from the both the requirements of the system and from any timing "peculiararities" in your system.

The easy ones are the create_clock, set_input_delay and set_output_delay. These come directly from your system

  • The create_clock commands describe the attributes of the clocks applied to the ports of your system (including jitter, duty cycle, etc...)
  • The set_input_delay/set_output_delay describe the timing characteristics/requirements of the stuff outside the FPGA connected to the ports of the FPGA (including any board effects)

Then, internally you have

  • Generated clocks: clocks that are obtained from other clocks
    • The tools take care of clocks that are generated from MMCMs, PLLs, BUFRs, and BUFGCE_DIV cells automatically
    • Other user created clocks (divided clocks created with BUFGCE, BUFHCE, or the fabric - fabric generated clocks are highly discouraged in FPGA) need create_generated_clock commands
  • Multicycle paths: paths that structurally have more than one clock period to complete their static timing paths
  • Other timing exceptions: set_clock_groups, set_false_path, set_max_delay, set_max_delay -datapath_only
    • These are almost always needed due to clock domain crossing (CDC)

If you have multiple clocks in your design, then anywhere there is a path between two different clock domains, you need a clock domain crossing circuit (CDCC). There are many styles of CDCCs - the appropriate one for each CDC is determined by the characteristics of the clocks, and the amount, width and coding of the data being moved across. The design of the CDCC dictactes the correct constraints on the paths.

The design of the CDCCs is probably the most complex aspect of digital design, and the one that most often causes problems - particularly problems that show up only in the FPGA (i.e. not in simulation).

So, you need to look at each CDC path and determine if it has a proper CDCC and if it is constrained properly. The tools report_clock_interaction (or the graphical version of it) and report_cdc can both help you look at these paths, but it is still up to you to deal with each one correctly...

Avrum

366 Views
Registered: ‎07-23-2019

Re: Precise Timing Constraints

 

Time constraints are safety belts, they are not meant to be 'precise' (as I understand them and I understand the term 'precise')

Time constrains are 'enough' to me (and who bears with me) if they produce something that works without (unacceptable) errors.

For the above, I begin with generous constrains that I tighten up us needed or until it becomes un-synthesizable.

That's just an approach, one could also start with tight constrains and loosen them till it works.

 

0 Kudos
359 Views
Registered: ‎07-23-2019

Re: Precise Timing Constraints

 

If you have a design with no timing problems that doesn't work, the problem is probably something else, there are many other reasons for failure.

How to properly and completely time-constraint? That's a bit of an art. With time one develops a sixth-sense. Even though, as the Japanese saying goes "even monkeys fall from trees", so nobody ever becomes a perfect master, we all fall sometimes. I would suggest:

- divide your modules, it's easy to get lost in a beg, complex module

- watch your critical signals (high delay and/ or fast clock)

0 Kudos
Scholar drjohnsmith
Scholar
342 Views
Registered: ‎07-09-2009

Re: Precise Timing Constraints

Unless your trying to see "how fast can it go"

then timing constraints are a KEY part of your design.

You know the clock frequency in to the device,

   you know the set up and hold time of all linputs,

 

If you have mutliple clocks going in to the FPGA, you know which ones have clock crossing, and have designed and you need to constrain accordingly.

 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Historian
Historian
313 Views
Registered: ‎01-23-2009

Re: Precise Timing Constraints

Time constraints are safety belts, they are not meant to be 'precise' (as I understand them and I understand the term 'precise')

Time constrains are 'enough' to me (and who bears with me) if they produce something that works without (unacceptable) errors.

Maybe we are having some misunderstanding as to what the term "precise" means, but I want to be clear as to what my "vision" on constraints are...

Timing constraints can be complex, and there is definitely a concept of "too much" or "too tight" constraints, but I do believe that timing constraints should be "precise" (I prefer the terms "correct and complete").

For a given clock, there is one (and pretty much only one) right set of constraints for the clock - the constraints extracted from the oscillator connected to the FPGA (modified by the board/power supply effects).

For a given interface there is, again, pretty much only one right set of constraints - the constraints extracted from the datasheet for the device connected to the FPGA, taking into account any board effects.

For internal exceptions, there are, again, generally only a small number of "correct" ways of specifying internal constraints, and they need to be dictated by the structure of the design and the type of data being manipulated. While there may be many different formats for specifying these constraints, there is really only one correct "concept" for these constraints.

So constraints should be "precise" - they should be exactly what is required by the system and internal structure of the design.

Failure to get your constraints correct and complete leaves the possibility of latent problems in your design; it may work on some boards, or at some combinations of process, voltage and temperature, but may not be 100% reliable at other combinations. The only way to ensure that your design is robust at all legal combinations of process/voltage/temperature (and hence portable to any legal board with any legal environmental conditions) is to ensure that your constraints are complete and correct (hence "precise") and that the design passes static timing analysis with these constraints.

Avrum

256 Views
Registered: ‎01-22-2015

Re: Precise Timing Constraints

@hermanfisher1994 

-here's my 2-cents worth.

When thinking about timing constraints, it's helpful to remember that HDL (eg. Verilog or VHDL) programmers use a  Register Transfer Level (RTL) style of coding.  That is, our RTL clocked-processes describe FPGA circuits where data is clocked from digital-register to digital-register as shown by the following figure from UG906.
UG906_Fig5p2.jpg

Each register-to-register transfer of data undergoes timing analysis.  To perform this timing analysis, Vivado needs the following information:

  • Electrical specifications (TSU=setup, THD=hold, TCO=clock-to-out) for the source-register, REGA, and for the destination-register, REGB (and how these values vary with Process, Temperature, and Voltage (PVT))
  • a properly defined clock for REGA
  • a properly defined clock for REGB
  • delay of the data-path between the output, Q, of REGA and the input, D, of REGB  (and how this delay varies with Process, Temperature, and Voltage (PVT))
  • delay of the clock-path from the clock source to the clock pin of REGA and REGB (and how this delay varies with Process, Temperature, and Voltage (PVT))

When any of this information is missing, then we must use timing constraints to specify the missing information.  Otherwise, timing analysis for the circuit will be ignored – sometimes without warning!   As you wisely worry, circuits that do not undergo timing analysis can fail when implemented in the FPGA.

Properly Defined Clocks
Normally, we bring a single base-clock into the FPGA via a clock-capable pin and then route it directly to a single MMCM or PLL.  We then use the MMCM/PLL to make other generated clocks.  Normally, the generated clocks are fed through simple clock-buffers (BUFG, BUFR) into the FPGA clock-tree and distributed to the clock-pins of many digital registers.  In this scenario, if you have used the Xilinx Clocking Wizard IP, then the necessary timing constraints (create_clock, set_input_jitter, create_generated_clock) have been automatically written for you – and all the resulting clocks are properly defined.  If you deviate from this scenario (eg. multiple base-clocks, multiple MMCM/PLL, use of clock buffers that further modify the clock (eg. by division, multiplexing, use of clock-enable pin)) then additional timing constraints may be necessary.

Electrical Specifications for Registers:
Vivado timing analysis knows the electrical specifications for all registers found inside the FPGA – and it knows how these specifications vary with PVT.  So, it is not necessary to write timing constraints that describe electrical specifications of in-FPGA registers.  However, when one of the registers lies outside the FPGA then timing constraints are necessary.   For example, with FPGA data input (eg. from an external ADC), the source register lies outside the FPGA and its electrical specifications become part of the needed set_input_delay timing constraints.  Similarly, with FPGA output data (eg. to a external DAC), the destination register lies outside the FPGA and its electrical specifications become part of the needed set_output_delay timing constraints. 

Path Delay:
Vivado timing analysis knows the propagation delay for all the clock paths and data paths found inside the FPGA – and it knows how these delays vary with PVT.  So, it is not necessary to write timing constraints that describe path delay inside the FPGA.  However, for FPGA data input (eg. from an external ADC), some clock/data path delay lies outside the FPGA and their values become part of the needed set_input_delay timing constraints.  Similarly, with FPGA output data (eg. to a external DAC), some clock/data path delay lies outside the FPGA and their values become part of the needed set_output_delay timing constraints.

Of course, there are other clocked components in the FPGA besides digital registers.  However, when it comes to thinking about timing constraints, it helps to think of everything as register-to-register transfer of data.

Finally, as Avrum points out, there are also timing exceptions – which are different from timing constraints.  Timing exceptions are a way of telling timing analysis that, “Hey, I’m smarter than you and I have written my HDL so that the resulting circuit passes timing analysis by design.  So, please ignore or modify timing analysis for this particular circuit”.  

The details of timing exceptions are another story……

Mark

Contributor
Contributor
234 Views
Registered: ‎12-10-2018

Re: Precise Timing Constraints

Thanks everyone for participating in this topic. To be more specific, my design and my related clock domains are attached. I need help on how to add timing constraints and timing exceptions for this project. Any help you can provide would be greatly helpful.

IMG_20190924_104500.jpg
0 Kudos
220 Views
Registered: ‎07-23-2019

Re: Precise Timing Constraints

@avrumw 

agree, I was thinking more of 'precise values'

0 Kudos
Scholar drjohnsmith
Scholar
202 Views
Registered: ‎07-09-2009

Re: Precise Timing Constraints

Apart form the input clock,

looks like all those clocks are generated off one clock source ?

You only need to constrain the source of a clock , the MMCM/ PLL will then properate the corect constraint for derived clocks,

Your input fifo should have the cross clock constraints built into it. if its a Xilinx IP, it will.

If the above is true, then you only extra you have to tell the tools is that the input clock andd the internal clock are not related,

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>