> 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