Hi, everybody:
    I'm confused with offset constraint and its report recently. Can anyonehelp me? Thanks very much!

    "din" is a input data whose bus width is 32bit.  I set a offsetconstraint :

Net "din<31>" offset = IN 2ns before clk_in. Period of clk_in wasconstrained to 6ns. And i got a result in P&R report:

    Constraint                      Request       Actual

din<31>offset...                     2ns          -3.17ns

All constraints are met. 


    According to my comprehension, din<31> can lag 3.17ns mostly behindrising edge of clk_in on the PAD. And after data path delay and clk pathdelay, din<31> can be sampled at the first FF correcttly and exactly. Am iright?

    But if din<31> arrive 2ns before clk_in rising edge just as offsetconstraint said, after delay of data path and clk path, clk rising edgewill present at nearly (2+3.17)ns with respect to din<31>, that is unstableperiod of din<31>.

    How to explain this?

    Thanks, guys!   


	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On Jan 22, 9:44=A0am, "realwood"
<realwood1...@163.com> wrote:
> Hi, everybody:
> =A0 =A0 I'm confused with offset constraint and its report recently. Can =
anyone
> help me? Thanks very much!
>
> =A0 =A0 "din" is a input data whose bus width is 32bit. =A0I set a offset
> constraint :
>
> Net "din<31>" offset =3D IN 2ns before clk_in. Period of clk_in was
> constrained to 6ns. And i got a result in P&R report:
>
> =A0 =A0 Constraint =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Request =A0=
 =A0 =A0 Actual
>
> din<31>offset... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2ns =A0 =A0 =A0 =
=A0 =A0-3.17ns
>
> All constraints are met.
>
> =A0 =A0 According to my comprehension, din<31> can lag 3.17ns mostly behi=
nd
> rising edge of clk_in on the PAD. And after data path delay and clk path
> delay, din<31> can be sampled at the first FF correcttly and exactly. Am =
i
> right?
>
> =A0 =A0 But if din<31> arrive 2ns before clk_in rising edge just as offse=
t
> constraint said, after delay of data path and clk path, clk rising edge
> will present at nearly (2+3.17)ns with respect to din<31>, that is unstab=
le
> period of din<31>.
>
> =A0 =A0 How to explain this?
>
> =A0 =A0 Thanks, guys! =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

You an explain this by looking at the other half of the
equation.  Your hold time will be very large, meaning
that you're not clocking in the data on the cycle
you intended to, unless the input signal also meets
the hold time requirement.

Thanks very much for your reply!

It tell me "all constraint are met", doesn't timing report analyze setuptime and hold time at the same time?

That is to say, if hold time equation doesn't meet, timing report will tellus offset constraint is "not met", right?	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

>Thanks very much for your reply!
>
>It tell me "all constraint are met", doesn't timing report analyze setup
>time and hold time at the same time?
>
>That is to say, if hold time equation doesn't meet, timing report willtell
>us offset constraint is "not met", right?	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>

According to ISE definition, input offset is the time of data transitionrelative to NEXT clock edge. 
Your setting of 2ns resulted in ISE reporting -3.17ns i.e. ISE nowcontradicted its own definition and related it to previous clock edge.
Whichever way you look at it, you got a transition at(6 - (-3.17)) = 2.83ns with respect to NEXT clock edge, almost centre aligned. I don't expectvolation of setup or hold as reported. Your own addition of 2 + 3.17nsmakes no sense to me. you asked for 2ns and you got 2.83ns

kadhiem	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

>According to ISE definition, input offset is the time of data transition
>relative to NEXT clock edge. 
>Your setting of 2ns resulted in ISE reporting -3.17ns i.e. ISE now
>contradicted its own definition and related it to previous clock edge.
>Whichever way you look at it, you got a transition at(6 - (-3.17)) = 2.83
>ns with respect to NEXT clock edge, almost centre aligned. I don't expect
>volation of setup or hold as reported. Your own addition of 2 + 3.17ns
>makes no sense to me. you asked for 2ns and you got 2.83ns
>
>kadhiem	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>

I think you are wrong. "transition at 2.83ns with respect to the next clkedge, almost center aligned" AT THE PAD means nothing, what we need isclocking correct AT THE FIRST Flip Flop.

What ISE report means is that: If data come 3.17ns lag behind clock risingedge, clock can just exactly sample data correctly at the first flip flop.Right?

