cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
ivan.mironenko
Contributor
Contributor
14,598 Views
Registered: ‎09-10-2008

OFFSET IN DDR timing constraints....again.....

Jump to solution

Hi everybody,

 

I am trying yet again to gain full understanding of how OFFSET IN constraints work.

So, I have read a couple of posts here on the forum, found some answer records, and then read the Timing Constraint Guide thoroughly.

 I still have a lot of questions regarding this guide and what it says.

So, let's start. All examples are from Timing Constraint Guide,:

Page 15  a simple example is given, where the clock period is 5 ns, the clock edge is 90deg shifted relative to data edge:
The constraints look as follows:

NET "SysCLk" TNM_NET = "SysClk";
TIMESPEC "TS_SysClk" = PERIOD "SysClk" 5 ns HIGH 50%;
OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE "SysClk" RISING;
OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE "SysClk" FALLING;

This is also a typical example I found here on forums, and also in the following blog:
http://myfpgablog.blogspot.com/2009/10/offset-in-constraints-for-source.html

Reading further,
Timing constraints User Guide p.52:

The OFFSET constraint automatically accounts for the following clocking path delays
when defined and analyzed with the PERIOD constraint: ..... Includes clock phase introduced by a rising or falling clock edge.

For me, it means that if I have a clock with the period of 5 ns arriving at X ns at the clock input of the DDR IOB,
and then I invert it, then the inverted clock edge will arrive at x + 2.5 ns to the 2nd clock input of the DDR IOB, and the Timing Analyser will take it into account, right?

But then I read further,
Timing constraints User Guide p.52:

The initial clock edge for analysis of OFFSET constraints is defined by the HIGH/LOW
keyword of the PERIOD constraint:
• HIGH keyword => the initial clock edge is rising
• LOW keyword => the initial clock edge is falling

So, if i say TIMESPEC "TS_SysClk" = PERIOD "SysClk" 5 ns HIGH 50%;
then this means that Timing analyzer will assume that the rising edge arrives at time 0 ns at the FPGA clock pad.

 

Timing constraints User Guide p.53:


The initial clock edge for analysis of OFFSET constraints can override the PERIOD
constraints default clock edge with the following keywords of the OFFSET constraints:
• RISING keyword => the initial clock edge is rising
• FALLING keyword => the initial clock edge is falling

 

If I understood it correct,  then this constraint

OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE "SysClk" FALLING;

 
will override the HIGH/LOW parameter of the clock edge, which will lead to the fact, that Timing analyzer will assume, that the falling clock edge arrives at 0 ns to the FPGA clock pin.

 

So, according to the userguide RISING and FALLING keywords do not actually tell timing analyser, that it should analyse data setup/hold relative to rising/falling clock edge, but only override
the initial clock edge(HIGH/LOW).  But in all examples I have seen it has completely different meaning. So, what does RISING/FALLING parameter really do?

 

2) Then comes this, which sounds even more confusing:
Timing constraints User Guide p.53:


The OFFSET constraint is analyzed with respect to only a single clock edge. If the OFFSET
Constraint needs to analyze multiple clock phases or clock edges, as in source synchronous
designs or Dual-Data Rate applications, then the OFFSET constraint must be manually
adjusted by the clock phase.

 

Again, "manually adjusted" does not sound the same as " The OFFSET constraint automatically accounts for ....clock phase introduced by a rising or falling clock edge", which was mentioned before.

So, should I, or should I not manually adjust anything in the OFFSET constraint to make it work?

 

3) Page 121 OFFSET IN BEFORE Constraints

There is another description of what an OFFSET IN constraint is, and then there is this:

 The tools automatically calculate and control internal data and clock delays to meet the flip-flop setup time.

 In my design I have instantiated an IBUFDS followed by IDDR2 for the data, and IBUFGDS for clock,

If I do not specify  IBUF_DELAY_VALUE for the clock buffer and IFD_DELAY_VALUE for the data buffer, then the design never meets timing, and the data and clock delays never change.
If, however, I manually adjust the values, then the design meets timing.

