On 10 Apr 2005 21:21:41 -0700, "Taras_96" <> wrote:
>I've heard a number of theories about when to use signal assignments or
>variable assignments for RTL code, and when to use concurrent or
>sequential VHDL. Does anyone have an opinion on the following 'rules
>of thumb'?
I have a useful opinion on rules of thumb in general: If you use
only your thumb to design things, they are quite helpful. Once you
graduate to using all ten fingers, the rules of thumb tend to get
consigned to the scrapheap of "things I learned along the way".
>1) Model combinational logic within a process with a full sensitivity
>list ...
In VHDL you have no choice - despite what you say about "concurrent
logic" (see below).
> ... using variable assignments
Assign to variables whenever it aids the noble cause of readability
and clarity of expression.
>Coming from a Verilog background, I was told to model combinational
>logic, using an always@(/*AUTOSENSE*/) ...
Yuck. What is (/*AUTOSENSE*/)? (I can guess.) Today,
Verilog-2001 always@* is fully supported by all serious tools.
> ... procedural block with blocking assignments.
Yes, that's entirely appropriate.
> The VHDL equivalent of this is using a process with a
>full sensitivty list, and using variable assignments.
No it isn't. VHDL variables are invisible outside the process
that defines them, but this is not true for Verilog regs.
> However, the
>variables are only visible from within the process, and thus it is
>difficult to get the results out to a sequential block (clocked
>process) bit of code.
So, you need a signal. You have no choice. It is appropriate.
>Once way of getting around this is by assigning the variable to a
>signal once all combinational logic has finished
An excellent idea.
> however, this breaks
>the general rule of not mixing blocking and non-blocking (in Verilog),
>or signal and variable (in VHDL) assignments
Please cite a reference to this "general rule". It is neither a
rule, nor general. It is a misunderstanding of the rule imposed
by almost every Verilog synthesis tool: "never mix blocking and
nonblocking assignment TO THE SAME VARIABLE". In VHDL such a "rule"
would be meaningless, because you can make variable assignment only
to variables, and signal assignment only to signals. Variable
assignment to a variable, and signal assignment to a signal, may
be freely mixed in a single process, of course.
[ mixing var:= and sig<= ]
> also seems cumbersome.
Why?
>>"In general:
>>
>>sequential blocks use non-blocking <=
>>combinational blocks use blocking ="
>http://groups-beta.google.com/group/...fd131568d5e217
In Verilog, that's a reasonable starting point.
In VHDL it makes no sense.
>>"Use non blocking assignments within sequential (clocked) blocks:"
>http://groups-beta.google.com/group/...b6011c11acbf7/
In several messages on comp.lang.verilog I have explained at some
length why this is pernicious nonsense. Others have responded with
entirely valid reasons why they personally choose to follow that
guideline even though they know it is not mandatory.
Please try to limit the quantity of Verilog baggage you bring
to VHDL. VHDL has enough baggage of its own, without adding
spurious stuff.
>Another solution is to migrate all combinational code into the
>concurrent section of VHDL
AARGH - As I said in an earlier response to you, there is NO
SUCH THING as "the concurrent section of VHDL" in the sense
you are using here. The body of an architecture contains
a collection of processes. These processes execute independently
and concurrently. However, sometimes processes appear in
disguise...
* a concurrent assignment is in fact a process, sensitive to
all signals that appear in the expression that it calculates,
containing an assignment to the target signal and nothing else
* a component instance is a rather complicated process made up
of the collection of processes in the architecture body of the
instantiated component
.... and so on.
> - but why then, in Verilog, would you write
>combinational code in procedural blocks rather than using assign
>statements?
So that you can say more complicated things clearly.
>Is there any other disadvantages in writing combinational code in
>concurrent VHDL - perhaps code clarity? The disadvantage mentioned
>above is not really relevant in RTL.
As pointed out above, "concurrent" VHDL is simply a shorthand
way of writing a particularly simple kind of process.
[...]
>So in summary:
>If you are to write combinational logic
[...]
> but this seems to go against conventional wisdom.
Conventional wisdom is often deluded, but far worse, it often is
transformed (by time and the passage of newsgroup postings) into
half-truth and urban myth. Trust it at your peril.
--
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, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:
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.
.
Similar Threads
