question about always definitions

M

Moritz

Guest
Hi,

I was wondering whether anyone could tell me if the always definitions,
which I can put into a module definition can be considered concurrent,
or if the order they are specified in does matter.

Thanks in advance,

Moritz
 
blakaxe@gmail.com wrote:
On Jul 23, 3:40 am, Moritz <hansbo...@gmx.de> wrote:
Hi,

I was wondering whether anyone could tell me if the always definitions,
which I can put into a module definition can be considered concurrent,
or if the order they are specified in does matter.

All statements inside an always block are concurrent if you use the
non blocking assignment <=
Click to expand...
The always blocks themselves run concurrently.
Inside each block, code executes sequentially.
Clocked blocks update once per clock cycle.
Asynch blocks update continuously.
Assignments using '<=' update at the end of the block.
Assignments using '=' update immediately.

-- Mike Treseler
 
On Jul 23, 3:40 am, Moritz <hansbo...@gmx.de> wrote:
Hi,

I was wondering whether anyone could tell me if the always definitions,
which I can put into a module definition can be considered concurrent,
or if the order they are specified in does matter.

Thanks in advance,

Moritz
Click to expand...
All statements inside an always block are concurrent if you use the
non blocking assignment <=
 
On Jul 23, 11:32 am, "blak...@gmail.com" <blak...@gmail.com> wrote:
On Jul 23, 3:40 am, Moritz <hansbo...@gmx.de> wrote:

Hi,

I was wondering whether anyone could tell me if the always definitions,
which I can put into a module definition can be considered concurrent,
or if the order they are specified in does matter.

Thanks in advance,

Moritz

All statements inside an always block are concurrent if you use the
non blocking assignment
always blocks themselves are concurrent.
Click to expand...
Does not depend on the order in which you write them.
 
On 2008-07-23 18:58:24 +0200, Mike Treseler <mtreseler@gmail.com> said:

blakaxe@gmail.com wrote:
On Jul 23, 3:40 am, Moritz <hansbo...@gmx.de> wrote:
Hi,

I was wondering whether anyone could tell me if the always definitions,
which I can put into a module definition can be considered concurrent,
or if the order they are specified in does matter.

All statements inside an always block are concurrent if you use the
non blocking assignment <=

The always blocks themselves run concurrently.
Inside each block, code executes sequentially.
Clocked blocks update once per clock cycle.
Asynch blocks update continuously.
Assignments using '<=' update at the end of the block.
Assignments using '=' update immediately.

-- Mike Treseler
Click to expand...

Thanks a lot!
That was exactly the answer I needed!

Moritz
 
Mike Treseler <mtreseler@gmail.com> writes a nice simple explanation
that just needs a little minor tweak:

Assignments using '<=' update at the end of the block.
Click to expand...
Assignments using '<=' update on the next update cycle. That happens
after all the assignments using '=' in all the always blocks are
executed, but before the next round of = executions. There are more
subtleties (e.g. can assignments in different always blocks get
interpersed? yes; can <= assignments with one block get rearranged?
no, etc.) if you are trying to pin down the semantics, but that's
close enough that if you depend on only that, you are likely to be
mostly safe.
 
Chris F Clark wrote:

... if you depend on only that, you are likely to be
mostly safe.
Click to expand...
Completely safe if I can enforce my design rules.
I favor modules with a single clocked block.

-- Mike Treseler
 
Mike Treseler <mtreseler@gmail.com> writes:

Completely safe if I can enforce my design rules.
I favor modules with a single clocked block.
Click to expand...
I don't doubt that you have design rules that keep you perfectly safe.
There are safe subsets of Verilog and design rules that keep you
within them. Design rules are good.

However, the designers here are not using such a set of design rules
and although they are using only always blocks and the two types of
assignments, blocking and non-blocking, they still have code with
races which synthesizes to something they like, but doesn't always
simulate to that result. Are they safe?

That's why I pointed out *mostly* safe. The things you pointed out in
your posting weren't sufficient by themselves to keep one in a safe
subset of Verilog. Now, perhaps you know that the other person is
using appropriate design rules and is actually safe. However, I don't
know that, and I didn't want to instill a false sense of security.
Especially, whne I know how easy it is to write Verilog that isn't
safe but may work on one simulator, using one set of options.
 
Chris F Clark wrote:

