X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Mon, 20 Feb 2012 06:44:39 -0500
From: gene glick <geneglick AT optonline DOT net>
Subject: Re: [geda-user] verilog question - blocking/non-blocking
In-reply-to: <201202200621.q1K6LM19029205@envy.delorie.com>
To: geda-user AT delorie DOT com
Cc: DJ Delorie <dj AT delorie DOT com>
Message-id: <4F423227.2010909@optonline.net>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <4F41CB0A DOT 2020902 AT optonline DOT net>
 <201202200517 DOT q1K5HrUD026271 AT envy DOT delorie DOT com>
 <4F41DD58 DOT 8030607 AT optonline DOT net> <201202200621 DOT q1K6LM19029205 AT envy DOT delorie DOT com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110323
 Thunderbird/3.1.9
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

On 02/20/2012 01:21 AM, DJ Delorie wrote:
>> I suppose the "=" (blocking) makes the code sequential,
> NOT SEQUENTIAL.  Think "series wired".  "=" means "if the signal has
> been re-defined by some previous logic, use that new output'd signal
> as my input".  "<=" means "my inputs will always be the original
> signals."
okay, consider these examples - in both cases think about what happens 
if the 2 statements are swapped :

always @(posedge clk)
   count = count + 1;
   some_output = count;

now this one:

always @(posedge clk)
   count < count + 1;
   some_output = count;

The first one, the order of statements is important.  The second one
the order is arbitrary as far as the logic goes - maybe it's easier to
read though. So in a manner of thinking, the 1st one is sequential in 
that the count has to complete before some_output can change.

Maybe we are saying the same thing :)

> Remember, verilog is a SCHEMATIC.  It is NOT CODE.  It is wires and
> gates and latches.

I don't see it that way. There are a lot of constructs that cannot be 
synthesized but work great for things like test benches. But you 
probably mean for an fpga. Still, I don't think about it as a schematic. 
How the tools implement my case statement, or how it demorganizes my 
logic, for example, really is unimportant. Don't get me wrong - I don't 
close a blind eye to the fact that this builds gates - it's just not the 
first thing I think of.


> The problem with propogation delay, is you might not meet the setup
> times for whoever uses those values.  At high clock speeds, you need
> the latches to re-synchronize everything and reset the setup times vs
> propogation delays.

All modern synthesis/place+route tools are similar. If you constrain the 
design by telling it the clock rate, it will do it's best to meet the 
setup/hold times on all internal logic. If it fails, it tells you. 
Again, I don't want to think about the exact implementation - let the 
tools do that for you.
>
> Don't confuse verilog "registers" with hardware "latches".  Registers
> are just "values you can change" but they could easily be the output
> of a NAND gate or even just a wire, not always a physical latch.
>
But it still consumes extra resources. That's all I was saying.