I'd rather switch than fight!

Thu Apr 15, 2010 5:07 am   

In comp.arch.fpga rickman <gnuarm_at_gmail.com> wrote:
(snip)


Seatbelts may save lives, but statistically many other safety
improvements don't. When people know that their car has air bags,
they compensate and drive less safely. (Corner a little faster, etc.)
Enough to mostly remove the life saving effect of the air bags.

It does seem likely that people will let down their guard and
code more sloppily knowing that the compiler will catch errors.

One of my least favorite is the Java check on variable initialization.
If the compiler can't be sure that it is initialized then it is
a fatal compilation error. There are just too many cases that
the compiler can't get right.

-- glen

Thu Apr 15, 2010 8:20 am   

Sorry, but I have to call BS on this whole line og "logic". Unless you can
point to some studies that prove this, my experiences are contrary to your
assertions. I don't change the way I code when I code in Verilog vs. VHDL
or C vs. Java, the compiler just does a better job of catching my stupid
mistakes, allowing me to get things done faster.


---Matthew Hicks

Thu Apr 15, 2010 9:32 am   

On 15/04/2010 04:07, glen herrmannsfeldt wrote:

It is difficult to be concrete about these things, because it is so
dependent on the programmers involved. If you see strong typing as a
useful tool, and write your code accordingly, then you will write
clearer and neater code and therefore have fewer mistakes - and more of
these will be caught at compile time. If you see strong typing as a
pain that has to be worked around, you will write ugly code that will
have more mistakes than clearly written code in with a weak typed language.

The main thing is to write your code clearly, and to take advantage of
whatever typing mechanisms your tool supports - even if it doesn't check
them (for example, use typedefs and enums in C rather than "int", even
though the compiler treats them the same). You can write good code in
any language, and you certainly can write bad code in any language. But
it is easier to write good code if the language and tools make support it.


It's a matter of understanding your tools. The big trouble with air
bags is that people think they don't need seatbelts because they have
air bags, without realising that they are designed to work together.


I don't use Java, but my C compilers have similar checks. There are
very few circumstances that the compiler will get this wrong unless you
have written particularly convoluted code. The answer, of course, is to
avoid writing convoluted code.

Any checking mechanism has a risk of false positives and false negatives
- the compiler doesn't know everything the programmer knows. But you
work with the tool to give the compiler as much knowledge as you can,
and let it help check that as much as /it/ can.

Thu Apr 15, 2010 2:03 pm   

On Thu, 15 Apr 2010 10:32:43 +0200, David Brown
<david_at_westcontrol.removethisbit.com> wrote:


Then (using enums as a simple example), strong typing can either catch
or eliminate errors that may not immediately be considered as type
errors.

Loop count errors or indexing off the end of an array, for example, are
usually type errors, since they use the range of a discrete subtype. In
C you have to build something complex and error prone, simply to
replicate "for i in my_enum'range loop ..." And remember to maintain it
whenever you add a value to the enum...



- Brian

Thu Apr 15, 2010 5:33 pm   

On Apr 15, 12:20 am, Matthew Hicks <mdhic...@uiuc.edu> wrote:

Thu Apr 15, 2010 5:37 pm   

On Apr 15, 12:20 am, Matthew Hicks <mdhic...@uiuc.edu> wrote:

You can "call BS" all you want, but the fact that you don't change the
way you code in Verilog vs. VHDL or or C vs. Java indicates that your
experiences are antithetical to mine, so I have to discard your
datapoint.

Regards,
Pat

Thu Apr 15, 2010 9:12 pm   

On 15/04/2010 21:23, Andy wrote:

This is perhaps a nit-pick, but bounds checks are not directly related
to type strength. Bound checks are either run-time (and therefore have
a cost), or compile-time (or both). For compile time, this mainly means
that the compiler must see the full declaration of the array or other
type when you are using it - modern gcc will do pretty good compile-time
bounds checking if it has enough information, even with weakly-typed C.


Agreed, although this applies to a lot of good programming techniques
(you can write strongly-typed code even if the language doesn't enforce
it, and typically the compiler's warnings will give you more help than
the language standards). It's faster to write code full of functions
"test" and "foo" than to think of meaningful names, but it makes a big
difference when you go back to the code latter.


Another famous contest involved a C and Ada comparison. It took the Ada
more than twice as long as the C team to write their code, but it took
the C team more than ten times as long to debug their code.

Thu Apr 15, 2010 9:19 pm   

On 15/04/2010 15:03, Brian Drummond wrote:

Yes - it's one of the advantages of C++ over C (C++ has plenty of
advantages and plenty of disadvantages) - type checking, including
enums, is much stronger. And with a bit of messing around with you can
make types that are effectively enums but even stronger typed.

