X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
Date: Mon, 20 Feb 2012 00:17:53 -0500
Message-Id: <201202200517.q1K5HrUD026271@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: geda-user AT delorie DOT com
In-reply-to: <4F41CB0A.2020902@optonline.net> (message from gene glick on Sun,
	19 Feb 2012 23:24:42 -0500)
Subject: Re: [geda-user] verilog question - blocking/non-blocking
References: <4F41CB0A DOT 2020902 AT optonline DOT net>
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> Question : does one method synthesize significantly different logic
> than the other?

For those who think verilog is software, it's not...

The "=" operator is like a bunch of gates wired in series, with each
gate's input tied to the previous gate's output.  If multiple gates
compute the same "output", the last active one listed wins.

The "<=" operator is like a bunch of gates with a common input.

If you think software-like, think of your code this way:

always @(posedge clk)
  begin
     /* edge happens here */
     new_count = count + 1;
     if (new_count == 0)
       do_something
     count = new_count;
  end


always @(posedge clk)
  begin
     prev_count = count;
     /* edge happens here */
     count <= prev_count + 1;   // non-blocking method
     if (prev_count == 0)
       do_something
  end


My personal paradigm is to use '=' in an @always combinatoric state
machine that computes the next state from the current state, and '<='
in a separate edge-triggered @always that just copies the next state
to the current state.

For example, see http://www.delorie.com/electronics/sdram/simple1.v

The last two blocks are an "always @(negedge ram_wclock) begin" that
copies the next state to the current state, followed by a huge "always
@(...lots of things...)" that computes the next state.

I've found that if I try to mix combinatoric and edge logic in the
same block, I end up doing something pessimal and the chip won't run
as fast as it should.