Sequential and Combinational Always block

[BlueDoze]

Helloo,

I just wonder the equivent verilog for VHDL Process.

I didn't understand the difference between the Sequential and
Combinational "always", all what I fount that if there's a "clk",
"reset", ... in the senstivity list then it will be sequential,

Does this mean that always block statements can be combinational, and
concurrent??


bluedoze

 

[Andy Peters]

bluedoze@yahoo.com (BlueDoze) wrote in message news:<a53ecee3.0401120418.5be122df@posting.google.com>...

Helloo,

I just wonder the equivent verilog for VHDL Process.

VHDL processes can be combinatorial or synchronous. Same for Verilog
always blocks (which I call processes, because "always block" is so
cumbersome!).

I didn't understand the difference between the Sequential and
Combinational "always", all what I fount that if there's a "clk",
"reset", ... in the senstivity list then it will be sequential,

Does this mean that always block statements can be combinational, and
concurrent??

Yes. A good example of a combinatorial always block is a mux (assume
sel is a two-bit vector):

always @(sel or a or b or c or d) begin : CombMux
case (sel)
2'b00 : q = a;
2'b01 : q = b;
2'b10 : q = c;
2'b11 : q = d;
endcase
end // CombMux

You could write this mux using an assignment but the case construct is
clearer (at least to me).

What's still not really clear (to me) is whether one should use
non-blocking or blocking assignments. The rule is to use non-blocking
assigments for sequential always blocks, but ...

-a

 

[Bluedoze]

I didn't understand the difference between the Sequential and
Combinational "always", all what I fount that if there's a "clk",
"reset", ... in the senstivity list then it will be sequential,

Does this mean that always block statements can be combinational, and
concurrent??

Yes. A good example of a combinatorial always block is a mux (assume
sel is a two-bit vector):

always @(sel or a or b or c or d) begin : CombMux
case (sel)
2'b00 : q = a;
2'b01 : q = b;
2'b10 : q = c;
2'b11 : q = d;
endcase
end // CombMux

but what if I want to make the always sensitive to only "sel", will that
work ?
I read that I should add all of the rhs signals to the sensitivty list of
the "always", but this doesn't apply on the VHDL process.

You could write this mux using an assignment but the case construct is
clearer (at least to me).

What's still not really clear (to me) is whether one should use
non-blocking or blocking assignments. The rule is to use non-blocking
assigments for sequential always blocks, but ...

-a

 

[Ian Poole]

"Bluedoze" <bluedoze@NOSPAMyahoo.com> wrote in message
news:4003b1af$1@solnews.wv.mentorg.com...

I didn't understand the difference between the Sequential and
Combinational "always", all what I fount that if there's a "clk",
"reset", ... in the senstivity list then it will be sequential,

Does this mean that always block statements can be combinational, and
concurrent??

Yes. A good example of a combinatorial always block is a mux (assume
sel is a two-bit vector):

always @(sel or a or b or c or d) begin : CombMux
case (sel)
2'b00 : q = a;
2'b01 : q = b;
2'b10 : q = c;
2'b11 : q = d;
endcase
end // CombMux



but what if I want to make the always sensitive to only "sel", will that
work ?
I read that I should add all of the rhs signals to the sensitivty list of
the "always", but this doesn't apply on the VHDL process.

It depends. VHDL processes can also represent combinational and clocked
logic.
The fundamental question you have to be confident with is "What's the point
of a sensitivity list?". The sensitivity list (or properly known in Verilog
its an "event control") is used by the simulator to "trigger" evaluation of
that block. However, your synthesis tool builds hardware based on the
contents of the process/always block, and only uses the sensitivity list as
a sanity check. This is the origin of the "incomplete sensitivity list"
message. This discrepancy in the use of the sensitivity list can lead to a
discrepancy between what you simulate and what you actually build (another
good reason to do gate level sims). In Andy's mux example, you could omit
sel from the sensitivity list and it would simulate. When you synthesise it,
you will get a mux. But, what happens in the built mux when sel changes? The
outputs probably change. What happens in the simulated design when sel
changes? Nothing 'cos sel is not in the sensitivity list.
For clocked logic, you only need to evaluate the block when the clock
changes, or you get a reset (and possibly a set...). In verilog, the
sensitivity list explicitly detects the edge (@posedge or @negedge) of the
clock. In VHDL, the process is sensitive to the clock and set/reset signals,
then in the body of the VHDL process you explicitly code up the particular
clock edge you want.

