Avoid action on very short peak on input signal (Xilinx Spar

M

Martin Maurer

Guest
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
 
i try to latch external data (AD7...AD0) into
an internal FPGA register on the rising edge of an external signal
[...] when i want to ignore all pulses below 50 ns
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
 
Martin Maurer wrote:

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

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 ?
This would distort the good edges
along with the glitch.

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

4) Or must i add an external clock only for this ?
Not only for this.
Use synchronous design for everything.

E.g. with a counter,
only when certain count value is reached, the line is valid ?
That's more like it.

-- Mike Treseler
 
Martin Maurer wrote:
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 ?
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 ?


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

3) Is there any method to do it FPGA internal ? Don't want to add external
hardware... read of bad ways with delay lines....
This is possible, but risky, so should only be a path of last resort...

i think i read somewhere
of reserved words like "SKEW", "SLOW", "FAST". Do they help me ? Should i go
in this direction ?
No, these are PIN features, not noise filters.

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 ?
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
 
Hi,

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

Welcome to EDABoard.com

Sponsor

Back
Top