cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Scholar
Scholar
6,234 Views
Registered: ‎06-23-2014

What happens with assignment conflict?

I'm not sure of the best forum for this, so I'm asking in this Timing Analysis forum.

 

Imagine I have the following SIMPLIFIED verilog code being used for a Virtex 7.

module ERRORcheck (
    input usr_clk,
    input error,
    input clear,
    output reg error_flag
);

always @(posedge usr_clk) begin
    if (error) begin
        error_flag <= 1;
    end

if (clear) begin error_flag <= 0; end end

It compiles fine.  What happens if error and clear are both set?  Will error_flag be set, cleared, burnt up, or something else?

 

Note that in my real case, there are real reasons that make it difficult to logically combine these things, for example, into a cascaded if/else/else structure.  I could go through much more trouble to prevent this simultaneous condition, but it would get very complicated.  Instead, if I knew the behavior on such conflict, things would be much easier.  In fact, since the two error conditions are likely to occur and persist, I almost don't care what happens during such a conflict.  For example, if the set always wins, then the clear would be ineffective.  There's little difference in this simultaneous scenario and the one where the error persisted at last one clock cycle after the clear.  The reverse is true as well.  If the clear always wins, then a simultaneous error would get cleared.  I guess this does leave the window to not see a single clock error.  However, this practically won't happen, becuase the clear will only happen in response to an error.  Nevertheless, I'd like to know if there is DEFINED BEHAVIOR in this condition.

 

 

Tags (1)
0 Kudos
4 Replies
Highlighted
Professor
Professor
6,216 Views
Registered: ‎08-14-2007

Re: What happens with assignment conflict?

The behavior is clearly defined by the language.  The last assignment (in your case error_flag <= 0) will "win" when there are more than one assignments to the same signal in a process.  In simulation, you can have issues if you add delays to these assignments and the delays don't match.  For example if you had:

 

always @(posedge usr_clk) begin
    if (error) begin
        error_flag <= #1 1;
    end

    if (clear) begin
        error_flag <= #0.5 0;
    end
end

 

Then if both flags are high at the clock edge in simulation you will see error_flag set to 1 after everything has settled out.  In synthesis, the delays are ignored, and the second assignment will always override the first.  This is a case where simulation will not match synthesis.  So for synthesis error_flag will be zero if both error and clear are asserted.

-- Gabor
0 Kudos
Highlighted
Scholar
Scholar
6,212 Views
Registered: ‎06-23-2014

Re: What happens with assignment conflict?

Gabor,

 

Thanks very much for the info.

 

(Below regarding actual hardware, not simulation...)

 

Now, just to be clear, when you say the "last assignment", you mean the one lowest down in the source file, aka the one at the highest line number in the source, right?  I ask because "last" is somewhat ambiguous and I want to be absolutely certain.

 

Therefore, if there are all kinds of state machines and other things between those two if clauses, but they are all within the same always begin/end block, then the "error_flag <= 0" will win?  Specifically, I have the "error_flag <= 1" above a state machine and the "error_flag <= 0" inside a state of that state machine.  

 

Triple checking...  So if the error condition arises it is generally set by the logic above the state machine in the source code.  The clear condition only happens within a specific state of the state machine, lower down in the source code.  If the error condition arises while I'm in that specific state, this conflict occurs and so the clear will win because it's later in the source code.

 

Alternatively...  If I moved the error condition check BELOW the state machine in the source code, then I could make it so that when the conflict occurs, the error condition check wins, right?

 

To date, I've been treating the order of source code as not meaningful.  But in such conflict cases, the order of source code will be meaningful.

 

So, please let me know if I understand or if I am misunderstanding something.

 

Thanks,

Helmut

0 Kudos
Highlighted
Professor
Professor
6,205 Views
Registered: ‎08-14-2007

Re: What happens with assignment conflict?

It sounds like you have it right.  One way to look at this is that Verilog was designed for simulation.  Everything within an always block will be run sequentially during simulation.  For non-blocking assignments, each assignment is scheduled in the order that the sequential assignment is reached.  For any given time slot, the last scheduled assignment to any reg will be what you end up with.  Note that this gives rise to the issue I pointed out when you add differing delays to the scheduled assignments.

 

What synthesis does is to ignore delays, but otherwise try its best to make the logic it infers do the same thing you saw in behavioral simulation.

 

Using multiple assignments to the same reg in a process has some interesting uses, and some not so intuitive side-effects.  For example:

 

always @ (posedge clk)

  begin

     flag <= 0; // unless set in the FSM

    case (state)

      . . .

      some_state:  flag <= 1;

    endcase

  end

 

Here you can design a state machine that sets a flag under some condition, and know that the flag will clear as soon as the condition is no longer true.

 

always @ (posedge clk)

  begin

     flag <= 0; // unless set in the FSM

    case (state)

      . . .

      some_state:  flag <= 1;

      default:  flag <= flag;

    endcase

  end

 

Here it looks like the default state does nothing.  Normally a register is assumed to hold its current value if no other assignment is made.  However in this case, because it happens after flag is assigned to zero, the default case overrides the clearing of the flag.

 

always @ (posedge clk)

  begin

    case (state)

      . . .

      some_state:  flag <= 1;

    endcase

     if (flag == 1) flag <= 0; // reset if necessary

   end

 

Here the flag is cleared at the end of the process, but only if it was already set.  This is another way to be sure it goes high for at least one cycle.  Without the "if (flag == 1)" the flag would never be set.

-- Gabor
0 Kudos
Highlighted
Scholar
Scholar
6,200 Views
Registered: ‎06-23-2014

Re: What happens with assignment conflict?

Fabulous info.  Thanks.

 

Note your first code example is essentially what I have.

 

Your last code example, were it ending with "if (error) error_flag <= 1", is akin to my describing reversing who wins.


Got it.  Thanks.

0 Kudos