Subject: RE: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003
From: Bailey, Stephen (SBailey@model.com)
Date: Fri Dec 19 2003 - 10:59:42 PST
I just had a private discussion that covered this same exact issue.
> Bailey, Stephen wrote:
> >
> >> Now you folks come along and want to imply meaning
> where none was
> >> intended.
> >
> > If no boolean equivalence is intended in the written code,
> how does the
> > proposal impose one?
>
> This is the crux of the type safety issue. If the user had
> intended to write
>
> if we = '0' ...
>
> but instead got distracted and wrote
>
> if we ...
>
> and there is a visible condition operator, then the proposal
> generates
> incorrect logic with no warning. The language is no longer strongly
> typed. Catching this sort of error at compile time is exactly what a
> strong statically typed language is meant to be good at.
The problem is that you are inferring far more meaning to a relatively simple syntax check today than what the language is telling you. If you write today:
if sl then
It is a syntax error. There's no information as to what the corresponding logic level is supposed to be. After encountering this error with the compiler, you can eliminate it and still create a subsequent logic error (again because you got distracted) ...
if sl = '1' then
You now have a logic bug that doesn't get detected until simulation.
With the proposal, (assuming you must indicate you want the capability and you choose it):
if sl then
Is no longer a syntax error.
If, however, you meant to have negative level logic and wrote:
if sl then
You would again have a logic bug that can only be detected with simulation.
We cannot protect everyone from making all mistakes. The argument comes down to:
"I don't trust myself and/or fellow engineers to understand the boolean equivalence of std_ulogic and be diligent designers. Therefore, even though I have the option not to use it, I don't want the new capability as someone somewhere might make a logic error." And, you completely blank out the fact that the same logic error is possible to make today!
Can you imagine how limiting this perspective is on making progress with VHDL? It dooms us to always being less efficient than competing languages. We cannot evolve VHDL to target the lowest common denominator or have the goal of preventing all possible errors. We need to assume competent designers/verification engineers and be reasonable in what errors we can help protect against.
-Steve Bailey
This archive was generated by hypermail 2b28 : Fri Dec 19 2003 - 11:02:00 PST