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: 
Observer sp_usr
Observer
232 Views
Registered: ‎10-16-2012

Spartan 6 PAD to FF time at IOB

Hi all,

I'm porting a Spartan 3A design to a Spartan 6 and I see that timing results are so different for both architectures.

I have many input signals constrained by PAD to FF constraint to 3 ns which were quite easy to meet at S3A IOB and impossible(?) to meet by spartan 6 (-2 speed grade LVCMOS33).

I see the timing analyzer tool calculates this max time like:

Tiopi (≈ 1.59 ns) + net delay (≈ 0.3 ns) + Tidock (≈1.73ns) , which is correct according to Spartan 6 datasheet.

I see that there is another time at datasheet called Tidockd (instead of Tidock) that has slower time values. It talks about using IODELAY2.

I have been reading about this IODELAY2 primitive, but I do not have it clear. Is it possible to use this primitive for any IOB? And could I find a solution to meet this time requirement using this primitive(3 ns)?

Thanks.

0 Kudos
1 Reply
200 Views
Registered: ‎01-22-2015

Re: Spartan 6 PAD to FF time at IOB

@sp_usr 

I have been reading about this IODELAY2 primitive, but I do not have it clear. Is it possible to use this primitive for any IOB?
Near Fig 1-1 in UG381, it says that every I/O tile contains two IOBs, two ILOGICs, two OLOGICs, and two IODELAYs.  So yes, it is possible to use IODELAY2 with any IOB.

The IODELAY2 primitive provides adjustable and fine-resolution delay.  The IODELAY2 can be inserted between the IOB block and either the ILOGIC2 or OLOGIC2 block in Fig 1-1 of UG381 to increase delay (not decrease delay).

I have many input signals constrained by PAD to FF constraint to 3 ns..
I agree with your calculation of the Spartan-6 PAD-to-FF delay and it seems that your constraint of 3ns cannot be met (for -2 speed grade and LVCMOS33).  Can you tell me where this 3ns constraint is coming from? 

If the 3ns constraint is coming from an FPGA clocked IO interface, then perhaps the constraint is not so strict.  That is, with FPGA IO, it is usually a delay-difference (between a data-path and a clock-path) that concerns us – and not the absolute delay of either path.  In fact, the IODELAY2 primitive is often used to adjust this delay-difference for FPGA IO so that the data is properly captured (ie. to locate the clock capture edge in the middle of the data eye).

Anyway, please tell me more about the 3ns delay requirement - then perhaps I can help you a little more.

Cheers,
Mark

0 Kudos