cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
kyle.drerup
Visitor
Visitor
799 Views
Registered: ‎06-17-2019

set_input_delay ddr constraints confusion (clear definition of xdc syntax?)

Jump to solution

Hello All,

  I've read the constraints user guide, and I'm still not clear on this..  The syntax doesn't make any sense to me at all.

What is the clear definition of the syntax for set_input_delay

# recommended source-synchronous iDDR syntax from the vivado examples is:

set skew_afe 0.1; # time after falling edge at which data becomes stable.
set skew_bfe 0.1; # time before falling edge at which data ceases to be stable.
set skew_are 0.1; # same, but rising edges.
set skew_bre 0.1; # same, but rising edges.

#1.
set_input_delay -clock $input_clock -max [expr $input_clock_period/2 + $skew_afe] [get_ports $input_ports];
#2. 
set_input_delay -clock $input_clock -min [expr $input_clock_period/2 - $skew_bfe] [get_ports $input_ports];
#3.
set_input_delay -clock $input_clock -max [expr $input_clock_period/2 + $skew_are] [get_ports $input_ports] -clock_fall -add_delay;
#4.
set_input_delay -clock $input_clock -min [expr $input_clock_period/2 - $skew_bre] [get_ports $input_ports] -clock_fall -add_delay;

 

the user guide states that  
"Min delay analysis = (hold/removal)" and " Max delay analysis = (setup/recovery)"
"The -clock_fall option specifies that the input delay constraint applies to timing paths launched by the falling clock edge of the relative clock."

# in (1),   (period/2 + skew_afe) would imply that this is the minimum delay from the previous rising edge, before data is stable to be sampled by the following rising edge?
# this would make sense as a setup constraint, assuming the tools subtract this number from the clock period.  but wouldn't this really be a falling driven => rising sampled setup constraint?  This would be at odds with definition of -clock_fall from the guide..

# in (2),  (period/2 - skew_bfe) would imply that this is the maximum delay from the previous rising edge, before data is no longer stable to be sampled by the following falling edge?
# this would make sense as a hold constraint, a rising driven  => falling sampled hold constraint.

This syntax is either very poorly designed and confusing, or the examples are incorrect.....
Maybe I'm missing something... Please clue me in.

any help is appreciated.

0 Kudos
1 Solution

Accepted Solutions
kyle.drerup
Visitor
Visitor
705 Views
Registered: ‎06-17-2019

Somewhere, in a few months, there's an engineer frustrated, trying to understand what is going on in this example.
This engineer is likely confused by the inconsistency between setup and hold set_input_delay syntax in xdc.
I'm not sure we need to delve into philosophical discussions about methodologies. 
A wall of text doesn't help that engineer.  Only a precise definition of the xdc set_input_delay constraint will. 
I've tried to distill that down here with minimum words, after beating my head on this for a day.

What that engineer needs to know is:
0.  The tool infers what edges of the clock you're looking at the data on (or tries to).  These are called "Active edges" for our purposes.
1.  xdc syntax does input setup an hold constraints in a silly way.  note the discrepancy between the definitions for setup and hold.  it's the only way this example makes sense..
     a.  setup is defined with set_input_delay with the -max flag.  it is defined as the time after the previous active edge, when data becomes valid to sample on this active edge.
     b.  hold is defined with  set_input_delay with the -min flag.  it is defined as the time after this active edge, when data becomes invalid to sample on this active edge.
