I'd rather switch than fight!

[rickman]

I think I have about had it with VHDL. I've been using the
numeric_std library and eventually learned how to get around the
issues created by strong typing although it can be very arcane at
times. I have read about a few suggestions people are making to help
with some aspects of the language, like a selection operator like
Verilog has. But it just seems like I am always fighting some aspect
of the VHDL language.

I guess part of my frustration is that I have yet to see where strong
typing has made a real difference in my work... at least an
improvement. My customer uses Verilog and has mentioned several times
how he had tried using VHDL and found it too arcane to bother with.
He works on a much more practical level than I often do and it seems
to work well for him.

One of my goals over the summer is to teach myself Verilog so that I
can use it as well as I currently use VHDL. Then I can make a fully
informed decision about which I will continue to use. I'd appreciate
pointers on good references, web or printed.

Without starting a major argument, anyone care to share their feelings
on the differences in the two languages?

Rick

 

[Andy]

Before the fixed and floating point packages came out, I would have
said there is little difference regarding RTL capabilities between
Verilog and VHDL. But those two packages revealed a fundamental
strength of VHDL that simply does not exist in verilog. By simply
writing a new package, a whole new capability was created that would
take a substantial language change in Verilog. Yes, the as-released
packages took advantage of features only available in a related change
in the language itself, but the "compatibility" packages ably
demonstrate that the working concept is viable even within the
confines the original language, thus demonstrating the true strengh of
the basic language of VHDL.

Not that the fixed/floating point packages are nirvana, but they do
represent a huge step in the right direction. If we only had
assignment operator overloading in VHDL, it would be much closer...
Still, that's a capability much closer to reality in VHDL than in
Verilog. Sure, verilog has many "built-in" tricks, but they are only
applicable to the existing type structure, and cannot be expanded upon
without revising the language itself.

Even before the fixed/floating point packages, integers simply work in
VHDL (within the range limitations), whereas in Verilog, they don't
always, but they also don't complain when they don't work either.

In general, strong typing and built-in bounds checking in VHDL catch
more problems, closer to the source of the problems, with no
additional code being written, than is possible in Verilog without
having to write A LOT of extra code. It seems for almost every weak-
typing-enabled shortcut in verilog, there is also a hidden, often
silent, "gotcha" to go along with it.

Andy

 

[Patrick Maupin]

On Apr 9, 9:07 am, rickman <gnu...@gmail.com> wrote:

I think I have about had it with VHDL.  I've been using the
numeric_std library and eventually learned how to get around the
issues created by strong typing although it can be very arcane at
times.  I have read about a few suggestions people are making to help
with some aspects of the language, like a selection operator like
Verilog has.  But it just seems like I am always fighting some aspect
of the VHDL language.

I guess part of my frustration is that I have yet to see where strong
typing has made a real difference in my work... at least an
improvement.  My customer uses Verilog and has mentioned several times
how he had tried using VHDL and found it too arcane to bother with.
He works on a much more practical level than I often do and it seems
to work well for him.

One of my goals over the summer is to teach myself Verilog so that I
can use it as well as I currently use VHDL.  Then I can make a fully
informed decision about which I will continue to use.  I'd appreciate
pointers on good references, web or printed.

Without starting a major argument, anyone care to share their feelings
on the differences in the two languages?

Rick

The best online references are the Sutherland Verilog references.
There is an online HTML reference for Verilog 95 (excellent), and a
PDF for Verilog 2001 (good):

http://www.sutherland-hdl.com/online_verilog_ref_guide/vlog_ref_top.html
http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.pdf

Cliff Cummings has a lot of good papers on Verilog at his site:

http://sunburst-design.com/papers/

In particular, if you read and carefully grok his paper about non-
blocking vs. blocking assignments, you will be well on your way to
being a Verilog wizard:

http://sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf

Regards,
Pat

 

[Nico Coesel]

rickman <gnuarm@gmail.com> wrote:

I think I have about had it with VHDL. I've been using the
numeric_std library and eventually learned how to get around the
issues created by strong typing although it can be very arcane at
times. I have read about a few suggestions people are making to help
with some aspects of the language, like a selection operator like
Verilog has. But it just seems like I am always fighting some aspect
of the VHDL language.

I guess part of my frustration is that I have yet to see where strong
typing has made a real difference in my work... at least an

