RE: [sv-ec] How do I make a "Virtual Port"

 I confess to having made an incorrect change when doing the global
search-and-replace to make LRM terminology more consistent.  I have put the
draft4 wording back in for draft 7a. 
 
Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898
www.sutherland-hdl.com


 
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Rich,
Dave
Sent: Saturday, October 04, 2008 11:12 PM
To: sv-ec@eda.org; Stuart Sutherland
Subject: RE: [sv-ec] How do I make a "Virtual Port"
 
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  <http://www.mailscanner.info/> 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.