If that is true, then: if data come 2ns before clock rising edge as theoffset constraint, after going through the same data path and clock path,clock rising edge will present at (2+3.17)ns with respect to the data. Thatis my question. 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

>
>>According to ISE definition, input offset is the time of data transition
>>relative to NEXT clock edge. 
>>Your setting of 2ns resulted in ISE reporting -3.17ns i.e. ISE now
>>contradicted its own definition and related it to previous clock edge.
>>Whichever way you look at it, you got a transition at(6 - (-3.17)) =2.83
>>ns with respect to NEXT clock edge, almost centre aligned. I don'texpect
>>volation of setup or hold as reported. Your own addition of 2 + 3.17ns
>>makes no sense to me. you asked for 2ns and you got 2.83ns
>>
>>kadhiem	   
>>					
>>---------------------------------------		
>>Posted through http://www.FPGARelated.com
>>
>
>I think you are wrong. "transition at 2.83ns with respect to the next clk
>edge, almost center aligned" AT THE PAD means nothing, what we need is
>clocking correct AT THE FIRST Flip Flop.
>
>What ISE report means is that: If data come 3.17ns lag behind clockrising
>edge, clock can just exactly sample data correctly at the first flipflop.
>Right?
>
>If that is true, then: if data come 2ns before clock rising edge as the
>offset constraint, after going through the same data path and clock path,
>clock rising edge will present at (2+3.17)ns with respect to the data.That
>is my question. 	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com

Both xilinx and altera timing tools are practically intersted in figuresfor setup/hold timing relations at pads so that timing of io registers isderived internally according to window shift. As a user, you only need tolook at pads and the tool will tell you if internal io and core registersare ok.

kadhiem
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

>>
>>>According to ISE definition, input offset is the time of datatransition
>>>relative to NEXT clock edge. 
>>>Your setting of 2ns resulted in ISE reporting -3.17ns i.e. ISE now
>>>contradicted its own definition and related it to previous clock edge.
>>>Whichever way you look at it, you got a transition at(6 - (-3.17)) =
>2.83
>>>ns with respect to NEXT clock edge, almost centre aligned. I don't
>expect
>>>volation of setup or hold as reported. Your own addition of 2 + 3.17ns
>>>makes no sense to me. you asked for 2ns and you got 2.83ns
>>>
>>>kadhiem	   
>>>					
>>>---------------------------------------		
>>>Posted through http://www.FPGARelated.com
>>>
>>
>>I think you are wrong. "transition at 2.83ns with respect to the nextclk
>>edge, almost center aligned" AT THE PAD means nothing, what we need is
>>clocking correct AT THE FIRST Flip Flop.
>>
>>What ISE report means is that: If data come 3.17ns lag behind clock
>rising
>>edge, clock can just exactly sample data correctly at the first flip
>flop.
>>Right?
>>
>>If that is true, then: if data come 2ns before clock rising edge as the
>>offset constraint, after going through the same data path and clockpath,
>>clock rising edge will present at (2+3.17)ns with respect to the data.
>That
>>is my question. 	   
>>					
>>---------------------------------------		
>>Posted through http://www.FPGARelated.com
>
>Both xilinx and altera timing tools are practically intersted in figures
>for setup/hold timing relations at pads so that timing of io registers is
>derived internally according to window shift. As a user, you only need to
>look at pads and the tool will tell you if internal io and core registers
>are ok.
>
>kadhiem
>	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>


kadhiem, thank for your reply first. And let me explain the questionagain:

What ISE report means is that: If data come 3.17ns lag behind clock rising
edge, clock can just exactly sample data correctly at the first flip flop.

So, if data come 2ns before clock rising edge, (i.e. come (2+3.17)nsearlier than ISE report), data will arrive the first flip flop (2+3.17)nsearlier than situation of ISE report which means fulfill setup time at FFexactly. 
And data period is 6ns, so, (2+3.17)ns will not be a stable time of data. 

I've read a pdf of xilinx which says constraint of "offset in before" onlyanalyze setup time, and hold time is analyzed when "valid" time is set. Andi think maybe that is the answer to my question: -3.17ns fulfill setuptime, but don't fulfill the hold time. So, i add "valid" time constraint,and -3.17ns is not reported again. 

Am i right? Thanks!

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com