FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 11-15-2005, 01:14 PM
Guest
 
Posts: n/a
Default 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 ?

Reply With Quote
  #2 (permalink)  
Old 11-15-2005, 01:38 PM
Gabor
Guest
 
Posts: n/a
Default Re: Rise time/fall time for Spartan3 clock inputs


[email protected] 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).

Reply With Quote
  #3 (permalink)  
Old 11-15-2005, 02:22 PM
Guest
 
Posts: n/a
Default Re: Rise time/fall time for Spartan3 clock inputs

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.

Reply With Quote
  #4 (permalink)  
Old 11-15-2005, 02:40 PM
John Adair
Guest
 
Posts: n/a
Default Re: Rise time/fall time for Spartan3 clock inputs

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


<[email protected]> wrote in message
news:[email protected] oups.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 ?
>



Reply With Quote
  #5 (permalink)  
Old 11-15-2005, 03:33 PM
Peter Alfke
Guest
 
Posts: n/a
Default Re: Rise time/fall time for Spartan3 clock inputs

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.

Reply With Quote
  #6 (permalink)  
Old 11-16-2005, 11:35 AM
Guest
 
Posts: n/a
Default Re: Rise time/fall time for Spartan3 clock inputs

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.

Reply With Quote
  #7 (permalink)  
Old 11-16-2005, 11:48 AM
Guest
 
Posts: n/a
Default Re: Rise time/fall time for Spartan3 clock inputs

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

Reply With Quote
  #8 (permalink)  
Old 11-16-2005, 04:34 PM
Peter Alfke
Guest
 
Posts: n/a
Default Re: Rise time/fall time for Spartan3 clock inputs

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

Reply With Quote
  #9 (permalink)  
Old 11-16-2005, 06:44 PM
Jim Granville
Guest
 
Posts: n/a
Default Re: Rise time/fall time for Spartan3 clock inputs

[email protected] 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

Reply With Quote
  #10 (permalink)  
Old 11-17-2005, 03:54 PM
johnp
Guest
 
Posts: n/a
Default Re: Rise time/fall time for Spartan3 clock inputs

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

Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
When writing testbench, do I need to add some time for the inputs? Ray Verilog 3 11-22-2007 08:46 AM
Using capacitor to slow the rise time. Brijesh FPGA 17 05-11-2005 11:07 PM
Converting High Rise Time clock to Low Rise time clock - Chellenge! Drew FPGA 6 07-23-2004 10:57 AM
[Spartan-IIE] Exeeding max. input rise/fall time of signals ?? Markus Meng FPGA 7 12-30-2003 01:59 AM


All times are GMT +1. The time now is 07:29 PM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved