Importing package

SystemVerilog
,
1

Hi all.
During building my systemverilog packages for commercial verification testbench, I have met importing issue for systemverilog packages.

In a_pkg.sv
package a_pkg;
include "a_1.sv" include “a_2.sv”
endpackage: a_pkg

In a_1.sv,
class A;
// contents of A
endclass: A

In a_2.sv,
class B;
// contents of B
endclass: B

In b_pkg.sv,
package b_pkg;
import a_pkg::*; // I am expecting b_pkg can use classes in a_pkg.
class C;
// contents of C
endclass: C
endpackage: b_pkg

In tb.sv
import b_pkg::*;
module tb;
A a; // Error!
B b; // Error!
C c;
endmodule

I’ve already added import a_pkg::8; above a line of import b_pkg to resolve this issue, but I am trying to make it successful to compile this with the line “import a_pkg::*;”

Can anyone give me wisdom?

2

In reply to stephenkim:

A package import only makes identifiers potentially visible in the scope where the import statement exists (the importing scope). The identifiers do not get imported unless there is an actual reference to the identifier, and the import statement does not make the identifiers visible as if they declared in the importing scope. In other words, the wildcard import pack::* doesn’t actually import anything until there is a reference to a specific identifier that appears in the importing scope.

There is an package export statement that will make an identifier visible as if was declared in the importing scope

package b_pkg;
  import a_pkg::*; // I am expecting b_pkg can use classes in a_pkg.
  class C;
    // contents of C
  endclass: C
  export a_pkg::A;
  export a_pkg::B;
endpackage: b_pkg

Note that I had to explicitly reference A and B to get them imported into b_pkg before they part of what gets imported by import b_pkg::*;. Most people will just import b_pkg where it is needed.

1 Like
3

Hi @dave_59

I’d never heard of this “export” functionality within packages. Seems super useful for multiple layers of reuse (Configuration sequences from hierarchical subblock testbenches for example). A question, does this approach preserve where the classes defined in the exported package originate from to avoid namespace collisions?

For example if we have the following packages (defined in different files, and indeed different testbenches that later we are importing into a subsystem level testbench somewhere higher in the project hierarchy)

package a_pkg;
  class A;
    //contents of A
  endclass: A
endpackage: a_pkg

package b_pkg;
  class A;
    //contents of A
  endclass: A
endpackage: b_pkg

package c_pkg;
  import a_pkg::*;
  import b_pkg::*;
  export a_pkg::*;
  export b_pkg::*;
endpackage c_pkg

Is there any way to extract a_pkg::A and b_pkg::A as different classes once they’ve both been exported by c_pkg? Something like c_pkg::a_pkg::A?

We currently get around namespace collisions by enforcing that import my_pkg::* is disallowed and forcing verifiers to be explicit about their namespace when declaring variables, but it leads to clunky packages at higher levels, needing to import individual packages from far down the hierarchy tree, and it looks like export could solve that.

Sorry for the long winded question and thanks in advance for your help!
Liam