So, does it mean that the tools are broken, or that that the documentation is wrong, or did I not understand something else?

 

4) Then comes an example "Two-Phase Example" (page 123), which is really far from being clear:

For example:
1) Figure 6-13(Timing Diagram with Two-Phase OFFSET IN Constraint) looks quite similar to Figure 6-12(Timing Diagram of Simple OFFSET IN Constraint).

There is no DDR data in the diagram, nothing. Why is this figure even there? What does it describe?

 

2)  There is a sentence:

 

The timing report displays the Clock Arrival time for each edge of the clock. ...

The resulting timing report displays the: [cut] Clock Arrival time (shown in bold in the example report below)

In the presented timing report there is no such thing as "Clock Arrival". There is "Destination Clock: clock0_ddr_bufg falling at 0.000ns" though, but the second phase(rising) is missing.


3) There is a sentence:

 

 In this example, the PERIOD constraint has the clock arrival on the falling edge, based upon the FALLING keyword.

The PERIOD constraint does not have parameter FALLING. Does it mean that it's a typo, and the author meant "HIGH" instead of FALLING, or does it refer to the OFFSET constraint ?

4) Then there is a sentsence:

   

The rising edge synchronous elements is onw-half the PERIOD constraint".

 

 Well, first there is a typo, and then, does this sentence mean anything? Or is it actually a sentence? :)

 

 

So, after reading this user guide it is still not clear to me what RISING/FALLING parameters really do, or whether the delays in the input buffers are actually adjusted, and why both rising and falling edges in the Timing analyser are arriving at time 0.

 

Can anybody clarify all these questions? Can somebody from Xilinx correct the documentation?

 

Best regards,

Ivan

0 Kudos
1 Solution

Accepted Solutions
hobson
Xilinx Employee
Xilinx Employee
16,501 Views
Registered: ‎04-15-2008

Ivan,

 

As John said, timing constraints, especially OFFSET constraints, have changed over time and there's probably a lot of docs out there that haven't been updated.  Also, OFFSET constraints are not just for source synchronous DDR interfaces.  They must handle system synchronous situations as well, so some info may have applied in those situations and then never got updated when system synchronous interfaces became more prevalent.  Finally, some of the info remains out there because older versions of software are still in use.

 

I'm not going to go into all the history about the old ways of doing things and what changed and why.  I'll just assume you're using ISE 11.3 and try to answer the questions at the bottom of your post.

 

1) The RISING & FALLING keyword parameters specify to the OFFSET constraint which set of flip-flops you want to constrain.  Here is the constraint example you gave:

 

NET "SysCLk" TNM_NET = "SysClk";
TIMESPEC "TS_SysClk" = PERIOD "SysClk" 5 ns HIGH 50%;
OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE "SysClk" RISING;
OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE "SysClk" FALLING;

 

Here, the first OFFSET constraint defines the data valid window for any input flops clocked with a rising edge.  The specified delays are in reference to the edge (rising) that clocks the flops.  The second OFFSET constraint does the same thing, but for the set of falling edge flip-flops.  The specified delays are again in reference to the edge (falling) that clocks the flops.  That is why you will likely see in the timing report, "clock rising at 0ns" for the first constraint and "clock falling at 0ns" for the second constraint.

 

Now one brief historical note.  This is not the way the delays worked in past versions of software.  It used to be that you would use the RISING & FALLING keywords to specify the set of flops to be constrained, but the delays you specified would all have to be in reference to the rising edge, which is quite confusing.  In those timing reports, you may have seen "clock rising at 0ns" and "clock falling at 2.5ns," but I can't remember for sure.

 

If you were doing a source synchronous DDR interface, but did *not* specify the RISING & FALLING keywords, I'm honestly not sure what would happen.  My guess is that the constraint would be correct for rising edge flops, but that for falling edge flops, the delays specified would be referenced to the rising edge (and therefore wrong).  That's just a guess, though.  Also, I'm not sure how the HIGH/LOW keyword would have an effect, but if you specified LOW 50% in this situation, I'm guessing the falling edge delays would now be correct and the rising edge delays would be wrong.  Again, just a guess.  My point is - don't do this.  When doing source synchronous DDR interfaces, always use the RISING & FALLING keywords as well as the VALID keyword.

 

