multiple analysis_imp in a single class - other than _imp_decl macro?

[soloist_huaxin]

This is somewhat old but I wish I could find better ways. I need a scoreboard class that takes in 2 types of transaction via uvm_analysis_imp, and currently the only way of doing it is using `*_decl macro. I'm hoping there is a better way since I'm not sure about the impact of using such macro on other classes. If I understand the class reference correctly, using _decl macro essentially creates a different set of uvm base classes, so if I have 2 scoreboards, both using the same _decl macro with same suffix would there be a conflict? for example:

 

file:scoreboard1.svh

 

`uvm_analysis_imp_decl(_rd)

class scoreboard1 extends uvm_scoreboard;

  uvm_analysis_imp_rd #(T1,scoreboard1) imp1;

  uvm_analysis_imp #(T2,scoreboard1) imp2;

 

  function void write_rd(T1 t); //Have to add _rd due to imp_decl macro

  endfunction

 

  function void write(T2 t); //Default method

endclass

 

-end of file-

 

file:scoreboard2.svh

`uvm_analysis_imp_decl(_rd)

class scoreboard2 extends uvm_scoreboard;

  uvm_analysis_imp #(T1,scoreboard1) imp1;

  uvm_analysis_imp_rd #(T2,scoreboard1) imp2;

 

  function void write(T1 t); //Method for T1

  endfunction

 

  function void write_rd(T2 t); //Method for T2

endclass

 

-end of file-

 

Would this create a conflict at compile time? What is best practice for implementing multiple analysis_imp in a single class?

[tudor.timi]

Seeing as how you have analysis ports of different types (different parametrizations), you can't use the analysis FIFO approach. Going by way of the macro is your best bet.

 

You shouldn't have any problems with conflicts because you define these new analysis imports inside the same package where you define your scoreboard (you are using packages, aren't you?). This way, if the same analysis imp is declared in some different package, you're perfectly safe because it's defined in a different scope.

[uwes]

hi,

 

to get multiple ports into one component you can

 

A) make one port only and have a wrapper transaction which encodes the source port plus the original transaction

use the uvm_subscriber (essentially a component with a single port forwarding the call to the place you want)

C) the *_decl macros

 

the decl macros create a new class in the scope where you use the macros. that means you cant use them twice in the same scope with the same argument. 

 

/uwe

[soloist_huaxin]

Seeing as how you have analysis ports of different types (different parametrizations), you can't use the analysis FIFO approach. Going by way of the macro is your best bet.

 

You shouldn't have any problems with conflicts because you define these new analysis imports inside the same package where you define your scoreboard (you are using packages, aren't you?). This way, if the same analysis imp is declared in some different package, you're perfectly safe because it's defined in a different scope.

 

Thanks. Guess I have to go with macro, which isn't that undesirable to me.

 

As for packages I have a follow-up question: for classes in a package, would you suggest adding guards around class as a safety measure? for example:

 

file: class_pkg.v

package class_pkg;

`define CLASS_PKG_DEFINE

`include "class1.vh"

endpackage

--end of file--

file: class1.vh

`ifndef CLASS_PKG_DEFINE

//Something that will cause compile error

***this class should ONLY be included in a package

***use package import to include this class

`else

class class1;

...

endclass

`endif

-end of file-

[tudor.timi]

In the package file, if you add the define before you include the class file, then the condition for the ifndef won't be true anymore and you won't include the class definition. This means your package file should just be:

// file: class_pkg.v
package class_pkg;
`include "class1.vh"
endpackage

Adding define guards for files that are included is AFAIK the way to go. What you usually do is name the define with your file name:

//file: class1.vh
`ifndef CLASS1_SVH
class class1;
...
endclass
`endif

I get that you're trying to avoid the situation where someone includes the class directly in their own code instead of importing it from the package, but that's a bit paranoid, IMO. They would definitely get problems when trying to interface that class they included with your package, because the types would be different from the compiler's point of view (one is defined in their scope, one is defined in the package's scope).

[soloist_huaxin]

In the package file, if you add the define before you include the class file, then the condition for the ifndef won't be true anymore and you won't include the class definition. 

 

That's why I put the class definition in the "`else" part of ifndef.(double-negative?) We have been using per-file guards, but we weren't using packages so it's a necessity. What I'm trying to achieve is to make sure a class can ONLY be included with package, prohibiting others from including class on their own. Yes, it would cause compile failures if others are interfacing with classes included in package, but they could(and I think they will) ignore the package altogether(like we did in the past) and the per-file approach won't stop them from doing it. 

[tudor.timi]

Even so, using your idea you can still add a "`define CLASS_PKG_DEFINE" before including the class instead of importing the package and you haven't solved anything (I'd even go so far as to say you've done more harm than good). This is an issue that you can't fix by coding alone. You have to train people to use packages, pure and simple. If you use a linting tool, you could also catch such issues, by not allowing any user code (except packages) to include any file (maybe with the exception of uvm_macros.svh).

[soloist_huaxin]

Even so, using your idea you can still add a "`define CLASS_PKG_DEFINE" before including the class instead of importing the package and you haven't solved anything (I'd even go so far as to say you've done more harm than good). This is an issue that you can't fix by coding alone. You have to train people to use packages, pure and simple. If you use a linting tool, you could also catch such issues, by not allowing any user code (except packages) to include any file (maybe with the exception of uvm_macros.svh).

 

Thanks for the insight. I fully agree on "This is an issue that you can't fix by coding alone. You have to train people to use packages, pure and simple."