However, the designers here are not using such a set of design rules
and although they are using only always blocks and the two types of
assignments, blocking and non-blocking, they still have code with
races which synthesizes to something they like, but doesn't always
simulate to that result. Are they safe?
Click to expand...
I hear what you are saying.
The problem is that verilog does not prevent sim races
and that any complete set of rules to avoid such races
is difficult for a novice to understand.

Jonathan's rules below the best I've seen,
but I expect that even this formulation
will make a novice's eyes glaze over.

-- Mike Treseler

________________________________________________________

Jonathan Bromley said:

- Keep synthesis happy by avoiding any mixture of blocking =
and nonblocking <= assignments *to the same variable* in any
code that models synthesisable logic. It's easy to find
examples where this rule is strictly unnecessary, but
synthesis tools enforce it and you lose nothing by
observing it.

- In a clocked always block, with or without asynch reset,
NEVER, NEVER, NEVER use blocking assignment = to any variable
whose value will be used outside that same always block.
Failure to observe this rule WILL give rise to code that
can suffer races in simulation, and therefore mismatches
between simulation and synthesis.

- In a combinational always block, nonblocking assignments <=
are always unnecessary and often wrong; stick to blocking
assignments throughout.
Click to expand...
 
On Wed, 23 Jul 2008 08:32:02 -0700 (PDT), <blakaxe@gmail.com> wrote:


All statements inside an always block are concurrent
if you use the non blocking assignment <=
Click to expand...
I really, really wish people wouldn't say that.

Normally I'm all in favour of free speech, but
when people write stuff that's easily verified
to be a complete load of dingo's kidneys then
I think we have a problem. Show me what's
concurrent about the three assignments here...

always @(posedge clock) begin
if (count) q <= q + 1;
if (load) q <= data;
if (reset) q <= 0;
end

Nope, you can't show me any such thing; they're
not concurrent at all. Just try moving the first
line of code to the bottom of the block, and see
whether the original design is preserved.

Ho hum.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On Sun, 27 Jul 2008 00:30:30 +0100, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

On Wed, 23 Jul 2008 08:32:02 -0700 (PDT), <blakaxe@gmail.com> wrote:


All statements inside an always block are concurrent
if you use the non blocking assignment <=

I really, really wish people wouldn't say that.

Normally I'm all in favour of free speech, but
when people write stuff that's easily verified
to be a complete load of dingo's kidneys then
I think we have a problem. Show me what's
concurrent about the three assignments here...

always @(posedge clock) begin
if (count) q <= q + 1;
if (load) q <= data;
if (reset) q <= 0;
end

Nope, you can't show me any such thing; they're
not concurrent at all. Just try moving the first
line of code to the bottom of the block, and see
whether the original design is preserved.
Click to expand...
Just to clarify for myself and others Verilog standard requires that
the above lines have the same behavior as follows:

always @(posedge clock) begin
if (reset) q <= 0;
else if (load) q <= data;
else if (count) q <= q + 1;
end
 
On Jul 27, 3:36 am, Muzaffer Kal <k...@dspia.com> wrote:
On Sun, 27 Jul 2008 00:30:30 +0100, Jonathan Bromley



jonathan.brom...@MYCOMPANY.com> wrote:
On Wed, 23 Jul 2008 08:32:02 -0700 (PDT), <blak...@gmail.com> wrote:

All statements inside an always block are concurrent
if you use the non blocking assignment <=

I really, really wish people wouldn't say that.

Normally I'm all in favour of free speech, but
when people write stuff that's easily verified
to be a complete load of dingo's kidneys then
I think we have a problem. Show me what's
concurrent about the three assignments here...

always @(posedge clock) begin
if (count) q <= q + 1;
if (load) q <= data;
if (reset) q <= 0;
end

Nope, you can't show me any such thing; they're
not concurrent at all. Just try moving the first
line of code to the bottom of the block, and see
whether the original design is preserved.

Just to clarify for myself and others Verilog standard requires that
the above lines have the same behavior as follows:

always @(posedge clock) begin
if (reset) q <= 0;
else if (load) q <= data;
else if (count) q <= q + 1;
end
Click to expand...
They are the same for synthesis, but in the first case
you could have zero-width pulses on q in simulation.
This would not matter in a typical synchronous design,
but if you used q as a clock signal you would end up
with a mismatch between simulation and synthesis in
the first case, but not the second.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top