cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Observer
Observer
205 Views
Registered: ‎11-24-2020

Baselining

Hi,

Can baselining be stopped at stage 1, if timing is met (without specifying IO constraints)? I remember seeing yes and no both in 2 places in Xilinx docs

 

Thanks in advance

0 Kudos
Reply
5 Replies
Xilinx Employee
Xilinx Employee
179 Views
Registered: ‎11-30-2007

@dharpeer 

Can you define the document you are referring to that defines "stage 1"?

Here are the Timing Baselining documents I reference:

  • UltraFast Design Methodology Guide for the Vivado Design Suite (UG949; v2020.1)
    • Chapter 6: Design Closure > Timing Closure > Baselining the Design
  • UltraFast Design Methodology Timing Closure Quick Reference Guide (UG1292; v2020.1; p 2)

forums_ug1292_p2.png

Please Reply, Kudos, and Accept as Solution.
0 Kudos
Reply
Observer
Observer
127 Views
Registered: ‎11-24-2020

Hi,

I am referring to what's in the attached image

 

 

baselining.png
0 Kudos
Reply
Guide
Guide
118 Views
Registered: ‎01-23-2009

Can baselining be stopped at stage 1, if timing is met (without specifying IO constraints)? I remember seeing yes and no both in 2 places in Xilinx docs

ABSOLUTELY NOT! (Trying to be clear here).

A design is only "timing closed" when all constraints have been accurately written; clocks, I/O,  exceptions, jitter, etc

The only point of baselining is that if you try and debug all aspects of timing in one run, you can spend a long time having the tool optimize incorrect constraints, and it can be hard to figure out what to fix when you get failing paths. The baselining process starts with the most basic constraints, which you then debug, then add the next set, which you debug, and then ultimately complete all the constraints, which you then debug. 

In fact it is expected that you get no failing paths after each step - that is the trigger to move on to the next step. But you must continue until you have a complete and accurate set of constraints before your design can be considered to meet timing.

Avrum

Observer
Observer
97 Views
Registered: ‎11-24-2020

Hi @avrumw ,

Thanks for the clarification.
I have a concern with respect to IO delay constraints though. 
Basically in specifying IO constraints in Vivado we need to know the delays of external devices right? I am not quite clear as to how this can be done.
While there are plenty of examples/videos on assigning the values (which is quite straight forward), non of them clearly mention as to where the delays can be obtained for different interfaces. And for the more complicated interfaces, where core generator does the IP generation (or external IPs are used), the constraint files are provided. But if the designer were to find the IO delays them selves, where can they be obtained?
Trace delays we can obtain from the FPGA board user manual I am guessing? But where to get the values for the IO delays for different interfaces, say GT, or DDR or PCIE even something simpler.

Thanks!

0 Kudos
Reply
Guide
Guide
75 Views
Registered: ‎01-23-2009

But if the designer were to find the IO delays them selves, where can they be obtained?

I/O delays must be extracted from the datasheet of the devices driving or being driven by the FPGA. Each device that uses synchronous interfaces must have a datasheet that specifies the relationship between the shared clock (between the FPGA and the external device) and the data. The timing from these datasheets needs to be modified by the timing of the board, and then must be turned into the appropriate set_input_delay and set_output_delay commands.

But where to get the values for the IO delays for different interfaces, say GT, or DDR or PCIE even something simpler.

All of these are bad examples.

Any interface that comes through the Gigabit Transceivers (GT and PCIe) have no timing constraints. These are not synchronous interfaces; they are self-timed (using clock/data recovery).

A DDRx_SDRAM is also not a good example; the I/O of these interfaces are not conventional; they use dynamic calibration, on-die calibrated termination, and odd timing (bidirectional DQS strobes). The DDRx_SDRAM interfaces pretty much must be generated by the Memory Interface Generator (MIG) and will be properly constrained by the MIG.

Constraints are needed for (pretty much) all other interfaces that use conventional I/O (i.e. not through the GT); interfaces between pairs of FPGAs, interfaces between FPGAs and DAC/ADC components, interfaces to/from physical layer chips (USB, Ethernet, ...) and interfaces between the FPGA and any other on-board device that uses conventional interfaces and synchronous clocking. For all these, the external device must have a datasheet that documents the timing.

Avrum

0 Kudos
Reply