RE: [vhdl-200x-dta] Review of: [vhdl-200x] Revised white paper on type genericity

Jim,

I think that the scenario you describe would be better addressed with what
we are thinking of as interfaces - essentially active connection objects
with methods that can be invoked by clients to do interface operations.

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@eda.org 
> [mailto:owner-vhdl-200x-dta@eda.org] On Behalf Of Jim Lewis
> Sent: Thursday, 22 April 2004 01:12
> To: vhdl-200x-dta@eda.org
> Subject: Re: [vhdl-200x-dta] Review of: [vhdl-200x] Revised 
> white paper on type genericity
> 
> 
> Peter,
>  >>... however, what if we took the next step and
>  >>port mapped signals and variables to a package and  
> >>instantiate the package in the process. Now I think I will  
> >>effectively get side-effect access in a procedure.  >  >  > 
> Why not just declare signal and variable parameters on the 
> procedure?  > That's what they're for.  The idea is to make 
> the interfaces and data  > connections explicit, rather than 
> having a spaghetti tangle of side-effects  > and implicit 
> cross references.
> 
> I like passing things through interfaces, however, in 
> testbenches we are calling subprograms up to 1000's of time 
> per testbench.
> 
> With all DUT IO on the call, the subprogram call looks as 
> shown below. Here Clk, nAds, Addr, Data, Read, and nRdy are just along
> for the ride.   As the number of signals or length of signal
> names increases the readability of the test intent decreases. 
> The test intent is passed in the constant parameters.  If the 
> subprogam were to split across multiple lines, the 
> readability decreases further.
> 
>    CpuWrite(Clk, nAds, Addr, Data, Read, nRdy, ADDR0, X"A5A5");
>    CpuRead (Clk, nAds, Addr, Data, Read, nRdy, ADDR0, DataO);
> 
> 
> Since we call the subprograms so many times, to improve the 
> readability of testbenches it is important to be able to 
> focus on the test intent and not get overly concerned with 
> the interface to the DUT.  One way to achieve this is to pack 
> the signals into a record:
> 
>    CpuWrite(CpuRec, ADDR0, X"A5A5");
>    CpuRead (CpuRec, ADDR0, DataO);
> 
> However, due to IO limitiations of VHDL, to make it so
> there is only one record, I have limit myself to types
> that support tristate resolution:  the std_logic family.
> 
> 
> Instantiating packages with ports/parameters would be an 
> alternate method to having to handle record IO and would get 
> us to a call of the following format.
> 
>    CpuWrite(ADDR0, X"A5A5") ;
>    CpuRead (ADDR0, DataO) ;
> 
> 
> Note, my preference would be to make VHDL's record IO
> work better.
> 
> 
> 
>  >>In section 3, Subprograms, I prefer the v1 subprogram 
> generic format
>  >>where:
>  >>subprogram specification ::=
>  >>  procedure designator
>  >>     [ generic ( generic_list ) ]
>  >>     [ [ parameter ] ( formal_parameter_list ) ]
>  >>
>  >>  | [ pure | impure ] function designator
>  >>     [ generic ( generic_list ) ]
>  >>     [ [ parameter ] [ ( formal_parameter_list ) ] return type_mark
>  >>
>  >>
>  >>If we do this, I would prefer we use the key word port to 
> parameter.
> 
>  > To some extent, this is a matter of taste.  My v1 proposal 
> makes subprograms  > consistent with the style of other units 
> that have interfaces, but it's a  > signficant departure from 
> the normal programming-language style that people  > are used 
> to.  The v2 proposal is more in line with the latter, and is  
> > cribbed directly from Ada.
> 
> This might be better, but it is not consistent with other
> VHDL features.  I consider consistency a requirement.
> So if this format is accepted here, then I would consider it
> a requirement to optionally allow generics to be specified 
> first for entities and blocks.
> 
> 
>  > Regarding the keyword in the v1 proposal: I would 
> definitely not use port,  > since a port list is for 
> interface signals only, and has associated static  > 
> semantics (eg, relating to default expressions).  A 
> subprogram has a  > parameter list, with semantics that are 
> different from port lists.  Using  > the keyword port for 
> parameters would be a really bad idea.
> 
>  From a language developer's perspective using parameter 
> makes sense.  From a user's perpsective, we are passing IO to 
> an object, so using a different keyword is inconsistent. Does 
> naming parameters and ports differently for the 
> compiler's/language developer's benefit buy us anything?
> 
> If we go this route, I would suggest that we make the
> port and port map keywords optional for entities.
> 
> 
>  >>Section 7:
>  > ...
>  > Yes, the action procedure is a generic to the traverse 
> subprogram.  It is  > specified in the generic list in the 
> subprogram declaration in the package  > declaration.  In the 
> package body, the generic list is optional in the  > subprogram body.
> 
> Cool.  I like it.
> 
> 
> Cheers,
> Jim
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Jim Lewis
> Director of Training             mailto:Jim@SynthWorks.com
> SynthWorks Design Inc.           http://www.SynthWorks.com
> 1-503-590-4787
> 
> Expert VHDL Training for Hardware Design and Verification 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>