Avoid action on very short peak on input signal (Xilinx Spartan 2)

Hello,

i have the following problem: i try to latch external data (AD7...AD0) into an internal FPGA register on the rising edge of an external signal (address latch enable = ALE). Generally this seems to work, but i often have situations where a very short peak is on the signal ALE. Peak is around 20 ns (can measure them with a scope), whereas my normal signal is around 12 us (600 times longer).

What is a common way of handling this ?

1) I read on some webpages that there is a VHDL mechanism called delay_mechanism (with "reject" or "after" statement). I tried it on target FPGA, but it seems not to work. Could it be that this works only for simulation ?

2) I found a lot of articles about doing an RC at the input side. How do i calculate the values of R and C e.g. when i want to ignore all pulses below

50 ns ?

3) Is there any method to do it FPGA internal ? Don't want to add external hardware... read of bad ways with delay lines.... i think i read somewhere of reserved words like "SKEW", "SLOW", "FAST". Do they help me ? Should i go in this direction ?

4) Or must i add an external clock only for this ? E.g. with a counter, only when certain count value is reached, the line is valid ?

Regards,

Martin

Reply to
Martin Maurer
Loading thread data ...

I don't think that there are good solutions with delays ...

I assume you have a clock in your FPGA - almost any speed fits ... I can't imagine an FPGA exclusively filled with async logic.. there is really nothing?

the common way (with clock) could be something like:

synchronize your ALE signal, then register it once more... AND the synchronized and delayed signal ... (call it reg_en) describe your register as clocked with your clock and reg_en as clock_enable ...

- the resulting behaviour is slightly different - your data gets captured after some delay ... if this is a problem: capture your data with ALE and register it to the next stage with clk and reg_en

- you get some delay until your data is available - but as you only know whether the data is valid after the 50ns you need to wait at least 50ns after rising ALE ...

- if your clock is faster than 20MHz you need more delays of the synced ALE

- you can produce delays in your fpga without clocks (by direct manual placement in the fpga) but this gives you only very few ns (far below 50ns)

bye, Michael

Reply to
Michael Schöberl

Yes.

This would distort the good edges along with the glitch.

No.

Not only for this. Use synchronous design for everything.

That's more like it.

-- Mike Treseler

Reply to
Mike Treseler

Best solution is to remove the glitch :) That may not always be possible - if not, are you confident you know what it causing it, and thus its MAX width when illegal ?

The RC product, or timeconstant of 3-5x Glitch get you in the ball-park of some-attenutaion. You need to confirm comfortably dropping it below the threshold, but also avoid going below the FPGAs min input slew rate, as well as not distorting the good edge outside valid data times....

An external RC plus a 1G14 or 1G17 SCHMITT tiny logic gate is probably the best solution, as you can probe the filtered, squared output to verify data windows.

This is possible, but risky, so should only be a path of last resort...

No, these are PIN features, not noise filters.

Depends on if ALE is async with this.

12us is relatively slow, so if you have a MHz region clock already in the FPGA, you can always make a digital filter from a simple saturating counter. You need to ensure the sampling instant is comfortably clear of both DATA invalid edges.

-jg

Reply to
Jim Granville

Hi,

Isn't ALE supposed to be used with an actual latch, like a

74LS373, where you'd tie ALE to the G (enable) input? There are latch primitives in some FPGAs if you need to use them.

In any event, you said you are using rising edge triggered flip flops with ALE as the clock. Are you sure the "data" is valid at the rising edge of ALE? If I were NOT using latches, and instead elected to use flip flops, I'd clock the "data" on the negative edge of ALE.

Eric

Reply to
Eric Crabill

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.