RE: [sv-ec] Re: Feedback from Freescale on name resolution issues

From: Jonathan Bromley <jonathan.bromley_at_.....>
Date: Mon Oct 22 2007 - 01:46:40 PDT
> I was thinking about the class randomize using the object RNG and
> std::randomize using the thread RNG. Attached is an example where
> changing to the thread RNG has a unwanted result. In the example, the
> random sequences in the two instances become the identical - which is
> likely not what is wanted.
> 
> But to me, the real issue is that you (Freescale) see a need 
> to develop a methodology that doesn't use the class randomize
> method - because you don't want unexpected behavior. That in
> itself says to me that the class randomize is broken - and
> needs to be fixed. 

A couple of observations, from someone who (note carefully) has
minimal experience of Vera but who knows 'e' well:

I was fascinated (horrified?) to see the suggestions from 
Arturo and others that we use std::randomize if we want 
different name resolution rules.  I confess that this idea 
had never before crossed my mind, but it is spectacularly 
counter-intuitive and confusing that the two forms have 
such (potentially) widely different behaviour. And, of 
course, there is the issue about thread stability and 
seed control.

The idea that inline constraints should silently favour
resolution into the target object has always seemed absurd
to me.  I'm sure that Vera users would disagree, but 
note that 'e' treats all names in an inline constraint
in the same way as names in the context in which it appears,
except that the special name "it" is a handle to the object
being randomized.  This seems to me to be easier to read and 
debug, less error-prone, and more natural.  And of course it
makes it trivially easy to refer to local automatic variables
from expressions in the constraint.

Personally, I have always regarded it as a major usability 
flaw that you can't already use "item." in an inline 
constraint to malke an explicit reference into the object
being randomized (and, note, that could perfectly well
work for std::randomize too, if it were randomizing a
class object).  And the various suggestions about
"obj.randomize() with (var1, var2) {constraints}"
seem to me to be obscure, even though they allow us to
get backward compatibility.

Is there any possibility that we could permit the use of
"item." in inline constraints, and then decree that 
if "item." appears *anywhere* in the constraint block, 
the name binding rules change for the *whole* of the 
constraint block?  That would permit the current form
to be preserved for backward compatibility and, perhaps,
for future deprecation.
-- 
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

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Oct 22 01:50:05 2007

This archive was generated by hypermail 2.1.8 : Mon Oct 22 2007 - 01:51:54 PDT