verilog - Subtleties of Non Blocking Assignments -

here in example,a non-blocking assignment propagates continuous assignment. can cause execution paradigms.please elaborate on piece of code- possible errors, how can removed , style of coding.

  @(posedge clk)         dff1 <= f(x);      assign fsm_in = f(dff1);     assign fsm_out = fsm_state;      @(fsm_in)         fsm_state <= g(fsm_in); 

your code fine, though agree greg it's better style use blocking assignments in combinatorial process.

on comments:

in simplified terms, scheduler contains 5 queues (sv has 17), you're interested in 2 of them: active event queue, , nonblocking assignment update queue. in given simulation cycle, simulator processes active event queue, , nonblocking update queue. in general, create more events, , simulator cycles around queues in pre-determined order until there no more events @ simulation time. simulator moves on next time @ event scheduled (at next clock edge, example).

assume 4 things happen 'at once': there change in fsm_state, there change in f(x), , both nba assignments executed. far simulator concerned, these 4 statements executed in same simulation cycle, in undefined order. definition of 'at once' rather complex, assume happen result of clock edge, no ordering dependencies between statements. simulator single-threaded, execute 4 statements @ different real times, knows 4 expected happen @ same simulation time.

the changes on fsm_state , f(dff1) update events, , added scheduler's active event queue.

the rhs of 2 nbas evaluated, , lhs updates added nonblocking assignment update queue.

the simulator sees queue 4 events on it. executes 2 active events first, in undefined order, fsm_in , fsm_out new values. if there no more active events, executes 2 non-blocking updates, in undefined order, dff1 , fsm_state new values.

in case, simulation cycle isn't finished, because change on fsm_in update event, , triggers evaluation/execution of block sensitive fsm_in. evaluation event. sim executes block, reads new value of fsm_in, , adds update of fsm_state nba assignment update queue. if there no active events, assignment acted on, , fsm_state gets it's new value.

this goes on until there no more events in simulation cycle, , simulator advances time, if scheduled in future.

you section 5 of verilog lrm, doesn't make sense. language grafted on late in standardisation process , uses (vhdl) terminology that's not used elsewhere in lrm. added in such way match behaviour of verilog-xl, , document non-determinism specific xl, don't expect it. nbas weren't added language till 1992, think. don't bother sv lrm; there many more queues, , common text has changed, adding level of confusion.

cliff cummings has simplified description in 1 of papers (on non-blocking assignments), read care. i'm pretty sure description of active event queue incorrect (for rhs evaluation of nbas). if right, cause sorts of problems; presumably got description version of lrm.

much best thing text on vhdl delta cycles. these easy understand, , work, , have done, , have crept verilog on years. details different, don't need know more you'll find in delta cycles.