2) The IDELAY delays are not (and should not be) adjusted by the software.  The note about controlling internal data delays to meet setup and hold times only applies if the software is free to place the input flip-flops where it wants to.  In the past, and especially with system synchronous designs, those flops would be placed in the fabric of the FPGA (vs. in the ILOGIC components), and then the software could control the placement of the flops and the routing to the flops to meet setup/hold times.  It has become common in source sync designs to place the flops inside the ILOGIC blocks.  Since there are hard routes from the pins to the ILOGIC flip-flops, the software no longer has the freedom to use the placer & router to help with setup/hold times.  Manipulation of the IDELAY tap values or use of different clock phases is up to the user.  When this technique is used, OFFSETs are not really "constraints" any more in the classical sense since they are not influencing how the place & route software treats these paths.  Instead, they are there mainly to allow the timing analysis algorithms to report on these paths.  The user can then make adjustment to IDELAY tap values or clock phases accordingly.

 

I hope this clears up at least some of the confusion.

 

Best Regards,

-Hobson

 

View solution in original post

4 Replies
drjohnsmith
Teacher
Teacher
14,591 Views
Registered: ‎07-09-2009

Hi

 

a long list you have there !

 

Yes in my opinion timing is

 

a) chaotic

b) how to do it keeps changing

c) old documentation and docs with errors don't get corrected or deleted

d) there is more than one way of doing anything which leads to interesting problems.

 

One thing I only recently found out was that there is a hierarchy of priorities, which attributes over ride what.

 

I'm trying to put together a 101 guide to timing, for my own use, might share it on the site.

  Aim is to put together a set of rules, 

 

 

Suggestion is have chat with you FAE. they know all and have access to even more expert help.

 

You never know, we might get a expert like Ken Chapman to do timing guide for us.

  we can but hope.

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
hobson
Xilinx Employee
Xilinx Employee
16,502 Views
Registered: ‎04-15-2008

Ivan,

 

As John said, timing constraints, especially OFFSET constraints, have changed over time and there's probably a lot of docs out there that haven't been updated.  Also, OFFSET constraints are not just for source synchronous DDR interfaces.  They must handle system synchronous situations as well, so some info may have applied in those situations and then never got updated when system synchronous interfaces became more prevalent.  Finally, some of the info remains out there because older versions of software are still in use.

 

I'm not going to go into all the history about the old ways of doing things and what changed and why.  I'll just assume you're using ISE 11.3 and try to answer the questions at the bottom of your post.

 

1) The RISING & FALLING keyword parameters specify to the OFFSET constraint which set of flip-flops you want to constrain.  Here is the constraint example you gave:

 

NET "SysCLk" TNM_NET = "SysClk";
TIMESPEC "TS_SysClk" = PERIOD "SysClk" 5 ns HIGH 50%;
OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE "SysClk" RISING;
OFFSET = IN 1.25 ns VALID 2.5 ns BEFORE "SysClk" FALLING;

 

Here, the first OFFSET constraint defines the data valid window for any input flops clocked with a rising edge.  The specified delays are in reference to the edge (rising) that clocks the flops.  The second OFFSET constraint does the same thing, but for the set of falling edge flip-flops.  The specified delays are again in reference to the edge (falling) that clocks the flops.  That is why you will likely see in the timing report, "clock rising at 0ns" for the first constraint and "clock falling at 0ns" for the second constraint.

 

Now one brief historical note.  This is not the way the delays worked in past versions of software.  It used to be that you would use the RISING & FALLING keywords to specify the set of flops to be constrained, but the delays you specified would all have to be in reference to the rising edge, which is quite confusing.  In those timing reports, you may have seen "clock rising at 0ns" and "clock falling at 2.5ns," but I can't remember for sure.

 

