RE: [sv-bc] Serious issue with default expressions for task and function arguments

Gordon Vreugdenhil wrote:

> I suspect that some people would object to requiring functions
> to be pure within interfaces

Most certainly.  The use of impure functions imported through a
modport is central to an interesting modelling/design approach
(described by Peter Jensen) that makes it possible to create 
generalised designs that can be specialised for a specific 
interface protocol by connecting them to a suitably named 
modport on one of a variety of interfaces - a kind of 
"pure virtual interface" approach.  It needs the existing 
behaviour of always_comb and impure functions in the interface.

> so perhaps the right approach
> is to adopt a "closure" semantic model.

Someone already metioned "messing with the heads" of C
programmers.  The heads of Verilog programmers, presumably,
are fair game for being messed with?
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                   Email: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves 
all rights of privilege in  respect thereof. It is intended for the use of 
the addressee only. If you are not the intended recipient please delete it 
from  your  system, any  use, disclosure, or copying  of this  document is 
unauthorised. The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.


> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> Sent: 03 March 2005 22:30
> To: Mark Hartoog
> Cc: Greg Jaxon; ieee1800@eda.org; SV_BC List
> Subject: Re: [sv-bc] Serious issue with default expressions 
> for task and
> function arguments
> 
> 
> This is the kind of feature interaction that is very problematic
> in the current language definitions.  I definitely appreciate
> the always_comb issue and how it corresponds; that in fact
> dovetails with an issue about which I've touched base with Karen P.
> and which will also be raised.
> 
> There are, in my mind, a couple of alternatives:
>    1) go the functional programming route and begin to talk about
>       "closures" and require that such references retain access
>       to their closure.
>    2) restrict the use of "escaping" references within interfaces
>       so that the closures are empty.
> 
> Interfaces are an issue right now since in some contexts people
> want to think about them as "fancy macros" that expand to
> be real references and in other cases they are talked about
> as being equivalent to hierarchical references to things.
> The semantic of interfaces have not, in my mind, been well
> enough defined to have a clear model for what the "right"
> answer is with respect to other features.  As a result, I think
> that we're seeing relatively ad hoc definitions that in
> other contexts don't make sense.
> 
> I'd rather have a clear and consistent semantic model, even if it
> is more restrictive, than what we appear to have at this point.
> 
> 
> Mark Hartoog wrote:
> 
> >>Obviously, one expects "p" in "foo" to be the parameter.  This
> >>is clear and is the case in virtually any language.  Why should
> >>the name binding of a default parameter value be any different?
> >>
> >>The arguments over static versus dynamic name binding are decades
> >>old.  Is there something distinct about this context that leads
> >>one to disregard that history?
> > 
> > 
> > I have no objection to changing it to this, but this is not what 
> > the LRM currently says. You might want to think about the 
> > following case:
> > 
> > interface if();
> > int a;
> > function foo( input int x = a);
> >    return x;
> > endfunction
> > 
> > modport bus ( import function foo);
> > endinterface
> > 
> > module m(if.bus i);
> > int y;
> > initial y = i.foo();
> > endmodule
> > 
> > module top();
> > if i();
> > m u(i);
> > endmodule
> > 
> > I think the current LRM makes this illegal, and your 
> proposal would make
> > this legal, but for this to be legal, does the modport 
> 'bus' need to 
> > include 'a' as an input port so that the module calling the 
> function 
> > 'foo' can pass it as the default argument? 
> > 
> > We already have this issue in always_comb blocks. If the 
> function foo had
> > no arguments, but just returned the value of 'a' and it was 
> called from
> > an always_comb block, then that always_comb block has to be 
> sensitive to 'a'.
> > It is unclear whether 'a' has to be an input port in the 
> modport for this
> > to be legal.
> > 
> > Gordon Vreugdenhil wrote: 
> > 
> >>Mark Hartoog wrote:
> >>
> >>>In addition to the possibilities mentioned by Gord, you 
> could also outlaw
> >>>the use of non-constant default values on all hierarchical 
> or interface
> >>>function/task calls. You might still have some confusion 
> for the case:
> >>>
> >>>module A();
> >>>parameter p = 1;
> >>>function int foo(int x = p);
> >>>   return x;
> >>>endfunction
> >>>
> >>>initial
> >>>begin
> >>>   int p = 2;
> >>>   $display(foo());
> >>>end
> >>>
> >>>endmodule
> >>>
> >>>Is this legal? If so, what value is displayed? 
> >>
> >>
> >>In my version of reality, of course it is legal.  The "p"
> >>in the default value binds to A.p.  The value displayed is "1".
> >>There is no confusion here just as there is no confusion if
> >>you have:
> >>
> >>   module A();
> >>   parameter p = 1;
> >>   function int foo;
> >>      return p;
> >>   endfunction
> >>
> >>   initial
> >>   begin
> >>      int p = 2;
> >>      $display(foo());
> >>   end
> >>   endmodule
> >>
> >>
> >>Obviously, one expects "p" in "foo" to be the parameter.  This
> >>is clear and is the case in virtually any language.  Why should
> >>the name binding of a default parameter value be any different?
> >>
> >>The arguments over static versus dynamic name binding are decades
> >>old.  Is there something distinct about this context that leads
> >>one to disregard that history?
> >>
> >>Gord.
> >>-- 
> >>--------------------------------------------------------------------
> >>Gordon Vreugdenhil,  Staff Engineer               503-685-0808
> >>Model Technology (Mentor Graphics)                gordonv@model.com
> 
> -- 
> --------------------------------------------------------------------
> Gordon Vreugdenhil,  Staff Engineer               503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
> 
>