RE: [vhdl-200x-ft] FT-12: comments on reading out-mode parameters

I know of no reason not to be consistent. Therefore, I agree with applying
the change to variable parameters as well as signal parameters and ports.

-Steve Bailey

> -----Original Message-----
> From: owner-vhdl-200x-ft@eda.org
> [mailto:owner-vhdl-200x-ft@eda.org] On Behalf Of Peter Ashenden
> Sent: Wednesday, September 15, 2004 2:06 AM
> To: vhdl-200x-ft@eda.org
> Subject: [vhdl-200x-ft] FT-12: comments on reading out-mode parameters
>
> Folks,
>
> I was reviewing the notes from the 26-Jul-04 telecon relating
> to FT-12 (allowing reading of out-mode interface objects).
> The notes indicate that participants wanted to allow reading
> out-mode signal parameters and ports, but not to allow
> reading of out-mode variable parameters.
>
> I'd prefer we uniformly allow reading of out-mode objects, as
> proposed in the current FT-12 document. This would mirror
> the change made in Ada-95. I offer the following comments
> from the Ada-95 Rationale:
>
> 6.1.1 Out Parameters
>
> In Ada 83 a formal parameter of mode out could not be read,
> even after
> being initialized within the procedure. This forced certain
> algorithms
> to include a local variable just to accumulate a result and
> which was then
> assigned to the out parameter. Introducing such a local
> variable is error
> prone, because the final assignment may be mistakenly omitted.
>
> Similarly, if an out parameter is passed to a second
> procedure to be filled
> in, the value returned cannot be checked prior to returning
> from the first
> procedure.
>
> For Ada 95, we have removed the restrictions on the use of
> out parameters.
> Specifying that a formal parameter is of mode out indicates
> that the caller
> need not initialize it prior to the call. However, within
> the procedure,
> once the parameter has been initialized, it may be read and
> updated like
> any other variable. As with a normal variable, it is an
> error to depend on
> the value of an out parameter prior to its being initialized.
>
> ...
>
> I think the same arguments apply in the case of VHDL. As
> testbenches become more complex, code in subprograms will
> become more and more like regular software code. I see no
> reason for us to assume that testbench developers will be
> immune from the pitfalls mentioned above for software developers.
>
> End $0.02.
>
> 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
>
>
>
Received on Wed Sep 15 05:14:54 2004