«

"William Wallace" <> wrote in message
news: om...
> 1. Is there a general rule I can use to know when I need to use the
> word "is" and when I do not? Also, what good does making somebody
> type these two characters do?

It means, for example, that the syntax doesn't need parentheses
around the selector of a "case" statement, because "is" acts as
a separator between the selector and the rest of the statement.

> 2. Is there a general rule I can use to figure out when two words are
> combined into one word (e.g., "elsif") versus being kept as two words
> (e.g., "end if")?

Yup. The only such elision in VHDL is "elsif" (a slightly mysterious
spelling; "elif" or "elseif" would perhaps have made more sense).
Contrast with Verilog's absurd statement bracketing syntax, with
the huge collection of elided terminators (endmodule, endcase,
endgenerate... and a scad more of them in SystemVerilog) and
interminable repetition of "begin...end".

> 3. Is there a general rule I can use to figure out when I need to put
> a semicolon (e.g., after the generic section and also the port section
> in the component declaration) and when I do not (e.g., not after the
> generic section but only after a port section of an instantiation)?

I agree this is fidgety syntax. Semicolon acts as:

- a statement TERMINATOR (one after every statement or declaration)
- a list SEPARATOR (one after every port specification in an
entity, except after the last one)

The second of these is likely to be regularised in VHDL-200x,
so that you can use semicolon at the very end of a port list if
you wish.

As for the instantiation syntax, surely it makes sense that
the port and generic lists of an entity are quite separate
things, but the port and entity bindings on an instance
are part of the same statement?

