Subject: Re: [vhdl-200x] RE: [vhdl-200x-dta] Object oriented VHDL
From: Gabe Moretti (gmoretti@comcast.net)
Date: Tue May 13 2003 - 19:31:48 PDT
Let me offer a non-technical view. C and C++ are now part of Design
Automation, Ada is not. I agree VHDL needs to support objective programming
methods, and the only thing that is important is that the resulting VHDL be
able to work with C++ programs as transparently as possible. How this is
achieved is really not important. But let's remember that we are not
building a monument to language engineering. We either are building a
product or we should go do something better with the rest of our lives. And
a product must meet its market window. So, the games have gone on too long;
we all played - each for his or her own reasons, and we have all lost to
less robust and less elegant languages. We need to get the profit motive
back in VHDL.
Gabe Moretti
----- Original Message -----
From: "Peter Ashenden" <peter@ashenden.com.au>
To: "'Kevin Cameron x3251'" <Kevin.Cameron@nsc.com>;
<vhdl-200x-dta@server.eda.org>
Cc: <vhdl-200x@server.eda.org>
Sent: Tuesday, May 13, 2003 8:31 PM
Subject: [vhdl-200x] RE: [vhdl-200x-dta] Object oriented VHDL
> Dear colleagues,
>
> Perhaps a bit of history might be helpful. I was chair of the OOVHDL
> working group while it was active. It is now defunct, and its PAR
> withdrawn.
>
> There have been many proposals to add OO features to VHDL. In the mid to
> late 1990s, a group headed by Wolfgang Nebel at the University of
Oldenburg,
> Germany, developed a proposal called Objective VHDL for extensible data
> classes and extensible entities and architetures. Their approach was
> motivates by classes in C++ and similar programming languages. At around
> the same time, I (at the University of Adelaide, Australia) and Phil
Wilsey
> (at the University of Cincinnati, US) developed a proposal called SUAVE
for
> OO data modeling based on the OO features of Ada-95. We also proposed
> features for dynamic process typing and management, and for high-level
> communication using CSP-style channels with send and receive operations.
>
> Both the Objective VHDL group and the SUAVE group brought our proposals to
> the IEEE DASC for consideration as draft standards. Since we took
> significantly different approaches to defining OO data types, we went
> through a process of trying to reconcile differences and ultimately having
a
> "play-off" to decide. The Objective VHDL proposal won the vote, but at
that
> time their funding source caused them to divert their effort elsewhere, so
> they could not continue with Objective VHDL. Likewise, my group changed
> direction, so SUAVE went dormant. Due to lack of other interest in
picking
> up either proposal, the IEEE Working Group went dormant.
>
> Nonetheless, the documentation from the previous work is still available.
> Given the renewed interest, it could serve as the basis for OO proposals
in
> the VHDL-200x arena. (Maybe we were just too far ahead of our time back
> then!)
>
> Perhaps at this point I could offer some personal perspectives on the
> relevant language design issues.
>
> The Objective VHDL proposal for OO data modeling was based on the notion
of
> defining a class, similar to the way it's done in C++, and then declaring
> variables or signals to be of the class. A class encapsulates data
members
> and methods that operate upon them. Derived classes can add further data
> members and methods. The rationale for this approach was that OO features
> were well developed in C++ and related languages, and those features
served
> as a good basis for developing features in VHDL.
>
> The SUAVE proposal, on the other hand, adopts the Ada-95 approach of
> encapsulating a record type in a package as the basis of OO data modeling.
> The details of the record type are made private to the package, and the
> subprograms defined in the package with parameters of the record type
serve
> as the methods of the OO data type. A second package can define a new
> record type that inherits the elements from a parent type and adds new
> elements. The subprograms in the second package can override or extend
> those inherited from the first package. The rational for this approach
was
> that VHDL, and in particular its type ssytem, was strongly founded on that
> of Ada. Since the Ada community had developed OO features extending that
> basis, a parallel extension would serve VHDL.
>
> Since the OOVHDL work was done, VASG developed the protected types
features
> as a way of dealing with concurrency control in the presence of shared
> variables. A protected type encapsulated data members and methods, in a
> similar way to an Objective VHDL class. As a consequence, VHDL now has
the
> basis for both the Objective VHDL and SUAVE approaches. Extensions based
on
> the Objective VHDL approach could be built upon the protected type
> mechanism, or extensions based on the SUAVE approach could be built upon
the
> record and package mechanism, as before. The VHDL-200x group considering
OO
> extensions to VHDL now needs to decide between the two approaches based on
a
> different set of criteria that affected the "play-off" on the OOVHDL
working
> group some years ago.
>
> Let the games begin...
>
> Cheers,
>
> PA
> --
> Dr. Peter J. Ashenden peter@ashenden.com.au
> Ashenden Designs Pty. Ltd. www.ashenden.com.au
> PO Box 640 Ph: +61 8 8339 7532
> Stirling, SA 5152 Fax: +61 8 8339 2616
> Australia Mobile: +61 414 70 9106
>
>
> > -----Original Message-----
> > From: owner-vhdl-200x-dta@server.eda.org
> > [mailto:owner-vhdl-200x-dta@server.eda.org] On Behalf Of
> > Kevin Cameron x3251
> > Sent: Wednesday, 14 May 2003 06:46
> > To: vhdl-200x-dta@server.eda.org
> > Cc: vhdl-200x@server.eda.org
> > Subject: [vhdl-200x-dta] Object oriented VHDL
> >
> >
> > I was wondering if anyone has been looking at a more object-oriented
> > type system
> > for VHDL - since the competion for simulating systems seems to be C++
> > (SystemC)
> > and SystemVerilog, and they both have that.
> >
> > Since I'm interested in hardware/software trade-off I'd like
> > to see VHDL
> > adopt a
> > C++ like scheme (if any) since that makes easier to move algorithmic
> > code from
> > C++ (software) to VHDL (hardware) and vice versa.
> >
> > The scheme used in SystemVerilog is derived from Java via
> > Vera and was
> > bolted
> > on in such a way that it doesn't mesh with modules or structs or
> > interfaces, and isn't
> > very friendly to synthesis, so it wouldn't be hard to do
> > better with VHDL.
> >
> > Kev.
> >
> > --
> > National Semiconductor, Tel: (408) 721 3251
> > 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
> >
> >
> >
>
>
This archive was generated by hypermail 2b28 : Tue May 13 2003 - 19:43:15 PDT