Spartan 3 clock to output tristate timing

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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 sheet since it is the time from a
clock input through an IOB FF that controls the tristate buffer.  When
I checked the data sheet 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 sheet 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 sheet 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?  ;^)


Re: Spartan 3 clock to output tristate timing
First of all, calm down! Next, it's not clear from your post what the
interface timing requirements are. Does the FPGA terminate the bus cycles or
is the cycle timing fixed (either hard-wired or programmed in the DSP)?
Regardless, there are only a few critical timing parameters on an interface
like this. On write cycles the FPGA has to latch the write data before it
goes away, and on read cycles it has to present valid data to the DSP when
the DSP is latching it, and it has to get off the bus before another device
tries to drive it.

On write cycles I usually try to detect the start of the write cycle (e.g.,
falling edge of cs/ with the rd_wr/ line low), synchronize it, and turn it
into a 1-cycle pulse used as a clock enable to latch the write data. The
only analysis needed is to make sure the write data is still valid at the
latching flip-flops when the 1-cycle pulse is asserted under all possible
timing circumstances. And you have to know how to generate that pulse
correctly.

On reads, I don't understand the obsession with an exact number for the OBUF
turn-off time. Personally I wouldn't even do that synchronously. I would
just use the cs/ from the DSP directly as the oe/ for the OBUFs (qualified,
of course, so that the FPGA only drives the bus during read cycles). Making
that path combinational makes the timing contraints easier, and the static
timing report will indicate clearly for each re-route if you made the
constraint or not. All you need is a max pad-to-pad delay such that the FPGA
quits driving within ??ns of the deassertion of cs/. The tools will take
into account the worst-case OBUF turn-off time. The timing analysis and
constraints get more complicated with an async bus if you generate a clocked
oe/.

As the board designer you should be telling the FPGA group the interface
timing they have to meet, so what you're doing sounds like the tail wagging
the dog anyway. You give them numbers and they tell you whether or not they
can meet them. I've seen you post before about these "wars" at work. Sounds
like a bunch of b.s. turf wars to me. Do yourself a favor and move on.

Rob

Quoted text here. Click to load it



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 sheet" 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 Sheet" 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:
Quoted text here. Click to load it

Re: Spartan 3 clock to output tristate timing
Hi Rick,
I agree with Rob, it sounds as though the FPGA supervisor should be asking
you what to put in the UCF file. And it should be something involving
'OFFSET'. In between browsing monster.com, have a look in the Xilinx
constraints guide and read up on the OFFSET constraint. I think it's what
you're looking for.
Yours &c, Syms.



Re: Spartan 3 clock to output tristate timing

Quoted text here. Click to load it

Can't you shove the whole problem upwards? And see what is falling
down again? It seems to me you'll need to know how the FPGA's IOBs are
used in order to know what timing to expect.

However, based on your statement that the clock period is approx 10ns,
they must have used the flipflops inside the IOB. Each IOB has 6
flipflops. 2 to control the output enable, 2 to control the output and
2 to capture the input. The reason why there are 2 flipflops for each
function is to be able to use the IOB at double datarate (DDR). The
flipflops can be programmed so that one will act on the rising edges
and the other one will act on the falling edges.

The timing path from these flipflops to the actual pin is well
documented. However, you'll still need to know whether they switched
IOB_DELAY on or off for the input path.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Re: Spartan 3 clock to output tristate timing
Thanks to all who posted.  I decided to chill out and just go passive
on this.  I have been butting heads a lot and have won every fight on
the facts.  But I am just too sick of this.  So I am doing a timing
analysis which will either end up specifying what the FPGA needs to
meet (I will have to dig into the VHDL to understand the design) or I
will just leave the relevant holes and explain to the superiors that
this is the info I am not getting.  I will need to dig into the design
either way to make sure I understand which timing parameters really are
an issue and which are not.  Some of the input setup times *could* be
an issue depending on whether they are latching them or not.

