Expression sizing: VHDL vs. Verilog

[Martin Vass]

Hi all -

in VHDL, you can write code like this:

process is
variable A, B, C : SLV8;
variable i, j, k, m : integer;
begin
A := X"06";
B := X"90";
i := 7; j := 4; k := 3; m := 0;
C := B(i downto j) & A(k downto m); -- produces X"96"

In other words, you can have arbitrary expressions as slice indexes.
You can't do this in Verilog - the indexes must be constant (with a
minor extension for V-2001, which isn't relevant here).

This got me thinking about expression sizing in VHDL and Verilog. In
Verilog, expression sizes are statically determined, during
compilation. This makes it impossible to have variable slice
("part-select") indexes (although you can have one variable index in
V-2001, as long as the length is still static). The rules are complex
and not very logical, but at least the compiler always knows what the
size of any object is, and can do static error detection.

VHDL is very different. If you change one of the indexes in the code
above so that the concatentation doesn't contain 8 bits, then the code
will still compile and elaborate Ok, and will only produce an error at
runtime. The VHDL version is much more flexible, but presumably (a
lot?) less efficient.

My problem is that I don't actually understand what the rules are for
VHDL. There doesn't seem to be anywhere in the LRM that states
explicitly how objects are sized, extended, or truncated, or when,
during expression evaluation. Or have I just missed it? Can anyone
explain expression sizing, or point me to a reference?

Thanks -

-MV

 

[Jonathan Bromley]

On Wed, 14 Mar 2007 19:45:17 +0000, Martin Vass

Martin,

My problem is that I don't actually understand what the rules are for
VHDL. There doesn't seem to be anywhere in the LRM that states
explicitly how objects are sized, extended, or truncated, or when,
during expression evaluation. Or have I just missed it? Can anyone
explain expression sizing, or point me to a reference?

Expression evaluation in VHDL is simply the execution of a
series of function calls - remember you can write your own
overloads for "+" and so on. Functions in VHDL are "dynamically
elaborated"; the consequence is that the return subtype can be
chosen by the function itself. Take, for example, (one of)
the RESIZE functions from numeric_std (this is only a
paraphrase, but it illustrates the point in question):

function RESIZE(V: unsigned; N: natural) return unsigned is
-- We can declare variables based on the parameters:
variable result: unsigned (N-1 downto 0);
begin
-- and we can determine the size of array parameters:
assert V'LENGTH >= N
report "RESIZE: result may be truncated"
severity WARNING;
....
return result;
end;

In a similar way, arithmetic functions such as "+" determine the
size of their results from the size of their arguments. For example,
NUMERIC_STD."+" [unsigned, unsigned] returns a result that is
the same width as the wider of its two arguments.

In Verilog-speak, you would say that all VHDL expressions are
"self-determined", but the determination is performed at
runtime by the arithmetic operators themselves, not at
compile/elaborate time.

The only operation you CAN'T overload (c'mon, what about it,
VHDL-200x?) is the assignment operator. When you finally
come to copy the result of the whole expression into its
target, there is a runtime check that the array shape matches.
--
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
(e-mail address removed)
http://www.MYCOMPANY.com

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

 

[Martin Vass]

On Thu, 15 Mar 2007 09:35:55 +0000, Jonathan Bromley

Hi Jonathan -

In Verilog-speak, you would say that all VHDL expressions are
"self-determined", but the determination is performed at
runtime by the arithmetic operators themselves, not at
compile/elaborate time.

I've been writing VHDL for over 10 years and this has never really
occurred to me, even though it seems obvious now that you've said it.
I guess I only had to think about this when writing the same code in
VHDL and Verilog.

This leads to another question - what is the point of the Verilog Way?
What advantage do the propagate up/propagate down again rules actually
give you? My immediate thoughts are (but my head is still spinning!) -

1) Everything is static, so the compiler can determine all object
sizes during compilation. This is safer than doing it at runtime; you
don't want to get an expression error after running for a couple of
days. But, hang on a minute - the Verilog rules also take into account
the *destination* size. So, there's no error checking anyway - you
can't tell if the expression has the 'wrong' size, because the size is
just adjusted to fit the destination. Ok, you can't get an error
flagged after 2 days running, but the downside is that your code is
just plain wrong anyway, and you may never find out.

2) It's presumably easier to write the Verilog compiler. But so what?
That doesn't help me.

So, what *is* the point of the Verilog sizing rules? Is it just a
badly designed language?

Thanks -

-MV

 

[Jonathan Bromley]

This leads to another question - what is the point of the Verilog Way?

I think you have somewhat answered your own question
For me, the one really big advantage is that Verilog makes it
very easy to capture carry/overflow information if I need it.
5bits<=4bits+4bits correctly captures the carry bit.
Doing the same in VHDL is irksome.

Ok, you can't get an error
flagged after 2 days running, but the downside is that your code is
just plain wrong anyway, and you may never find out.

As we tend to say on courses:
Verilog: You know best.
VHDL: Nanny knows best.

As I tend to say in private:
Verilog -> West Coast hippydom
VHDL -> European bureaucracy

Take your pick, according to taste.

I have to admit that I find it VERY frustrating that I can't overload
the assignment operators in VHDL. I'm very glad to be told
about my own stupidity, but I also would very much like to be
able to define types that have automatic rounding and/or
truncation behaviour when I want it. I fell foul of this when
writing a fixed-point package for VHDL - which, in other
respects, was a rather nice example of why VHDL's way is
so much more flexible; arithmetic operators can "know about"
the attributes of their operands in an intelligent way. But
I could never find a way to prevent idiots (i.e. me) from
copying a fixed-point number with one scaling on to a
fixed-point variable with the same width but different
scaling, thereby trashing the numeric value. Overloading
of the assignment operator would have permitted me to
build mathematically-reasonable, synthesisable rounding
and overflow behaviour into such assignments.

David Bishop, writing the package that's now part of
VHDL-200x, had more staying power than I did

2) It's presumably easier to write the Verilog compiler

I am not at all sure about that. And don't even ask about
SystemVerilog.

So, what *is* the point of the Verilog sizing rules? Is it just a
badly designed language?

No, it's not badly designed; it just chooses a set of compromises
that typically seem rather bizarre to the averagely thoughtful
computer-science-literate grunt like you or me. In fairness,
as I've grown to know Verilog more intimately I have gained
considerable respect for its far-sighted design and its (albeit
often counterintuitive) internal consistency.

Personal prejudice only: The arithmetic sizing/signing rules
seem to me to be an ill-advised attempt to make simple
things really easy, with the inevitable side-effect that
complicated things are somewhere on the scale of
difficult to impossible. VHDL goes too far the other way:
in an attempt to be elegant and consistent, it makes
it unpleasantly hard to do some rather simple things,
whilst making it possible (it's never easy) to do the
really hard stuff.

It's not often that I draw attention to the own-opinions-only
disclaimer in my sig, but this is definitely such a moment!
--
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
(e-mail address removed)
http://www.MYCOMPANY.com

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