Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronic Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

edge detection on asynch signal

Status
Not open for further replies.

buenos

Advanced Member level 3
Joined
Oct 24, 2005
Messages
954
Helped
40
Reputation
82
Reaction score
21
Trophy points
1,298
Location
Sunnyvale, California, USA
Activity points
9,053
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
Joined
Jul 5, 2009
Messages
147
Helped
21
Reputation
40
Reaction score
17
Trophy points
1,298
Location
Turkey
Activity points
2,043
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
Joined
Nov 5, 2007
Messages
244
Helped
33
Reputation
66
Reaction score
12
Trophy points
1,298
Location
India.
Activity points
2,576
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?
 

kvingle

Full Member level 5
Joined
Nov 5, 2007
Messages
244
Helped
33
Reputation
66
Reaction score
12
Trophy points
1,298
Location
India.
Activity points
2,576
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

Advanced Member level 3
Joined
Oct 24, 2005
Messages
954
Helped
40
Reputation
82
Reaction score
21
Trophy points
1,298
Location
Sunnyvale, California, USA
Activity points
9,053
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
Joined
Jan 22, 2008
Messages
47,854
Helped
14,119
Reputation
28,495
Reaction score
12,800
Trophy points
1,393
Location
Bochum, Germany
Activity points
277,754
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
Joined
Nov 5, 2007
Messages
244
Helped
33
Reputation
66
Reaction score
12
Trophy points
1,298
Location
India.
Activity points
2,576
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
Joined
Jan 6, 2009
Messages
296
Helped
50
Reputation
98
Reaction score
28
Trophy points
1,308
Location
India-Gujarat
Activity points
3,019
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
 

FvM

Super Moderator
Staff member
Joined
Jan 22, 2008
Messages
47,854
Helped
14,119
Reputation
28,495
Reaction score
12,800
Trophy points
1,393
Location
Bochum, Germany
Activity points
277,754
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
Joined
Jan 6, 2009
Messages
296
Helped
50
Reputation
98
Reaction score
28
Trophy points
1,308
Location
India-Gujarat
Activity points
3,019
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.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Top