I also write a lot of C. Over the past years I've noticed that C
compilers (GCC to be exact) have become much more strict when it comes
to type checking. No more automatic casting. I'm sure this is done for
a good reason!

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

[gabor]

On Apr 9, 10:07 am, rickman <gnu...@gmail.com> wrote:

I think I have about had it with VHDL.  I've been using the
numeric_std library and eventually learned how to get around the
issues created by strong typing although it can be very arcane at
times.  I have read about a few suggestions people are making to help
with some aspects of the language, like a selection operator like
Verilog has.  But it just seems like I am always fighting some aspect
of the VHDL language.

I guess part of my frustration is that I have yet to see where strong
typing has made a real difference in my work... at least an
improvement.  My customer uses Verilog and has mentioned several times
how he had tried using VHDL and found it too arcane to bother with.
He works on a much more practical level than I often do and it seems
to work well for him.

One of my goals over the summer is to teach myself Verilog so that I
can use it as well as I currently use VHDL.  Then I can make a fully
informed decision about which I will continue to use.  I'd appreciate
pointers on good references, web or printed.

Without starting a major argument, anyone care to share their feelings
on the differences in the two languages?

Rick

At the end of the day, it really comes down to how you can be more
productive. If you tend to code with many levels of abstraction
you may do better with VHDL. I find that I am more productive
with Verilog, but it could be because I tend to look at hardware
at a fairly detailed level, a bottom-up approach if you will. I
inherited Verilog projects at my current place of employment and
just stuck with the language as it grew on me. At one point I
read Thomas & Moorby's green book from cover to cover. However
it described Verilog 95, not the more commonly used Verilog 2001,
and was not a particularly good reference book. I keep a copy
of the Doulos Golden Reference handy for the bits I don't use
every day.

Good Luck,
Gabor

 

[glen herrmannsfeldt]

In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:
(snip)

Without starting a major argument, anyone care to share their feelings
on the differences in the two languages?

I started with verilog, as that is what others I was working with
were doing, and was also told that it was a better choice for
previous C programmers. (Not that I believe that HDL should be
related to a software language.)

At some point, I learned to read VHDL, at least enough to convert
an module to verilog when needed, or to understand why something
didn't work the way I thought it should. (I had one project with
schematic capture, VHDL, and AHDL, and then I started adding
verilog to it.)

It seems to me that verilog, similar to C, gets the ideas across
without being excessively wordy. In comparison to some other
languages, I find the convenience in C of converting between
char and int without the need for any special conversion operation
(such as the Fortran CHAR function) convenient.

Well, I write my verilog mostly using continuous assignment,
with a fairly small amount of behavioral verilog. For those who
prefer behavioral coding, the recommendation might be different.

-- glen

 

[Jonathan Bromley]

On Apr 9, 3:07 pm, rickman <gnu...@gmail.com> wrote:

I think I have about had it with VHDL.  I've been using the
numeric_std library and eventually learned how to get around the
issues created by strong typing although it can be very arcane at
times.  I have read about a few suggestions people are making to help
with some aspects of the language, like a selection operator like
Verilog has.  But it just seems like I am always fighting some aspect
of the VHDL language.

I guess part of my frustration is that I have yet to see where strong
typing has made a real difference in my work... at least an
improvement.

I think Andy has it about right. If you think signed arithmetic
was a tad messy in VHDL, wait until you find how successfully you
can be screwed by Verilog. The really cool thing is that Verilog
is polite, and doesn't tell you when it's screwing you. At least
VHDL is up-front about it. How many times have you created a
design in VHDL that got through compilation, but was broken in
a surprising way that was directly related to a quirk of the
language? Betcha you can count the occurrences on one hand.
Verilog does that to you all the time; it has startlingly
weak compile-time checking, and only slightly stronger
elaboration-time checking.

How comfortable are you with most-significant bits being
silently lost when you copy a wide vector into a narrow
one? How about signed values being silently zero-filled
to the width of a wider target?

 My customer uses Verilog and has mentioned several times
how he had tried using VHDL and found it too arcane to bother with.
He works on a much more practical level than I often do and it seems
to work well for him.

Is "practical" here a euphemism?

One of my goals over the summer is to teach myself Verilog so that I
can use it as well as I currently use VHDL.  Then I can make a fully
informed decision about which I will continue to use.  I'd appreciate
pointers on good references, web or printed.

Good luck. As I've pointed out on many occasions, the textbook
situation is much less satisfactory for Verilog than it is
for VHDL. Whatever you do, PLEASE get yourself a copy of
Sutherland's Verilog Gotchas book (much of it is available free
online). You may not understand all of it at first, but
you sure will want to revisit it later. It's just a pity
that it's incomplete and doesn't cover ALL the many ways
in which Verilog can silently mess you up.

To be serious for a moment: a training class from a
reputable independent provider will save you a ton
of money in the long run. Your time is valuable.

Without starting a major argument, anyone care to share their feelings
on the differences in the two languages?

Errrrm, I think I just did.
--
Jonathan Bromley

 

[Jan Decaluwe]

On Apr 9, 6:53 pm, Patrick Maupin <pmau...@gmail.com> wrote:

On Apr 9, 9:07 am, rickman <gnu...@gmail.com> wrote:



I think I have about had it with VHDL.  I've been using the
numeric_std library and eventually learned how to get around the
issues created by strong typing although it can be very arcane at
times.  I have read about a few suggestions people are making to help
with some aspects of the language, like a selection operator like
Verilog has.  But it just seems like I am always fighting some aspect
of the VHDL language.

I guess part of my frustration is that I have yet to see where strong
typing has made a real difference in my work... at least an
improvement.  My customer uses Verilog and has mentioned several times
how he had tried using VHDL and found it too arcane to bother with.
He works on a much more practical level than I often do and it seems
to work well for him.

One of my goals over the summer is to teach myself Verilog so that I
can use it as well as I currently use VHDL.  Then I can make a fully
informed decision about which I will continue to use.  I'd appreciate
pointers on good references, web or printed.

Without starting a major argument, anyone care to share their feelings
on the differences in the two languages?

Rick

The best online references are the Sutherland Verilog references.
There is an online HTML reference for Verilog 95 (excellent), and a
PDF for Verilog 2001 (good):

http://www.sutherland-hdl.com/online_verilog_ref_guide/vlog_ref_top.htmlhttp://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_g...

Cliff Cummings has a lot of good papers on Verilog at his site:

http://sunburst-design.com/papers/

In particular, if you read and carefully grok his paper about non-
blocking vs. blocking assignments, you will be well on your way to
being a Verilog wizard:

http://sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf

The infamous Guideline #5 bans variable semantics from always blocks
with sequential logic. It must be the Worst Guideline ever for RTL
designers.
The result is not wizardry but ignorance.

How are we supposed to "raise the abstraction level" if Verilog RTL
designers
can't even use variables?

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com

 

[David Brown]

On 09/04/2010 21:31, Nico Coesel wrote:

rickman<gnuarm@gmail.com> wrote:

I think I have about had it with VHDL. I've been using the
numeric_std library and eventually learned how to get around the
issues created by strong typing although it can be very arcane at
times. I have read about a few suggestions people are making to help
with some aspects of the language, like a selection operator like
Verilog has. But it just seems like I am always fighting some aspect
of the VHDL language.

I guess part of my frustration is that I have yet to see where strong
typing has made a real difference in my work... at least an

I also write a lot of C. Over the past years I've noticed that C
compilers (GCC to be exact) have become much more strict when it comes
to type checking. No more automatic casting. I'm sure this is done for
a good reason!

It's not correct that C compilers have become stricter about type
checking - a standards-conforming C compiler has to support exactly the
same automatic typecasting as always. However, gcc's warning
capabilities have improved enormously over the years (it's better than
any other C compiler I have used), and if you enable those warnings it
will tell you about potential problems with losing bits on casts, mixing
signed and unsigned data, etc. It still has to accept it as valid C,
however (unless you use the option to make warnings act as errors).

Compiling in C++ mode gives you a little bit extra type strength - for
example, enumerations become proper types.

 

[fpgabuilder]

How comfortable are you with most-significant bits being
silently lost when you copy a wide vector into a narrow
one?  How about signed values being silently zero-filled
to the width of a wider target?

I always ran into this problem at my old employer as there wasn't

strict enforcement of coding guidelines. But I never tripped on it in
a messy way because the tools always caught the problem as a warning
(not an error). And they were pretty consistent about it. One aspect
of the learning the language I found quite useful was that I thought
of coding with the language as if I was drawing a schematic with it.
I filtered all the new knowledge about the language through this
fundamental premise. Here Palnitkar's book really helped me.
Ofcourse at that time verilog 2001 was just getting a lot of
attention.

 

[Bernd Paysan]

Jonathan Bromley wrote:

How comfortable are you with most-significant bits being
silently lost when you copy a wide vector into a narrow
one? How about signed values being silently zero-filled
to the width of a wider target?

Icarus Verilog (the free simulator) has pretty good checks on this and tells
you about vector size mismatches - IIRC, it is more pedantic than Cadence's
original Verilog simulator (they improved in the meantime, but I haven't
checked if they are as pedantic as Icarus Verilog). This is IMHO not a
language problem, but a quality of implementation issue.

--
Bernd Paysan
"If you want it done right, you have to do it yourself!"
http://www.jwdt.com/~paysan/

 

[Andy]

On Apr 14, 4:39 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:

Icarus Verilog (the free simulator) has pretty good checks on this and tells
you about vector size mismatches - IIRC, it is more pedantic than Cadence's
original Verilog simulator (they improved in the meantime, but I haven't
checked if they are as pedantic as Icarus Verilog).  This is IMHO not a
language problem, but a quality of implementation issue.

It wouldn't be an implementation issue if it wasn't first and foremost
a language issue! Sure, tools can go a long ways in mitigating the
effects of language issues, but the problem starts with the language,
not the tools that are less adept at mitigation.

Andy

 

[rickman]

On Apr 9, 2:25 pm, gabor <ga...@alacron.com> wrote:

On Apr 9, 10:07 am, rickman <gnu...@gmail.com> wrote:



I think I have about had it with VHDL.  I've been using the
numeric_std library and eventually learned how to get around the
issues created by strong typing although it can be very arcane at
times.  I have read about a few suggestions people are making to help
with some aspects of the language, like a selection operator like
Verilog has.  But it just seems like I am always fighting some aspect
of the VHDL language.

I guess part of my frustration is that I have yet to see where strong
typing has made a real difference in my work... at least an
improvement.  My customer uses Verilog and has mentioned several times
how he had tried using VHDL and found it too arcane to bother with.
He works on a much more practical level than I often do and it seems
to work well for him.

One of my goals over the summer is to teach myself Verilog so that I
can use it as well as I currently use VHDL.  Then I can make a fully
informed decision about which I will continue to use.  I'd appreciate
pointers on good references, web or printed.

Without starting a major argument, anyone care to share their feelings
on the differences in the two languages?

Rick

At the end of the day, it really comes down to how you can be more
productive.  If you tend to code with many levels of abstraction
you may do better with VHDL.  I find that I am more productive
with Verilog, but it could be because I tend to look at hardware
at a fairly detailed level, a bottom-up approach if you will.  I
inherited Verilog projects at my current place of employment and
just stuck with the language as it grew on me.  At one point I
read Thomas & Moorby's green book from cover to cover.  However
it described Verilog 95, not the more commonly used Verilog 2001,
and was not a particularly good reference book.  I keep a copy
of the Doulos Golden Reference handy for the bits I don't use
every day.

I have always used Hardware Description Languages (HDLs) as a way to
describe hardware rather than just a way to code an application. In
the early days this would pay off in smaller implementations. But the
tools are better now and you have to work to get an improvement in the
size of your design. Sometimes the durn language just seems to get in
the way of being able to cleanly express what I want to do.

Rick

 

[rickman]

On Apr 9, 10:50 am, Andy <jonesa...@comcast.net> wrote:

In general, strong typing and built-in bounds checking in VHDL catch
more problems, closer to the source of the problems, with no
additional code being written, than is possible in Verilog without
having to write A LOT of extra code. It seems for almost every weak-
typing-enabled shortcut in verilog, there is also a hidden, often
silent, "gotcha" to go along with it.

People say that strong typing catches bugs, but I've never seen any
real proof of that. There are all sorts of anecdotal evidence, but
nothing concrete. Sure, wearing a seat belt helps to save lives, but
at what point do we draw the line? Should we have four point
harnesses, helmets, fireproof suits...?

Rick

 

[rickman]

On Apr 9, 3:07 pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

On Apr 9, 3:07 pm, rickman <gnu...@gmail.com> wrote:

How comfortable are you with most-significant bits being
silently lost when you copy a wide vector into a narrow
one?  How about signed values being silently zero-filled
to the width of a wider target?