Please see figure 98 from the Ultra Fast Design Methodology guide (good job marketing dep't..)

 
For the case of the example input edge-aligned DDR constraints, let's explain exactly what is happening..
# we're capturing data on both edges, which means that both rising and falling edges are active.  
# so, because the syntax is silly, to specify setup for a falling edge, we tell the tool that that data setup window happens relative to the rising edge (even though that's not really true) and vice-versa.
# for hold, things are as you'd expect.  we define hold relative to the edge data's both sent and received on.
 
set_input_delay -clock $input_clock -max [expr $input_clock_period/2 + $skew_afe] [get_ports $input_ports];
#1.  this is a setup constraint, for data  that (in the real system) is both sent and received on a falling edge.  there is $skew_afe negative setup at the edge of the chip in this example.
# because xdc syntax is silly, we lie to the tool, telling it that this data was sent on the rising edge, because the tool defines setup relative to the previous active edge.
 
set_input_delay -clock $input_clock -min [expr $input_clock_period/2 - $skew_bfe] [get_ports $input_ports];
#2.  this is a hold constraint, for data  that (in the real system) is both sent and received on a rising edge. 
# the syntax for xdc defines hold constraints relative to the same clock edge that it was both sent and received on (sane definition)

set_input_delay -clock $input_clock -max [expr $input_clock_period/2 + $skew_are] [get_ports $input_ports] -clock_fall -add_delay;
#3. this is a setup constraint, for data  that (in the real system) is both sent and received on a rising edge.   there is $skew_are negative setup at the edge of the chip in this example.
#  same method as (1) above, just telling the tool that this data was sent on -clock_fall, and to keep both constraints defined for setup, with -add_delay


set_input_delay -clock $input_clock -min [expr $input_clock_period/2 - $skew_bre] [get_ports $input_ports] -clock_fall -add_delay;
#4.  this is a hold constraint, for data  that (in the real system) is both sent and received on a falling edge. 
# similar to (2), just for falling edge, and with flags from (3)

To the frustrated engineer:  hang in there.

View solution in original post

0 Kudos
12 Replies
avrumw
Expert
Expert
780 Views
Registered: ‎01-23-2009

The set_input_delay (and set_output_delay) syntax is very consistent, and, if you can understand it, does make sense. I will admit that it isn't always easy to really absorb it though.

The user guide does a relatively good job of explaining "normal" input and output constraints; SDR constraints aren't particularly complicated. 

Things get much more complicated with DDR constraints. The tools have no special rules for DDR constraints; you use the existing syntax to describe DDR interfaces. Furthermore, DDR interfaces often have "different" launch/capture edge relationships than SDR interfaces. For this reason, DDR constraints can be particularly difficult to understand...

Take a look at this post on constraining edge aligned source synchronous DDR input interfaces - hopefully this will help...

Avrum

0 Kudos
kyle.drerup
Visitor
Visitor
759 Views
Registered: ‎06-17-2019

@avrumw 
Thanks for the reply...

After digesting your previous post, I think I can summarize the first and third constraints with no issues:
#1.
set_input_delay -clock $input_clock -max [expr $input_clock_period/2 + $skew_afe] [get_ports $input_ports];
# this is a setup constraint for the data clocked in on the falling-edge...
# the tool needs to be told that this data was sent relative to the previous (rising) edge
# we tell the tool that data becomes valid [expr $input_clock_period/2 + $skew_afe] after a rising edge.
# why?
# the tool always assumes we clock data on the next active edge (after the edge the data is sent on)
   #(this is probably only true if it's actually clocked in on both rising and falling edges, otherwise normal sdr interfaces would be messy)
# because this constraint does not use -clock_fall, we're telling the tool that this data was sent relative to a rising edge (at t0)
# so the tool assumes it is clocked by iDDR on a falling edge..
# we've told the tool that the data window becomes valid at [expr $input_clock_period/2 + $skew_afe] after the rising edge.
# the tool, knowing about the 50% duty cycle clock, does -($input_clock_period/2 + $skew_afe) + $input_clock_period/2 => -$skew_afe setup
# this means that data becomes valid  $skew_afe after the falling edge of the clock (negative setup).

#3.
set_input_delay -clock $input_clock -max [expr $input_clock_period/2 + $skew_are] [get_ports $input_ports] -clock_fall -add_delay;
# similar to #1 above, just opposite edges.  this is a setup constraint for the data clocked in on the rising edge.
# the tool needs to be told that this data was sent relative to the previous (falling) edge

ONE IMPORTANT NOTE:
But, for #2 and #4, I think I was missing an important piece of information..
In your referenced description, you say that "We know that the tool assumes that the window defined by the risinge edge of virt_clk @0ns will be captured by the falling edge of fpga_clk at @5ns. ".  It's possible that you only meant the setup constraint, not both setup and hold..
Based on the diagram on page159, figure3-74: of UG949, it sure seems that:
   Setup (-MAX) always assumes that data is clocked on the next active edge.
   Hold (-MIN) assumes that data is clocked on the same edge as it was sent.
Unless this is true (hold analysis = same edge, setup analysis = next edge), I can't make any sense of constraints #2 and #4...

#2, #4 below are assuming (hold analysis = same edge, setup analysis = next edge):
#2. 
set_input_delay -clock $input_clock -min [expr $input_clock_period/2 - $skew_bfe] [get_ports $input_ports];
# this is a simple hold constraint for the data clocked in on the rising edge.....
# we tell the tool that data ceases to be valid [expr $input_clock_period/2 - $skew_bfe] after a rising edge.
# we're not lying to the tool with this one.  the tool analyzes hold constraints relative to the same clock edge the data was sent on.

#4.
set_input_delay -clock $input_clock -min [expr $input_clock_period/2 - $skew_bre] [get_ports $input_ports] -clock_fall -add_delay;
# this is a simple hold constraint for the data clocked in on the falling edge....

If this is correct, please confirm...

0 Kudos
avrumw
Expert
Expert
751 Views
Registered: ‎01-23-2009

Well, sort of...

Thinking about these as "setup constraints" and "hold constraints" are not really consistent with how SDC/XDC defines things. SDC/XDC focus on "describing the environment outside the FPGA" through constraints, and then having the tool figure out what the proper requirements are on setup and hold checks. This is significantly different to I/O constraints in ISE, which directly described the requirements.

The set_input_delay command, as its name implies, specifies the timing relationship - the "input delay" between a clock an a related data signal. It goes further and specifies a minimum and a maximum delay - this directly describes when the input will make a change - it will be somewhere between the -min and the -max of the set_input_delay. This is the definition of set_input_delay and should remain the focus of constraints, rather than trying to second guess how the tool will create requirements on paths based on these.

Looking at the constraints you are exploring, I don't particularly like this style (even though it comes from a Xilinx template) - it is what I refer to in my post as "the cheating way" - trying to lie to the tool as to which clock edge causes which data change so that the requirements that the tools derive come out right. But they don't really make sense.

In an edge aligned interface source synchronous interface, the clock edges and the data transitions are generated by the source device using a common internal clock; the internal clock edge in that device creates both the forwarded clock transition and the data change. This is why edge aligned is commonly used in devices; the skew between the clock and data are usually very small in a mechanism like this.

Without trying to second guess the tools, the "natural" way to constrain this is 

[edit: my original ones were wrong - the sign of the -min was incorrect]

set_input_delay -clock clk -min $skew_bre [get_ports ...]
set_input_delay -clock clk -max $skew_are [get_ports ...]

set_input_delay -clock clk -min $skew_bfe [get_ports ...] -clock_fall -add_delay
set_input_delay -clock clk -max $skew_afe [get_ports ...] -clock_fall -add_delay

set_input_delay -clock clk -min [expr {-$skew_bre}] [get_ports ...]
set_input_delay -clock clk -max $skew_are [get_ports ...]

set_input_delay -clock clk -min [expr {-$skew_bfe}] [get_ports ...] -clock_fall -add_delay
set_input_delay -clock clk -max $skew_afe [get_ports ...] -clock_fall -add_delay

This directly and simply describes the relationship between the clock and data - the earliest it will change is "bre" (which will be positive in a perfectly edge aligned interface, resulting in a negative -min) and the latest it will change is "are" (which will be positive and the same magnitude in a perfectly edge aligned interface, resulting in a positive -max). This is the "correct way".

One of the advantages of edge aligned source synchronous interfaces is the tight alignment between the forwarded clock edge and the corresponding data change. As a result, it is usually advantageous to capture the data window that follows a clock edge with that clock edge. But the default capture is the next clock edge. Capturing it with the next edge is actually inferior in terms of timing - particularly if you have any kind of duty distortion of the clock.

In the cheater way, you muck with the set_input_delay commands to "lie" to the tool so that it looks like a particular data window is created not by the clock edge that is just before it (which really did create it, or at least is the most tightly related to it), but the clock edge before that; in the cheater way, the window between the falling edge and the rising edge is described as being caused by the previous rising edge. It isn't - it is caused by the falling edge! That's why this is lying.

So in my post, I describe both - the "cheater way" and the "correct way".

The "correct way" uses the natural (correct!) set of commands commands for describing the timing and then using the "correct" commands to tell the tools that you want to change the default relationship between the launch and capture edges to have the tools do the "right" thing - capture the first window (between the rising and falling edge of the clock) with the rising edge of the clock and capture the second window (between the falling and next rising) with the falling edge of the clock.

Yes, it is confusing to see the set_multicycle_path 0 command - it is not initially intuitive. But if you go through my post carefully it describes exactly what these commands do and why they are necessary.

Avrum

0 Kudos
kyle.drerup
Visitor
Visitor
706 Views
Registered: ‎06-17-2019

Somewhere, in a few months, there's an engineer frustrated, trying to understand what is going on in this example.
This engineer is likely confused by the inconsistency between setup and hold set_input_delay syntax in xdc.
I'm not sure we need to delve into philosophical discussions about methodologies. 
A wall of text doesn't help that engineer.  Only a precise definition of the xdc set_input_delay constraint will. 
I've tried to distill that down here with minimum words, after beating my head on this for a day.

What that engineer needs to know is:
0.  The tool infers what edges of the clock you're looking at the data on (or tries to).  These are called "Active edges" for our purposes.
1.  xdc syntax does input setup an hold constraints in a silly way.  note the discrepancy between the definitions for setup and hold.  it's the only way this example makes sense..
     a.  setup is defined with set_input_delay with the -max flag.  it is defined as the time after the previous active edge, when data becomes valid to sample on this active edge.
     b.  hold is defined with  set_input_delay with the -min flag.  it is defined as the time after this active edge, when data becomes invalid to sample on this active edge.
Please see figure 98 from the Ultra Fast Design Methodology guide (good job marketing dep't..)

 
For the case of the example input edge-aligned DDR constraints, let's explain exactly what is happening..
# we're capturing data on both edges, which means that both rising and falling edges are active.  
# so, because the syntax is silly, to specify setup for a falling edge, we tell the tool that that data setup window happens relative to the rising edge (even though that's not really true) and vice-versa.
# for hold, things are as you'd expect.  we define hold relative to the edge data's both sent and received on.
 
set_input_delay -clock $input_clock -max [expr $input_clock_period/2 + $skew_afe] [get_ports $input_ports];
#1.  this is a setup constraint, for data  that (in the real system) is both sent and received on a falling edge.  there is $skew_afe negative setup at the edge of the chip in this example.
# because xdc syntax is silly, we lie to the tool, telling it that this data was sent on the rising edge, because the tool defines setup relative to the previous active edge.
 
set_input_delay -clock $input_clock -min [expr $input_clock_period/2 - $skew_bfe] [get_ports $input_ports];
#2.  this is a hold constraint, for data  that (in the real system) is both sent and received on a rising edge. 
# the syntax for xdc defines hold constraints relative to the same clock edge that it was both sent and received on (sane definition)

set_input_delay -clock $input_clock -max [expr $input_clock_period/2 + $skew_are] [get_ports $input_ports] -clock_fall -add_delay;
#3. this is a setup constraint, for data  that (in the real system) is both sent and received on a rising edge.   there is $skew_are negative setup at the edge of the chip in this example.
#  same method as (1) above, just telling the tool that this data was sent on -clock_fall, and to keep both constraints defined for setup, with -add_delay


set_input_delay -clock $input_clock -min [expr $input_clock_period/2 - $skew_bre] [get_ports $input_ports] -clock_fall -add_delay;
#4.  this is a hold constraint, for data  that (in the real system) is both sent and received on a falling edge. 
# similar to (2), just for falling edge, and with flags from (3)

To the frustrated engineer:  hang in there.

View solution in original post

0 Kudos
kyle.drerup
Visitor
Visitor
699 Views
Registered: ‎06-17-2019

@avrumw  :  When you say:

Without trying to second guess the tools, the "natural" way to constrain this is 

set_input_delay -clock clk -min $skew_bre [get_ports ...]
set_input_delay -clock clk -max $skew_are [get_ports ...]

set_input_delay -clock clk -min $skew_bfe [get_ports ...] -clock_fall -add_delay
set_input_delay -clock clk -max $skew_afe [get_ports ...] -clock_fall -add_delay

This directly and simply describes the relationship between the clock and data - the earliest it will change is "bre" (which will be negative in a perfectly edge aligned interface) and the latest it will change is "are" (which will be positive and the same magnitude in a perfectly edge aligned interface). This is the "correct way".

Just to be clear, this doesn't work without multicycycle constraints.
I agree, this is the most natural way to describe, but most engineers are looking for the quick (if dirty)  solution to get the constraints right.

Also, assuming this is for the edge-aligned DDR example:

set_input_delay -clock clk -min $skew_bre [get_ports ...]  # it looks like a hold constraint for the data sent on the rising edge, to be coupled with a multicycle.  If so, I think it should be $skew_bfe
set_input_delay -clock clk -max $skew_are [get_ports ...] # with a multicycle constraint, I think this is a good rising edge setup constraint.

set_input_delay -clock clk -min $skew_bfe [get_ports ...] -clock_fall -add_delay # if this is supposed to be hold for falling (with multicycle), I think it should be  $skew_bre
set_input_delay -clock clk -max $skew_afe [get_ports ...] -clock_fall -add_delay # with a multicycle constraint, I think this is a good rising edge setup constraint.

0 Kudos
avrumw
Expert
Expert
693 Views
Registered: ‎01-23-2009

Just to be clear, this doesn't work without multicycycle constraints.

That is correct. At least with most clocking schemes. In an edge aligned interface you will normally want to capture the data window after the rising edge with the rising edge; effectively push the clock forward to capture the data. It would be viable to do the opposite - to try and pull the clock back so that the data between the rising and falling edge is captured by the falling edge. In this case, the constraint would work without the multicycle path. But it is usually pretty clear that pushing the clock forward is the better solution (and hence needs the multicycle path).

I agree, this is the most natural way to describe, but most engineers are looking for the quick (if dirty)  solution to get the constraints right.

I understand what you are saying, and I understand this desire. But it goes against the spirit of XDC/SDC - there is a clear "right" way to do this that is more consistent with how the concepts of static timing are designed in SDC/XDC. I prefer to convey that understanding than to do things quick and dirty. But, again, I understand that the real world sometimes requires us to take shortcuts.

set_input_delay -clock clk -min $skew_bre [get_ports ...]  # it looks like a hold constraint for the data sent on the rising edge, to be coupled with a multicycle.  If so, I think it should be $skew_bfe

This I disagree with. Again, this is not a "hold constraint" - it is specifying the minimum propagation delay between a clock and a data. Since this doesn't use the -clock_fall, the relationship I am describing is with respect to the rising edge, and hence it should use the skew with respect to the rising edge, which is $skew_bre - using $skew_bfe would actually be incorrect if the two weren't equal.

In fact, when you use the cheater way, you need to swap the "f" (falling) and the "r" (rising) in the bre/are/bfe/afe notation; by adding the 1/2 clock cycle, the delays you are specifying on the commands without the -clock_fall (hence with respect to the rising edge of the clock) are actually describing the window after the falling edge - as a result, they need to use the bfe/afe. The ones with the -clock_fall (hence with respect to the falling edge) are describing the window after the rising edge, which therefore need to use the bre/are (which is what your original constraints did). This is another reason that the "cheating" way is confusing...

Avrum

0 Kudos
kyle.drerup
Visitor
Visitor
684 Views
Registered: ‎06-17-2019

"
set_input_delay -clock clk -min $skew_bre [get_ports ...]  # it looks like a hold constraint for the data sent on the rising edge, to be coupled with a multicycle.  If so, I think it should be $skew_bfe

This I disagree with. Again, this isnota "hold constraint" - it is specifying the minimum propagation delay between a clock and a data. Since this doesn't use the -clock_fall, the relationship I am describing is with respect to the rising edge, and hence it should use the skew with respect to the rising edge, which is $skew_bre - using $skew_bfe would actually be incorrect if the two weren't equal.
"

if we're defining the valid data window that happens after the rising edge in this example, doesn't that data window end at  [expr ($period / 2) - $skew_bfe] with respect to the rising edge? 
unless you're re-defining $skew_bre to be more than half the clock cycle..

0 Kudos
avrumw
Expert
Expert
654 Views
Registered: ‎01-23-2009

if we're defining the valid data window that happens after the rising edge in this example

No. Again, we are not defining a window, nor are we directly specifying constraints. We are describing a timing relationship between a clock edge and a data transition - we describe the minimum and maximum delay between the clock edge and the transition. We define the delay. Think of the set_input_delay as taking the place of a flip-flop (in fact it virtually is) - the flip-flop has a minimum and a maximum clock to output time; this is what we describe to the tool.

For timing analysis, on any path, the tool first looks at the clocks driving the startpoint and endpoint. From these it looks at the edges of these clocks and determines which edge of the startpoint clock is the launch edge and which edge of the destination clock is the capture edge. It has a well defined algorithm for doing so that covers all clocks, including ones with different frequencies. For a path that starts and ends at the same clock, this will resolve to the following combinations

  • For a setup check, the launch will be the first clock edge, and the capture edge will be the second clock edge
  • For a hold check the launch will be the first clock edge and the capture will be the same edge (the first)

With the edges determined, the tool then does the timing analysis. For the propagation delays of the input_delay it uses either the min or max (depending on the check) of the set_input_delay for the appropriate edge. For an input it will use the -max for the setup check and the -min for the hold check.

Avrum

0 Kudos
kyle.drerup
Visitor
Visitor
615 Views
Registered: ‎06-17-2019

@avrumw 
I understand. 
set_input_delay -min defines the earliest that the data can change w.r.t. the clock edge that triggered the event. (for a single clock domain, equivalent to hold)
set_input_delay -max defines the latest that the data can change w.r.t. the clock edge that triggered the event.   (for a single clock domain, equivalent to a setup constraint, minus the delta between the sender's driving edge and the receiver's capture edge)

Maybe this is a dead horse, but I'm not above that...

From your earlier example of the "Natural way":

set_input_delay -clock $clk -min $skew_bre [get_ports ...]  #

When used with appropriate multicycle -1 and false path constraints from your example, please confirm that this is equivalent to a HOLD constraint for data that starts based on a rising edge and is captured on that same rising edge.

Please answer Yes, or No?

0 Kudos
avrumw
Expert
Expert
564 Views
Registered: ‎01-23-2009

No.

Aside from everything I said above, about how this way of thinking is just not how Vivado works, I realize that that I probably made an error in my constraints (I will fix them).

Assuming the "bre"/"bfe" really means "before", so that if the signal can change 1ns before the rising edge this would be 1.0, not -1.0, then the constraint should really be

set_input_delay -clock clk -min [expr {-$skew_bre}] [get_ports ...]
set_input_delay -clock clk -max $skew_are [get_ports ...]

set_input_delay -clock clk -min [expr {-$skew_bfe}] [get_ports ...] -clock_fall -add_delay
set_input_delay -clock clk -max $skew_afe [get_ports ...] -clock_fall -add_delay

The set_input_delay is the delay from the clock edge to the data transition. If the value is positive, this means after the clock edge, and if it is negative it means before the clock edge. Conversely, if the bre/bfe is positive this means before the clock edge, and if it is negative it means after the clock edge.

Avrum

0 Kudos
kyle.drerup
Visitor
Visitor
446 Views
Registered: ‎06-17-2019

From your earlier example of the "Natural way":

set_input_delay -clock $clk -min $skew_bre [get_ports ...]  #

When used with multicycle and false path constraints, exactly what timing relationship is this intended to convey to the tool?
Could we get a FULL example of those constraints?  It's very confusing to get it piecemeal.

I thought this was supposed to describe the time from the rising edge of clock cycle N until the earliest time the data can change after that cycle.

0 Kudos
avrumw
Expert
Expert
438 Views
Registered: ‎01-23-2009

I thought this was supposed to describe the time from the rising edge of clock cycle N until the earliest time the data can change after that cycle.

Yes.

Lets take a real example. If the data can change anywhere from 0.1ns before the edge of the clock to 0.1ns after the edge of the clock this will result in the following.

set_input_delay -clock <clock> -min -0.1 [get_ports <ports>]; # 0.1ns before the rising clock edge is the earliest it can change
set_input_delay -clock <clock> -max 0.1 [get_ports <ports>]; # 0.1ns after the rising clock edge is the latest it can change
set_input_delay -clock <clock> -min -0.1 [get_ports <ports>] -clock_fall -add_delay; # 0.1ns before the falling clock edge is the earliest it can change
set_input_delay -clock <clock> -max 0.1 [get_ports <ports>] -clock_fall -add_delay; # 0.1ns after the falling clock edge is the latest it can change

The confusion is the terms "bre/are/bfe/afe" - these are terms that were "made up" by the I/O timing wizard and some of the Xilinx documentation. They are not consistent with the definitions of min/max. 

So, with the above timing

$skew_are=0.1
$skew_bre=0.1   - Note that direction of time is backwards - a positive number means "earlier in time" - "before" the clock edge
$skew_afe=0.1
$skew_bfe=0.1    - again, note that the direction of time is backwards

For a set_input_delay the delay is always in the positive time direction. A positive number means "later" a negative time means "earlier". However, for the bre/are/bfe/afe notation, a positive "b" means "backwards in time" whereas a negative "b" means "forwards in time". This is the opposite of the direction of time for set_input_delay -min

Conversely (and this can be a bit confusing), a set_output_delay is the opposite; a positive set_output_delay means the data must be available before the edge of the clock and a negative number means it is after the edge of the clock (but let's not go here unless we have to).

Avrum

0 Kudos