> 4. Why if I pass a argument, say a std_logic_vector, to a function
> that takes a std_logic_vector, do I need to use data_in(arg'low) in
> the function as opposed to data_in(0). Why doesn't VHDL automatically
> rejustify a function call, say, function(data(15 downto ) to
> data_in(7 downto 0) in the function automatically?

So you can find out what you were given. If you want to renormalise
the input vector, you can easily do that using alias, constant or
a variable:

function f (a: in std_logic_vector) return stuff is
constant norm_a: std_logic_vector(a'LENGTH-1 downto 0) := a;
begin
...

This is one of several areas where VHDL has immense superiority
over Verilog. See my recently posted fixed-point arithmetic
package for a more extended example.

> 5. Is there a better way to bit reverse a bus than "new_bus(7 downto
> 0) <= old_bus(0) & old_bus(1) & ... & old_bus (7);", which gives my
> hands cramps for large busses.

Yup; use a for loop or a generate loop, depending on the situation.
Unlike Verilog, you can do it in a completely general way, thanks to
exactly the thing you were complaining about with the function
arguments. (Needs VHDL-93 for the "reverse_range" attribute;
without that, a bit more work is required but it's still easy.)
There is an appealing recursive formulation too, also impossible
in Verilog, but this version is more practical.

function reverse_any_bus (a: in std_logic_vector)
return std_logic_vector is
variable result: std_logic_vector(a'RANGE);
alias aa: std_logic_vector(a'REVERSE_RANGE) is a;
begin
for i in aa'RANGE loop
result(i) := aa(i);
end loop;
return result;
end; -- function reverse_any_bus

Show me how to do that in Verilog

> 6. What advantage is there in not allowing an port output to not be
> used on the rhs of an assignment in a module, forcing the RTL authors
> to create internal versions of such signals (e.g., "signal oData_v
> std_logic_vector(3 downto 0);") and later doing an assignment such as
> "oData <= oData_v;"?

It gives better consistency between entities and subprograms, but
I agree that it's a bit of a nuisance. On the other hand, creating
an internal signal is hardly a five-star headache.

> I have actually seen RTL code from VHDL
> engineers who did not know Verilog come up with even more ludicrous
> ways of solving this problem (routing an output back into a module as
> an input for use on the RHS of assigments inside the module).

There are people writing execrably bad VHDL, just as there are people
writing execrably bad Verilog. That's life.

> I have concluded that the people who came up with VHDL syntax were not
> working with each other, not referring back to previous decisions they
> made when making new ones,

Hmm. Maybe that's why the VHDL LRM is half the thickness of the Verilog
LRM, but is considerably more precise and consistent.

> and/or took the concept of "strongly typed"
> to a ludicrous extreme.

You mean, like, they chose to USE that concept? There's plenty that
needs fixing about VHDL, but very little of it is stuff that the
Verilog camp are likely to be able to teach us!

> It is also my belief that if it weren't for the government mandate,
> and the hordes of VHDL-only engineers these mandates created (VHDL
> fanatics who refuse to learn a better HDL), VHDL would be dead.

Believe away. You have many supporters.

> Any VHDL apologists care to explain?

I prefer to think of myself as an "HDL apologist", as someone who's
been using both Verilog and VHDL for a decade and who is very aware
that both have their considerable strengths and weaknesses.
--

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:
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.

A few responses to "Jonathan Bromley" <>

> function reverse_any_bus (a: in std_logic_vector)
> return std_logic_vector is
> variable result: std_logic_vector(a'RANGE);
> alias aa: std_logic_vector(a'REVERSE_RANGE) is a;
> begin
> for i in aa'RANGE loop
> result(i) := aa(i);
> end loop;
> return result;
>end; -- function reverse_any_bus
>
>Show me how to do that in Verilog

It's a trick. But is it really better than:

`define BITS_n 8
data_out[`BITS_n -1:0] <= data_in[0:`BITS_n:0];

Show me how to do that in VHDL, please! It is much more readable,
understandable, and concise than the 11 lines necessary to do the
same thing with your function.

> > 6. What advantage is there in not allowing an port output to not be
> > used on the rhs of an assignment in a module, forcing the RTL authors
> > to create internal versions of such signals (e.g., "signal oData_v
> > std_logic_vector(3 downto 0);") and later doing an assignment such as
> > "oData <= oData_v;"?
>
> It gives better consistency between entities and subprograms, but
> I agree that it's a bit of a nuisance. On the other hand, creating
> an internal signal is hardly a five-star headache.

It is non-obvious and a major nuisance if you have not seen the
workaround before. Many an engineer who has self-taught himself
many other languages will bang his head for a few hours figuring
this VHDLism out. Once you learn the workaround, it's not a big
deal, I suppose.

> There are people writing execrably bad VHDL, just as there are people
> writing execrably bad Verilog. That's life.

In my experience, a much larger percentage of VHDL designers write
bad code. Just my observation.

> > and/or took the concept of "strongly typed"
> > to a ludicrous extreme.
>
> You mean, like, they chose to USE that concept? There's plenty that
> needs fixing about VHDL, but very little of it is stuff that the
> Verilog camp are likely to be able to teach us!

You act as though being strongly typed is a good thing. I'll take
C over ADA any day, and I'll take Verilog over VHDL as well.

Take two advanced designers with similar design philosophies (code,
test modules exhaustively, or if that is not feasible, identify and
test corner cases, then test the whole system), and strip the
advanced VHDL designer of all of his hack functions he relies
on, and put him head to head against an experienced Verilog
designer similarly stripped of stuff he routinely re-uses,
give them the same design specification, and I firmly believe
that the Verilog designer will get it done, simulated, verified,
and synthesized while the VHDL designer is still trying to
re-create VHDL crutches he has long forgotten were not part
of the language (e.g., support functions). Take two new users,
and the new VHDL designer will barely have time to test at all
by the time the market window closes.

VHDL has unnecessary overhead, and overhead costs money and time
to market. Which is probably why, in my experience, and in the
absence of a government mandate, Verilog is used the vast majority
of the time.

reg [`BITS_n -1:0]William Wallace wrote:
> A few responses to "Jonathan Bromley" <>
>
>
>>function reverse_any_bus (a: in std_logic_vector)
>> return std_logic_vector is
>> variable result: std_logic_vector(a'RANGE);
>> alias aa: std_logic_vector(a'REVERSE_RANGE) is a;
>>begin
>> for i in aa'RANGE loop
>> result(i) := aa(i);
>> end loop;
>> return result;
>>end; -- function reverse_any_bus
>>
>>Show me how to do that in Verilog
>
>
> It's a trick. But is it really better than:
>
> `define BITS_n 8
> data_out[`BITS_n -1:0] <= data_in[0:`BITS_n:0];
>
> Show me how to do that in VHDL, please! It is much more readable,
> understandable, and concise than the 11 lines necessary to do the
> same thing with your function.


To complete Jonathan's answer I'll say that reversing the bits has two
different possible meanings. Let's take an 8 bits vector:

variable A: BIT_VECTOR(7 downto 0); -- VHDL

reg [7:0] A; // Verilog

The MSB (leftmost) bit is indexed 7 and the LSB (rightmost) is indexed 0.

You may want another representation of the same data where the MSB is
indexed 1 and the LSB 8. In VHDL, as in Verilog, it's very easy:

variable B: BIT_VECTOR(1 to ; -- VHDL
B := A;

reg [1:8] B; // Verilog
B = A;

But you may also want to modify the data by having the MSB becoming the
LSB and the LSB becoming the MSB. In VHDL it's a bit more difficult and
you need a for loop. As Jonathan explained VHDL attributes may be
helpfull. I thought it was the same in Verilog, without the help of
attributes. Your solution is interesting. I didn't know this syntax.
Neither did my version of Modelsim. Could you explain where it comes
from and what are the associated semantics?

Regards,
--
Renaud Pacalet, ENST, 46 rue Barrault 75634 Paris Cedex 13
###### Tel. : 01 45 81 78 08 | Fax : 01 45 80 40 36 ######
# Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/ #

Hi,


William Wallace wrote:
>
> You act as though being strongly typed is a good thing. I'll take
> C over ADA any day,

Hmm, I think it depends on the problem that has to be solved.
For large projects, I wouldn't take C. Would you?
I love to program in C/C++, did it for years and will
continue to. But, to be honest, I also see its weaknesses.
If there are no important reasons to use C/C++ (e.g.,
maximize speed of executable) I choose another language.
I've spent too many hours hunting stupid bugs that
slipped into the code due to the "creative interpretation"
of the source code by the C/C++ compiler.

We are facing design complexities, where the major problem
is not designing but verifying that the system works
as intended. Hence, time to market is not just determined
by the design time but also by the effort to fix all the
bugs. The software guys already faced this problem and
found their solutions (e.g., shift away from C/C++
if possible).

So, the major question is whether it pays of to invest some
more effort during design in order save verification time.
In my opinion, this is the better approach for now and
especially for the future.



--
Edwin

Jonathan Bromley wrote:

>
> Many an engineer who has taught himself Verilog will screw up
> a few designs by misuse of blocking and nonblocking assignment.
> Your argument is in favour of proper training and learning, not
> a reason for using one language rather than another.

It's worse than that. The fatal Verilog flaw of not making
a distinction between variable and signal causes *eternal*
confusion, even among "gurus", and leads to absurd rules
like "don't use both blocking and nonblocking assignments
in the same always block". In VHDL, this would mean
"don't use both variable and signal assignment in the same
process". Verilog courses will happily "train" you on this
fantastic insight. Talking about progress ...

Regards, Jan

--
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
Bored with EDA the way it is? Check this:
http://jandecaluwe.com/Tools/MyHDL/Overview.html

Renaud Pacalet < e> wrote in message news:<bi4kpp$1jmr$>...
> Could you explain where it comes
> from and what are the associated semantics?
>

It was a rant, and this particular rant was based on a problem for which I do
not remember all the details, so I withdraw it

William Wallace wrote:
>
>
> Types in VHDL are nice, if you know what you're doing, and realize
> you're playing with sharp knives, but too many VHDL designers use
> these sharp knives as crutches, without taking the time to consider
> what the types represent, and run into, for example, sign extension
> bugs, counters with more bits than necessary, etc.

It's not using (abstract) types that will cause problems, but *not* using
them. For example, by trying to map everything to std_logic_vector.

> I've seen std_logic_vectors converted to signed, sent to another
> module, where it was again converted to an integer, where it was added
> to a constant integer and incorrectly used in a comparison with
> another integer that had its range restricted to positive numbers,
> resulting in a bug that was not detected due to (and this is not a
> VHDL issue) incomplete testing at the module level.

Where was the bug exactly? There's nothing wrong with comparing
a potentially negative number with a positive one.

> If only this
> whole thing had been done with std_logic_vectors...

but you *can't* without ending up with obscure code. For example,
you cannot use std_logic_vector as a number without either
- using non-standard, even standard-violating, obscure packages (please don't!)
- coding at a very low level with all 0's and 1'
- using obscure type conversions all over the place

> You can chalk it up to poor engineering (if a module level test bench
> had be written testing the range of inputs, this bug would have been
> discovered earlier and less expensively), but my intuition tells me
> that if the whole thing had been coded with std_logic_vectors, or in
> Verilog, the issue would not have reared its head.

Use reason over intuition this time then. That should tell you
that trying to use a strongly type language as lowly type one,
will naturally get you into trouble.

The problem you describe seems to have something to do with
the valid range of a number. What would be the appropriate
type then? Obviously, a constrained integer subtype. These
at least give you a *chance* to flag a problem much earlier than
any of the other types (including the Verilog ones) because
you basically get bound-check assertions for "free".

Regards, Jan


--
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
Bored with EDA the way it is? Check this:
http://jandecaluwe.com/Tools/MyHDL/Overview.html

Jonathan Bromley wrote:
"[..]
Your argument is in favour of proper training and learning, not
a reason for using one language rather than another."

In article <>, Jan Decaluwe wrote:

"[..] The fatal Verilog flaw of not making
a distinction between variable and signal causes *eternal*
confusion, even among "gurus", [..]
Verilog courses will happily "train" you on this
fantastic insight. Talking about progress ..."

Ah, miseducation. I recently looked at HDL lecture notes by a
Verilog lecturer reputed to be anti-VHDL. There was one just
VHDL example in the notes I saw. He used a signal assignment
operator on a variable.