Rise time/fall time for Spartan3 clock inputs

Hi there,

I am encountering a strange problem in a state machine using a 33M3333
clock in a Spartan3 FPGA.

>From time to time, the state machine misbehaves. The problem has at
first been attributed to a relatively poor waveshape of the clock line.
A load of 100ohms/10pF in series to ground has been put at the end of
the line, improving a bit the problem.

However, the problem is still there. I am now suspecting a too slow
rise time or fall time of the clock input to the FPGA, that could let a
noise go through around the threshold point. This idea is backed up by
the fact that extra edges seem to be added. By the way, I am unable to
find in the Xilinx data sheet any value for the RT and FT of the
clocks.

I would have liked to be able to force input hysteresis on the clock
signals, but I think it is not possible nor maybe desirable.


Any idea ?

abeaujean@gillam-fei.be wrote:
> Hi there,
>
> I am encountering a strange problem in a state machine using a 33M3333
> clock in a Spartan3 FPGA.
>
> >From time to time, the state machine misbehaves. The problem has at
> first been attributed to a relatively poor waveshape of the clock line.
> A load of 100ohms/10pF in series to ground has been put at the end of
> the line, improving a bit the problem.
>
> However, the problem is still there. I am now suspecting a too slow
> rise time or fall time of the clock input to the FPGA, that could let a
> noise go through around the threshold point. This idea is backed up by
> the fact that extra edges seem to be added. By the way, I am unable to
> find in the Xilinx data sheet any value for the RT and FT of the
> clocks.
>
> I would have liked to be able to force input hysteresis on the clock
> signals, but I think it is not possible nor maybe desirable.
>
>
> Any idea ?

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.
http://www.enterpoint.co.uk


<abeaujean@gillam-fei.be> wrote in message 
news:1132060488.081334.147800@f14g2000cwb.googlegroups.com...
> Hi there,
>
> I am encountering a strange problem in a state machine using a 33M3333
> clock in a Spartan3 FPGA.
>
>>From time to time, the state machine misbehaves. The problem has at
> first been attributed to a relatively poor waveshape of the clock line.
> A load of 100ohms/10pF in series to ground has been put at the end of
> the line, improving a bit the problem.
>
> However, the problem is still there. I am now suspecting a too slow
> rise time or fall time of the clock input to the FPGA, that could let a
> noise go through around the threshold point. This idea is backed up by
> the fact that extra edges seem to be added. By the way, I am unable to
> find in the Xilinx data sheet any value for the RT and FT of the
> clocks.
>
> I would have liked to be able to force input hysteresis on the clock
> signals, but I think it is not possible nor maybe desirable.
>
>
> Any idea ?
> 

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

abeaujean@gillam-fei.be wrote:

> 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.

  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