Hi there, this problem occures in my work from time to time: I want to start a State-Machine (Transition from Idle-State S000 to State S010) either with a single one-clock-pulse or on the edge (rising or falling) of a signal. But just when I think "Hey, this seems secure!", the state-machine misses the pulse or the edge. Is there some kind of attribute or something to mark an input or a signal of the component as really really really very important to the compiler? I currently work on a project which uses mainly a 125MHz-Clock. some tries here: (The following codes are inside the idle-state of a state-machine.) edge detection (with filter) on input start_in: sig_Start_IN(0) <= Start_IN; sig_Start_IN(1) <= sig_Start_IN(0); sig_Start_IN(2) <= sig_Start_IN(1); sig_Start_IN(3) <= sig_Start_IN(2); if (sig_Start_IN = "0011") then current_state <= S010; elsif (sig_Start_IN = "1111") then current_state <= current_state; elsif (sig_Start_IN = "1100") then current_state <= S000; else current_state <= current_state; end if; edge detection (without filter) on input start_in: sig_Start_IN <= Start_IN; if ((sig_Start_IN = '0') AND (Start_IN = '1')) then current_state <= S010; else current_state <= S000; end if; start by a one-clock-pulse on start_in: if (Start_IN = '1') then current_state <= S010; else current_state <= S000; end if; Is there somewhere a better way defined to securely "see" the pulse ore edge? Why does the process sometimes skip a pulse or an edge?

assuming start_IN is fully synchronous to your 125MHz clock, then your problems are problems with your design, not the fact it is being "missed". Logic never misses anything. If startIN is not fully synchronous, then you may be getting some meta-stable values on sig_start_in(0) or bouncing when you shift it into your shift register (so you dont get a clean "0011"). I suggest synchronising the signal first.

OK, this is an information I dind't give you: The Start_IN-Signal is generated by an other core, which uses the exactly same 125MHz clock like this component. Normally for clock crossing I use a kind of handshaking: Core 1: Set Start_IN to '1'. -> Core 2: Set Started_OUT to '1' to indicate the Core is started. -> Core 1: Checks if Core 2 is started and sets Start_IN-Signal to '0'. -> Core 2: Sets Started_OUT to '0' if it's done with its work. This works very well, but I can not use this every time. So you can call me a liar, but you can not call my oszilloscope a liar. I see that there is a synchronous Start_IN-Pulse attached to the correct clock-edge but the next core (on the same clock) doesn't see it. I know it's strange, but it happens from time to time.

if its from another core inside the same FPGA on the same clock, then I suggest there is a problem with the statemachine logic - its not that it is "not seeing it", there is a bug in your code - either this block or the other one.

I can't agree with you because the core normally starts ery well, except for about 1 out of 100 to 1000 tries. This could be caused by a clock-glitch, but they are on the same clock, so there can be no glitch. If my state-machine is kind of messed up, wouldn't this cause much more errors? Besides, I've already checked if the state-machine is in an other state than the idle-state when the Start_IN comes. -It isn't. My cores process a message from outside the FPGA. The outside "Logic" (Processor) sends one message and the waits for the result (answer-message) before sending the next message. If the processor is done receiving the answer, every core in the FPGA is already in idle-state. So I assume the state-machines are working well. Except that it can occure, that one of the cores seems to "miss" its start-signal and so the message is lost.

you assume - how do you know? do you have a full verification testbench? have you got one that tries to do bad things in bad states? If everything is on the same clock - then the only answer is that its a code bug. Simple as that.

Altera_Forum

Honored Contributor

10 years ago

Securely start a State-Machine with pulses or edges

Hi there,

this problem occures in my work from time to time:

I want to start a State-Machine (Transition from Idle-State S000 to State S010) either with a single one-clock-pulse or on the edge (rising or falling) of a signal.

But just when I think "Hey, this seems secure!", the state-machine misses the pulse or the edge.

Is there some kind of attribute or something to mark an input or a signal of the component as really really really very important to the compiler?

I currently work on a project which uses mainly a 125MHz-Clock.

some tries here:

(The following codes are inside the idle-state of a state-machine.)

edge detection (with filter) on input start_in:

   
   sig_Start_IN(0)            <= Start_IN;
   sig_Start_IN(1)            <= sig_Start_IN(0);
   sig_Start_IN(2)            <= sig_Start_IN(1);
   sig_Start_IN(3)            <= sig_Start_IN(2);
                        
   if (sig_Start_IN = "0011") then
      current_state             <= S010; 
   elsif (sig_Start_IN = "1111") then
      current_state             <= current_state;   
   elsif (sig_Start_IN = "1100") then
      current_state             <= S000; 
   else
      current_state             <= current_state;   
   end if;

