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!

Reply

Timing Analysis: thru-the-years

Accepted Solution Solved
Explorer
Posts: 185
Registered: ‎01-22-2015
Accepted Solution

Timing Analysis: thru-the-years

[ Edited ]

Because of my late start with FPGAs, I have been fortunate to always have (and use) Vivado. However, I often read in posts on this forum that ISE was (is?) not powerful enough to handle certain issues of timing analysis.  Further, as I look through ISE projects left by my predecessor, I see that little thought was given to timing analysis (ie. the constraints file contains very few timing constraints and timing exceptions). 

 

Can someone comment on how the ability to control/constrain timing analysis has evolved at Xilinx over the years?


Accepted Solutions
Highlighted
Instructor
Posts: 3,832
Registered: ‎01-23-2009

Re: Timing Analysis: thru-the-years

I'm not sure what you are looking for in terms of a comment - Vivado is better than ISE!

 

(Note: I don't go "all the way back" so some of the stuff from the beginning is a bit of guess work/hearsay ...)

 

ISE evolved many years ago. It got its start in CPLDs and smaller FPGAs. These designs tended to be quite simple, often using only one clock. With only a single clock and with good control over clock skew (using the dedicated clock networks), it was architecturally impossible to have hold time issues.

 

Furthermore, board I/O tended to be pretty slow - simple system synchronous interfaces were the "norm" back then.

 

The UCF constraint format originated with these fairly modest requirements. As a result, the original timing engine and UCF format had no mechanisms for

  - specifying I/O constraints with respect to different clocks

  - dealing with "generated" clocks (i.e. from a DCM/PLL/MMCM)

  - doing hold time checking of any kind, including

    - internal hold checks, which were unnecessary

    - I/O hold checks

 

Over the years, as the devices got more complex, UCF and the timing engine evolved.

 

When devices included multiple clock trees, they added mechanisms of constraining I/O to different clocks.

 

When devices started including clock modifying blocks, they added the ability to deal with "derived" timespecs.

 

When people started doing synchronous clock domain crossing between related clocks, they added cross domain setup checking.

 

When multiple clocks with different insertion delays were supported, limited internal hold time checking was added.

 

When devices started using DDR I/O they added new formats for OFFSET IN/OUT that could specify delays to/from rising/falling edges.

 

When people started using high speed input interfaces with narrow windows, they added support for hold time checking on inputs.

 

But all of these were "patches" to the underlying timing engine and constraint format. This led to the "final" UCF having a really inconsistent format, multiple different formats for accomplishing things (some of which were better supported then others), as well as significant deficiencies. The most notable deficiency is that it is still impossible in ISE to do hold time analysis of output interfaces...

 

Conversely, XDC is derived from SDC, which has been the premiere constraint format for specifying timing in ASICs for more than 20 years. The SDC format was designed with most (maybe even all) of these concepts "from the start" - it started with a much more consistent view of timing analysis and (most notably) with the idea that designs with complex clocking schemes (multiple synchronous and asynchronous clocks in the same design) were the norm. As a result, SDC/XDC is built for the types of timing analysis that we need to do today.

 

So, does that mean that it was impossible to design complex designs and interfaces with ISE? No - it was just more difficult. For complex interfaces, the final analysis became the responsibility of the designer, not the tool (well, even now the responsibility is still with the designer, but the tool helps a lot more). Designers had to rely on characteristics of the hardware (balanced clock skew, fast I/O clock networks, IOB flip-flops, ISERDES/OSERDES and IDELAY/ODELAY when they were added) and construct logical analyses of these interfaces to prove that they would work. The timing numbers used in the analyses of these interfaces would be derived partially from the data sheets, partially from (partial) timing results from the tool, partly by a little guess work and "reasonable" assumptions and even (although, in my opinion as rarely as possible) from tests done in the lab.

 

I definitely prefer the Vivado way!

 

Avrum

View solution in original post


All Replies
Highlighted
Instructor
Posts: 3,832
Registered: ‎01-23-2009

Re: Timing Analysis: thru-the-years

I'm not sure what you are looking for in terms of a comment - Vivado is better than ISE!

 

(Note: I don't go "all the way back" so some of the stuff from the beginning is a bit of guess work/hearsay ...)

 

ISE evolved many years ago. It got its start in CPLDs and smaller FPGAs. These designs tended to be quite simple, often using only one clock. With only a single clock and with good control over clock skew (using the dedicated clock networks), it was architecturally impossible to have hold time issues.

 

Furthermore, board I/O tended to be pretty slow - simple system synchronous interfaces were the "norm" back then.

 

The UCF constraint format originated with these fairly modest requirements. As a result, the original timing engine and UCF format had no mechanisms for

  - specifying I/O constraints with respect to different clocks

  - dealing with "generated" clocks (i.e. from a DCM/PLL/MMCM)

  - doing hold time checking of any kind, including

    - internal hold checks, which were unnecessary

    - I/O hold checks

 

Over the years, as the devices got more complex, UCF and the timing engine evolved.

 

When devices included multiple clock trees, they added mechanisms of constraining I/O to different clocks.

 

When devices started including clock modifying blocks, they added the ability to deal with "derived" timespecs.

 

When people started doing synchronous clock domain crossing between related clocks, they added cross domain setup checking.

 

When multiple clocks with different insertion delays were supported, limited internal hold time checking was added.

 

When devices started using DDR I/O they added new formats for OFFSET IN/OUT that could specify delays to/from rising/falling edges.

 

When people started using high speed input interfaces with narrow windows, they added support for hold time checking on inputs.

 

But all of these were "patches" to the underlying timing engine and constraint format. This led to the "final" UCF having a really inconsistent format, multiple different formats for accomplishing things (some of which were better supported then others), as well as significant deficiencies. The most notable deficiency is that it is still impossible in ISE to do hold time analysis of output interfaces...

 

Conversely, XDC is derived from SDC, which has been the premiere constraint format for specifying timing in ASICs for more than 20 years. The SDC format was designed with most (maybe even all) of these concepts "from the start" - it started with a much more consistent view of timing analysis and (most notably) with the idea that designs with complex clocking schemes (multiple synchronous and asynchronous clocks in the same design) were the norm. As a result, SDC/XDC is built for the types of timing analysis that we need to do today.

 

So, does that mean that it was impossible to design complex designs and interfaces with ISE? No - it was just more difficult. For complex interfaces, the final analysis became the responsibility of the designer, not the tool (well, even now the responsibility is still with the designer, but the tool helps a lot more). Designers had to rely on characteristics of the hardware (balanced clock skew, fast I/O clock networks, IOB flip-flops, ISERDES/OSERDES and IDELAY/ODELAY when they were added) and construct logical analyses of these interfaces to prove that they would work. The timing numbers used in the analyses of these interfaces would be derived partially from the data sheets, partially from (partial) timing results from the tool, partly by a little guess work and "reasonable" assumptions and even (although, in my opinion as rarely as possible) from tests done in the lab.

 

I definitely prefer the Vivado way!

 

Avrum

Explorer
Posts: 185
Registered: ‎01-22-2015

Re: Timing Analysis: thru-the-years

Avrum – many thanks for the historical perspective!  The many parts of timing analysis are finally starting to come together for me.

 

When devices included multiple clock trees…

 

Some years ago, I joined the Xilinx forum specifically to talk about timing analysis issues resulting from the use of multiple clocks. You and others kindly explained that specifying all clock domains to be asynchronous (the ISE default) often just covers up a problem that should be solved using a clock-crosser circuit and appropriate timing exceptions.  Then, all by myself, I learned ways to break the clock-crossers.  Again, you and the forum came to the rescue by explaining my breaks.  Vivado and I still spend a lot of time dealing with multiple clocks and the crossing of signals between clock domains.

 

 

…construct logical analyses of these interfaces to prove that they would work.

 

Can you speak a little more on this topic? Where should I go to start very basic learning of this topic?

 

Mark

Instructor
Posts: 3,832
Registered: ‎01-23-2009

Re: Timing Analysis: thru-the-years

…construct logical analyses of these interfaces to prove that they would work.

 

Can you speak a little more on this topic? Where should I go to start very basic learning of this topic?

 

You can take a look at this post on RMII timing as an example of the thought process...

 

Avrum

Explorer
Posts: 185
Registered: ‎01-22-2015

Re: Timing Analysis: thru-the-years

Avrum,

 

Thanks for reference to the RMII post about I/O constraints – but arghhh!  That’s where @yashp sent me from another of my posts.  I’m not yet smart enough to understand the RMII post.

 

I see from other posts in this forum that small companies are formed to help dummies (like me) prove/write/correct I/O constraints for their FPGA projects. It seems that a lot of people don’t understand these constraints.

 

I also see that Vivado has “XDC constraints templates” and the “Timing Constraints Wizard” to help us with the syntax of writing I/O constraints. However, neither these tools nor Xilinx documentation for these tools helps much towards understanding I/O constraints.

 

I know that taking classes would be the best solution for my ignorance. However, can’t you point me towards an “I/O constraints for dummies” document?

 

mark

Instructor
Posts: 3,832
Registered: ‎01-23-2009

Re: Timing Analysis: thru-the-years

Mark,

 

The only document I can point you to is UG903, "Using Constraints", but it is pretty high level.

 

The thing about XDC is that it is all built around a number of basic concepts - when used properly, the I/O aren't actually "special" - they use the same rules as all other paths. Of course, the number of ways that I/O interfaces can be created and timed means that there can be significantly more complexity in applying these rules. So, before you can understand constraints for complex I/O structures, you must first understand (and understand well) the rest of XDC. So there isn't really such a thing as "I/O Constraints for Dummies"...

 

The class Vivado Design Suite Advanced XDC and Static Timing Analysis for ISE Design Suite Users is really the most comprehensive class on timing constraints...

 

Avrum

Explorer
Posts: 185
Registered: ‎01-22-2015

Re: Timing Analysis: thru-the-years

   ...I/O aren't actually "special" - they use the same rules as all other paths.

 

Avrum - Thanks for that important reminder and for the class reference.