FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > Verilog

Verilog comp.lang.verilog newsgroup / usenet

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 10-15-2008, 07:18 PM
mrfirmware
Guest
 
Posts: n/a
Default SystemVerilog: can't use hierarchical naming from within a package?

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
Reply With Quote
  #2 (permalink)  
Old 10-15-2008, 08:42 PM
Guest
 
Posts: n/a
Default Re: SystemVerilog: can't use hierarchical naming from within apackage?

On Oct 15, 7:18 pm, mrfirmware <[email protected]> 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
Reply With Quote
  #3 (permalink)  
Old 10-15-2008, 09:05 PM
mrfirmware
Guest
 
Posts: n/a
Default Re: SystemVerilog: can't use hierarchical naming from within apackage?

On Oct 15, 3:42*pm, [email protected] wrote:
> On Oct 15, 7:18 pm, mrfirmware <[email protected]> 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

Reply With Quote
  #4 (permalink)  
Old 10-16-2008, 11:30 AM
Guest
 
Posts: n/a
Default Re: SystemVerilog: can't use hierarchical naming from within apackage?

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
Reply With Quote
  #5 (permalink)  
Old 10-16-2008, 01:56 PM
mrfirmware
Guest
 
Posts: n/a
Default Re: SystemVerilog: can't use hierarchical naming from within apackage?

On Oct 16, 6:30*am, "[email protected]" <[email protected]> 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
Reply With Quote
  #6 (permalink)  
Old 10-16-2008, 07:17 PM
Guest
 
Posts: n/a
Default Re: SystemVerilog: can't use hierarchical naming from within apackage?

On Oct 16, 8:56*am, mrfirmware <[email protected]> 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.
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Cross-hierarchical upward name references Evan Lavelle Verilog 2 08-20-2007 10:17 AM
Race in hierarchical access? Neo Verilog 3 08-13-2007 06:43 PM
VHDL package Verilog testbench rik Verilog 5 10-12-2006 11:21 PM
parameter declarations and hierarchical references Mike Verilog 5 07-13-2006 11:20 PM
Hierarchical FSM? Davy Verilog 1 04-01-2006 02:00 AM


All times are GMT +1. The time now is 11:27 AM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved