slow edge on clk inputs

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)

Reply to
Morten Leikvoll
Loading thread data ...

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

Reply to
glen herrmannsfeldt

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.
 Click to see the full signature
Reply to
Tim Wescott

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

Reply to
Morten Leikvoll

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.
 Click to see the full signature
Reply to
Tim Wescott

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

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

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.