Reply by Robert Sefton●September 14, 20042004-09-14
"John_H" <johnhandwork@mail.com> wrote in message
news:xUK1d.9$l1.933@news-west.eli.net...
>
> 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.
Reply by John_H●September 14, 20042004-09-14
"Robert Sefton" <rsefton@abc.net> wrote in message
news:2qott4F12cbadU1@uni-berlin.de...
[snip]
> 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
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.
Reply by Robert Sefton●September 14, 20042004-09-14
"Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com> wrote in message
news:ci7b93$9rd1@cliff.xsj.xilinx.com...
>
> 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.
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)
> 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.
> http://www.xilinx.com/bvdocs/publications/ds099-3.pdf
>
> 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
>
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.
> 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.
>
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
Reply by Steven K. Knapp●September 14, 20042004-09-14
"Robert Sefton" <rsefton@abc.net> wrote in message
news:2qn4qtF111ef9U1@uni-berlin.de...
> Can someone explain this to me?
>
> Here's the LVTTL I/O timing for Virtex-2 -4 and Spartan-3 -4 (Fast 12mA
> drive for the outputs):
>
> Virtex-2 Spartan-3
> -------- ----------
> TIOPI 0.88ns 2.15ns (pad to IOB .I output)
> TIOOP 1.74ns 0.48ns (IOB ,O input to pad)
>
> According to these numbers the Spartan-3 input buffer got 1.27ns slower
and
> the output buffer got 1.26ns faster. Is this possible?
>
> I have a Virtex-2 1000 design that fits perfectly in a Spartan-3 1000, but
I
> just routed it and got a ton of input path timing errors. So much for
saving
> $125 per chip with S3.
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.
http://www.xilinx.com/bvdocs/publications/ds099-3.pdf
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
http://www.xilinx.com/spartan3
---------------------------------
Spartan-3: Make it Your ASIC
Reply by Robert Sefton●September 14, 20042004-09-14
"Channing Wen" <channing@pldsupport.com> wrote in message
news:ci7a1g$1o0i$1@mail.cn99.com...
> 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.
>
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
Reply by Channing Wen●September 14, 20042004-09-14
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" <rsefton@abc.net> д���ʼ�
news:2qn4qtF111ef9U1@uni-berlin.de...
> Can someone explain this to me?
>
> Here's the LVTTL I/O timing for Virtex-2 -4 and Spartan-3 -4 (Fast 12mA
> drive for the outputs):
>
> Virtex-2 Spartan-3
> -------- ----------
> TIOPI 0.88ns 2.15ns (pad to IOB .I output)
> TIOOP 1.74ns 0.48ns (IOB ,O input to pad)
>
> According to these numbers the Spartan-3 input buffer got 1.27ns slower
and
> the output buffer got 1.26ns faster. Is this possible?
>
> I have a Virtex-2 1000 design that fits perfectly in a Spartan-3 1000, but
I
> just routed it and got a ton of input path timing errors. So much for
saving
> $125 per chip with S3.
>
> Thanks,
> Rob
> (email is bogus, please reply to group)
>
>
Reply by Robert Sefton●September 14, 20042004-09-14
"John_H" <johnhandwork@mail.com> wrote in message
news:wnE1d.2$l1.691@news-west.eli.net...
>
> 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
Reply by John_H●September 14, 20042004-09-14
"Robert Sefton" <rsefton@abc.net> wrote in message
news:2qn4qtF111ef9U1@uni-berlin.de...
> Can someone explain this to me?
>
> Here's the LVTTL I/O timing for Virtex-2 -4 and Spartan-3 -4 (Fast 12mA
> drive for the outputs):
>
> Virtex-2 Spartan-3
> -------- ----------
> TIOPI 0.88ns 2.15ns (pad to IOB .I output)
> TIOOP 1.74ns 0.48ns (IOB ,O input to pad)
>
> According to these numbers the Spartan-3 input buffer got 1.27ns slower
and
> the output buffer got 1.26ns faster. Is this possible?
>
> I have a Virtex-2 1000 design that fits perfectly in a Spartan-3 1000, but
I
> just routed it and got a ton of input path timing errors. So much for
saving
> $125 per chip with S3.
>
> Thanks,
> Rob
> (email is bogus, please reply to group)
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.
Reply by Robert Sefton●September 13, 20042004-09-13
Can someone explain this to me?
Here's the LVTTL I/O timing for Virtex-2 -4 and Spartan-3 -4 (Fast 12mA
drive for the outputs):
Virtex-2 Spartan-3
-------- ----------
TIOPI 0.88ns 2.15ns (pad to IOB .I output)
TIOOP 1.74ns 0.48ns (IOB ,O input to pad)
According to these numbers the Spartan-3 input buffer got 1.27ns slower and
the output buffer got 1.26ns faster. Is this possible?
I have a Virtex-2 1000 design that fits perfectly in a Spartan-3 1000, but I
just routed it and got a ton of input path timing errors. So much for saving
$125 per chip with S3.
Thanks,
Rob
(email is bogus, please reply to group)