Re: Spartan 3 clock to output tristate timing

Rickman - sorry you have to deal with such annoyances. I'm a stickler for well defined I/O constraints so I see shoddy engineering on the part of the FPGA group, but that's me.

The "data ***" is probably not what you think.

The Timing Analyzer within the Xilinx tool suite has a section at the end that summarizes data input setup and hold times as well as clock-to-out for all the various signals. I believe the clock and clock edge are included as well. While I specify my PCI numbers with one value in my constraints for Tcko and another for the turnaround cycle - Toff - it's the longest value that ends up in the "Data ***" section of the Timing Analyzer report which would be the Ton/Toff.

It's probably the timing for one *iteration* of the FPGA but worst case values, not measured. As long as the design doesn't budge, great. Otherwise, the next rev could move the unconstrained I/O around one direction or another.


rickman wrote:
I've got a problem at work where the FPGA group is at war with the
hardware group and I am sick and tired of ducking the punches. I
designed the board although there was not a lot of original design. I
was told what main chips to use since they had done a similar design
before. So I pretty much copied the design which uses an XC3S400-4 and
a TMS320VC5510 with a combined SRAM/Flash chip. I am being asked for a
proper bus timing analysis and I need the data on the FPGA. That is
where the punches start flying!

The bus is asynchronous, but for whatever reason, the FPGA designers
originally chose to use the CLKOUT from the DSP as the interface clock
rather than the other clock being provided to the FPGA. This may be
because although the DSP memory interface is designed to work with
async bus devices like RAMs and Flash, all the timing parameters are
WRT the DSP CLKOUT. However, the timings are such that you can't use
CLKOUT to clock in the signals in a synchronous manner. The signal
transitions are on the rising clock edge +- a few ns. The clock is
about 10 ns period. When it is matched to the FPGA IO timing I don't
think you can meet the setup and hold times from what I have seen and I
am told the design double clocks all inputs to remove metastability.

To do the timing analysis, I have asked the FPGA group to provide
timing data on the FPGA. I expected them to come back with the data
they are using for timing constraints. Instead they basically told me
"you don't need no stinkin' timing data". They seem to feel that
because we are using lots of clock cycles on the bus cycle, the
detailed timing is not important. We have gone around a few times and
I continue to assert that there are a few parameters that I need from
the FPGA design such as the time from the RD_N signal rising to the
data out going high-Z. After half a dozen emails, I finally got an
answer of 16 ns. But I realized that I can't believe this since it was
presented as a measurement from one iteration of the design. I looked
at the timing constraints and they don't have any other than the
clocks!

Today in a meeting the FPGA supervisor told me that this timing
parameter was from the Spartan data *** since it is the time from a
clock input through an IOB FF that controls the tristate buffer. When
I checked the data *** I can't find such a timing parameter and the
data I do find says the time in the IOB itself is less than 1 ns under
the given conditions.

"Time from the active transition at the OTCLK input of the Three-state
Flip-Flop (TFF) to when the Output pin enters the high-impedance state
(LVCMOS25, 12mA output drive, Fast slew rate) All 0.28 0.74 0.85 ns"

Our interface is 3.3 volts and the worst case adjustment I can find is
"LVTTL Slow 2 mA 2.76 7.27 8.36 ns". So we still end up at well less
than 10 ns without counting the clock delay. They seem to be using the
DCMs, but I can't say how they have them set up. Even so, with the DCM
the clock input to output pin (through an IOB FF) is under 2 ns and
even without the DCM it is under 5 ns. So giving the most leeway I
possibly can I still come up with less than 15 ns for clock to output
high-Z compared to 16 ns.

That leaves these possibilities...
1) I don't know what I am doing and the above rational is full of
holes.
2) This supervisor is incompetent.
3) This supervisor is deliberately misleading us to cover someone
else's incompetence.
4) ???

I am getting so tired of having to sift through the BS that the other
departments are feeding me that I am close to quitting. But before I
do, I want to get to the bottom of this. Have I completely
misunderstood how the tristate outputs work somehow? Is there a number
in the data *** that justifies the 16 ns number somewhere?

In reality I expect this signal path is going through logic inside the
chip and is not being clocked in the IOB. The 16 ns number most likely
came from a measurement of one iteration of the chip. I may take the
time to dig into the design files at some point. But first I would
just like to get a sanity check on the idea that the 16 ns number came
from the data *** as a path from the clock input to an output going
high-Z.

So who is nuts, me or the other guy??? (or is it both? ;^)
.

Loading