So two rules for sensitivity lists, and these apply to both Verilog always
blocks and to VHDL processes -
If its combinational, you should have all inputs on the sensitivity list -
everything that appears on the RHS, as well as arguments to if / case etc
If its clocked, you should have just the clock and reset/set signals on the
sensitivity list.

You could write this mux using an assignment but the case construct is
clearer (at least to me).

What's still not really clear (to me) is whether one should use
non-blocking or blocking assignments. The rule is to use non-blocking
assigments for sequential always blocks, but ...

-a

--
Ian Poole, Consultant

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

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: ian.poole@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Chris F Clark]

Sensitivity lists are an annoyance in Verilog because they have two
distinct uses, just as their are two types of processes in VHDL.

The general rule of a sensitivity list is that it should contain all
signals/events (and only those signals and events) which cause the
block to execute.

In practice, when designing synthesizable code, there are two distinct
kinds of always blocks: combinatorial and clocked.

If you are designing a combinatorial block, the sensitivity list
should include all signals which are used in assignments within the
block. Thus, for your mux, you should list sel, a, b, c, and d in
your sensitivity list. Alternatively, you should use the new 2001
version of a sensitivity list with a * entry, which causes the
simulator to calculate which inputs affect outputs--which is the same
as listing the relevant outputs.

If you are designing a clocked block, the senstivity list should
include those events that represent edges where your clocked logic
should transitions (e.g. always @((posedge clock) or (negdge reset))).

Unless you are far more clever than the designers here, you should not
mix the two kinds of sensitivity lists in one always block. It should
either have edge events (and only edge events) or it should only have
signals and no edge events.

Note, the simulator we use and developed internally enforces those
rules (and some others, such as no non-blocking assignments in
combinatorial always blocks), which means it rejects some "valid"
Verilog, but only "valid" Verilog we don't want our designers using
anyway. Generally such subsets of Verilog are called "syntehsizable"
because they describe well-known gates that can be laid down on a chip
or board by a synthesizer.

This all harks back to the fact that Verilog was originally intended
to model (simulate) circuit behavior not to define it. It is far
simpler to design a general simulation language than it is to define
the "correct" one for all possible gates (especially since one doesn't
know how technology may advance in the future). Thus, some day
someone may invent a type of gate that is half-combinatorial and
half-clocked and that a mixed sensitivity list with some non-edge
signals and some edge signals in the sensitivity list is the right
description. If and when they do, Verilog will be ready to describe
it. Until that time, it is better to avoid mixing the two types of
sensitivity lists in synthesizable code because they represent
different types of gates.

Because of this, you will find that I suggest learning "synthesizable"
Verilog, i.e. a few patterns that represent known gates, rather than
the entire language. There are many things in Verilog whose semantics
are complicated (and just plain wrong) for use in *designing*
circuits. On the other hand, there is a subset of Verilog which is
quite simple to understand and will allow one to design and synthesize
almost any chip one could desire--and the set is only a small bit
larger when one wants to design test benches. So, why learn the
complicated parts, if one shouldn't be using them anyway?

Just one persons opinion,
-Chris

*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
19 Bronte Way #33M voice : (508) 435-5016
Marlboro, MA 01752 USA fax : (508) 251-2347 (24 hours)
------------------------------------------------------------------------------

 

[Jonathan Bromley]

"Chris F Clark" <cfc@shell01.TheWorld.com> wrote in message
news:sddk73vu9jr.fsf@shell01.TheWorld.com...

Sensitivity lists are an annoyance in Verilog because they have two
distinct uses, just as their are two types of processes in VHDL.

Run that one by me again... what are the "two types of process"
in VHDL?????

The general rule of a sensitivity list is that it should contain all
signals/events (and only those signals and events) which cause the
block to execute.

Indeed.

In practice, when designing synthesizable code, there are two distinct
kinds of always blocks: combinatorial and clocked.

I'd argue for at least a third type: latched (with a complete
sensitivity list but incomplete assignment, as mandated by
synthesis subsets 1076.6 (VHDL) and 1364.1 (Verilog)).

If you are designing a combinatorial block,

or a latch,

the sensitivity list
should include all signals which are used in assignments within the
block.

Not a very precise formulation: surely the sensitivity list
should include all signals that are *read* in the block - or,
if you like, are used in expressions within the block. Not
forgetting those expressions that appear as if() and case()
selectors. Assignment is irrelevant here.

Unless you are far more clever than the designers here,

