Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorSecurely 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;
sig_Start_IN <= Start_IN;
if ((sig_Start_IN = '0') AND (Start_IN = '1')) then
current_state <= S010;
else
current_state <= S000;
end if;
if (Start_IN = '1') then
current_state <= S010;
else
current_state <= S000;
end if;
20 Replies
Altera_Forumassuming 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
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
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
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
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
is your input signal Start_in synchronised to clock?
- Altera_Forum
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
Hi kaz,
yes it is. I already mentioned it above. - Altera_Forum--- 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
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.
