I'm working on a prime calculation project which is to be implemented using Verilog on a Zybo board. I'm currently facing a strange problem and looking for a method to way forward. I have implemented an FSM with 12 states. In my FSM, I set a register called 'flag' to LOW at state 'S2' and it is set to HIGH at state 'S10'. All simulations, including Post-implementation Timing Simulation, give results as expected. However, when implemented on the hardware it doesn't give expected results. After many days of troubleshooting, I found(using Integrated Logic Analyzer) that the register 'flag' stays HIGH only at state 'S10'. It works like I had assigned a default value for 'flag' as ZERO and change to HIGH when it is at state 'S10'. But that is not what I have coded. Any idea or suggestion to solve this issue would be highly appreciated.

The relevant Verilog code is given below.

// Output logic
always@(*) begin
    idle_reg = 0;
    ld_A = 0;
    ld_n = 0;
    ld_i = 0;
    ld_P = 0;
    clr = 0;
    start_mod = 0;
    prime_found = 0;
    done = 0;
        WAIT: begin
            idle_reg = 1;
            clr = 1;
        S1: begin
            ld_A = 1;
            ld_n = 1;
        S2: begin
            flag = 1'b0;
            ld_n = 1;
        S5: begin
            ld_i = 1;
        S7: begin
            start_mod = 1;
        S10: begin
            flag = 1'b1;
        S11: begin
            prime_found = 1;
            ld_P = 1;
        DONE: begin
            done = 1;
  • 1
    \$\begingroup\$ You are only showing us a tiny portion of the code. And it may be your testbench that is actually producing incorrect output rather than the real world. What does your testbench look like? \$\endgroup\$ Sep 2, 2021 at 11:09
  • 1
    \$\begingroup\$ Hmm FSM without clock. Maybe you should first google the full of FSM. Specifically the letter 'S'. \$\endgroup\$
    – Mitu Raj
    Sep 2, 2021 at 13:02

1 Answer 1


Since it is a "state machine"; Change "always@(*) begin" to "always @(posedge clk) begin".
Your "// Output logic" is concurrent with "always@(*) begin" and deserved to get immediate result of '0'. Meantime the "case()" is missing default case/state that can cover either concurrent or sequential behavior.
It's been a while since last using Verilog. Please pardon me if the syntax error occurs.

  • \$\begingroup\$ Thanks for the comments. Yes, I've shown the segment of code where 'flag' is assigned values. The full FSM has a sequential block and two combinational blocks. One combinational block is for 'next state' logic and the other combinational block, which is shown here, is for generating outputs(it may not need a 'default' as I have included it in the other combinational block). The sequential block has 'always @(posedge clk)'. By the way, assigning a value to 'flag' prior to 'case' (default value)will not produce the desired result. \$\endgroup\$ Sep 2, 2021 at 18:10
  • \$\begingroup\$ @SusanthaWijesinghe , Could the problem be out side of this "Output logic"? \$\endgroup\$
    – jay
    Sep 2, 2021 at 19:06
  • \$\begingroup\$ Yes (see above) always @(*) makes stuff that synthesises into wires, or sometimes latches (but never flops) even if they are declared as "reg" in verilog - normally we'd expect all of the things assigned in such a block to end up as wires - however because you are not defining 'flag' for every case there (there isn't a default define at the beginning) verilog simulation for it is going to result in latch-like behaviour - vivado may or may not be able to infer a latch there (which I'm sure is not what you expect) \$\endgroup\$
    – Taniwha
    Sep 3, 2021 at 4:29
  • 1
    \$\begingroup\$ Jay and Taniwha are genious people. You pointed exactly at where the problem was. Once I changed the 'output logic' to 'always @(posedge clk)' and registered the outputs, the problem vanished, and the system worked as expected. Thanks again for your valuable idea. I would like to thanks all people who commented on this issue. \$\endgroup\$ Sep 3, 2021 at 5:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.