By and large I aim to be a little less patronising than this.
Perhaps you should attempt the same?

you should not
mix the two kinds of sensitivity lists in one always block. It should
either have edge events (and only edge events) or it should only have
signals and no edge events.

It is very far from obvious why this is true (in the case of
clocked logic with asynchronous set/reset/load inputs), but
indeed it IS true **for synthesisable logic**.

Note, the simulator we use and developed internally enforces those
rules (and some others, such as no non-blocking assignments in
combinatorial always blocks), which means it rejects some "valid"
Verilog, but only "valid" Verilog we don't want our designers using
anyway.

What about people who want to write behavioural models and
test benches? I would have thought that your simulator's
arbitrary restrictions would be very irksome to them.
These are the kind of restrictions that should be enforced
by a linting or rule-checking tool, surely?

Generally such subsets of Verilog are called "syntehsizable"
because they describe well-known gates that can be laid down on a chip
or board by a synthesizer.

And synthesisers will issue warning or error messages for violations
of these subsets.

This all harks back to the fact that Verilog was originally intended
to model (simulate) circuit behavior not to define it. It is far
simpler to design a general simulation language than it is to define
the "correct" one for all possible gates (especially since one doesn't
know how technology may advance in the future). Thus, some day
someone may invent a type of gate that is half-combinatorial and
half-clocked and that a mixed sensitivity list with some non-edge
signals and some edge signals in the sensitivity list is the right
description. If and when they do, Verilog will be ready to describe
it. Until that time, it is better to avoid mixing the two types of
sensitivity lists in synthesizable code because they represent
different types of gates.

I can't disagree.

Because of this, you will find that I suggest learning "synthesizable"
Verilog, i.e. a few patterns that represent known gates, rather than
the entire language. There are many things in Verilog whose semantics
are complicated (and just plain wrong) for use in *designing*
circuits. On the other hand, there is a subset of Verilog which is
quite simple to understand and will allow one to design and synthesize
almost any chip one could desire

Yes, but...

--and the set is only a small bit
larger when one wants to design test benches.

....I regard this last comment as pernicious nonsense!


Finally, it's worth mentioning a small but important point about
Verilog "sensitivity lists": THERE IS NO SUCH THING. In Verilog
any procedural statement whatsoever can be prefixed by a timing
control. The @(...) sensitivity list is NOT a part of the
enclosing "always"; it is a prefix to the procedural statement
or the begin...end block that the "always" controls. In most
cases, and certainly for synthesisable logic, you don't need
to worry about the difference, and it's perfectly OK to think
of "always @(...)" as a process with a sensitivity list. But
that's not how the Verilog syntax really works.

By contrast, a VHDL process with a sensitivity list is a
specific syntax construct. It's defined to be equivalent
to a process WITHOUT a sensitivity list, but with a wait
statement added to the very end of the process. This
has the interesting effect that all VHDL processes with
sensitivity lists will run to completion once at time 0,
whereas Verilog "always @(...)" processes won't run until
there is an event on one of the signals in their sensitivity
list. Interestingly, SystemVerilog adds new synthesisable
process constructs (always_comb, always_ff) that behave just
like their VHDL equivalents.
--
Jonathan Bromley, Consultant

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

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Chris F Clark]

Jonathan Bromley chided me in the post quoted here:

Run that one by me again... what are the "two types of process"
in VHDL?????

I'm sorry I was following upon on the previous posters categorization.
As a result, I did forget latches as Jonathan properly corrected me.
We try to keep our designers from writing unitended latches, but
that's no excuse for my omitting them. Latches are not strictly
combinatorial and also do not have edge sensitivities either.
Similarly, Jonathan is correct that the list of signals should include
those *read* by the always block (e.g. those in if and case
statements) should also be included.

What about people who want to write behavioural models and test
benches? I would have thought that your simulator's arbitrary
restrictions would be very irksome to them. These are the kind of
restrictions that should be enforced by a linting or rule-checking
tool, surely?

Actually, that is the point of the tool. We are specifically trying
to keep designers from writing behavioral code. We want them thinking
in terms of code that has an obvious realization in the synthesized
circuit. We want those checks enforced by the first tool in the
chain, not discovered somewhere later, so that there is no excuse for
not creating a design another chip designer can pick up and instantly
recognize what the design creates. Portability and reuse of designs
is a key goal. We have outs for the test bench designers and for
foreign IP, but we don't want our chip designers using those outs.