Isn't this just a matter of knowing the rules and following them? The
same is true with VHDL. There may be fewer ways to forget, but it is
still the same.

 My customer uses Verilog and has mentioned several times
how he had tried using VHDL and found it too arcane to bother with.
He works on a much more practical level than I often do and it seems
to work well for him.

Is "practical" here a euphemism?

No, I mean it literally. He is always focused on getting the job done
and doesn't spend any time on things he isn't sure will pay off in
tangible ways. When I designed the board, I also designed a test
fixture since the board goes in his chassis that costs a few grand.
It took a while and ended up delaying some of the FPGA work a bit, but
in the end has paid off greatly since I can do so much debugging on my
own without involving him. He wouldn't have done that. Oh, it is
also the only way to power the board so the FPGA can be programmed.
He is supposed to develop a download capability in his system, but has
never spent the time to get it working. Again, he'll do that when he
knows it will pay some return.

One of my goals over the summer is to teach myself Verilog so that I
can use it as well as I currently use VHDL.  Then I can make a fully
informed decision about which I will continue to use.  I'd appreciate
pointers on good references, web or printed.

Good luck.  As I've pointed out on many occasions, the textbook
situation is much less satisfactory for Verilog than it is
for VHDL.  Whatever you do, PLEASE get yourself a copy of
Sutherland's Verilog Gotchas book (much of it is available free
online).  You may not understand all of it at first, but
you sure will want to revisit it later.  It's just a pity
that it's incomplete and doesn't cover ALL the many ways
in which Verilog can silently mess you up.

When I started learning VHDL I thought about writing a book from the
"practical" side of the language since so many were more like text
books. But I was overtaken by the market and it was flooded before I
got comfortable enough to do that. However, there may be a good
Verilog for the VHDL Designer book in this. If I find it was a good
thing to switch, I will seriously consider that.

To be serious for a moment: a training class from a
reputable independent provider will save you a ton
of money in the long run.  Your time is valuable.

You are assuming my time is worth something. When I have no work,
there is no point in paying someone big bucks to teach me something I
can learn on my own. I am expecting to not have a lot of work over
the next few months.

Without starting a major argument, anyone care to share their feelings
on the differences in the two languages?

Errrrm, I think I just did.

You did what, shared your feelings or started a major argument?

Rick

 

[glen herrmannsfeldt]

In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:
(snip)

People say that strong typing catches bugs, but I've never seen any
real proof of that. There are all sorts of anecdotal evidence, but
nothing concrete. Sure, wearing a seat belt helps to save lives, but
at what point do we draw the line? Should we have four point
harnesses, helmets, fireproof suits...?

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

 

[Matthew Hicks]

In comp.arch.fpga rickman <gnuarm@gmail.com> wrote: (snip)

People say that strong typing catches bugs, but I've never seen any
real proof of that. There are all sorts of anecdotal evidence, but
nothing concrete. Sure, wearing a seat belt helps to save lives, but
at what point do we draw the line? Should we have four point
harnesses, helmets, fireproof suits...?

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.

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

 

[David Brown]

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

In comp.arch.fpga rickman<gnuarm@gmail.com> wrote:
(snip)

People say that strong typing catches bugs, but I've never seen any
real proof of that. There are all sorts of anecdotal evidence, but
nothing concrete. Sure, wearing a seat belt helps to save lives, but
at what point do we draw the line? Should we have four point
harnesses, helmets, fireproof suits...?

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.

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

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.

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.

 

[Brian Drummond]

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

On 15/04/2010 04:07, glen herrmannsfeldt wrote:
In comp.arch.fpga rickman<gnuarm@gmail.com> wrote:
(snip)

People say that strong typing catches bugs, but I've never seen any
real proof of that. There are all sorts of anecdotal evidence, but
nothing concrete. Sure, wearing a seat belt helps to save lives, but
at what point do we draw the line? Should we have four point
harnesses, helmets, fireproof suits...?

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.

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

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.

Agreed

- Brian

 

[Patrick Maupin]

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

In comp.arch.fpga rickman <gnu...@gmail.com> wrote: (snip)

People say that strong typing catches bugs, but I've never seen any
real proof of that.  There are all sorts of anecdotal evidence, but
nothing concrete.  Sure, wearing a seat belt helps to save lives, but
at what point do we draw the line?  Should we have four point
harnesses, helmets, fireproof suits...?

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.

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