Subject: Re: e-mail discussion on review report
From: Peter Ashenden (petera@cs.adelaide.edu.au)
Date: Tue Mar 14 2000 - 20:08:42 PST
Wolfgang Nebel wrote:
>
> 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.
Precisely.
> 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.
But this only works if the parent's processes that you don't want to
override do not drive signals that you need the new processes to drive.
I think I understand the point your are making, but I say again, I have
yet to see a non-trivial example where this works and affords
significant reuse. As they say in a US radio station, "Show me the
money!"
> 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.
I concur.
> Deriving a structural model from a behavioral one is a design task.
Possibly automatic (via behavioural synthesis).
> 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.
Sorry, I don't understand the point.
> >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?
Not yet, but we're working on them. I have a student starting work on
synthesis of communication using SUAVE channels.
> >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.
We are designing a trial-use standard, leading towards some form of
subsequent standard. This is a process lasting several years. I don't
think we should constrain the language design to what is directly
synthesizable now. VHDL has been around for nearly 20 years, and only
now are we starting to see tools that can deal with more than a
rudimentary subset of the language. If we seriously believe in the
longevity of our language design, we should project how it will be used
in 2, 5, 10 and 20 years from now.
> >> - 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!
Agreed 150%!
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 : Tue Mar 14 2000 - 20:10:52 PST