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: 
Adventurer
Adventurer
4,678 Views
Registered: ‎11-09-2009

skew from input to registers

Jump to solution

Hi,

I have a case where i have one input and then

two registers; one with rising edge and other one with falling edge.

What is the correct way to constrain the delay/path from input pin to these registers so that they have same delay ?

There isn't set_max_skew-command, anything else to be used ? Constrain or design method ?

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
7,049 Views
Registered: ‎01-23-2009

Re: skew from input to registers

Jump to solution

I don't know what the io_reset pin of the clock wizard generated IP in this configuration does - you will have to look at the documentation for the core. If this really is just IDDRs and the io_reset is just the reset to the two IDDRs, then you can tie it inactive - the data on the "first clock" of the system after powerup will be potentially unknown, but as long as the rest of the system has an explicit reset this shouldn't cause any harm.

 

As for the synchronizer chain, I already answered that. Two FFs is probably sufficient, but you can use 3 (or more). The IDDR is either one or two FFs (back to back) depending on what mode you use - in "SAME_EDGE_PIPELINED" it is 2 on the Q1 output and 1.5 on the Q2. You can follow this with one or two others in the fabric if you want. Note that I am not sure if you can specify the ASYNC_REG property on the IDDR itself - so to be really paranoid and safe, you may want to put 2 or 3 FFs in the fabric with ASYNC_REG on them.

 

Avrum

View solution in original post

8 Replies
Historian
Historian
4,670 Views
Registered: ‎01-23-2009

Re: skew from input to registers

Jump to solution

You should use the IDDR to do this - not separate fabric flip-flops. The IDDR is designed specifically for this, and is fixed in the input/output block (close to the input), so there is no issue with data path skew.

 

If you must do this in the fabric (and I REALLY REALLY don't recommend it), then you would have to do it with a combination of set_max_delay and set_min delay to force the routing to be constrained - but you will have to play with the values (with the max being roughly 3x the min) to determine what the tools can actually accomplish.

 

Avrum

 

0 Kudos
Highlighted
Adventurer
Adventurer
4,076 Views
Registered: ‎11-09-2009

Re: skew from input to registers

Jump to solution

Hi Avrum,

Thanks from your earlier answer.

I would like to ask you yet few question regarding this.

1) The input is asynchronous to iddr.

set_input_delay -clock [get_clocks y] -max 1.000 [get_ports X]
set_input_delay -clock [get_clocks y] -clock_fall -max -add_delay 1.000 [get_ports X]
set_input_delay -clock [get_clocks y] -min -add_delay 2.200 [get_ports UART1_RX]
set_input_delay -clock [get_clocks y] -clock_fall -min -add_delay 2.200 [get_ports X]
set_false_path -from [get_ports X]

If don't use the false_path command I get 16 routes reported from timing analysis. (rise/fall edges data/clock + corners)

If I use it, I get only (unsconstrained) path 8. But they are all from falling edge of the sampling clock to iddr.

I would assume I would get same 16

This is strange and why it is so ?

 

2) is there any need to use io_reset or could it be tied to constant? I am only using IDDR with two registers here..

 

3) If using, let's say f>300MHz, how many synchronise registers would you put after this block ? (Zynq)

 

 

0 Kudos
Historian
Historian
4,058 Views
Registered: ‎01-23-2009

Re: skew from input to registers

Jump to solution

So first - there appear to be several errors in the set_input_delay commands:

  - 3 of them are to port X, the last one is to port UART1_RX (I presume this is just a typo in your post)

  - the -min is larger than the -max - that should never be the case

  - your third one has the -add_delay and probably shouldn't (see below)

 

Each port can, by default have one max and one min. Normally one does

  1)  -max            : This places a max on the rising edge

  2) -min              : This places a min in the rising edge

  3) -add_delay -clock_fall: This adds a second set of max on the falling edge. The -add_delay prevents it from removing the ones that are already there

  4) -min -add_delay -clock_fall: This adds a second min on the falling edge

 

With the extra -add_delay, if you have some other constraint somewhere else in your design (before this one), any min already on the rising edge will be kept in addition to the new one you are adding

 

