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: 
5,167 Views
Registered: ‎01-22-2015

FPGA I/O analysis - keeping it simple?

Jump to solution

I have just read <this post> which describes a source-synchronous DDR-LVDS output interface from the FPGA.  A lot of thought and at least 18 constraint-file entries are needed to run full-up timing analysis on this interface.  I know this is the standard way to ensure that the interface will work properly – but there must be an easier way!

 

I have a suggestion….

 

FPGA interface design roughly reduces to ensuring that the forwarded clock, fclk, is delayed enough to place it in the “eye” of the data window.  For DDR interfaces this means delaying fclk by ~90degs, whereas for SDR interfaces fclk is delay by ~180degs.  So, interface design is concerned with delay.

 

When we describe the portion of the interface that is external to the FPGA, we are again concerned only with delay.  That is, we use the set_output_delay constraint which basically needs one number – the delay-difference between the external paths for the data and fclk.

 

So, why don’t we have/use an analysis tool for FPGA interfaces that focuses on delay (instead of using full-up timing analysis)? 

 

This proposed delay-analysis-tool only needs to add the internal-delay-differences and external-delay-differences for the data and fclk paths.  If this sum gives the delay needed to place fclk in the data eye, then the interface will work.  Right?  Further, when preparing to use this proposed tool, we need to write only a single set_output_delay constraint.  The rest of the 18 constraint-file entries mentioned above were only needed to guide the full-up timing analysis for the interface, which I am arguing is unnecessarily complicated.

 

Nonsense, novel or neither?

0 Kudos
1 Solution

Accepted Solutions
Teacher muzaffer
Teacher
8,578 Views
Registered: ‎03-31-2012

Re: FPGA I/O analysis - keeping it simple?

Jump to solution

markg@prosensing.com as far as I can tell, the constraints given in the other post (other than the false paths) are the minimum sufficient and necessary constraints to time the delay of the issue at hand. Clock delay is not the only parameter which needs to be considered. Basically you have 5 delay parameters you need to verify in any timing: source clock, target clock, source clock to output, combinational delay of signal, setup & hold parameters of the target all of which have to be considered for successfully constraining a path. I don't think it's advisable to skimp on any of these constraints.

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

View solution in original post

10 Replies
Teacher muzaffer
Teacher
8,579 Views
Registered: ‎03-31-2012

Re: FPGA I/O analysis - keeping it simple?

Jump to solution

markg@prosensing.com as far as I can tell, the constraints given in the other post (other than the false paths) are the minimum sufficient and necessary constraints to time the delay of the issue at hand. Clock delay is not the only parameter which needs to be considered. Basically you have 5 delay parameters you need to verify in any timing: source clock, target clock, source clock to output, combinational delay of signal, setup & hold parameters of the target all of which have to be considered for successfully constraining a path. I don't think it's advisable to skimp on any of these constraints.

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

View solution in original post

Moderator
Moderator
5,120 Views
Registered: ‎01-16-2013

Re: FPGA I/O analysis - keeping it simple?

Jump to solution
Hi,

I second muzzerefs information.
Constraints are required to validate the interface and must.
Note: One can just ignore the constraints but Xilinx can not give assurance whether it will work or not on hardware.

Thanks,
Yash
0 Kudos
5,100 Views
Registered: ‎01-22-2015

Re: FPGA I/O analysis - keeping it simple?

Jump to solution

Muzaffer and Yashp – thanks for considering my crazy ideas.

 

Please bear with me a little longer..

 

Suppose that static timing analysis (STA) for the interface tells us that the interface will not work. Then, either:

  1. STA was setup/done incorrectly (happens often with me),
  2. the interface will never work (ie. not enough margin), or
  3. we need to adjust the fclk-to-data delay – either by delaying (or phase shifting) fclk or delaying the data (eg. use ODELAY).

The thing is, many of us struggle with the complexity of setup (ie. writing the proper constraints) for STA of the interface. -all to obtain guidance for adjusting one simple parameter called fclk-to-data delay.  There must be an easier way!

0 Kudos
Guide avrumw
Guide
5,084 Views
Registered: ‎01-23-2009

Re: FPGA I/O analysis - keeping it simple?

Jump to solution

Mark,

 

You have to realize that there are TONS of different types of interfaces. You can have pretty much any combination of:

  - input and output interfaces

  - single data rate and double data rate

  - clock forwarded (source synchronous) or system synchronous

  - edge aligned or center alinged

  - captured using direct clocking or MMCM/PLL clocking

  - capturing with the same edge (pushing the clock forward) or capturing with the next edge (pushing the data forward)

     - or even more exotic combinations - like capturing with the edge after the next edge

 

For some combinations of these you do end up with "simple" constraints - a clock definition and a min and max set_input_delay or set_output_delay.

 

For others you need more complex constraints - two sets of delays for DDR.

 

For yet others you need even more - to modify the launch/capture clock relationship.

 

For each of the interfaces that are not currently described by "simple" constraints, you could, of course, come up with some new constraint mechanism that constrains this interface "more simply". But, pretty much by definition, this mechanism would be more difficult for other interfaces (some of which are currently constrained by simpler constraints).

 

The way SDC/XDC is designed is around some very basic concepts that hold true for all timing paths - internal and external. While it may not seem so, SDC/XDC is actually pretty simple - there really are only around 9 primary constraint commands

   - create_clock

   - create_generated_clock

   - set_clock_latency

   - set_input_jitter

   - set_input_delay

   - set_output_delay

   - set_multicycle_path

   - set_max_delay

   - set_false_path

 

(there are others, but I would say these are the "primary" ones)

 

