X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <20120220060252.5513.qmail@stuge.se>
Date: Mon, 20 Feb 2012 07:02:52 +0100
From: Peter Stuge <peter AT stuge DOT se>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] verilog question - blocking/non-blocking
Mail-Followup-To: geda-user AT delorie DOT com
References: <4F41CB0A DOT 2020902 AT optonline DOT net> <201202200517 DOT q1K5HrUD026271 AT envy DOT delorie DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201202200517.q1K5HrUD026271@envy.delorie.com>
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

DJ Delorie wrote:
> > Question : does one method synthesize significantly different logic
> > than the other?
> 
> For those who think verilog is software, it's not...
..
> If you think software-like, think of your code this way:

It might be worth emphasizing that logic is not sequential the way
software is.

If you can visualize easily, then think of your lines of logic design
running "down" in a file being "rotated" into "executing" in hardware
almost completely in parallell; ie. simultaneously.

This is an oversimplification, but key when starting out is to wrap
head around that even though you write things sequentially they may
happen simultaneously in running logic.

Enter good friend finite state machine. The two counter assignments
both support state machines, but as was pointed out with slightly
different behavior to keep in mind, and design around. That's the
almost in "almost completely in parallell." ;)


//Peter