Re: [sv-ac] formal types proposal

Egad -- I deserve to get dinged on this, but I'll try to autocorrect anyway:

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

I should have said, "gives no information about the first and third
of these things" -- we have the pass by substitution mechanism for
the implicit/void/this arguments.

J.H.

> X-Authentication-Warning: server.eda-stds.org: majordom set sender to owner-sv-ac@eda-stds.org using -f
> Date: Fri, 30 Jun 2006 07:11:27 -0500
> Cc: Bassam.Tabbara@synopsys.com, sv-ac@verilog.org
> From: John Havlicek <john.havlicek@freescale.com>
> Reply-To: john.havlicek@freescale.com
> X-Virus-Status: Clean
> Sender: owner-sv-ac@eda-stds.org
> X-OriginalArrivalTime: 30 Jun 2006 12:15:09.0686 (UTC) FILETIME=[D4B03160:01C69C3E]
> 
> 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.
> 
>