1. Home
  2. Field-Programmable Gate Arrays
  3. Spartan 3 clock to output tristate timing

Spartan 3 clock to output tristate timing

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? ;^)

Reply to
rickman
Loading thread data ...

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

Reply to
RobJ

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:

Reply to
John_H

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.

Reply to
Symon

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
Reply to
Nico Coesel

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:

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.

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.

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.

Reply to
rickman

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

Reply to
KJ

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.

Reply to
John_H

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.

Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.