[vhdl-200x] boolean equivalence

Subject: [vhdl-200x] boolean equivalence
From: John Shields (jshields@ipns.com)
Date: Sun Dec 21 2003 - 19:46:38 PST


The issue of boolean equivalence remains interesting. I think many
individuals are listening,
some hoping to be compelled by persuasive argument to weigh in. I am
in favor of boolean
equivalence being added to VHDL, provided it is done in a manner that
allows the
implicit COND operator to be defined for any type, that COND operators
are defined for
all well-known logic types in standard packages, and that the packaging
of those
definitions allow its use to be restricted as matter of style. I think
this achieves the goal
in a general way while preserving strict backward compatibility for
existing designs. (Vendors
may provide features to support review of designs affected by this
language feature
to ease its acceptance, too :).

My rationale is as follows:

1. This is one of many 200x strategies to achieve more expressiveness
in the language
and efficiency for designers. A designer's efficiency can be expressed
in lines of code/hour.
The argument is based on complexity being a function of the
number of lines of code to express a given idea. The number of errors
per line of code increases with
complexity. I might suggest that VHDL is hard to become proficient in
to Verilog. These statements have been a mantra of Verilog and
SystemVerilog proponents
for a long time. I believe there is something to this and it is not
just a couple of consultants
incessantly criticizing VHDL.

2. The verification bottleneck has led the industry to explore and
commit to many
strategies besides simulation. Assertions, formal verification, and
new languages for
testbench generation are in standard practice. Whether this appeals
to you or not, SystemVerilog
is aimed at extending the expressiveness of HDL to embrace these
practices and define
language constructs that make design intent clear and more aspects of
design description correct by
construction. It is building on an organically grown language that has
some challenging
inconsistencies and warts. It will fall on its sword to preserve
backward compatibility.
Nevertheless, it is seeking productivity for designers in
the correct expression of design intent, amendable to broader classes
of analysis. This
goal resonates in the industry, regardless of whether you like the
specifics of the language design
or the fairness of the language design process. VHDL *should be* a
better foundation to accomplish these
same goals within. If these goals do not resonate in the VHDL design
<insert your favorite dire prediction>.
Bringing assertions into VHDL with consistent expression of design
for both assertion and simulation is compelling to me. I agree with
that goal.

3. Strongly typed languages do not erode by the support of implicit
type conversion for related types.
We are talking about discrete data types used to represent digital
logic and the control flow constructs
of the language. A clear set of conversion functions, if they exist,
will be applied to support
better expressiveness of control flow. It appeals to me.

4. Language design is a difficult domain for computer science. There
is significant theory and art
to it. It requires good understanding of the domain that the language
will be applied to as well.
Rarely is anything elegant and successful achieved by committee-based
design. The work of
a small number of people, when it achieves, shows its conceptual unity
of thought and
purpose. I like what was defined for boolean equivalence and it has
benefited from the
discussion. I do not like the proposal for a new logic type nor the
addition of a duplicate
set of control flow constructs (if?, while?, etc.) It is my opinion
that these ideas will not stand
up under serious scrutiny, though I appreciate the brainstorming.

I'm sorry, but I find little new or refreshing going on in the
rehashing of the ideas on this topic.
I'd like to see boolean equivalence go back to the task force and be
completed in formal specification
before reviewing it again. The task force would do well to elaborate
the set of requirements
and rationale for them behind the work. One thing that struck me in
this dialog is the lack
of common ground on the goals.

I've offered comment and opinion that can easily be rebutted and
debated. People convinced
against their will, will remain of the same opinion still. I hope most
can agree to return this
to the task force soon.

Regards and Happy Holidays,
John Shields

This archive was generated by hypermail 2b28 : Mon Dec 22 2003 - 23:20:29 PST