Michael Burns wrote: > Following on to my own message, I should reiterate that our > users _expect_ to bind preferentially into the object. > They like the way things work today; they just want a > way, when writing reusable VIP with type parameters or > other kind of opaque types, to "bulletproof" the VIP Apologies to Michael; I had gotten carried away with my personal preference for explicit binding into the target object, and had not fully understood this strength of preference from very experienced users. Thinking some more about it, I start to find myself at least partly agreeing; the inline constraint is just another constraint, and as such "belongs" inside the target object. However, inline constraints also offer a specific and valuable opportunity to have local values, from the context of the inline site, involved in the constraints. So.. would the following make any sense (obviously, the specific syntax is only a straw-man): obj.randomize() with { x < local(y-3); }; Here "local()" is a pseudo-function that requires its argument expression to be evaluated strictly in the context of the inline site. Furthermore, existence of one or more local() expressions in the constraint should strictly require all other names and expressions in the constraint to be evaluated as if they were embedded in the target object's class. I thought it might be better to apply the "local()" to an entire expression rather than to individual names - because it would be more concise in some cases. And I prefer some kind of function-like syntax, because I don't want any suggestion that name resolution rules are being altered here - it's just a directive to evaluate the expression precisely as it would be evaluated outside the "with" block. I'm not at all convinced that "local" is the right word, but it makes at least some sense to me and I think it's syntactically unambiguous here. If we also define the semantics to be that the local() expressions should be pre-evaluated, before the call to randomize(), then we get a rather interesting new feature for free: obj.randomize() with { x != local(obj.x); }; Without needing a local state variable, we have imposed a constraint between a data member's current and next values. That's something I often find myself wishing to do in practice. -- 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 Thu Oct 25 01:00:05 2007
This archive was generated by hypermail 2.1.8 : Thu Oct 25 2007 - 01:00:41 PDT