Sign in

username:

password:



Not a member?

Search Comp.Arch.FPGA



Search tips

fpga by Keywords

Altera | ASIC | CPLD | Cyclone | DCM | DDR | DSP | Ethernet | ISE | JTAG | Linux | LVDS | Microblaze | ML310 | Modelsim | NIOS | OPB | PCI | Quartus | RocketIO | SDRAM | Spartan | Spartan3 | SRAM | Stratix | Verilog | VHDL | Virtex | Virtex-4 | Virtex-II | Xilinx | XST

Ads

See Also

DSPEmbedded SystemsElectronics

Comp.Arch.FPGA | slow edge on clk inputs

There are 6 messages in this thread.

You are currently looking at messages 0 to 6.

slow edge on clk inputs - Morten Leikvoll - 2012-01-25 09:04:00

Are there any simple practical [fpga internal]
solutions to aviod internal 
"ringing" on slow (edged) clock inputs on fpga's, other than resampling and 
filtering in a different clock domain?
(Using Altera Stratix III atm)





Re: slow edge on clk inputs - glen herrmannsfeldt - 2012-01-25 10:32:00

Morten Leikvoll <m...@yahoo.nospam>
wrote:
> Are there any simple practical [fpga internal] solutions to aviod internal 
> "ringing" on slow (edged) clock inputs on fpga's, other than resampling and

> filtering in a different clock domain?
> (Using Altera Stratix III atm)

Best to keep the slow edge out.

You could connect the clock to a nearby output, with a resistor
(of appropriate size) to the input, to supply a little positive
feedback. (An additional small series resistor if the clock
generator output is too low impedance.)

Even better is to do it before it gets to the clock input.

-- glen

Re: slow edge on clk inputs - Tim Wescott - 2012-01-25 12:24:00

On Wed, 25 Jan 2012 15:32:11 +0000, glen
herrmannsfeldt wrote:

> Morten Leikvoll <m...@yahoo.nospam> wrote:
>> Are there any simple practical [fpga internal] solutions to aviod
>> internal "ringing" on slow (edged) clock inputs on fpga's, other than
>> resampling and filtering in a different clock domain? (Using Altera
>> Stratix III atm)
> 
> Best to keep the slow edge out.
> 
> You could connect the clock to a nearby output, with a resistor (of
> appropriate size) to the input, to supply a little positive feedback.
> (An additional small series resistor if the clock generator output is
> too low impedance.)
> 
> Even better is to do it before it gets to the clock input.

Yup.  One little Schmitt trigger in an SOT-23 (or smaller) package, and 
suddenly your clock is clean (well, cleaner).

Or have you already gotten the board laid out and built, and now you need 
a bandaid?

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.

Re: slow edge on clk inputs - Morten Leikvoll - 2012-01-26 03:41:00

"Tim Wescott" <t...@seemywebsite.com> wrote in message 
news:W...@web-ster.com...
> On Wed, 25 Jan 2012 15:32:11 +0000, glen herrmannsfeldt wrote:
>
>> Morten Leikvoll <m...@yahoo.nospam> wrote:
>>> Are there any simple practical [fpga internal] solutions to aviod
>>> internal "ringing" on slow (edged) clock inputs on fpga's, other
than
>>> resampling and filtering in a different clock domain? (Using Altera
>>> Stratix III atm)
>>
>> Best to keep the slow edge out.
>>
>> You could connect the clock to a nearby output, with a resistor (of
>> appropriate size) to the input, to supply a little positive feedback.
>> (An additional small series resistor if the clock generator output is
>> too low impedance.)
>>
>> Even better is to do it before it gets to the clock input.
>
> Yup.  One little Schmitt trigger in an SOT-23 (or smaller) package, and
> suddenly your clock is clean (well, cleaner).
>
> Or have you already gotten the board laid out and built, and now you need
> a bandaid?

Im really just lazy.. This clock is so slow I can resample it (got a 100Mhz 
available for that), but I wrote and simulated it for direct clk (it's the 
SCL of a i2c bus, and to make the case even worse, its the SCL of a DVI DDC 
bus wich runs on long, often bad quality wires with SDA/SCL crosstalk).
I was kinda hoping for some builtin schmitt trigger attribute that I could 
assign to it.
I'll start on the resampling part right now ;p

Thanks



Re: slow edge on clk inputs - Tim Wescott - 2012-01-26 10:55:00

On Thu, 26 Jan 2012 09:41:46 +0100, Morten
Leikvoll wrote:

