You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If an FSM drives a combinational signal from the whenIsActive block of one of its states, and then transitions to a nested FSM state whose entry state has an onEntry block which also drives the combinational signal, then the outer FSM's statement always wins even if it appears earlier in the file.
In the above FSM, we expect to see io.a and io.b act the same way, since the second driver on io.b (the only one which io.a does not have) is redundant. However, io.b never goes high, but io.a does.
The generated Verilog also demonstrates the issue. The (correct) block produced for io.a is:
always @(*) begin
io_a =1'b0;
if(when_StateMachine_l253) begin
io_a =1'b1;
endend
whereas the (incorrect) block for io.b is:
always @(*) begin
io_b =1'b0;
if(when_StateMachine_l253) begin
io_b =1'b1;
endcase(fsm_stateReg)
fsm_enumDef_idle : begin
io_b =1'b0;
endfsm_enumDef_par : begin
enddefault : begin
end
endcase
end
In the latter, the branch for the idle state comes after the branch for the onEntry state (the if above), which if I understand Verilog's semantics correctly means that it wins.
The text was updated successfully, but these errors were encountered:
Yes right.
Currently, the parrent statemachine first do childStateMachines.foreach(_.build()) and then build itself.
Instead what should maybe be done, is to stage the child state machine build into multiple sub step called at different stages of the parrent FSM.
If an FSM drives a combinational signal from the
whenIsActive
block of one of its states, and then transitions to a nested FSM state whose entry state has anonEntry
block which also drives the combinational signal, then the outer FSM's statement always wins even if it appears earlier in the file.For example:
In the above FSM, we expect to see
io.a
andio.b
act the same way, since the second driver onio.b
(the only one whichio.a
does not have) is redundant. However,io.b
never goes high, butio.a
does.The generated Verilog also demonstrates the issue. The (correct) block produced for
io.a
is:whereas the (incorrect) block for
io.b
is:In the latter, the branch for the
idle
state comes after the branch for theonEntry
state (theif
above), which if I understand Verilog's semantics correctly means that it wins.The text was updated successfully, but these errors were encountered: