Subject: Re: e-mail discussion on review report
From: Wolfgang Nebel (Nebel@informatik.uni-oldenburg.de)
Date: Tue Mar 14 2000 - 14:43:04 PST
Dear Peter,
just some remarks included in the conversation - although now it gets
difficult to read:
At 11:01 Uhr -0800 12.03.2000, Peter Ashenden wrote:
>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.
Using entity/architecture inhertitance structural bindings can only be
modified by overriding the drivers of these bindings, in your example you
would have to override the register process, unless you have planned for
reuse. For this tiny example it may not really make a lot of sense, however
giving the possibility to override processes (or equivalent constructs) in
larger designs allows for more efficient reuse. Further potential for reuse
lies in the addition of functionality in terms of processes.
Looking at the design flow we have in mind, this is not equivalent to
structural modelling. Structural modelling refers to physical structures
and partitionings of the ASIC or chip/FPGA sets, while processes are used
to specify sequential and concurrent behavior. Ideally concurrent processes
within one entity could be subject to global scheduling and resource
sharing within the entity, while I would not expect this bejond the entity
border. Deriving a structural model from a behavioral one is a design task.
Further including existing models into a design with the possibility to
adapt tghem to changed requirements is an other application. Hence the use
of entities is a means to express design intent and not to overcome reuse
limitations of the language.
>
>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.
As within Objective VHDL
>
>> 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.
Can you point me to tools which are capable to handle this level?
>
>> 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.
I did not want to constrain the discussion (I would not even know how to do
that), but to suggest to step back for a moment and keep in mind that the
users from my point of view will regard any language as a means to
- enter their design intent into design tools and to
- capture and reuse design know-how.
They want to solve their task as efficient as possible, they want stable
tool now. Hence I was suggesting to put priority in the discussion on scope
of the group which is closely related to the position of OO-VHDL in the
design flow.
>
>> - 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.
Throughout the entire design flow to synthesizable code!
>
>> (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.
>
Currently I am observing more activities to synthesize from C and
derivatives. Frankly speaking, your question "how high?" nails it down. How
far do we expect SLDL to come down the path to hardware, what role do we
see for SystemC and others, and what is the final scope within which VHDL
(and its extensions ;-) ) are is stronger from the user perspective. One
strong point I clearly see is its power in structural and configuration
modelling. For this reason I am suggesting to build on the strong parts of
VHDL.
Cheers,
Wolfgang
________________________________________________________________________
| | | | | | Tel.: +49-(0)441-798-4519
| | | | | | Secretary: +49-(0)441-798-3132
|O|F|F|I|S| Fax: +49-(0)441-798-2145
Home: +49-(0)441- 52826
Prof. Dr.-Ing. Wolfgang Nebel Mobile: +49-(0)171-62 52827
Escherweg 2 e-mail: nebel@offis.de
D-26121 Oldenburg or: nebel@computer.org
Germany http://www.offis.de
________________________________________________________________________
This archive was generated by hypermail 2b28 : Tue Mar 14 2000 - 14:53:18 PST