spartan-3 I/O timing

and

I

saving

I don't have your answer but I have a suggestion: consider using a DCM to move the clock up by about 1.25 ns. If your clock is continuous, you can match the input and output timing to your original design.

True, if you can use the DCM. Not always an option.

I'm just trying to understand the physics of the timing differences. Just doesn't make sense to me.

Rob

Is seems the TIOPI only 1.20 - 0.31 = 0.89ns for LVTTL input described in SP-3 datasheet v1.3, and the TIOOP for LVTTL F12 is 3.42-0.12 = 3.2ns.

"Robert Sefton" ?ÈëÓ?þ news: snipped-for-privacy@uni-berlin.de...

and

I

saving

Channing -

Are you looking at Tables 16 and 17 for the input delay and Tables 18 and 20 for the output delay? I still get 2.15ns for the input delay (1.94 + 0.21), but I had the output delay wrong. 0.48ns is just the correction factor for LVTTL F12. The complete output delay is 1.46 - 0.48 = 0.98ns. Where did you get your numbers?

Thanks, Rob

and

I

saving

Do you know which version of the speeds file you are using? It should be listed in the timing report. Alternately, you can type the following on the command line or in a DOS box.

speedprint 3s1000 > timing.txt

The "version id" is listed toward the top of the file. You want v1.32 or later. The numbers in your posting don't seem to match up completely with the v1.32 speeds file or the Spartan-3 data sheet, even with the relevant adjustments to LVTTL. Here are the values from the Spartan-3 data sheet.

Tiopi = 1.94 ns (measured for LVCMOS, 2.5V, 12 mA output drive, Fast slew rate) LVTTL input adjustment = 0.21 ns Tiopi (LVTLL) = 1.94 + 0.21 = 2.15 ns

Tioop = 1.46 ns LVTTL output adjustment = 0.48 ns Tioop (LVTTL) = 1.46 + 0.48 = 1.94 ns

There is a physical reason for some I/O timing differences between Virtex-II and Spartan-3. Spartan-3 uses lower cost wire-bonded packages and has a dual I/O ring.

What is the nature of you input path timing errors? What timing do you need? Perhaps there is a relatively easy work-around. The Digital Clock Managers (DCMs) on a Spartan-3 FPGA allow you to adjust I/O timing if you have a monotonic clock. If the clock is not monotonic, you can also use a technique that Xilinx calls "local clocking". We use this on a number of high-speed memory interfaces.

"Saving $125 per chip with S3", I hope, justifies a little further analysis. ;-)

--------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/II/IIE FPGAs

--------------------------------- Spartan-3: Make it Your ASIC

Steve -

Thanks for the reply. Here's the speed file version from the timing report:

Device,speed: xc3s1000,-4 (ADVANCED 1.32 2004-06-09)

I was working from the data sheet. I got Tiopi right but butchered Tioop twice. When I use the tables correctly I get 1.94ns. So the S-3/V-2 (-4) comparison looks like this now for LVTTL F12:

Virtex-2 Spartan-3 -------- ---------- TIOPI 0.88ns 2.15ns (pad to IOB .I output) TIOOP 1.74ns 1.94ns (IOB .O input to pad)

This is a huge hit to take on the input path. My Virtex-2 design interfaces to a PowerPC and SDRAM on a 66MHz 60X bus, and there's also flash and a couple of peripherals on the bus. The FPGA is a bus master for SDRAM DMAs, and the I/O timing for the ciritcal arbitration and control signals is extremely tight. They can't be registered in the IOB. I'm already using the DCM.

Here's one of my input timing constraints:

NET "abb_n_pad" OFFSET = IN 7.1 ns AFTER "clk66_pad"; (7.1ns is the PowerPC derated output delay + trace delay + fudge for clock skew)

Here's the result in Virtex-2:

================================================================================ Timing constraint: COMP "abb_n_pad" OFFSET = IN 7.100 nS AFTER COMP "clk66_pad" ;

50 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold errors) Maximum allowable offset is 7.380ns.

--------------------------------------------------------------------------------

So Virtex-2 makes the constraint with 280ps margin.

Here's the Spartan-3 result:

================================================================================ Timing constraint: COMP "abb2_n_pad" OFFSET = IN 7.100 nS AFTER COMP "clk66_pad" ;

13 items analyzed, 7 timing errors detected. (7 setup errors, 0 hold errors) Maximum allowable offset is 5.637ns.

--------------------------------------------------------------------------------

So the Spartan-3 misses by 7.1 - 5.637 = 1.463ns. That's pretty close to the

1.27ns increase in the input buffer delay. The rest is lost in the internal logic, which is also slower in Spartan-3. Here are the internal 66MHz timing results:

Virtex-2:

================================================================================ Timing constraint: TS_clk66_dll_clk0 = PERIOD TIMEGRP "clk66_dll_clk0" TS_CLK66 * 1.000000 HIGH

50.000 % ; 59785 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold errors) Minimum period is 11.770ns.

--------------------------------------------------------------------------------

Spartan-3:

================================================================================ Timing constraint: TS_clk66_dll_clk0 = PERIOD TIMEGRP "clk66_dll_clk0" TS_CLK66 * 1.000000 HIGH

50.000 % ; 59860 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold errors) Minimum period is 13.694ns.

--------------------------------------------------------------------------------

So the Spartan-3 is about 15% slower than Virtex-2 internally. I'm pretty bummed with these results. The Spartan-3 pricing is compelling, but just a tease if it can't make timing. And I need the industrial temp range, so I can currently only use -4 parts.

I'm open to any and all ideas, but I can't speed up the PowerPC so Spartan-3 looks like a no-go on this one.

Thanks, Rob

[snip]

Spartan-3

My 133MHz PowerPC interface hasn't been in a Spartan-3 yet but was readily implemented in the Spartan-IIE. Being the second of 2 masters interfacing to a bridge (the first is the processor), the timing was aggressive considering the complexity in a qualified bus grant. To get around the need to come in, go through logic, and go out with only one register in the path, I leveraged the FDSE primitives in the IOBs to turn the tristates on and off with the exceptionally low delays. I had the advantage of DMAs going only into the chip - I'm thinking DMAs back out would be troublesome for the 133 MHz speeds.

A reconfiguration of the interface might get your bus control to behave much better with the Spartan-3 I/O timings.

Another trick that I've used... if delaying the clock would help but the DCM is unavailable, add another clock buffer in the clock path. Controlling the routing to the same or opposite sides of the chip will give slightly different times. Since routing delays tend to track faster/slower with the rest of the chip, I wasn't too concerned about just "adding delays" to improve my timing.

Thanks for the ideas. I have three masters in the FPGA, and each master supports four DMA functions, so there are a total of 12 DMA channels. Plus the MPC8250 uses GPCM accesses on the 60X bus to access internal FPGA registers. Lot's of logic hanging off the critical nets. The MPC8250 has dedicated br-/bg-/dbg- lines for each master, but abb-, dbb-, psdval-, etc., are shared.

I am using the DCM, but shifting the clock won't help because there are output paths that are just as critical. One upside with the Spartan-3 is that the S-3 1000 has almost 50% more logic (LUTs and FFs) than the V-2 1000. So I have more headroom there. Now that I've accepted the I/O timing situation and stopped being pissed about it maybe I can find a way to make it work.