For now I have analyzed the timing to the memory chip and believe it or
not, there is a small bug!  The timing spec on the DSP is not really
written correctly for an async interface.  All the timing is relative
to the internal clock, so you have to add a couple of parameters to get
the timing between the strobe and the setup/hold times on the data.
Turns out the strobe can go away 2 ns before the clock edge that
latches the read data. So the memory chip has to have a 2 ns hold time
which it doesn't have.  I don't think this will be a problem, but it
does not meet formal timing analysis.


Nico Coesel wrote:
Quoted text here. Click to load it

I originally tried this, but management is very weak.  I went around
for two weeks on an issue of a capacitor with the software guy.  The
project manager kept taking his side even after I proved him wrong.
The software guy came back with bogus test data and it was only after I
showed the manager that the data was not just two different value caps,
but two different boards!  So management is not just weak, but also
poorly informed (read that as too stupid to know when they are being
mislead).

We have some good engineers and we have some "political" engineers who
think they need to spend their time making themselves "look" good
rather than "doing" good.  I can't seem to figure out how to do my job
correctly without having problems from some of these types.


Quoted text here. Click to load it

I can't say exactly what they did.  The interface is not synchronous.
The DSP specs the timing on the interface relative to the CLKOUT which
is a low voltage clock at the CPU speed.  The clock they are using is
CLKMEM which is not used in the spec for the async memory interface.
It is not the same speed or the same delay.  So the control signals are
in reality asynch to the clock.  The FPGA treats them as asynch and
goes through two registers for metastability reduction... at least that
is what I am told.

Quoted text here. Click to load it

I could not find this documentation for the tristate path.  The data
sheet gives specs on timing for the path from the clock input pin to
the output pin using the IOB FF that clocks the data, but no such
similar spec exists from the clock input pin to the output pin going
tristate when using the IOB tristate FF.  I will check the design
tomorrow and see if that is what the design uses.  Even so, I will have
to get the delay from the tools since it is not in the data sheet.


Re: Spartan 3 clock to output tristate timing
A possibly simple test might be to write a simple testbench model to model
the DSP to write and read back some registers.  During a write cycle keep
the data bus unknown until the latest possible time that the spec says
before the data will be valid and then also make it unknown at precisely the
earliest time that the spec for the part says that the bus starts going
tri-state or otherwise unknown.  Do the same for the address bus relative to
the read/write controls.

Since the spec doesn't reference timing relative to the clock that the FPGA
is using than have the model start and end cycles at various points relative
to the clock cycle (say check every 1 or 2 ns throughout the entire 10 ns
clock period).

If all the registers read back correctly it doesn't say that all the timing
works out but at least it's not totally out to lunch ('someone' would still
need to do the timing analysis).  But if anything does read back with
unknowns than it says that there definitely is a problem and you should be
able to punt it back to the FPGA guys and say "Here is a model of the bus
that meets the spec but when connected to your design it fails".

This all assumes that the bus model is a relatively simple one (since I'm
not actually familiar with the TMS320VC5510 itself).

KJ



Re: Spartan 3 clock to output tristate timing
<snip>

Quoted text here. Click to load it

Rather than delving deep into the design, perhaps Timing Analyzer can
supply a lot of information.  If the I/O are unconstrained, the
Analyze/Against Auto Generated Design Constraints will give you the
input and output timing.  These can show the full combinatorial paths
(or lack thereof) between the pads and registers.  The Data Sheet
section of the report will also give you Tcko, Tsu, and Th for the
design.  You may even find the IOBDELAY values here rather than having
to go to the pad report.

Re: Spartan 3 clock to output tristate timing
I dug into the design and found that there are *NO* registers in the
path from the RD signal to the output tristate control.  So I was right
that either I am being deliberately misled or the guy is incompetent.

I also found that in the last week since I have been saying that they
need a timing spec on this path, it has appeared in the UCF file.
Surprise, surprise.

Now I just have to finish up my analysis and figure out what other
timing specs they are missing.  It is likely that none of the others
will be any real issue since they will be in the 10s of ns and even
without the timing constraint would be very unlikely to be any problem.


Thanks for the support.  I don't get that from any of the managers and
it can be difficult to work in a job that is so distasteful.  I will be
looking for something new around here very shortly.


Site Timeline