edge detection (without filter) on input start_in:

   
   sig_Start_IN            <= Start_IN;
                        
   if ((sig_Start_IN = '0') AND (Start_IN = '1')) then
      current_state             <= S010; 
   else
      current_state             <= S000;  
   end if;

start by a one-clock-pulse on start_in:

                           
   if (Start_IN = '1') then
      current_state             <= S010; 
   else
      current_state             <= S000;  
   end if;

Is there somewhere a better way defined to securely "see" the pulse ore edge? Why does the process sometimes skip a pulse or an edge?

20 Replies

Altera_Forum
Honored Contributor
10 years ago
assuming start_IN is fully synchronous to your 125MHz clock, then your problems are problems with your design, not the fact it is being "missed". Logic never misses anything.
If startIN is not fully synchronous, then you may be getting some meta-stable values on sig_start_in(0) or bouncing when you shift it into your shift register (so you dont get a clean "0011"). I suggest synchronising the signal first.
Altera_Forum
Honored Contributor
10 years ago
OK, this is an information I dind't give you:
The Start_IN-Signal is generated by an other core, which uses the exactly same 125MHz clock like this component.

Normally for clock crossing I use a kind of handshaking:
Core 1: Set Start_IN to '1'.
-> Core 2: Set Started_OUT to '1' to indicate the Core is started.
-> Core 1: Checks if Core 2 is started and sets Start_IN-Signal to '0'.
-> Core 2: Sets Started_OUT to '0' if it's done with its work.
This works very well, but I can not use this every time.

So you can call me a liar, but you can not call my oszilloscope a liar. I see that there is a synchronous Start_IN-Pulse attached to the correct clock-edge but the next core (on the same clock) doesn't see it.
I know it's strange, but it happens from time to time.
Altera_Forum
Honored Contributor
10 years ago
if its from another core inside the same FPGA on the same clock, then I suggest there is a problem with the statemachine logic - its not that it is "not seeing it", there is a bug in your code - either this block or the other one.
Altera_Forum
Honored Contributor
10 years ago
I can't agree with you because the core normally starts ery well, except for about 1 out of 100 to 1000 tries. This could be caused by a clock-glitch, but they are on the same clock, so there can be no glitch.
If my state-machine is kind of messed up, wouldn't this cause much more errors?
Besides, I've already checked if the state-machine is in an other state than the idle-state when the Start_IN comes. -It isn't.
My cores process a message from outside the FPGA. The outside "Logic" (Processor) sends one message and the waits for the result (answer-message) before sending the next message. If the processor is done receiving the answer, every core in the FPGA is already in idle-state. So I assume the state-machines are working well.

Except that it can occure, that one of the cores seems to "miss" its start-signal and so the message is lost.
Altera_Forum
Honored Contributor
10 years ago
you assume - how do you know?
do you have a full verification testbench? have you got one that tries to do bad things in bad states?
If everything is on the same clock - then the only answer is that its a code bug. Simple as that.
Altera_Forum
Honored Contributor
10 years ago
is your input signal Start_in synchronised to clock?
Altera_Forum
Honored Contributor
10 years ago
I assume it because I made a extra logic which gives me a trigger, when the situation occurs.
This trigger plus a signal indicating the state of the core is routed out using LAI.
I see, when the trigger occurs, the state was 0 (for several clocks) and stays 0 (for several clocks). Now tell me is it in a bad state? Does the core start but doesn't tell me it by keeping the state-indication low?
Altera_Forum
Honored Contributor
10 years ago
Hi kaz,
yes it is. I already mentioned it above.
Altera_Forum
Honored Contributor
10 years ago
--- Quote Start ---
Hi kaz,
yes it is. I already mentioned it above.
--- Quote End ---

I meant do you use two stage synchroniser on start_in e.g.

on clock edge:
start_1d <= start_in;
start_2d <=start_1d;

then use start_2d as input to state machine(not start_1d, nor start_in)
and make sure start_in is of enough duration to be sampled
Altera_Forum
Honored Contributor
10 years ago
This is something I normally don't use. But I think my filtered edge-detection is somehow similar to that.
The problem is between two cores inside the FPGA. Both cores are on the same clock and are working on the same edge (falling_edge).
So I think the signal must already be synchronized.

Forum Discussion

Securely start a State-Machine with pulses or edges

20 Replies

Recent Discussions

AGI027 Dev Kit example build takes a long time

Quartus Prime only loads in admin mode

License issue

Perpetual license Quartus II doesn't allow to build Cyclone V devices anymore.

Warning at Standard 25.1 by Arria 10