Rise time/fall time for Spartan3 clock inputs

When you say you put a load at the end of the line, are you saying the end of the line is not at the Spartan? Were you able to put a scope at the pin of the FPGA? If the clock driver doesn't have a low enough output impedance and the Spartan is not at the end of the line, you could be seeing a stepped transition where the clock actually sits in the threshold region for a while until the reflected wave brings the voltage up.

Since your clock seems to be slow, I don't see why hysteresis would be a bad idea, unless the data you capture externally has a small setup/hold window. In the case of the stepped transition, hysteresis would delay the clock edges until the signal reflection. The extra delay from this depends on the length of trace between the Spartan and the end of the line.

The best fix of course would be to route the clock only point to point, using zero delay buffers if necessary to fan out. Then a proper clock signal would be achievable using only series termination at the source (or buffer).

Thanks for the prompt answer.

The input pin of the FPGA is actually very near to the end of the line, where the R/C load sits.

No, I have not been able yet to look at the waveform "near to the pin" (the configuration is not easily accessible).

OUPS. Glad you talk about the "driver" chip anyway. Reviewing my parts list (and not only the schematics that do not clearly show that) makes me realize that it is a 74LVC2244 (with 30 ohms series termination in it). That should not look too good with the RC termination.

SO. I shall first try a 74LVC244A instead and see what happens.

By the way, I see no way to force an input hysteresis in a Spartan3 FPGA.

Key to a clean clock either (1) Using termination either series at source, or parallel at endpoint (2) Limiting clock edge rate to reduce reflections.

To think sideways you problem sounds very like the classic asyncronous input, or not meeting setup/hold, problem. Are any of you inputs to your state machine asynchronous(or different clock) to the clock used for the state machine?

John Adair Enterpoint Ltd. - Home of Raggedstone. The Cheap Spartan3 Development Board.

100 Ohm + 10 pF in series is not a meaningful termination. R should = the char. impedance, probably 50 Ohm. C should give it a time constant that is longer than a transition time, but shorter than a clock half-period. Make that 10 ns in your case. That means 50 Ohm + 200 pF.

But this assumes that you want to do a parallel termination at the far end. If your driver has a series termination, then you want to keep the far end unterminated, but you then also accept a step function everywhere along the line, except at the far end. If you suspect double-triggering, then just implement a free-running

2-bit counter in the FPGA and look at its outputs. That will indicate double-triggering very clearly.

Peter Alfke, Xilinx Applications.

No. There are no async inputs to my state machine, and only one clock. The problem has been clearly identified as a bad behaviour of PART only of the state machine. That part seems to pickup extra clock edges. I still believe that the problem lies in the shape/reflection/etc.. of the clock. The part of the state machine that fails runs (badly) on itself, no external interaction.

Thanks for the comment.

OK. Thanks for the comments. I made a typing mistake about the value of C. C is actually 100 pF with 100 ohms --> 10 nS. But I fully aggree with you about the characteristic impedance --> R should be more like

50 ohms and C 200 pF. The 100 ohms value was the first approach.

Aggree on all your comments about series or parallel terminations, and

2-bit counter.

I discovered yesterday that the (discrete) driver used for the clock is a 74LVC2244, meaning the presence of an embedded 30 ohms series resistance (OUUPS) in the outputs. Of course, the waveshape at line end with a series termination of 30 ohms at the beginning of the line and a

100ohm/100pF parallel termination at the end must be inadequate, or maybe prone to crosstalk from other lines. I had no chance yet to look at the waveform due to very poor accessibility of the point.

Next step is to swap the 74LVC2244 with a standard 74LVC244 (no series resistance in the outputs), tune the RC termination and watch the result.

Thanks for all the comments.

By the way, was I right saying that there is no way to specify an input hysteresis on the Spartan3 inputs ?

A. Beaujean

You cannot specify the amount of hysteresis. There is "a little bit", but not adjustable. Hysteresis is like most medicines: A little bit is good, but too much is bad.

Peter Alfke, Xilinx

If you have the room, you could build another state-engine, and condition that ones clock, with anti-furr logic : that is, a Set/Reset scheme on the clock, with delay elements to prevent too rapid toggling. Then compare the two state pathways in operation ?

-jg

You mentioned it's hard to look at the clock at the FPGA, but do you have any other FPGA pins that you can get to? Set up a simple toggle flip-flop to drive the pin and look at that. It will show you what the FPGA is seeing.

If you get a nice square wave, the clock is getting in OK. If it isn't a perfect square wave, the input clock is bad. Try using a digital scope with infinite persistance turned on so you see a LOT of history. Else set the triggering to 'trigger on pulse less than N nsec'.

John P