CODEWITHSUNDEEP
verilog
wizerd00
wizerd00

Reputation: 33

Always block not behaving as expected

I am making a state machine in verilog to implement certain arithmetic functions based on user input. I've run into a snag, however; my first always block, the one that handles my reset and maintains the correct state, is not behaving as expected; it is not updating the state correctly. The code is as follows:

always @ (posedge CLOCK_50 or negedge RESET) begin
    if(RESET == 1'b0)
        STATE <= BASE;
    else 
        STATE <= NEXT_STATE; // this always block, and specifically this line, is //not executing correctly.
end

Here is the general output of the file when reset and then following three button presses (KEY[1]) with SW = 0000:

EDIT: waveform with actual CLOCK_50 and RESET signals added

https://i.sstatic.net/DsGfG.jpg

As for my question, I just want to know what I am doing incorrectly with this section of code. I can think of no reason for it to behave this way. Thanks for any help you can provide.

EDIT2: FFS, I changed the block to negedge CLOCK_50 and now it's working. I'd really like to know why if you can tell.

Upvotes: 1

Views: 631

Answers (2)

user3000101
user3000101

Reputation: 41

Every always block, as well as every statement outside of an always block, effectively runs in parallel.

Since you have "state" being driven by two always blocks, you're effectively having two wires feed into a single wire. In digital logic design, you just can't do that. (Excluding pull-up resistors and such, but that's another topic.)

In simulation, if the multiple wires driving that single wire have the same logical value, you can get the output you desire; but if they have different values, you'll get invalid or unpredictable output.

In synthesis, this will simply fail with a "multiple drivers" error.

Also, the sensitivity list for an always block should have one of three things in it:

  1. A clock
  2. A clock and an asynchronous reset
  3. Every wire/reg that is used as an input to that always block (*)

Anything else can result in an unintentional latch, which will cause problems.

In case 3, you need to make sure that every wire driven in the always block has a default value. Anything else can result in an unintentional latch.

Lastly, you can't have circular assignments or you risk a logic loop. You have one by assigning next_state to itself. Anything "circular" requires a flip-flop, aka an always block of type 1 or 2 outlined above.

Upvotes: 1

Tim
Tim

Reputation: 35933

Ah, I see what you did now. You're assigning STATE in both of your two always blocks (STATE <= STATE in the default of the case block). This is bad, as it's a race condition between the two blocks as to which gets actually assigned. In your case, the second block is overriding the first, such that STATE <= STATE gets executed every clock. You should not assign the same variable in more than one always block.

Also you should pay attention to those warnings, but they are referring to the always @(ENABLE) block. This is complaining because you are inferring weird latched behavior, because the output is depending on STATE and SW, but they are not in the sensitivity list. You should probably just make this a combinational block, and use the auto-sensitivity list always @*.

Upvotes: 2

Related Questions