Verilog "sensitivity lists": THERE IS NO SUCH THING. In Verilog
any procedural statement whatsoever can be prefixed by a timing
control. The @(...) sensitivity list is NOT a part of the
enclosing "always"; it is a prefix to the procedural statement
or the begin...end block that the "always" controls.

And, this is exactly the kind of Verilog we are attempting to
prohibit. Yes, it is true that the @ clause is separate from the
always. However, the only place we want the designer writing an @ is
directly after the always and moreover, we want them only writing the
two constrained types of sensitivity lists I mentioned (in fact we
don't want them writing the combinatorial one at all, only the one
representing clocked circuits, so we support/recommend the Verilog
2001 format for non-edge sensitive blocks).

While for the purpose of deigning the Verilog language as a simulation
language, having the @ clause as its own clause in the grammar that
can be used in all the varieties of clauses that it can occur makes
sense. However, from the standpoint of trying to write Verilog that
describes something that someone else can decipher what you have
designed, that freedom is too unconstrained.

If my comments seem patronizing because of that, I apologize.
However, my bosses find Verilog a language that gives the designer too
much rope and want the designers to be isolated from some of those
features that make a good simulation language but a poor chip design
language. As such I have become somewhat of a crank on avoiding the
obscure interactions between Verilog features that don't represent
simple circuitry concepts.

I will withdraw my comments about only needing a slightly larger
subset for designing testbenches as there may be testing methodologies
that make good use of many of the different semantic interactions in
Verilog and I have just not been exposed to them. My bias is that
test bench design should also be simple and transparent, but that does
not mean that there are not simple transparent test benches that use a
wholy different subset of Verilog. (Just as we have tools that don't
use Verilog at all in the design flow.)

My personal feelings on this are that most people learning Verilog
should learn the synthesizable subset first, because that corresponds
to something else they can understand, the piece of circuitry being
modelled. This would not be true if Verilog were used as a more
general simulation language. However, I don't think most people learn
Verilog to write simulations of anything other than circuits. Thus, I
think the Verilog that they know should correspond to those circuits
and not represesent things that cannot be realized. This is
particularly true for those who get confused, like I do. Why should
we intentionally be exposed to things which will only make our life
more confusing, when there is a simpler model available?

Do all the ways an @ or # clause can be used in Verilog make a
designers life simpler? Or do they simply serve to muddle the issue?

Hope this helps,
-Chris

*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
19 Bronte Way #33M voice : (508) 435-5016
Marlboro, MA 01752 USA fax : (508) 251-2347 (24 hours)
------------------------------------------------------------------------------

 

[Jonathan Bromley]

"Chris F Clark" <cfc@shell01.TheWorld.com> wrote in
message news:sddsmijzlts.fsf@shell01.TheWorld.com...

Jonathan Bromley chided me in the post quoted here:

OK, perhaps I overdid it a bit.... Thanks for your
interesting clarifications.

[...]

What about people who want to write behavioural models and test
benches? I would have thought that your simulator's arbitrary
restrictions would be very irksome to them. These are the kind of
restrictions that should be enforced by a linting or rule-checking
tool, surely?

Actually, that is the point of the tool. We are specifically trying
to keep designers from writing behavioral code. We want them thinking
in terms of code that has an obvious realization in the synthesized
circuit. We want those checks enforced by the first tool in the
chain, not discovered somewhere later, so that there is no excuse for
not creating a design another chip designer can pick up and instantly
recognize what the design creates. Portability and reuse of designs
is a key goal. We have outs for the test bench designers and for
foreign IP, but we don't want our chip designers using those outs.

That's very interesting. Most IP shops I have encountered
use a standard Verilog *simulator*, but then run the code through
a rule checker such as Atrenta Spyglass to determine conformance
with synthesisability and style rules. I am still a tad
disturbed by the idea of a Verilog simulator that intentionally
fails to comply with the Verilog standard (although I can easily
see the value of a command-line switch that enforces some such
set of rules).

While for the purpose of deigning the Verilog language as a simulation
language, having the @ clause as its own clause in the grammar that
can be used in all the varieties of clauses that it can occur makes
sense. However, from the standpoint of trying to write Verilog that
describes something that someone else can decipher what you have
designed, that freedom is too unconstrained.

I would never advocate bizarre uses of timing controls in
synthesisable designs. I'm with you 100% on that. However,
I definitely DO want the freedom to write whatever behavioural
models I like.

My bias is that
test bench design should also be simple and transparent, but that does
not mean that there are not simple transparent test benches that use a
wholy different subset of Verilog.

