Stu and Jonathon, There seems to be an improper editorial change going from draft4 to draft5. There was a change to consolidate explicitly stating all the various fork blocks into a generic fork block "Within a fork-join_any or fork-join_none fork-join block-block, it shall be illegal to refer to formal arguments passed by reference other than in the initialization value expressions of variables declared in a block_item_declaration of the fork." However in this case, the simple fork/join was originally excluded because only the other two types of forks were explicitly mentioned. The original text from IEEE Std 1800-2005 thru draft 4 says "Within a fork-join_any or fork-join_none block, it shall be illegal to refer to formal arguments passed by reference other than in the initialization value expressions of variables declared in a block_item_declaration of the fork." Jonathan, So I do believe it is legal to call the start() task within a fork/join_none with a hierarchical reference as its actual argument. I believe the LRM does not specify the effect on an actual argument passed by reference, but I agree that it should be counted as a potential procedural assignment. However, if you change the formal to a const ref, then there can be no assignment to that argument. That should allow you to set up a monitor to a variable that has a continuous assignment. Dave > -----Original Message----- > From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On > Behalf Of Brad Pierce > Sent: Saturday, October 04, 2008 10:02 AM > To: sv-ec@server.eda.org > Subject: RE: [sv-ec] How do I make a "Virtual Port" > > Jonathan, > > > illegal to access a ref argument in a fork...join_none > > I don't know if it's relevant to your test case, but according to the > LRM via ballot issue 232 (Mantis 652) > > "Within a fork-join block, it shall be illegal to refer to formal > arguments passed by reference other than in the initialization value > expressions of variables declared in a block_item_declaration of the > fork." > > -- Brad > > -----Original Message----- > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of > jonathan.bromley@doulos.com > Sent: Saturday, October 04, 2008 1:01 AM > To: Rich, Dave > Cc: sv-ec@eda.org; Alsop, Thomas R > Subject: RE: [sv-ec] How do I make a "Virtual Port" > > [Dave Rich] > > Having said all that, I do have a register probe class (attached) > > that may do what you are looking for. You can pass a hierarchical > > signal to the constructor, and it forks off two threads that keep > > the signal in sync with the class property. > > I suggested something very similar to Tom Alsop in a > separate email: spawn, as an independent thread, > a long-running task that has the signal of interest > as a ref argument. It's potentially a very useful > idea, I believe. > > Unfortunately, one of the three mainstream simulators > I can try reports this as an error, asserting that it > is illegal to access a ref argument in a fork...join_none. > This seems odd to me, but I can't really find LRM > evidence to back up the legality of such usage. > > Yet another simulator allows it, but infers a > procedural driver on the signal from the fact > that it is passed to a task as a ref argument; > this prevents you from using the technique > to monitor the state of any signal that has > a continuous driver on it. > > I'm sure someone else has a clearer idea than I do > about whether all this is truly legal and reasonable... > -- > 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 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. > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sat Oct 4 23:13:42 2008
This archive was generated by hypermail 2.1.8 : Sat Oct 04 2008 - 23:14:19 PDT