Re: [sv-ac] 928 Proposal Updated

Hi Lisa:

Between alternatives 1 and 2, I strongly favor fixing 
this now.

I like the direction of the proposal you have outlined.

I think we will have to put some more thought into 
how "const" works as a type and whether we allow "const"
with other types.

We should also think about the fact that pass-by-value 
is the default for tasks and functions, while pass-by-reference
is the mechanism for typed arguments to sequences and 
properties and pass-by-substitution is the mechanism 
for untyped (and presumably, void, sequence, and property)
arguments.

Even if we do not add pass-by-value as a part of this
solution, I think we should have a clear idea of how 
to add it later.

How does the argument passing work in PSL?

Best regards,

John H.


> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Tue, 27 Jun 2006 14:40:40 -0400
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] 928 Proposal Updated
> Thread-Index: AcaaDNZwVdRAZQUnSKCvR9WVy8Q16wAA6K/gAAEJTfA=
> From: "Lisa Piper" <piper@cadence.com>
> Cc: <Eduard.Cerny@synopsys.com>, <dmitry.korchemny@intel.com>,
>         <Brad.Pierce@synopsys.com>, <sv-ac@eda-stds.org>
> X-Received: By mx-sanjose.cadence.com as k5RIef8N010126 at Tue Jun 27 11:40:42 2006
> X-OriginalArrivalTime: 27 Jun 2006 18:41:57.0873 (UTC) FILETIME=[5E9B3E10:01C69A19]
> 
> Hi all,
> 
> I think the earlier we make these types of changes, the less impact it
> will have on users. This implies that IF we do it, we need to do it now.
> I am for fixing it now!
> 
> Personally I think the four big "holes" that are needed to fix this:
> 
> 	void      for untyped parameters when used in this context
> 	property  for properties
> 	sequence  for sequences
> 	const     for constant integers for repetition and delays
> 
> Using this terminology does not create any new keywords so there is
> minimal change. I would make the default type "void" to help with
> backwards compatibility issues (this is different as Manisha pointed out
> than the default type of logic for functions/tasks).
> 
> I'm not sure whether people care, but PSL does not allow untyped
> parameters, and their syntax for arguments is like tf_port_list.  PSL
> uses the keywords property, sequence, and const for arguments.
> 
> So the questions are:
> 
> 1) should we do this now - that is make the port list consistent with
> tf_port_list format AND add new types to the list of allowed type names.
> 	- add all 4 types?
> 	- are the type names ok?
> 	- is the default of "void" ok?
> 
> 2) strip it out and live with it forever
> 
> 3) other?
> 
> Lisa
> 
> 
>