Indeed, some people intentionally write synthesisable test benches,
the easier to map them on to accelerator hardware. My own
preference (and experience) leads me the other way, towards
making testbenches as "software-ish" as possible.

My personal feelings on this are that most people learning Verilog
should learn the synthesizable subset first, because that corresponds
to something else they can understand, the piece of circuitry being
modelled.

True, perhaps, for electronics engineers brought up on schematic-based
design flows. Many trainers start from the same point. Me, I'm
not convinced - but it's an interesting and open issue.

Why should
we intentionally be exposed to things which will only make our life
more confusing, when there is a simpler model available?

Hear, hear!

Do all the ways an @ or # clause can be used in Verilog make a
designers life simpler? Or do they simply serve to muddle the issue?

Either is possible - it depends on the competence of the programmer!

Here are two little Verilog fragments that IMHO express their
intent very clearly, but of course are nowhere near synthesisable:


// Example 1: Wait, with timeout, for signal Done to go true
// (useful in testbenches, if device under test is not proven)
fork: WaitWithTimeout
wait (Done) disable WaitWithTimeout;
#(Timeout) disable WaitWithTimeout;
join
// now test Done to see whether you timed out

// Example 2: Behavioural model of N-clock pipeline delay
always @(posedge clock)
Out <= repeat (N) @(posedge clock) In;

Once again, though, some of the clarity comes from the
use of well-known idioms - which is precisely what you
are advocating. So I guess that we are broadly in
agreement, but coming at the problem from different
directions and therefore arriving at different conclusions.

Fortunately, life is complicated enough to
remain interesting

--

Jonathan Bromley, Consultant

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

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Chris F Clark]

From an ongoing public conversation with Jonathan Bromley:

OK, perhaps I overdid it a bit.... Thanks for your
interesting clarifications.

No, your chides were correct.

Most IP shops I have encountered use a standard Verilog *simulator*,
but then run the code through a rule checker such as Atrenta
Spyglass to determine conformance with synthesisability and style
rules.

I think if we were an IP shop and selling our Verilog that would be a
totally logical path. However, we are actually a chip house and sell
the resulting chips. At some level our simulation strategy comes from
the way our chips are marketed. The resulting chips are used in
embedded designs and are programmable. So, our customers need a
simulator that they can run their programs on. Previously, such
simulators had been written by hand in C or by using special tools
that understand "instruction sets".

However, little glitches in the chip design, could cause the chip to
not behave precisely like the architectural spec. This caused undue
problems for the customers. Thus, we want the simulation we give them
to precisely match the behavior of the chip (to the limits of the
technology), as such our simulator is a cycle accurate design-level
encapsulation of the exact chips we send (and is generated from the
same Verilog we run through the synthesizer). This hopefully means
that the only mismatches between the behavior of the simulator and the
actual chip are due to physical artifacts (and not logical design
artifacts).

This implies that our simulator needs to be "faster" than a typical
Verilog simulator. Part of that speed we get by restricting the
Verilog to a subset that has semantics that can be simulated faster.

One could argue that one could get the same speed by writing an
architectural/behavioral model. However, that introduces the problem
of design aritacts as mentioned above--and these are not acceptable to
management, at least not in general, so we do have some parts of the
chip that are modelled architecurally, but only in some carefully
chosen places where we can carefully track that the architectural
model really won't introduce artifacts and where the performance
difference is worthwhile, and all the important properties are
simulated from the exact design.

There is no discounting the value of a *standard* Verilog simulator
also, so the design is also run through standard Verilog simulations,
and also other tools such as lint checkers. One thing we do is
compare waveforms of our sped-up simulation to the standard Verilog
simulation, discrepancies there must be carefully scrutinized and we
don't allow diferences at cycle boundaries (although we do allow some
differences at the sub-cycle level, but no glitches).

However, the key point is that our designers are designing hardware
that we can simulate accurately (and quickly), and our management is
willing to sacrifice some of their coding flexibility to achieve that
goal. So, our designers design in the synthesizable subet that our
simulator enforces.

I am still a tad disturbed by the idea of a Verilog simulator that
intentionally fails to comply with the Verilog standard (although I
can easily see the value of a command-line switch that enforces some
such set of rules).

I think this is a matter of semantics. For the subset of Verilog we
allow, it is crucial that the semantics of our simulator precisely
match those of the standard. We don't allow certain Verilog
constructs precisely because we could not give a correct simulation of
those constructs and still meet our other goals. It would also have
been a failure if our simulator could not handle any significant
Verilog contruct that was synthesizable, because it is important that
the code which we synthesize from is the same that we simulate from.

