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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~