I've seen some code to use C++ classes to encapsulate rules about lock
orders for multi-threaded code (such as "you must not take lock A unless
you first have lock B, and you must release them in reverse order").
The result was that violations of these rules ended up as type errors
and were therefore caught at compile time.

It's often possible to add features to the language in this way - some
ugly macros will give you zero-cost static asserts in C, for example.


typedef enum {
red, blue, green,
noOfColours
} colours;

for (int i = 0; i < noOfColours; i++) { ... }

But it would be *so* much nicer if it were part of the language as it is
in Ada or Pascal.

Thu Apr 15, 2010 10:23 pm   

The benefits of a "strongly typed" language, with bounds checks, etc.
are somewhat different between the first time you write/use the code,
and the Nth time reuse and revise it. Strong typeing and bounds
checking let you know quickly the possibly hidden side effects of
making changes in the code, especially when it may have been a few
days/weeks/months since the last time you worked with it.

A long time ago there was a famous contest for designing a simple
circuit in verilog vs. vhdl to see which language was better. The
requirements were provided on paper, and the contestents were given an
hour or two (don't remember how long, but it was certainly not even a
day), and whoever got the fastest and the smallest (two winners)
correct synthesized circuit, their chosen language won. Verilog won
both, and I don't think vhdl even finished.

IMHO, they missed the point. Any design that can be completed in a
couple of hours will necessarily favor the language with the least
overhead. Unfortunately, two-hour-solvable designs are not
representative of real life designs, and neither was the contest's
declared winner.

If you just want to hack out the code and get it working by yourself
for the day, a weakly typed language may be the better choice for you.
If you need to be able to reuse/revise/update/extend the design over
time, more strongly typed languages are preferred.

Andy

Thu Apr 15, 2010 10:31 pm   

On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin
<pmaupin_at_gmail.com> wrote:


There are two issues to consider. One is the relative times of writing
the codes vs debugging ie if writing took 5 hours and debugging 10
minutes (unlikely) then C still wins. Which brings the second issue:
it is very likely that the programming contest involved a "larger"
design to be finished. If I am remembering correctly RTL was an async
reset, synchronously loadable up-down counter which is a "smallish"
project. If programming contest involved something more "involved" it
still points to the benefit of strong typing and other features of
Ada/VHDL etc.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Fri Apr 16, 2010 12:21 am   

On Apr 15, 3:12 pm, David Brown <da...@westcontrol.removethisbit.com>
wrote:


Well, this isn't at all the same then. The Verilog teams got working
designs, and the VHDL teams didn't.

Fri Apr 16, 2010 12:27 am   

On Apr 15, 2:23 pm, Andy <jonesa...@comcast.net> wrote:

For this usage, a good testbench will catch more bugs and make strong
type and bounds checking redundant.


Contest details here:

http://www.see.ed.ac.uk/~gerard/Teach/Verilog/manual/Example/lrgeEx2/cooley..html


Well, I think the takeaway is a lot more nuanced than that, but
whatever. Believe what you will.


Again, IMHO, a really good testbench will more than make up for any
perceived weaknesses in Verilog in this area. But you are free to
continue to believe that the language is really helping you.

Regards,
Pat

Fri Apr 16, 2010 12:48 am   

On Apr 15, 4:31 pm, Muzaffer Kal <k...@dspia.com> wrote:

But it's mostly academic and FPGA people who think that VHDL might
have any future at all. See, for example:

http://www.eetimes.com/news/design/columns/industry_gadfly/showArticle.jhtml?articleID=17408302

Regards,
Pat

Fri Apr 16, 2010 12:57 am   

Interesting in the discussion on myHdl/testbenches, no-one raised
SystemVerilog. SystemVerilog raises the level of abstraction(like
myHdl), but more importantly it introduces constrained random
verification. For writing testbenches, SV is a better choice than
MyHdl/VHDL/Verilog, assuming tool availablility.

It would seem that SV does not bring much to the table in terms of RTL
design - its just a catchup to get verilog up to the capabilities that
VHDL already has.

Fri Apr 16, 2010 12:58 am   

On Apr 15, 10:21 pm, Patrick Maupin <pmau...@gmail.com> wrote:


It's really about time that this old VHDL-Verilog shootout nonsense
was shown up for the garbage it was.

It was set up by John Cooley many years ago. It took place in the
US where Verilog predominated, then as now, so there was a much
smaller pool of skilled VHDL users than Veriloggers at the host
event. At the time, VHDL did indeed lag badly behind in some
respects - the situation with numeric packages was chaotic, and
the design was a (very simple) counter of some kind so anyone
who wasn't fluent with the VHDL numeric packages **as accepted
by the tools in use** was doomed. And, as Andy pointed out, the
scale of the problem was so tiny that Verilog would always come
out on top - Verilog is definitely faster to write for tiny
designs; you don't need a contest to work that out.

All of this means that the "contest" was little more than a
good way to show how feeble were VHDL's **tools** at that
time. It wasn't very long before the tool vendors got their
acts together, but the shootout wasn't re-run; instead, it
became part of the folklore. It was unreliable populist
hokum then, it's out-of-date unreliable hokum now, and I'm
saddened to see it adduced in evidence so many years on.

There's a lot wrong with VHDL, for sure, but a lot right too.
Here's a sampler of a few things that have been in VHDL since
at least 1987:

Added to Verilog in 2001:
- generate
- multi-dimensional arrays
- signed vector arithmetic
- configurations (nasty in both languages!)

Added to SystemVerilog in 2003-2005:
- packages
- structs (a.k.a. records)
- non-trivial data types (e.g. arrays, structs) on ports
- enumeration types
- unresolved signals (compiler errors on multiple drivers)
- non-trivial data types as subprogram arguments
- reference arguments to subprograms
- default values for input arguments
- inquiry functions to determine the dimensionality and
bounds of an array

May possibly be added to SystemVerilog in 2012:
- parameterized subprograms (like VHDL unconstrained arrays)
- subprogram overloading

Of course, there's also a ton of stuff that Verilog can do
but VHDL can't. And it's rarely a good idea to judge any
language by a laundry-list of its feature goodies. But
it is NEVER a good idea to trivialize the discussion.
--
Jonathan Bromley