SystemVerilog: can't use hierarchical naming from within a p

[mrfirmware]

I'm in testbench land and I've got a DUT with a DDR2 controller
circuit and DIMM model. The circuit and the DIMM model are not our IP
and we'd like not to waste clocks on them in certain simulation runs,
e.g. we wish to focus on our IP. So, I've create a very simple fake
DDR2 controller and DIMM BFM that has the exact module port list as
the DDR2 controller in the circuit. My make file picks either the real
circuit+model or the fake BFM based upon the target name so no Verilog
source code needs to change when switching version, just a rebuild of
the instantiating module.

This is great b/c it's much faster than the actual circuit + model
version. However, we'd like to go faster. In my BFM I have a fake_ddr
hash that is accessed by read and write FIFO. What I'd like to do is
put the data directly into this hash from a few layers up w/o using
any clocks, e.g. from a class method. The problem is, my
write_to_ram() method is in a class within a package and QuestaSim
says (essentially) that I cannot access the fake_ddr hash
hierarchically from within a package.

Any suggestions on how to get to this hash? If I put the hash in my
class, then I might be able to refer back to it from the module
hierarchically but the hash is dependent upon burst size, data bus
width, etc. that is (currently) only known to the BFM via module
parameters.

Thanks,

- Mark

 

On Oct 15, 7:18 pm, mrfirmware <mrfirmw...@gmail.com> wrote:

write_to_ram() method is in a class within a package and QuestaSim
says (essentially) that I cannot access the fake_ddr hash
hierarchically from within a package.

Any suggestions on how to get to this hash? If I put the hash in my
class, then I might be able to refer back to it from the module
hierarchically but the hash is dependent upon burst size, data bus
width, etc. that is (currently) only known to the BFM via module
parameters.

A few thoughts:

(1) The hash will only ever be used in testbench anyhow, so there
is no need for it to be synthesizable. Consider constructing
a class using code inside the BFM, where you have access to
the BFM's parameters and can use them either to type-parameterize
the class itself or as arguments to its constructor:

package DDR_faker;
class DDR_mimic;
....
function new(args...);
...
endclass
endpackage : DDR_faker

module BFM #(params) (...);
import DDR_faker::*;
...
DDR_mimic the_DDR;
...
initial
the_DDR = new(params,...);
...
endmodule : BFM

(2) Alternatively, put an interface instance inside
the BFM; give it access to whatever you need there,
by port connection or whatever; and give your class a
virtual interface handle to that embedded interface
instance.

Ultimately you'll probably do better, and have a less
painful time, if you start using one of the published
verification methodologies and build your BFMs and
DDR-faker blocks as classes instanced in the testbench.
It's a big disruption when you first adopt it, though.
--
Jonathan Bromley

 

[mrfirmware]

On Oct 15, 3:42 pm, s...@oxfordbromley.plus.com wrote:

On Oct 15, 7:18 pm, mrfirmware <mrfirmw...@gmail.com> wrote:

write_to_ram() method is in a class within a package and QuestaSim
says (essentially) that I cannot access the fake_ddr hash
hierarchically from within a package.

Any suggestions on how to get to this hash? If I put the hash in my
class, then I might be able to refer back to it from the module
hierarchically but the hash is dependent upon burst size, data bus
width, etc. that is (currently) only known to the BFM via module
parameters.

A few thoughts:

(1) The hash will only ever be used in testbench anyhow, so there
    is no need for it to be synthesizable.  Consider constructing
a class using code inside the BFM, where you have access to
the BFM's parameters and can use them either to type-parameterize
the class itself or as arguments to its constructor:

  package DDR_faker;
    class DDR_mimic;
      ....
      function new(args...);
        ...
    endclass
  endpackage : DDR_faker

  module BFM #(params) (...);
    import DDR_faker::*;
    ...
    DDR_mimic the_DDR;
    ...
    initial
      the_DDR = new(params,...);
    ...
  endmodule : BFM

(2) Alternatively, put an interface instance inside
    the BFM; give it access to whatever you need there,
by port connection or whatever; and give your class a
virtual interface handle to that embedded interface
instance.

Ultimately you'll probably do better, and have a less
painful time, if you start using one of the published
verification methodologies and build your BFMs and
DDR-faker blocks as classes instanced in the testbench.
It's a big disruption when you first adopt it, though.

Jonathan,

Thanks for the reply. I've tried (1) but since the RTL instantiates
the real DDR controller and I just have 'make' slip the faker in w/o
the RTL knowing I still have the hierarchical access problem.
Suggestion (2) is reasonable but I don't want the conditionalize the
RTL, thus I can't change the BFM's port list - it must match the real
DDR controller exactly. All my other class/BFM combos are instantiated
by the testbench, not the RTL, but since the DDR controller is
instantiated by the RTL I didn't see an easy way to move the
instantiation into the TB. I can't use OVM w/o upgrading my Modelsim
licenses to full SV. With 6 Modelsim SE licenses it'd be too pricey.

Thanks again,

- Mark

 

[mmintz@gmail.com]

Hi Mark,

Welcome to "Packages are third class citizens in SV". I have stopped
using them entirely.

What I have done is put a task in the program block that reaches down
into your module. The program block is the only place that can make
hierarchical references.

Take Care,
Mike Mintz

 

[mrfirmware]

On Oct 16, 6:30 am, "mmi...@gmail.com" <mmi...@gmail.com> wrote:

Hi Mark,

Welcome to "Packages are third class citizens in SV". I have stopped
using them entirely.

What I have done is put a task in the program block that reaches down
into your module.  The program block is the only place that can make
hierarchical references.

Take Care,
Mike Mintz

Mike,

This is good news - and bad. We don't have the full SV license for
QuestaSim so I can't use program blocks. Ugh. Maybe I'll see if we can
upgrade but it's awfully expensive.

Thanks,

- Mark

 

On Oct 16, 8:56 am, mrfirmware <mrfirmw...@gmail.com> wrote:

What I have done is put a task in the program block that reaches down
into your module.  The program block is the only place that can make
hierarchical references.

This is good news - and bad. We don't have the full SV license for
QuestaSim so I can't use program blocks.

Modules can make hierarchical references down into your module.

I assume that Mike meant that a program block is the only place that
can make hierarchical references to everywhere that it is possible to
do so. A module cannot make a hierarchical reference into a program,
but a program can make one into a module or another program. But if
you don't have any programs, this does not matter to you.