On making Verilog more like C
Elliot H. Mednick
International, posted a request for suggestions as to what should --
and should not -- be added to the Verilog language. So far, this has
several good (and not so good:-) suggestions, and a great deal of
discussion, and I will be posting a follow up in the coming weeks.
However, I must comment now on some of the suggestions that would
change the fundamental syntax of the language, that is, that Verilog
be made to look more like C. Realistically, nobody is going to change
the syntax of Verilog to make it more like C, or any other language
for the same reasons that nobady is going to change PASCAL to make it
more like C. To do so would render existing models obsolete, and
would require much retooling and retraining.
Let us say, for the sake of argument, that Verilog is changed to
support curly braces instead of begin/end/fork/join. We would then
have to change concatenation to something else (say '(*' and '*)'; can
you name the language?) as well. Perhaps we can add a compiler
directive, say `C-LIKE to the beginning. Now, lets say you start
writing models in the C-style. How long will it take before the tools
that you use (simulators, synthesis, timing analysers, etc) are
retooled to support the new style?
With these suggestions, there is an underlying assumption that this
C-style is easier to use, or that more hardware engineers would feel
more comfortable using C-style than the current style. However,
o Most hardware engineers do not have enough programming experience
to have a preference beteen C-style and Pascal-style other than
the number of characters required to type,
o C is a very commonly-used language, not because it is a good language,
but because, by either an accident of history or great educational
discounts, Unix, which is an old, mediocre operating system,
dragged C with it to all its host systems. Is is generally
observed that, although C is an adequate systems language, practical
application development, and inexperienced programmers (i.e. many hardware
engineers), are best left to Pascal, Modula, or to other strongly-typed,
easy-to-read LALR1 language. C is a lower-level language than these;
Verilog should be on same the level as, or higher than, Pascal.
o I admit that electric-} can save a slight amount of time.
o We would be more likely to add features to Verilog, perhaps in
a manner more like how C++ extends C.
BTW, the Language Committee had considered and rejected pre- and post-
increment and decrement because of the ease by which it can be misused
and its inability to be synthesized under certain circumstances which would
be difficult to document. We also considered assignment operations
(-=, +=, etc.), but also rejected because of a conflict with current syntax
(<=). Both of these were deemed syntactic sugar and not necessary.
We are always open to reconsider any decision, given a strong case.
Perhaps it would be informative if I posted a list of what the LS has
accepted by added to the 2.0 spec, what was rejected, and what was tabled
for 3.0. In the mean time, keep those suggestions coming! Some of them
are new to us.
--
Elliot H. Mednick P.O. Box 150
Wellspring Solutions, Inc. Sutton, MA. 01590
ell...@Wellspring.com +1 508 865 7271
John Hagerman
ell...@Wellspring.COM (Elliot H. Mednick) writes:
> Realistically, nobody is going to change the syntax of Verilog to
> make it more like C ...
Lesson for the reader: Next time you design a language, base it on a
language that many people already like...
> o Most hardware engineers do not have enough programming experience
> to have a preference beteen C-style and Pascal-style other than
> the number of characters required to type,
>
> o C is a very commonly-used language, not because it is a good language,
> but because, by either an accident of history or great educational
> discounts, Unix, which is an old, mediocre operating system,
> dragged C with it to all its host systems. Is is generally
> observed that, although C is an adequate systems language, practical
> application development, and inexperienced programmers (i.e. many hardware
> engineers), are best left to Pascal, Modula, or to other strongly-typed,
> easy-to-read LALR1 language. C is a lower-level language than these;
> Verilog should be on same the level as, or higher than, Pascal.
>
> o I admit that electric-} can save a slight amount of time.
I would accept these arguments more easily if a decent Emacs Verilog
mode existed -- not one of the many "insert a BEGIN/END pair here"
modes, but a true know-how-to-indent-Verilog mode. The BEGIN/END
syntax makes writing such a mode a real pain in the ass (I've tried).
I'm not suggesting a change, but I reiterate my above comment.
Also note that the second point is opinion more than fact; C is not a
"lower-level" language, nor is it any harder to read than any other
language. The "accident" that makes C so popular is the combination
of features, such as break statements, I/O libraries rather than extra
syntax, local declarations, etc. Since the combination is generally
useful, I doubt that it was accidental. The use of braces, however,
more probably was.
- John
--
hage...@ece.cmu.edu
Paul Israel
> With these suggestions, there is an underlying assumption that this
> C-style is easier to use, or that more hardware engineers would feel
> more comfortable using C-style than the current style. However,
>
> o Most hardware engineers do not have enough programming experience
> to have a preference beteen C-style and Pascal-style other than
> the number of characters required to type,
>
I take strong exception to this statement. The vast majority of HARDWARE
design engineers that I've worked with have vast experience as programmers.
Frequently, they are required to write their own test code or diagnostics
to debug their hardware, and C is more and more becoming the lanquage of
choice for such procedures. The low-level access that the language allows
makes it easy to exercise the hardware directly, while the higher-level
constructs make it easier to use than assembly code.
> o C is a very commonly-used language, not because it is a good language,
> but because, by either an accident of history or great educational
> discounts, Unix, which is an old, mediocre operating system,
>
Unix was designed to be a good software engineering environment, which
extends well to the use of HDLs too. As an "old, mediocre operating system",
it continues to perform this function well, arguably better than any other
system on the market today. It appears on such a wide variety of hosts because
it was the first operating system written in a high-level language (namely "C")
thus making it possible to port to any machine for which a C compiler could
be written. Since UNIX was written by engineers for engineers, it is hardly
surprising that it appears as the native environment for so many engineering
workstations.
> dragged C with it to all its host systems. Is is generally
> observed that, although C is an adequate systems language, practical
> application development, and inexperienced programmers (i.e. many hardware
> engineers), are best left to Pascal, Modula, or to other strongly-typed,
> easy-to-read LALR1 language. C is a lower-level language than these;
> Verilog should be on same the level as, or higher than, Pascal.
Once again, I take exception to your view of the majority of hardware
engineers as "inexperienced programmers". This may have been true in the past,
but the engineers coming on to the scene over the last ten years have much
better programming skills, and hence tend to use them more often, then
their predecessors. I agree that C is a lower level language than Pascal
or Modula, but that is precisely why it is so appealing for hardware
engineers to work with. And since HDLs exist for the purpose of aiding
hardware design, it is this same sort of low-level access to the
hardware structures that make it genuinely useful to us. Making the language
higher level than Pascal will start making things too abstract, taking
control of the logic design away from the designer and leaving it solely
in the hands of the synthesis software. I find that approach a little too
inflexible.
I guess what I'm trying to say is that high-level language constructs
are fine, especially if all you're doing is behavioral simulation, but
low-level constructs are often needed when you're getting down to the
logic gates. So I guess you need something both above and below Pascal.
I think your argument might also be a bit stronger if Cadence managed
to produce a compiler capable of more accurate error reporting, so it could
better aid those poor "inexperienced programmers" you're so concerned about.
No language is simple to use with lousy error reporting.
--
Paul Israel, Senior Smartypants, Unisys Corporation, San Jose, California
isr...@risky.convergent.com Disclaimer: "Who, me? I wasn't even there!"
Quote: "Don't think of it as a gun - think of it as a remote control for
turning people off." - Roger Guts, PI
Bakul Shah
>Let us say, for the sake of argument, that Verilog is changed to
>support curly braces instead of begin/end/fork/join. We would then
>have to change concatenation to something else (say '(*' and '*)'; can
>you name the language?) as well. Perhaps we can add a compiler
>directive, say `C-LIKE to the beginning. Now, lets say you start
>writing models in the C-style. How long will it take before the tools
>that you use (simulators, synthesis, timing analysers, etc) are
>retooled to support the new style?
Perhaps you (and the committee) may be interested in my
experience with this -- I found that the new curly brace syntax
can happily co-exist with the current syntax.
Over the past weekend just for kicks I added rules for curly
braces to my experimental Verilog parser. These rules allow use
of braces in place of begin, end, as well as a whole bunch of
other constructs that end with ``end<FOO>'' where <FOO> is
module, primitive, function, task, case, casez, casex and table.
Let me emphasize that these rules DO NOT disallow any existing
constructs (with one very obscure exception); they merely allow
an additional, alternate syntax for certain constructs. Yacc
reported there was one reduce/reduce conflict. The parser
accepted everything I threw at it including things like
always {
{a, b} = {c, {d{e, f}}, g};
}
The one exception is
always {
{a<=b?c:d, e} = some-expr;
}
That <= confuses the parser. To disambiguate this construct
a pair of parentheses are required around the comparison:
always {
{(a<=b)?c:d, e} = some-expr;
}
Such a use of concatenation on the LHS of an assignment must be
rather rare and obscure. I for one would be willing to use an
extra parentheses pair to gain this ability.
To ward off one possibile criticism, note that my parser parses
pretty much the entire language and I did not have to add any
kludges for this to work. Adding these rules should work for any
LALR(1) (or yacc based) verilog frontend and will take no more
than a few minutes of work. At the end of this message I have
attached an example of a program in the modified language for
your pleasure (or horror, depending on your point of view).
>o Most hardware engineers do not have enough programming experience
> to have a preference beteen C-style and Pascal-style other than
> the number of characters required to type,
All the more reason for adapting a C style because increasingly
people have to learn more than one language to get their job done
and a hardware engineer who is familiar with C-verilog (to coin
a term) will find it easier to write PLI routines in C..
>o C is a very commonly-used language, not because it is a good language,
> but because, by either an accident of history or great educational
> discounts, Unix, which is an old, mediocre operating system,
> dragged C with it to all its host systems. Is is generally
> observed that, although C is an adequate systems language, practical
> application development, and inexperienced programmers (i.e. many hardware
> engineers), are best left to Pascal, Modula, or to other strongly-typed,
> easy-to-read LALR1 language. C is a lower-level language than these;
> Verilog should be on same the level as, or higher than, Pascal.
C *is* a very commonly used language. It does not matter very
much why because the *practical implication* of this fact is that
it is much more likely that a Verilog user will be using C than
any other language.
I will also observe that Verilog is much closer to C in spirit
than any other programming language. The impedance mismatch
between Verilog and a higher level languages like Prolog, Scheme,
Haskell, Self, Eifell, Modula-3 etc. is much greater than say C
or C++. In terms of feature Pascal, Modula and C are at about
the same level and nowadays one can write equally type safe
programs in ANSI C.
Also note that people do not want a lax type system like in C;
they do want Verilog to be a strongly typed language (which is
why others have proposed adding ``extern'' and
module/task/function prototypes). It is just that the
conciseness of C appeals to an experienced user. Most
experienced programmers reject the notion that the mere presence
of a few English keywords makes a language more suited for
programming.
As for inexperienced programmers, the best thing that will help
them is *experience* and *guidance* from knowledgeable programmers,
not Pascal or Modula. Hopefully, they are inexperienced for once
and _experienced_ for the rest of their lives.
>We are always open to reconsider any decision, given a strong case.
To summarize, the strongest case I can think of is that a)
Verilog is already much like C and b) even hardware engineers
will end up using other programming languages and most likely it
will be C.
>Perhaps it would be informative if I posted a list of what the LS has
>accepted by added to the 2.0 spec, what was rejected, and what was tabled
>for 3.0. In the mean time, keep those suggestions coming! Some of them
>are new to us.
Please do.
Bakul Shah <b...@BitBlocks.com>
Here is a `braced' version of example 2.9 from the Thomas-Moorby
book. I also used prototype module & task headers, and abolished
an implicit forward reference by moving the task definition, all
of which should make type checking easier. [I hope this is okay
with Messrs. Thomas & Moorby]
module mark1Task {
task multiply(inout [31:0] a, input [31:0] b) {
reg [15:0] mcnd, mpy; //multiplicand and multiplier
reg [31:0] prod; //product
{
mpy = b[15:0];
mcnd = a[15:0];
prod = 0;
repeat (16) {
if (mpy[0])
prod = prod + {mcnd, 16'h0000};
prod = prod >> 1;
mpy = mpy >> 1;
}
a = prod;
}
}
reg [31:0] m [0:8191]; // 8192 x 32 bit memory
reg [12:0] pc; // 13 bit program counter
reg [31:0] acc; // 32 bit accumulator
reg [15:0] ir; // 16 bit instruction register
always {
ir = m [pc];
case (ir [15:13]) {
3'b000 : pc = m [ir [12:0]];
3'b001 : pc = pc + m [ir [12:0]];
3'b010 : acc = -m [ir [12:0]];
3'b011 : m [ir [12:0]] = acc;
3'b100,
3'b101 : acc = acc - m [ir [12:0]];
3'b110 : if (acc < 0) pc = pc + 1;
3'b111 : multiply(acc, m [ir [12:0]]);
}
pc = pc + 1;
}
}
Gavin Brebner
>"lower-level" language, nor is it any harder to read than any other
>language. The "accident" that makes C so popular is the combination
C is so low-level, that viewing it as a macro-assembler might be more
appropriate; it has semantics derived directly from PDP-11 assembler.
This is, of course, why it is such a good language for systems work, the
semantics of the target application - addresses, bytes, words, indirect
addressing modes, post / pre -increment etc. are built-in to the language.
For describing arbitrary hardware, however, the ability to deal with
abstraction is more important (IMHO). Here, C is but poorly equipped. Of
course, it can be done, but it is obvious it isn't really what the
language is for.
As for being no harder to read, C's generous use of side-effects disqualify
it, for me, from being an easy to read language.
>of features, such as break statements, I/O libraries rather than extra
>syntax, local declarations, etc. Since the combination is generally
>useful, I doubt that it was accidental. The use of braces, however,
All these, and more, exist in other languages, of course, in one form or
another; except that when it comes to local declarations, most languages do
a lot better than C.
If we are going to base Verilog on a popular, widely-used, long-lived language
should we not be using Fortran as the model ? :)
More seriously, the familiarity with C may even be a strong disincentive. There is
a large difference in methodology between programming in a sequential language
(C, Pascal, Fortran ...) as opposed to a parallel one (Occam, Ada, Verilog, ....)
I've always found that swapping between parallel and sequential languages involves
a significant alteration in style and thought process. Hiding this by copying
the same syntax may not be helpful.
---
Gavin Brebner,
Advanced Computer Research Institute,
1 Bd. Marius Vivier-Merle,
69443 Lyon Cedex 03, France
email: bre...@acri.fr
Tel : (33) 72 35 84 45
Fax : (33) 72 35 84 77
Paul Campbell
>be made to look more like C. Realistically, nobody is going to change
>the syntax of Verilog to make it more like C, or any other language
>for the same reasons that nobady is going to change PASCAL to make it
>more like C. To do so would render existing models obsolete, and
>would require much retooling and retraining.
>Let us say, for the sake of argument, that Verilog is changed to
>support curly braces instead of begin/end/fork/join. We would then
>have to change concatenation to something else (say '(*' and '*)'; can
>you name the language?) as well. Perhaps we can add a compiler
>directive, say `C-LIKE to the beginning. Now, lets say you start
>writing models in the C-style. How long will it take before the tools
>that you use (simulators, synthesis, timing analysers, etc) are
>retooled to support the new style?
I write occasional compilers, including a Verilog one .... I don't
see any reason why '{'/'}' couldn't be synonyms for 'begin'/'end'
in a future Verilog, braces used in this context would be unambiguous
as they occur in a different syntactic position from those used
in concatanation. To prove my point I just went and replaced 'begin'/'end'
with '{'/'}' in the YACC grammer I use for my compiler and recompiled it
presto-chango a Verilog that understands C-style braces (actually both styles),
it took about 2 minutes .....
fork/join is a different matter since you need something to distinguish
them from begin/end (maybe '['/']' .... fork { ...} wont do).
Paul Campbell
--
Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P
"Well the guy at the door said 'Alcohol, Tobacco and Firearms', we just
assumed it was more supplies ...."
Interpretive Systems
> ...
> I think your argument might also be a bit stronger if Cadence managed
>to produce a compiler capable of more accurate error reporting, so it could
>better aid those poor "inexperienced programmers" you're so concerned about.
>No language is simple to use with lousy error reporting.
>--
Try using interHDL's Verilint. This "lint" program checks your Verilog
source and produces many diagnostics messages for suspicious constructs
such as incompatible widths, etc.
Eli Sterheim,
interHDL inc.
(408) 749-8775
e...@interhdl.com