Almost all paths are completely described using these commands, based on the same consistent set of rules. Once you learn those rules, you can construct constraints for all cases - including the 64+ combinations of interfaces I described above. Yes, some of these require more commands to constrain... But the whole point is that all these interfaces are able to be described by a single consistent constraint system...

 

Avrum

5,032 Views
Registered: ‎01-22-2015

Re: FPGA I/O analysis - keeping it simple?

Jump to solution

Avrum – thanks!

 

Again, I am guilty of generalizing based on my experience with one (rather simple) type of interface (source-synchronous output). Sorry!  However, I find that source-synchronous interfaces are very popular, so understanding them from different viewpoints is maybe worthwhile.

 

The thing is, some of us grab an XDC-template of constraints for our interface, fill it in, and then write a post to the Xilinx forum saying, “Avrum, can you check my constraints?”. We won’t always have the luxury of “ask Avrum”.  Unless we write constraints for these interfaces every day, knowing absolutely that we are writing the correct constraints is a level of understanding that some of us cannot maintain.  We need a back-of-the-envelope calculation that we can carry around with us.  -something we can use to verify that results of STA for our interface make sense.

 

Am I wrong to say that for most (all?) source-synchronous interfaces, the problem of "making the interface work" reduces to correctly setting delay between the data and the forwarded clock?

0 Kudos
5,018 Views
Registered: ‎01-22-2015

Re: FPGA I/O analysis - keeping it simple?

Jump to solution

Avrum,

Here’s an example (125MHz DDR source synchronous output) of looking at things from the delay viewpoint. I started by placing meaningless set_output_delay constraints on the FPGA ports for the interface, which allow STA to run.  In this design, data is fed to the IOB register identified as bDAC_DAT_reg[0] in the image below.  The forwarded clock is generated using the common method of “toggling a data bit”, with toggles occurring 2ns (90deg) after changes in bDAC_DAT_reg[0].  This toggle is fed to the IOB register identified as TOG180_reg in the image below.

 

After running implementation, I can open the implemented design and study the clock-output and data-output paths. Tcl commands like “report_timing -from ddr1/TOG180_reg….”, can be used to get the Path Properties listings shown below.

 

From Path Properties for the data path, I find that delay associated with the register(FDRE) and the buffer(OBUFDS) totals (0.221+0.712)=0.933. So, the FPGA “gets the data out” with a delay 0.933ns.

 

From Path Properties for the clock path, I find that delay associated with the register(FDRE) and the buffer(OBUFDS) totals (0.221+0.753)=0.974. So, the FPGA “gets the clock out” with a delay 0.974ns.

 

So, the delay-difference between “getting out” the data and clock is only 0.041ns (=0.974-0.933).

 

Next, I drew a little timing diagram (see last image below) with setup time, tsu, and hold time, thd, clearly marked. I find that the delay-difference of 0.041ns calculated above has very little effect on my generated delay-difference of 2ns (ie. 90deg) for this DDR interface. -and edges of the forwarded clock, TOG180_reg, fall into the “margin” window.  So, I conclude that the interface should operate properly.

 

Is this type of simple analysis for the interface correct?

DDR1.jpg

DDR2.jpg

0 Kudos
Guide avrumw
Guide
5,011 Views
Registered: ‎01-23-2009

Re: FPGA I/O analysis - keeping it simple?

Jump to solution

Unfortunately, this analysis is just too simple...

 

The analysis you did is only at one process corner (whichever has the largest magnitude delay, which may not be the one with the most skew), does not take into account any on-chip variation, and does not account for the internal clock skew nor the phase error of the two MMCM outputs. All of these have an impact on the margin of this interface...

 

So the analysis you did is a reasonable starting point, but cannot be considered a "complete" verification that the interface works. In order to really verify it, you will need to write proper constraints and run full static timing analysis on it.

 

Avrum

 

 

4,970 Views
Registered: ‎01-22-2015

Re: FPGA I/O analysis - keeping it simple?

Jump to solution

      ...a reasonable starting point

 

Avrum - thanks for confirming that I am not completely off-track.  

 

-and thanks to all for courteous responses to my peculiar posts.

0 Kudos
4,965 Views
Registered: ‎01-22-2015

Re: FPGA I/O analysis - keeping it simple?

Jump to solution

Avrum,

 

Would you please answer the question in my 2nd post (repeated below).  Please note that this question is not about whether or not we should do STA.  Rather, I am questioning what to do with the results of STA.

 

Am I wrong to say that for most (all?) source-synchronous interfaces, the problem of "making the interface work" reduces to correctly setting delay between the data and the forwarded clock?

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

Re: FPGA I/O analysis - keeping it simple?

Jump to solution

Am I wrong to say that for most (all?) source-synchronous interfaces, the problem of "making the interface work" reduces to correctly setting delay between the data and the forwarded clock?

 

On one level, "getting the delays right" is what all static timing analysis is about. But, again, I find this too simple.

 

Ultimately, the goal of static timing analysis (STA) is to determine if an system will work as designed. For this interface, the design consists of a number of things - yes, the programmable delay on certain elements is one of them, but there are others. For examples, there are multiple clocking schemes that can be used inside an FPGA that all have different timing characteristics in terms of skew, jitter and phase error. Similarly different clocking mechanisms as well as different delay generation mechanisms will have different characteristics in terms of process/voltage/temperature variability. You need to look at the whole thing to determine if the interface will work.

 

And that is the crux of the matter. Your statement assumes that the interface is viable - that a set of delays exists that will make the interface work; this is not an assumption, but something that needs to be validated through STA.

 

Avrum

Tags (1)