Subject: Re: e-mail discussion on review report
From: Peter Ashenden (petera@cs.adelaide.edu.au)
Date: Sun Mar 12 2000 - 11:01:35 PST
Wolfgang Nebel wrote:
>
> Both need extensions:
> - e.g. SUAVE: entity/architecure objects,
> - e.g. Objective VHDL: genericity.
I agree that design entities can be considered as a form of class in an
object model, but I am yet to be convinced that entity/architecture
inheritance is a useful thing. This is honest scepticism - if it is
proven to be useful, I will happily work towards including it in the
language.
So far, the examples I have seen have been small and could equally well
be expressed using component instatiation. The register augmented with
enable could well be expressed as a composition of a register with a
tristate gate.
The power of inheritance in OO data modeling comes from two aspects:
reuse and polymorphism. You define a superclass and a subclass.
Inheritance allows you to reuse aspects of the superclass in the
subclass. Polymorphism allows you to define polymorphic objects, and
either treat them uniformly as objects of the root class, project them
to specific subclasses, or dynamically bind using their specific class.
The proposal for inheritance in design entities only promises reuse
benefits; there are is no corresponding polymorphism. I question the
amount and cost of reuse that can be achieved in practice. The
difficulty lies in what is inherited, overridden or added when defining
a derived architecture.
Consider what happens when defining a derived data class. Here, it is
the methods that are inherited, reused and added. The interface to a
method is its set of parameters, which are bound dynamically when the
method is called. Thus, at the time of overriding or adding of methods
(compile time), there is no binding of interface established for the
methods.
Compare this with overriding and addition of concurrent statements in a
derived architecture. Here, the interface to a statement is either an
explicit port list (in the case of a component instance, or an implicit
set of signals that are sensed or driven (in the case of a process or
process-equivalent). The statement has its interface statically bound
in the parent architecture. [I am using the term bound in the general
sense, not the specific sense of VHDL component binding.] In the case
of a component instance, the ports are bound to actual signals in the
enclosing architecture. In the case of process statements, the process
names signals that it senses and drives.
In a derived architecture, the inherited statements also inherit the
static binding to signals. If the derived architecture simply needs to
override inherited behaviour, it can replace an inherited statement with
a new statement that has the *same* statically bound interface.
However, if the derived architecture needs to augment the inherited
behaviour, it must do so within the context of the existing bindings.
It cannot remove the existing bindings.
To illustrate, consider the example of a parent register architecture
and a derived register with tristate enable architecture. The parent
has a storage process that is bound to the register output port by
virtue of the driver within the process. In the derived architecture,
the statement is inherited, along with the binding from the process to
the output port. The desire is to augment the architecture by including
a tristate buffer between the storage process and the output. However,
the inherited binding cannot be broken. The only solution is to replace
the storage process, thus losing the reuse sought. A better solution
would have been to *instantiate* the unbuffered register as a component
in a buffered register architecture.
I think the problem described in general terms above prevents effective
post-hoc reuse of designs. It may be useful for planned reuse, where
the designer takes particular care in designing a parent architecture in
the form of a template. If the designer has a general structure in
mind, they can include dummy statements in the architecture to serve as
placeholders to be overridden in derived architectures. But this only
works in cases where the inheritance hierarchy is envisaged a priori by
the designer.
As I said at the outset, I have yet to see convincing examples where
this kind of reuse buys you much. Until I see such an example, I remain
sceptical.
> SUAVE targets the system level and abstract data modelling.
Yes, but also modeling in general. I think the OO data modeling and the
genericity features improve expressiveness across the modeling spectrum.
> Objective VHDL targets electronic hardware design and synthesizability.
SUAVE by no means precludes synthesis of hardware. Indeed, the reason
Ada-95 distinguishes classwide types from specific types is to enable
more static bidning of types than approaches such as are used in C++ and
Java. The benefit, when translated to SUAVE, is that if the spcific
type is known statically, synthesis of operations is straightforward.
But even in the case of classwide types, synthesis is feasible. The
class hierarchy is fixed at elaboration time, so synthesis of dynamic
binding could be done using the tag of an object as a selector.
What is not intended for low-level hardware synthesis is the abstract
communication and dynamic process features of SUAVE. These are oriented
towards high-level modeling and high-level synthesis.
> In the discussion the group should avoid to get lost in many detailed
> technical issues but concentrate on the global picture, i.e. the position
> and scope the group sees for VHDL in the electronic system design world.
I don't think it is desirable or even feasible to constrain the
discussion. The whole point of the review was to choose between two
proposals on technical issues.
> - Should it become a system level language?
To answer this, we need to be clear on what you mean by "system level".
If you ask a system engineer, they will talk about design at the level
of requirements and constraints, abstract behaviour in various domains
(electrical, mechanical, etc), power, performance, task scheduling, and
so on. I think we would agree we are not trying to address this level
of design. That is within the scope of the SLDL committee.
Another answer is high-level behavioural and structural. But then you
need to ask, "How high?" VHDL already supports behavioural and
structural modling above the register transfer level. I think our job
is to improve its utility and expressiveness at the levels already
addressed by the language. You can (and people do) use VHDL for
expressing algorithms to be implemented by a hardware system. VHDL
includes programming language constructs to support this - the type
system, sequential control structures, and procedural abstractions are
typical of programming languages. Our job is to improve these
facilities to support more recent programming practice. This means
object-orientation, genericity and concurrency.
> (N.b. if you like ADA style for this, why not use ADA95 for system level?)
Lots of reasons, but that's a red herring to this discussion.
> - Should it support a seamless path to hardware, i.e. should it be
> synthesizable?
Most definitely, but not constrained by the synthesis technology
embodied in current synthesis tools. There has been much research in
high-level synthesis over recent years, and commercial products are
starting to appear. We should expect the field to mature over the next
several years, and see increasing adoption of behavioural synthesis as
chip complexities increase.
Cheers,
PA
-- Dr. Peter J. Ashenden Email: petera@cs.adelaide.edu.au Dept. Computer Science peter.ashenden@acm.org University of Adelaide peter.ashenden@computer.org Adelaide, SA 5005 Phone: +61 8 8303 4477 Australia Fax: +61 8 8303 4366WWW: http://www.cs.adelaide.edu.au/~petera (includes PGP public key)
This archive was generated by hypermail 2b28 : Sun Mar 12 2000 - 15:15:59 PST