As for whether you get a report on 8 or 16 paths when the set_false_path is applied - I don't know. Getting timing reports on unconstrained paths can be difficult - the tools don't really want to report them.

 

So, first try fixing your constraints. If that doesn't fix it, then get more explicit - something like

 

report_timing -max_paths 100 -nworst 100 -rise_from [get_clocks y] -through [get_ports X]

(and the same for -fall_from [get_clocks y]

 

You should be able to force it to report all 16 combinations.

 

The 16 combinations are

  - from the rising edge of the clock and the falling edge of the clock

  - for the slow process corner and the fast process corner

  - for the setup check and the hold check (although these don't really apply to false paths)

  - for the 0->1 (r) transition at the source (not the clock edge, but the data transition) and for the 1->0 (f) transition

 

Avrum

0 Kudos
Adventurer
Adventurer
4,038 Views
Registered: ‎11-09-2009

Re: skew from input to registers

Jump to solution

Hi Avrum,

Thanks for the answer, again.

It just doesn't seem to report the rising edge if false-path is used.

So, perhaps i won't use false_path here...

 

How about the other things, could you help with those ?

 

2) is there any need to use io_reset or could it be tied to constant? I am only using IDDR with two registers here..

 

3) If using, let's say f>300MHz, how many synchronise registers would you put after this block ? (Zynq)

 

 

0 Kudos
Historian
Historian
4,029 Views
Registered: ‎01-23-2009

Re: skew from input to registers

Jump to solution

2) is there any need to use io_reset or could it be tied to constant? I am only using IDDR with two registers here..

 

I don't know what "io_reset" is - it is not an input to the IDDR itself. Give me some more information...

 

3) If using, let's say f>300MHz, how many synchronise registers would you put after this block ? (Zynq)

 

This is a tough one to answer too. I have habitually used only 2, but I suspect that that isn't enough anymore. At 300MHz, I would probably consider 3.

 

But, I want to point out that in most cases the back to back flip-flops (with the ASYNC_REG property set) are only part of the solution for a clock domain crossing circuit - there are very few circumstances where it is sufficient on its own, and it almost always needs specific constraints as well...

 

Avrum

0 Kudos
Adventurer
Adventurer
4,023 Views
Registered: ‎11-09-2009

Re: skew from input to registers

Jump to solution

Hi Avrum,

 

2) I am using selectio_wizard,so that the block is configured as iddr with just two registers, falling/rising sampling

-without serialising factor, external datawidth=1

=>this turns out to behave just two flip-flops with different samplin edges.

So, is the reset really needed ?

 

 

3) just just making a synchronizer chain to the signal, before I can search for rising edges out of it

 So how many you think would be nessecary after the iddr ?

 

Untitled1.png
0 Kudos
Adventurer
Adventurer
3,939 Views
Registered: ‎11-09-2009

Re: skew from input to registers

Jump to solution

Hi Avrum,

Could you help with the extra info provided ?

Thanks.

0 Kudos
Historian
Historian
7,050 Views
Registered: ‎01-23-2009

Re: skew from input to registers

Jump to solution

I don't know what the io_reset pin of the clock wizard generated IP in this configuration does - you will have to look at the documentation for the core. If this really is just IDDRs and the io_reset is just the reset to the two IDDRs, then you can tie it inactive - the data on the "first clock" of the system after powerup will be potentially unknown, but as long as the rest of the system has an explicit reset this shouldn't cause any harm.

 

As for the synchronizer chain, I already answered that. Two FFs is probably sufficient, but you can use 3 (or more). The IDDR is either one or two FFs (back to back) depending on what mode you use - in "SAME_EDGE_PIPELINED" it is 2 on the Q1 output and 1.5 on the Q2. You can follow this with one or two others in the fabric if you want. Note that I am not sure if you can specify the ASYNC_REG property on the IDDR itself - so to be really paranoid and safe, you may want to put 2 or 3 FFs in the fabric with ASYNC_REG on them.

 

Avrum

View solution in original post