RE: [sv-ac] 1728 mantis: "let" construct vs function

1)
I agree about benefit from seqeuence / property arguments.
 
But there would be still alternative - allow sequence / property to be
specified as actual parameter for the type parameter, and than we can go
back to the parametrized function / tasks idea again.
 
(other variant: introduce explicit 'sequence' and 'property' parameters as
opossed to 'type' parameters (if you prefer to avoid conflicts / ambiguity
with 'sequence' and 'property'  apperance in contexts where the built-in
types and class types are allowed as 'type' parameters),
 
                    btw, the sequence and property definitions semantics
would benefit greatly from the 'sequence' and 'property'  parameters too,
 
                    this issue was also rised some time ago ...
 )
 
 
 
2) The context sensitivness - shall be the same for function call and let
statement as long as you keep the function code following basic structural
programming rule:
    - no global references from inside the function,
 
    Than all the sensitive data must be provided as arguments to the
function, so they have to be placed explicitly at the function call
construct, and thus they will be exposed exactly at the assertion
sensitivity context.
 
 
The "let" construct is a nice idea. 
But if the parametrized functions will be introduced eventually, than it may
appear that the "let" will just duplicate the same capabilities that the
parametrized functions will provide, and will not provide any unique
capabilities any more. 
 
Mirek

  _____  

From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
Sent: 7 kwietnia 2008 16:56
To: Mirek Forczek; sv-ac@server.eda.org
Subject: RE: [sv-ac] 1728 mantis: "let" construct vs function


There are several advantages to let over parameterized tasks and functions
(which have not been done yet because it is not trivial to do so). Others
can explain them better than I. One example, though, is that let arguments
can be sequences and properties. Another is their context sensitiveness.
 
Shalom


  _____  

From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Mirek Forczek
Sent: Monday, April 07, 2008 5:34 PM
To: sv-ac@server.eda.org
Subject: [sv-ac] 1728 mantis: "let" construct vs function


Hi,
 
The 1728 mantis introduces 'let' construct: the motivation is given as:
 
"Including let expressions into packages (See Clause 25) is a natural way to
implement a well-structured customization for assertions."
 
there is an example also:
 
// in a package
let at_least_two(sig, rst = 1'b0) = rst || ($countones(sig) >= 2);

// in a design
reg [15:0] sig1; reg [3:0] sig2;
    always_comb begin
        q1: assert (at_least_two(sig1));
        q2: assert (at_least_two(~sig2));
    end
 
 
I'm wondering if the same could be achieved just with functions (?):
 

// in a package
function automatic bit at_least_two(sig, rst = 1'b0);
    return rst || ($countones(sig) >= 2);
endfunction


// in a design (no change at all vs 'let' version)
reg [15:0] sig1; reg [3:0] sig2;
    always_comb begin
        q1: assert (at_least_two(sig1));
        q2: assert (at_least_two(~sig2));
    end
 
 
Are there any other benefits in having 'let' construct over already existing
'function' ?
 
If it is about unbounded argument types in 'let' construct, a parametrized
function and tasks shall be considered as an alternative.
They shall provide same flexibility as the "let" construct but they would be
an extension of an existing concept (function, task) instead of a brand new
one (let).
The parametrized function and tasks extension (functions and tasks with
#parameters - in particular: with type parameters) would be consistent with
already intorduced concpet of the parametrized classes - and their methods
in particular.
 
 
Regards,
Mirek
  

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 

---------------------------------------------------------------------

Intel Israel (74) Limited



This e-mail and any attachments may contain confidential material for

the sole use of the intended recipient(s). Any review or distribution

by others is strictly prohibited. If you are not the intended

recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.