Re: [vhdl-200x] A 2nd proposal to boolean equivalence

Subject: Re: [vhdl-200x] A 2nd proposal to boolean equivalence
From: Marcus Harnisch (
Date: Mon Jan 05 2004 - 08:14:24 PST

Evan Lavelle writes:
> There's another reason why your proposal is much better than the
> package-based 'COND' proposal. For the packaged-COND proposal, the
> user's intent is split into two parts: the point of (implicit) use of
> the 'cast', and the point where the relevant COND is defined in a
> package.

What's wrong with that? It enables you to easily choose whether you
want to/can(!) use implicit conversion or not.

> But anyone who's ever read VHDL code will know that the average
> user generally has little grasp of which packages are required to make
> code work (how many times have you seen code which uses both Synopsys
> and IEEE arithmetic packages?). I also see (and have) exactly this
> problem in C++ and 'e' all the time - you simply mess with your includes
> until everything compiles. In other words, for the packaged-COND
> proposal, the writer's original intent can be lost simply because
> another user of the code gets their package visibilities wrong. Consider
> a case where package A has a COND which sets 'X' as true, and package B
> sets 'X' as false. This obviously has the potential for major problems.

I agree that some people might be tempted to do that. Since this is by
no means the only place people can mess with, I am sure you have a
code review stage in your development process.

> Put differently, packaged-COND only works if the original writer *wrote*
> the code correctly, *and* all later users *use* it correctly. It's a
> maintenance nightmare.

Fortunately, as I pointed out in an earlier message, VHDL makes it
just so easy to deal with that in a review process. Summary:

1. If your policiy does not allow using implicit conversion, go to 2.

   Every designer should know whether (s)he intended to use implicit
   conversion or not. The boolean mapping of the answers would look
   roughly like that:
     "Yes" = TRUE
     "No" = FALSE
     "What's that" = FALSE

2. Compile code that is not supposed to use implicit boolean
   conversion with a special library mapping pointing to empty
   conversion libraries, which have been created for the review
   process. These libraries have to be set up only once for every one
   and could actually be shipped with your EDA tools. Your system
   library mapping let's you create a policy.

3. Look at the compiler error messages.

Best regards,

Marcus Harnisch               | Mint Technology, a division of LSI Logic | 200 West Street, Waltham, MA 02431
Tel: +1-781-768-0772          |

This archive was generated by hypermail 2b28 : Mon Jan 05 2004 - 12:39:44 PST