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

Hi Jonathan,  

 

-----Original Message-----
From: jonathan.bromley@doulos.com [mailto:jonathan.bromley@doulos.com] 
Sent: Friday, October 03, 2008 1:16 AM
To: Alsop, Thomas R
Cc: sv-ec@server.eda.org
Subject: Re: [sv-ec] How do I make a "Virtual Port"

 

Tom

 

> class RegisterAccess ; 

>    logic        myPwrUp;

>    logic [15:0] myRegWr;

>    logic [15:0] myRegRd;

 

But... these will be variables (data members) of the object.

I suspect you would like them to be references to some

real signals in the module-based world outside the class?

[Alsop, Thomas R] Exactly.  

 

>    function new(logic myPwrUp, [15:0] myRegWr, [15:0] myRegRd);

>       this.myPwrUp = myPwrUp;

>       this.myRegWr = myRegWr;

>       this.myRegRd = myRegRd;

>    endfunction

> 

> And here is the construction code:

> 

>    RegisterAccess RA;

>    initial begin

>       RA = new(cb.mu2mlcrwrpwrup, cb.mu2mlcrwr, cb.ml2mucrrd);

 

No, this won't work.  All you are doing is to use the current 

values of those three signals to initialize the values of 

data members of your class.  I guess you already knew that :-)

 

I suppose in some hypothetical future world you might be 

able to write

 

   class SignalTwiddler;

     ref logic TheSignal;

     function new(ref logic WhichSignal);

       TheSignal = WhichSignal;

     endfunction

     ...

 

but for the time being there is no such thing as a pointer

or reference to an individual signal.  

[Alsop, Thomas R] Sniff... (head hanging down).  Okay. But I would love
to see this in the 2012 LRM, so I may join the SV-EC to make this
happen...

 

The only ways I know

to do what you want are...

 

  1) the canonical approach:

  use a virtual interface variable to point to a real 

interface instance.

[Alsop, Thomas R] Downside is that if the name in the interface changes,
I have to change the name used in the classes.  You'll probably argue
that the interface name shouldn't change, but our DUT interfaces change
all the time.  But yes, in this case, I can map the changed signal
instead of changing the interface and all the TB code.  I understand
this, we still see a strong usage of "ref" pointers in classes.

 

  2) abstract-BFM approach:

  Make an abstract base class for your SignalTwiddler.

  Create a module that can see the required signal

  directly.  In that module, declare a class derived from

  SignalTwiddler that implements the required virtual method;

  construct an instance of that class, in an initial block

  in the module, and give a copy of the resulting object

handle to your verification code.

[Alsop, Thomas R] So your saying I basically creating a virtual method
within the _module_ where it existes and which then acts on the signal,
then pass the handle to the TB code to call when I need it.  But this
doesn't create the generic reusable class code for all the DUTs that
will be using this. I'd have to do this for every DUT. Yikes! Really we
have three signals out of hundreds in each DUT which get acted upon (for
this protocol), and the protocol is the same across dozens of DUTs.
Each DUT has different signal names.  Unless I have ref like property, I
have to separate out these 3 signals into their own interface, make them
virtual, and then hook up via mapping the names of the signals to the
interface.  I can try that, but it's still somewhat painful to implement
and means I'll have many sets of interfaces. 

 

I don't think there's anything especially troublesome about

using virtual interfaces here.  You just:

 - create an interface to encapsulate a group of signals 

   matching the ones you want to access in your DUT;

 - create a (static, of course) instance of that interface

   in your test harness module

 - arrange that the DUT ports are connected or otherwise

   linked to the test-access signals in the interface

 - set up a virtual interface to point to the interface 

   Instance

[Alsop, Thomas R] Precisely, but again this seems painful.  I'll try it
and let you know how it works.  Still I think there is a lot of merit in
a ref binding for properties in classes. Instead of jumping through all
these hoops, I could have just set up a ref property and upon
construction binded it to a specific signal.  

 

In other words, you can have a pointer to an interface

instance (virtual interface) but you can't have a pointer

to anything else in the static module hierarchy (except

events - that might be useful...)

 

Forgive me if I've missed the real point of your question.

I have a bunch of examples on how to do this, so please

feel free to contact me directly if you'd like something

more specific.

[Alsop, Thomas R] I think you nailed what I'm trying to do.  Appreciate
your help again!! 

 

Regards

-- 

Jonathan Bromley

 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.