If you were doing a source synchronous DDR interface, but did *not* specify the RISING & FALLING keywords, I'm honestly not sure what would happen.  My guess is that the constraint would be correct for rising edge flops, but that for falling edge flops, the delays specified would be referenced to the rising edge (and therefore wrong).  That's just a guess, though.  Also, I'm not sure how the HIGH/LOW keyword would have an effect, but if you specified LOW 50% in this situation, I'm guessing the falling edge delays would now be correct and the rising edge delays would be wrong.  Again, just a guess.  My point is - don't do this.  When doing source synchronous DDR interfaces, always use the RISING & FALLING keywords as well as the VALID keyword.

 

2) The IDELAY delays are not (and should not be) adjusted by the software.  The note about controlling internal data delays to meet setup and hold times only applies if the software is free to place the input flip-flops where it wants to.  In the past, and especially with system synchronous designs, those flops would be placed in the fabric of the FPGA (vs. in the ILOGIC components), and then the software could control the placement of the flops and the routing to the flops to meet setup/hold times.  It has become common in source sync designs to place the flops inside the ILOGIC blocks.  Since there are hard routes from the pins to the ILOGIC flip-flops, the software no longer has the freedom to use the placer & router to help with setup/hold times.  Manipulation of the IDELAY tap values or use of different clock phases is up to the user.  When this technique is used, OFFSETs are not really "constraints" any more in the classical sense since they are not influencing how the place & route software treats these paths.  Instead, they are there mainly to allow the timing analysis algorithms to report on these paths.  The user can then make adjustment to IDELAY tap values or clock phases accordingly.

 

I hope this clears up at least some of the confusion.

 

Best Regards,

-Hobson

 

View solution in original post

ivan.mironenko
Contributor
Contributor
14,521 Views
Registered: ‎09-10-2008

Hi Hobson,

 

your answer was really helpful. Especially this part,

 

 In the past, and especially with system synchronous designs, those flops would be placed in the fabric of the FPGA (vs. in the ILOGIC components), and then the software could control the placement of the flops and the routing to the flops to meet setup/hold times.  It has become common in source sync designs to place the flops inside the ILOGIC blocks.  Since there are hard routes from the pins to the ILOGIC flip-flops, the software no longer has the freedom to use the placer & router to help with setup/hold times.  Manipulation of the IDELAY tap values or use of different clock phases is up to the user.  When this technique is used, OFFSETs are not really "constraints" any more in the classical sense since they are not influencing how the place & route software treats these paths.  Instead, they are there mainly to allow the timing analysis algorithms to report on these paths.  The user can then make adjustment to IDELAY tap values or clock phases accordingly.

The part in bold is what made me so frustrated. I somehow assumed that the OFFSET constraints will actually influence the delays and everything will happen automatically. And then, when it didn't work the easy way, I had dig into the Constraints Guide, but found nothing relevant.

 

Ok, now my design passes timing analysis with setup slack of 0.029 ns and hold slack of 0.007 ns, the clock rate is 280MHz(in Spartan 3A-DSP) And I have not specified a clock jitter yet. What do you think, is it normal ? :)

I was thinking about pushing this design to  315 MHz, but looking at the slack at 280MHz , I think it is just not possible.

 

 

 

John,

I think right the next day after you finish your timing 101 guide, a new version of ISE will come out , and the constraint format will change, or something like this :)

 

 

Thank you for the answers.

Best regards,

Ivan

0 Kudos
ezequielsasky
Explorer
Explorer
12,910 Views
Registered: ‎02-22-2010

Hi Hobson,

 

My question is not directly related to the OFFSET IN constraint but would appreciate to use your knowledge on some issue I'm having:

 

A clock and a data bus (presumably aligned) are input to my Virtex-5. I use an IODELAY to delay the clock. This delayed clock and the data bus are input to an IDDR. The idea is to sample the data at the center of the eye.

The issue is that the tools for some reason routes the data lines through IODELAYS and the routing delay for all the data lines is a fixed value (greater than my IODELAY for the clock).

Note 1: there's no OFFSET IN constraint

Note 2: IOBpacking is ON

 

My workaround is to instantiate an IODELAY (delay_value=0) for each data line

 

However, do you have an explanation for the above behavior?

 

THANKS IN ADVANCE

Eze

0 Kudos