Re: [sv-ac] formal types proposal

Hi Lisa:

On Adam's question regarding sequence instance as clocking event,
I think the right thing to do is to try to make the formal argument
qualifier (notice I am not saying "type" because I do not want to
debate about theories of types) specify as far as possible the 
following three things:

1. The kinds of actual arguments that can be bound to the formal 
   argument.
2. The mechanism for binding the actual argument to the formal
   argument.
3. The ways in which the formal argument can be used within the 
   declaration of the sequence or property.

In the case of implicit qualifier or "void" or "this", the qualifier 
gives no information about these three things.

In other cases, I would like, as far as possible, for the formal
argument qualifier to determine all three of these things.

Some actual arguments are compatible with more than one non-void 
formal argument qualifier.  In such cases, I think the non-void formal 
qualifiers determine different ways in which the formal argument can
be used.  So I think it is better to keep the formal argument
qualifiers separate and duplicate actual arguments as necessary.

E.g., 

   sequence foo(event e, f, sequence r, s);
      @(e) r ##1 @(f) s;
   endsequence

instantiated as

   foo(s1, posedge clk, s2, s1)  // s1, s2 sequence instances

rather than

   sequence bar(event e, f, sequence r);
      @(e) r ##1 @(f) e;
   endsequence

[for which I would expect a compilation error based on the use of e]
instantiated as

   bar(s1, posedge clk, s2)  // s1, s2 sequence instances

Best regards,

John H.


> X-Authentication-Warning: server.eda-stds.org: majordom set sender to owner-sv-ac@eda-stds.org using -f
> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Thu, 29 Jun 2006 16:57:38 -0400
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] formal types proposal
> Thread-Index: AcaboIBg3FJWrIjDRPWVSEfncKLkYgACL0jgAAOjRWA=
> From: "Lisa Piper" <piper@cadence.com>
> X-Received: By mx-sanjose.cadence.com as k5TKvdPe012302 at Thu Jun 29 13:57:39 2006
> X-Virus-Status: Clean
> Sender: owner-sv-ac@eda-stds.org
> X-OriginalArrivalTime: 29 Jun 2006 21:02:18.0896 (UTC) FILETIME=[4EC0E100:01C69BBF]
> 
> This is a multi-part message in MIME format.
> 
> ------_=_NextPart_001_01C69BBE.A7E09EB7
> Content-Type: text/plain;
> 	charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> Hi Bassam,
> 
> =20
> 
> Thanks for the comments.  Return comments below.
> 
> =20
> 
> ________________________________
> 
> From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com]=20
> Sent: Thursday, June 29, 2006 2:53 PM
> To: Lisa Piper; sv-ac@verilog.org
> Subject: RE: [sv-ac] formal types proposal
> 
> =20
> 
> Hi Lisa,
> 
> =20
> 
> I skimmed this a bit and here's some food for thought on what strikes
> me. I think the only 2 *types* to add (detail below) are sequence,
> property, and we also need to add clearly (restate) what (built-in)
> operations are allowed on these types, and what type-casting is allowed
> i.e. between seq/prop.=20
> 
> =20
> 
> Const is not a type it is a qualifier (already in language) that goes
> before a type (bit etc...), so we should use it as such.=20
> 
> Void is highly inadequate, may be a "self" is more meaningful and again
> here this is not a type it is a qualifier. This can possibly be used
> later for other things in language. Also I would feel better about
> backward compatibility as I stated before if this is available, it makes
> porting much easier with this additional tag qualifier.
> 
> [Lisa Piper >>>] I have acknowledged that const is a qualifier.  I'm not
> sure I agree that void is not adequate - it depends on how it is defined
> in this context.  it is clear from the context and uses existing
> keywords.  I think that introducing new keywords will be an enhancement
> versus a fix, and I think it is important to introduce this particular
> one with the others. How about "this"
> 
> =20
> 
> Event also bothers me note that we state that events cannot be operands
> of assertions. Moreover it is inadequate -- we've already established we
> are passing an event_expression, so again a qualifier is what's needed
> here (particularly since sequences fall under this category too and they
> have a type), I can't come up with a good name now, some variant of
> clocking_expr or event_expr should do the trick, preferably if there is
> some "precedent" of sorts in the LRM.
> 
> [Lisa Piper >>>] It is defined that this be used for clock events.  They
> can be used only where an event_control is used - that is for clocking
> properties/sequences and in built-in functions.  It is clearly a
> restricted use of the event data type but I think it is consistent.
> 
> =20
> 
>  I think that Adam brought up some good questions that I am still
> thinking about.  If I have a clocking event that is a sequence instance,
> do I say it is an event or a sequence. In this case, if the user
> specified event, it would have to be used in the context of a clocking
> event.  If it was a sequence, it could be used outside of a clocking
> event.  In this instance I can see that event could be used as a
> qualifier versus a type.=20
> 
> =20
> 
> Looping back around, seq/prop are not qualifiers but are indeed "types"
> with their own operations etc... and the return type is indeed another
> seq/prop. In fact one can think of these types as built-in classes,
> indeed they are, and again we need to organize the information in LRM
> operations/casting etc ... to reflect this.
> 
> [Lisa Piper >>>] So would it be acceptable to define event,  void (or
> whatever name), and const as qualifiers instead of types and state that
> either a qualifier or a type or both can be specified. =20
> 
> =20
> 
> Hope this helps. Take home point, distinction between type and type
> qualifiers.
> 
> =20
> 
> Thx.
> 
> -Bassam.
> 
> =20
> 
> =20
>