X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Virus-Scanned: amavisd-new at oregonstate.edu
Date: Sun, 19 Feb 2012 22:07:00 -0800
From: Traylor Roger  <traylor AT eecs DOT oregonstate DOT edu>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] verilog question - blocking/non-blocking
Message-ID: <20120220060700.GD26782@slana.eecs.oregonstate.edu>
References: <4F41CB0A DOT 2020902 AT optonline DOT net> <201202200517 DOT q1K5HrUD026271 AT envy DOT delorie DOT com> <4F41DD58 DOT 8030607 AT optonline DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4F41DD58.8030607@optonline.net>
User-Agent: Mutt/1.4.2.2i
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

Gene,
  I think the greatest danger is that your synthesized code
  behaves differently than your simulation.  The evaluation
  of verilog is tricky. I stick to some simple guidelines
  that have always worked for me and they synthesize to 
  circuits that act exactly as the simulation does.  
  These are:
  -When modeling sequential logic, use nonblocking assignments.
  -When modeling latches, use nonblocking assignments.
  -When modeling combo logic with an always block, use blocking
   assignments.
  -When modeling both sequential and combo logic within the same
   always block, use nonblocking assignments.
  -Do not mix blocking and nonblocking assignments in the same
   always block.
  -Do not make assignments to the same variable from more than one
   always block.
 
 These come from Cliff Cummings of Sunburst Design.

 Roger
  
  
  
  
  On Mon, Feb 20, 2012 at 12:42:48AM -0500, gene glick wrote:
> On 02/20/2012 12:17 AM, DJ Delorie wrote:
> 
> >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.
> >
> 
> I suppose the "=" (blocking) makes the code sequential, like C - if that 
> clarifies it some. But I was really wondering how the synthesis tools 
> deal with this. I almost always avoid using the "=" form.  It doesn't 
> bother me that my states are off (delayed) by 1 clock tick.  So in my 
> 2nd example, during simulation do_something runs when the counter is 1 
> not 0. Not really a big deal. In the first example, do_something runs 
> when the counter is 0. Makes looking at the waveforms, and the counter, 
> line up nice but what the heck does the synthesis tool build?
> 
> Wouldn't your method of 'previous count' and 'count' use twice as many 
> registers?