Indeed, some people intentionally write synthesisable test benches,
the easier to map them on to accelerator hardware. My own
preference (and experience) leads me the other way, towards making
testbenches as "software-ish" as possible.
....
Me, I'm not convinced - but it's an interesting and open issue.

Yes, the results on test benching with our simulator still have to be
seen.

Much of the testing of the simulated chips is done in C (interfaced to
our simulator), so the Verilog semantics of the simulator are not
relevant there. (Another whole set of testing is done at an even
higher level, where the tests are written in assembly language for the
chip and those are simulated and the results checked at the chip's
assembly language level.)

Low level (verification) testing is also done in yet another language
using another tool. However, the verification enginners are keen on
integrating their tests into our tool to get faster turn-arounds.

Some testing, such as setup and hold times, are not likely to be ever
done with our tool, at least not as it is currently architected,
simply because the tool cannot simulate the design correctly at that
precision--it is inherent in the tools cycle-based nature.

One curious aside worth mentioning is that it isn't the behavioral
nature of Verilog that gives our simulator problems. In fact, our
simulator is actually much better internally on certain behavioral
pieces of code than it is on a more synthesizable design. In fact,
some of the checks to prohibit behavioral code are not put in to
"protect" the correctness of the resulting simulation, but instead to
keep the designers from accidentally writing something
non-synthesizable and that is a management issue. I think those
checks will be relaxed for "test bench" code.

Still, I think the argument that learning only the subset of
synthesiazable Verilog and having a simulator that supports only that
subset is not an unreasonable position. I also think that there is a
reasonably small subset of "extensions" to that model which can
support test bench design--and most of those extensions don't require
all the complexity of Verilog (in particular how some of the feautres
interact).

I find it hard to believe that a test bench design methodology would
require one to know how a non-blocking assign with an internal delay
interacts with a different block that have both mixed edge and signal
sensitivities. And each of those features has it's place, but the
semantics of mixing them should mostly be left to language lawyers
whose job it is to ensure that the semantics does something at least
defensible if not entirely obvious, which is why I get so cranky ;-).
I don't think your point was ever that we should have a confusing
language, just that one shouldn't "throw the baby out with the bath
water" in trying to get a simpler language. And, here I agree. There
are features of Verilog that the chip designers I support have no use
for, but which make perfectly reasonable features of the language when
viewed from other perspectives.

It's not my argument that those features should never be learned by a
student of the language, just that the subtle interactions between the
features isn't the first thing students should be taught nor graded
on. The only time one should have to learn the subtle features is to
know when they might bite you. And if one can avoid a problem by not
using some combination of features, it might be best to just say,
don't use that combination, pretend it isn't in the language.

One example I remember Steve Sharp teaching me when I worked with him
relates to udp's. It turns out that they have really obnoxious
behavior in response to certain transitions involving x signals--not
what one would really want. That behavior is only a problem if one
desings udp's to do certain things and then expose those things to
signals which can go to x. So, it's not that one should never use a
udp, but one might wish to design the problematic devices with
something other than a udp, especially if one isn't certain whether
one will fall into the ugly part of the Verilog semantics. For those
devies it might be better to pretend that udp's were not part of the
language, rather than learning the problem transitions.

-Chris

*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
19 Bronte Way #33M voice : (508) 435-5016
Marlboro, MA 01752 USA fax : (508) 251-2347 (24 hours)
------------------------------------------------------------------------------

 

[Lalith]

always @(sel or a or b or c or d) begin : CombMux
case (sel)
2'b00 : q = a;
2'b01 : q = b;
2'b10 : q = c;
2'b11 : q = d;
endcase
end // CombMux

What's still not really clear (to me) is whether one should use
non-blocking or blocking assignments. The rule is to use non-blocking
assigments for sequential always blocks, but ...

I dont know if i understand exactly what your confusion about blocking
and non blocking assignments is, but here goes.
The idea is that, in sequential circuits, you typically have signals
separated by flip flops. you wouldnt want one signal value racing
across two flip flops at a clock.
as an example if you had

A ---- FF ------B -------FF--------C
C would get A's value if you did not use non-blocking assignments

A good way to understand/ visualize this is that the simulator does
not block the assignment, instead it runs through all of them at the
same instant
b<=a
c<=b

Hope that helped,
-Lalith