Continue to Site

edge detection on asynch signal

Status
Not open for further replies.

buenos

detect one rising edge

hi

i want to detect a rising edge on an asynchronous signal, where the detection logic is synchronous.

i did this:

Code:
process (input, clk, reset_n)
begin
if (reset_n='0') then
detected <= '0';
input_previous <= '0';
elsif (clk'event and clk='1') then
input_previous <= input;
if (input='1' and input_previous='0' ) then --rising edge on the input
detected <= '1';
end if;
end if;
end process;

so, this should generate a pulse on the output for 1*T_clk.
sometimes it does not generate the pulse when the input signal has an edge. WHY?

if we generate the input event periodically and count the detection pulses, it seems it misses around 10-15% of them, and its varying.
If i make one more delayed version of the input, and use that (input_previous_previous) in the if-statement condition instead of input_previous, then it does not miss anything. its very strange.
the FPGA is an ACTEL proasic3.

could anyone explain what is going on?

zula

Full Member level 2
i think you can use this code for your problem;

Code:
process (input, clk, reset_n)
begin
if (reset_n='0') then
detected <= '0';

elsif (clk'event and clk='1') then

if (input'EVENT and input = '1' ) then --rising edge on the input
detected <= '1';
else
detected <= '0';
end if;
end if;
end process;

try it

kvingle

Full Member level 5
zula said:
i think you can use this code for your problem;

Code:
process (input, clk, reset_n)
begin
if (reset_n='0') then
detected <= '0';

elsif (clk'event and clk='1') then

if (input'EVENT and input = '1' ) then --rising edge on the input
detected <= '1';
else
detected <= '0';
end if;
end if;
end process;

try it
I doubt above is not synthsizable...
what hardware would allow to detect edge under edge....?

When you were missing your 10/15% detection was your Asyc input asserted for a time less that one clk?

buenos

no, it is much longer than one clk, its about 150 clk long.

kvingle

Full Member level 5
Try this.

Code:
process (input, clk, reset_n)
begin
if (reset_n='0') then
input_previous <= '0';
elsif (clk'event and clk='1') then
input_previous <= input;
end if;
end process;

detected <= input and not (input_previous) ;

buenos

ok
thanks.
why would it be better, and what was the problem with the original solution?
(in first my post i forgot to have an else statement with detected<='0'; but in my design it was there, so that was not the problem)

FvM

Super Moderator
Staff member
It's a classical case of missing synchronisation of asynchronous signals. If the input signal edge coincides with the clock edge, the event may be missed due to logic delay skew. This problem also isn't solved by the code suggested by kvingle. Adding another register level most likely removes the problem.
Code:
  if rising_edge(clk) then
input_sync <= input;
input_prev <= input_sync;
end if;
detected <= input sync and not input_prev;

P.S.: I must confess, that it still happens to me from time to time (in different disguises), although I know it very well.

kvingle

Full Member level 5
Agree.

Async signal in sync domain...A nightmare of digital designers.
A basic double flop synchronizer as suggested above is a good way to minimize this.

shitansh

Full Member level 5
Hi,

you can use FSM also to do this.

I have sucssess fully implemented it on hardware. But in my case i have to detect rising edge of slow clock (Frame Clk 2.25MHz) with in higher clock domain (bitclk= 18*Frame clk = 40.5MHz).

So for my case FrameClk was asynchronous signal in BitClk domain.

But if you have to detect reverse way then you must have to use one of synchronization method along with your logic.

Attached code is in verilogHDL.

wave form is here

--
Shitansh Vaghela

buenos

thanks guys.

is this the case of "metastability" on the first delayed signal?

Yes.

FvM

Super Moderator
Staff member
Although there's a finite likelihood of metastable events in processing of asynchronous signals, the present problem is obviously the much more common case of missing synchronisation and violated setup/hold conditions. It's effectively impossible to watch metastability with 10 or 15% incidence.

In my suggested solution, metastability means that input_sync hasn't settled to a final value after a full clock period. FPGA vendors have data, that allows to calculate the likelihood of this event. Depending on the input signal and clock frequency , it may take hours up to many years for the first occurance. In situations, where even this minimal likelihood is too high, you have to add multiple synchronizer stages, raising the metastability likelihood to a power of n. A second stage may be sufficient to prevent it for the further lifetime of our planet.

shitansh

Full Member level 5
buenos said:
thanks guys.

is this the case of "metastability" on the first delayed signal?

Hi,

in FSM coding for perticular application you can avoid metastability, since cominational block is asynchronous, any change to input signals or Current sate transaction will change Next sate and generate pulse using this and synchronize it to your FSM working clock domai. i.e.Frm_Dtct_Sync signal in my code. This way you need not to bouther about metastability and also never miss any detection pulse(must use synchronouse outpu else there is posiblity of very short pulse that cant detect if you use Frm_Dtct_Async output in my code).

HTH
--
Shitansh Vaghela

Status
Not open for further replies.