> "Tim Wescott" <t...@seemywebsite.com> wrote in message
> news:W...@web-ster.com...
>> On Wed, 25 Jan 2012 15:32:11 +0000, glen herrmannsfeldt wrote:
>>
>>> Morten Leikvoll <m...@yahoo.nospam> wrote:
>>>> Are there any simple practical [fpga internal] solutions to aviod
>>>> internal "ringing" on slow (edged) clock inputs on fpga's,
other than
>>>> resampling and filtering in a different clock domain? (Using Altera
>>>> Stratix III atm)
>>>
>>> Best to keep the slow edge out.
>>>
>>> You could connect the clock to a nearby output, with a resistor (of
>>> appropriate size) to the input, to supply a little positive feedback.
>>> (An additional small series resistor if the clock generator output is
>>> too low impedance.)
>>>
>>> Even better is to do it before it gets to the clock input.
>>
>> Yup.  One little Schmitt trigger in an SOT-23 (or smaller) package, and
>> suddenly your clock is clean (well, cleaner).
>>
>> Or have you already gotten the board laid out and built, and now you
>> need a bandaid?
> 
> Im really just lazy.. This clock is so slow I can resample it (got a
> 100Mhz available for that), but I wrote and simulated it for direct clk
> (it's the SCL of a i2c bus, and to make the case even worse, its the SCL
> of a DVI DDC bus wich runs on long, often bad quality wires with SDA/SCL
> crosstalk). I was kinda hoping for some builtin schmitt trigger
> attribute that I could assign to it.
> I'll start on the resampling part right now ;p

If it's noisy you might want to do more than just resampling it.  
Resample, then make a filter that only transitions if the input has been 
at the new value for N consecutive FPGA clocks (with N chosen empirically 
to pound down the known noise, or maybe better with N chosen to be as 
large as practical).

That way when you get short-term scrud on the line it won't show up as a 
clock transition and mess up your I2C logic.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Re: slow edge on clk inputs - rickman - 2012-01-26 20:02:00

On Jan 26, 3:41 am, "Morten Leikvoll"
<mleik...@yahoo.nospam> wrote:
> "Tim Wescott" <t...@seemywebsite.com> wrote in message
>
> news:W...@web-ster.com...
>
> > On Wed, 25 Jan 2012 15:32:11 +0000, glen herrmannsfeldt wrote:
>
> >> Morten Leikvoll <mleik...@yahoo.nospam> wrote:
> >>> Are there any simple practical [fpga internal] solutions to aviod
> >>> internal "ringing" on slow (edged) clock inputs on fpga's,
other than
> >>> resampling and filtering in a different clock domain? (Using Altera
> >>> Stratix III atm)
>
> >> Best to keep the slow edge out.
>
> >> You could connect the clock to a nearby output, with a resistor (of
> >> appropriate size) to the input, to supply a little positive feedback.
> >> (An additional small series resistor if the clock generator output is
> >> too low impedance.)
>
> >> Even better is to do it before it gets to the clock input.
>
> > Yup.  One little Schmitt trigger in an SOT-23 (or smaller) package, and
> > suddenly your clock is clean (well, cleaner).
>
> > Or have you already gotten the board laid out and built, and now you need
> > a bandaid?
>
> Im really just lazy.. This clock is so slow I can resample it (got a 100Mhz
> available for that), but I wrote and simulated it for direct clk (it's the
> SCL of a i2c bus, and to make the case even worse, its the SCL of a DVI DDC
> bus wich runs on long, often bad quality wires with SDA/SCL crosstalk).
> I was kinda hoping for some builtin schmitt trigger attribute that I could
> assign to it.
> I'll start on the resampling part right now ;p
>
> Thanks

I tend to use a single clock domain in most of my designs.  It is a
nice easy thing to do from many perspectives.  The exceptions include
interfaces like SPI and I2C... <g>

In serial interfaces, especially ones that run at faster clock rates
like SPI I use the clock for the handshake and shift register and then
cross the clock domain using the standard techniques.

I was trying to think how you might make a Schmitt trigger in the
FPGA.  Just using an output with a resistor might not work well
because the FPGA input is fast and the feedback would be slow.  The
positive feedback it would not prevent oscillations from noise for a
few nanoseconds.

One way that might work would add a second input pin and an output pin
with a resistor and a wire.  Some generations back Xilinx parts had a
configurable input delay.  I assume this is available on the part you
are using.  One input gets the delay, the other does not.  The input
without the delay is fed back through the output pin to provide
hysteresis through the resistor.  The input with the delay is the one
used in the internal clock circuit.  Or you might need to use a
function of the two inputs to drive the output to prevent the output
from toggling.  Using the delay this way can prevent the feedback
delay through the chip from interfering with the proper function of
the hysteresis.

I don't know I would ever bother doing this unless I was desperate to
get something working without the sampling, but it has
possibilities.

Rick
______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.