SV: How to "import" an interface into a module w/o `include?

M

mrfirmware

Guest
I'd like to have a file with an interface in it and then "import" it
into my top level testbench.sv file. Something like this:

// File: my_if.sv
interface my_if;
....
endinterface : my_if

---

// File testbench.sv
import my_if::*;

module testbench;
my_if if0;
....
endmodule : testbench

There's something very basic I'm missing here, I realize that. I just
don't understand how to "link" things like programs, interfaces, and
classes into a top level module. All I see are nasty `includes which
just inlines the text of the included files into the file. There must
be a better way?

Thank,
- Mark
 
On Tue, 11 Sep 2007 18:52:43 -0000, mrfirmware
<mrfirmware@gmail.com> wrote:

I'd like to have a file with an interface in it and then "import" it
into my top level testbench.sv file. Something like this:

// File: my_if.sv
interface my_if;
...
endinterface : my_if

---

// File testbench.sv
import my_if::*;

module testbench;
my_if if0;
...
endmodule : testbench

There's something very basic I'm missing here, I realize that.
Click to expand...
Verilog compilation is a little odd that way.

Each module (and interfaces are just a sort of module on steroids)
gets compiled individually, the result going into... well, that's
tool-dependent, but somewhere. And when the compiler's all done
with compiling the modules, then someone has to decide what top-
level modules exist in the sim. Having taken that decision,
the elaborator then builds each top-level in a top-down fashion:
module Top has instances of modules Mid1 and Mid2, module Mid2
has instances of module Bottom1 and Bottom2.... until you have
assembled the complete instance hierarchy and you can then get on
and simulate it.

Like I said, it's tool-dependent. To a very rough approximation:
- if you're using Synopsys VCS, it's necessary to present the
compiler with *all* the source code that participates in your
simulation. Hence the `include mullarkey. Each compilation
is independent of the others. (Yes, Synopsys gurus, I know
that VCS-MX doesn't work like that. But for simple use of
regular VCS it's not far from the truth.) Having compiled
all your modules, VCS looks for any modules that are not
instantiated by any other module; these it assumes to be
the top level module(s).
- if you're using Cadence NC/Incisive, you compile each Verilog
source file individually (and it doesn't matter a scrap if
the source file instantiates some module you've not yet
compiled); precisely *where* you compile into is determined
by settings in the cds.lib and hdl.var files, but the NCLaunch
tool will set up sensible defaults for you. You then invoke
the ncelab tool, telling it which module(s) (already compiled)
are to be the top level(s). ncelab constructs a "snapshot",
an image of the ready-to-run simulation.
- if you're using ModelSim/Questa, you create one or more
library directories, use the 'vlog' compiler to compile
each Verilog source file into an appropriate library (again
it doesn't matter if a source file instantiates a module
that's not yet compiled) and then you use the 'vsim'
simulator to stitch them all together, telling it which
top-level modules you want and in which libraries to go
looking for any modules they instantiate.

What you definitely do NOT is to "import" an interface. In
SystemVerilog you can only "import" a package.

Generally, when you specify a module or interface instance
in Verilog or SV, the compiler *assumes* that the compiled
version of that module or interface will exist when you
finally get around to stitching the whole sim together.
Consequently, the checks that a compiler can perform on
the syntax of a module instance are somewhat limited;
most of the checking gets done at elaboration time.

My guess is that you will be able to make everything work
simply by omitting the offending "import" statement.
Give us a bit more detail and we can be more precise.

Oh, by the way: when instantiating a module or interface
that has no ports, it is nevertheless mandatory to give
the instance an empty port connection list in parentheses:

my_if if0(); // NOT my_if if0;

cheers
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
mrfirmware <mrfirmware@gmail.com> writes:

just inlines the text of the included files into the file. There must
be a better way?
Click to expand...
You can include my_if.sv before testbench.sv in your driver script.

vcs my_if.sv testbench.sv

Verilog compiles everyting in a single process.

Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
On Sep 11, 4:11 pm, Petter Gustad <newsmailco...@gustad.com> wrote:
mrfirmware <mrfirmw...@gmail.com> writes:
just inlines the text of the included files into the file. There must
be a better way?

You can include my_if.sv before testbench.sv in your driver script.

vcs my_if.sv testbench.sv

Verilog compiles everyting in a single process.
Click to expand...
Yes, but this is a SystemVerilog (I guess I'm in the wrong group)
which does not default to the Verilog behavior (which I find odd as a
C programmer).

Thanks,
- Mark
 
On Sep 11, 3:09 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
On Tue, 11 Sep 2007 18:52:43 -0000, mrfirmware



mrfirmw...@gmail.com> wrote:
I'd like to have a file with an interface in it and then "import" it
into my top level testbench.sv file. Something like this:

// File: my_if.sv
interface my_if;
...
endinterface : my_if

---

// File testbench.sv
import my_if::*;

module testbench;
my_if if0;
...
endmodule : testbench

There's something very basic I'm missing here, I realize that.

Verilog compilation is a little odd that way.

Each module (and interfaces are just a sort of module on steroids)
gets compiled individually, the result going into... well, that's
tool-dependent, but somewhere. And when the compiler's all done
with compiling the modules, then someone has to decide what top-
level modules exist in the sim. Having taken that decision,
the elaborator then builds each top-level in a top-down fashion:
module Top has instances of modules Mid1 and Mid2, module Mid2
has instances of module Bottom1 and Bottom2.... until you have
assembled the complete instance hierarchy and you can then get on
and simulate it.

Like I said, it's tool-dependent. To a very rough approximation:

- if you're using ModelSim/Questa, you create one or more
library directories, use the 'vlog' compiler to compile
each Verilog source file into an appropriate library (again
it doesn't matter if a source file instantiates a module
that's not yet compiled) and then you use the 'vsim'
simulator to stitch them all together, telling it which
top-level modules you want and in which libraries to go
looking for any modules they instantiate.
Click to expand...
This is my tool (v6.3b). I do compile different sources into different
libs but not one file per lib. Must I? I've got my RTL in lib nz_rtl,
my testbench and top level .sv files in lib nz_top, and my packages in
nz_pkg. I put my sole a typedef package file and the interface file
into nz_pkg and then tell vlog about all the library dirs via -L
nz_rtl -L nz_pkg, etc. However, vlog just complains that 'my_if' is an
undefined variable (which isn't too surprising as I don't know how it
could possibly know it's an interface).

What you definitely do NOT is to "import" an interface. In
SystemVerilog you can only "import" a package.
Click to expand...
Okay. Got it, thanks.

Generally, when you specify a module or interface instance
in Verilog or SV, the compiler *assumes* that the compiled
version of that module or interface will exist when you
finally get around to stitching the whole sim together.
Consequently, the checks that a compiler can perform on
the syntax of a module instance are somewhat limited;
most of the checking gets done at elaboration time.
Click to expand...
For modules, this seems to work just fine. For interfaces, I'm not
having any luck. Do I just put the interface in a file all by itself
and then use it in the top level module w/o any sort of declaration? I
just don't get the magic here. A compiler has to know what the heck
the "thing" is you will define later, doesn't it?

My guess is that you will be able to make everything work
simply by omitting the offending "import" statement.
Click to expand...
No joy.

Give us a bit more detail and we can be more precise.
Click to expand...
I've tried.

Oh, by the way: when instantiating a module or interface
that has no ports, it is nevertheless mandatory to give
the instance an empty port connection list in parentheses:

my_if if0(); // NOT my_if if0;
Click to expand...
Got it and thanks very much.

- Mark
 
On Tue, 11 Sep 2007 20:01:28 -0000,
mrfirmware <mrfirmware@gmail.com> wrote:

mrfirmw...@gmail.com> wrote:
I'd like to have a file with an interface in it and then "import" it
into my top level testbench.sv file. Something like this:

// File: my_if.sv
interface my_if;
...
endinterface : my_if

---

// File testbench.sv
import my_if::*;

module testbench;
my_if if0;
...
endmodule : testbench

There's something very basic I'm missing here, I realize that.
[...]
[ModelSim/Questa] (v6.3b). I do compile different sources into different
libs but not one file per lib. Must I?
Click to expand...
No, certainly not. In fact, many people work with just one
single library for the entire project; that's OK too.

I've got my RTL in lib nz_rtl,
my testbench and top level .sv files in lib nz_top, and my packages in
nz_pkg.
Click to expand...
Do you mean the source files are in those directories, or
do you mean that you have used 'vlog' to compile your source files
into ModelSim libraries of those names? If these are simply
the names of directories that contain your source code, then
they are not "libraries" at all and your use of the -L option
is misplaced.

I put my sole a typedef package file and the interface file
into nz_pkg and then tell vlog about all the library dirs via -L
nz_rtl -L nz_pkg, etc. However, vlog just complains that 'my_if' is an
undefined variable (which isn't too surprising as I don't know how it
could possibly know it's an interface).
Click to expand...
Ahah... Do you *really* mean that it's *vlog* complaining (not vsim) ?
If so, it's simple... You don't want the -L option at that stage,
unless you're using packages. You need the -L option to 'vsim'
to tell it the names of all the libraries into which you've compiled
your various SystemVerilog modules and interfaces.

Just as a for-instance...

Suppose you have this file tree:

project_home/
project_home/sim/ ---- working dir for the simulator
project_home/sources/ ---- dir to hold all source code
project_home/sources/nz_pkg/
project_home/sources/nz_pkg/your_interface.sv
project_home/sources/nz_pkg/your_package.sv
project_home/sources/nz_rtl/
project_home/sources/nz_rtl/your_module1.sv
project_home/sources/nz_rtl/your_module2.sv
project_home/sources/nz_top/
project_home/sources/nz_top/your_design_top.sv
project_home/sources/nz_top/your_testbench.sv

File "your_package.sv" contains a package:
package your_package;
...
endpackage : your_package

Most of the other files import it; for example,
file "your_interface.sv" might look like this:

import your_package::*;
interface your_interface;
...
endinterface

And the instance hierarchy will be

your_testbench
|
|__ your_design_top
|
|__ your_module1
|
|__ your_interface
|
|__ your_module2

My compile/load script for ModelSim might look
something like this:

cd project_home/sim
# make a bunch of libraries - only needed on first run of
# the script, will give harmless warnings on later runs
vlib pkg_lib; # make a ModelSim lib for the packages
vlib rtl_lib; # and another for the RTL design
vlib tb_lib; # and a third for the testbench
# compile package first, into pkg_lib
vlog -work pkg_lib ../sources/nz_pkg/your_package.sv
# now compile all the other code, in any order;
# make pkg_lib visible to each compile so they can
# import the package as needed; put design modules
# into "rtl_lib" and testbench modules into "tb_lib"
vlog -work rtl_lib -L pkg_lib ../sources/nz_pkg/your_interface.sv
vlog -work rtl_lib -L pkg_lib ../sources/nz_rtl/*.sv
vlog -work rtl_lib -L pkg_lib ../sources/nz_top/your_design_top.sv
vlog -work tb_lib -L pkg_lib ../sources/nz_top/your_testbench.sv
# OK, now everything compiled, load it into ModelSim
# making sure that the simulator looks in the right libs
vsim -novopt -L pkg_lib -L rtl_lib tb_lib.your_testbench

Natch, you may want to add a bunch of other options on some
of these commands. The point I'm really trying to get across
is that a directory full of source code is absolutely NOT the
same as a ModelSim library. (Please, please don't get me
started about Verilog configurations and "libraries", the
Verilog library mapping file [as opposed to ModelSim's
library mapping] and the `uselib directive. That would
take too long, and it's not at all clear my blood pressure
would cope.)

Hope this makes some sense.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
mrfirmware <mrfirmware@gmail.com> writes:

Yes, but this is a SystemVerilog (I guess I'm in the wrong group)
which does not default to the Verilog behavior (which I find odd as a
C programmer).
Click to expand...
For VCS it's the same.

Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
On Tue, 11 Sep 2007 20:01:28 -0000,
mrfirmware <mrfirmware@gmail.com> wrote:

Sorry, I failed to answer this rather key question:

Generally, when you specify a module or interface instance
in Verilog or SV, the compiler *assumes* that the compiled
version of that module or interface will exist when you
finally get around to stitching the whole sim together.
Consequently, the checks that a compiler can perform on
the syntax of a module instance are somewhat limited;
most of the checking gets done at elaboration time.

For modules, this seems to work just fine. For interfaces, I'm not
having any luck. Do I just put the interface in a file all by itself
and then use it in the top level module w/o any sort of declaration? I
just don't get the magic here. A compiler has to know what the heck
the "thing" is you will define later, doesn't it?
Click to expand...
Well... you'd think so, yes. But in Verilog or SV, the following
syntax (at the top level of a module or interface)

name1 name2(...);

can ONLY be an instantiation. So the compiler just thinks
to itself: "ok, name1 is the name of a module or interface,
name2 is the instance name, it will all be sorted out at
elaboration time" and that's as far as it can go. There
is absolutely no requirement for name1 to be declared
in the current compilation scope. That's just the way
Verilog works, and SV preserves backward compatibility
with that.

It does mean, of course, that all manner of silly errors
will get past the compiler, only to be detected much
later at elaboration time. Fortunately, the compilers
usually preserve plenty of source code backtrack information
so they can give you half-decent diagnostics at elab time.
It's still frustrating, though, especially to people who
are accustomed to proper separately-compiled languages
like VHDL or C++.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On 2007-09-11, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote:
On Tue, 11 Sep 2007 20:01:28 -0000,
mrfirmware <mrfirmware@gmail.com> wrote:

mrfirmw...@gmail.com> wrote:
I'd like to have a file with an interface in it and then "import" it
into my top level testbench.sv file. Something like this:

// File: my_if.sv
interface my_if;
...
endinterface : my_if

---

// File testbench.sv
import my_if::*;

module testbench;
my_if if0;
...
endmodule : testbench

There's something very basic I'm missing here, I realize that.
[...]
[ModelSim/Questa] (v6.3b). I do compile different sources into different
libs but not one file per lib. Must I?

No, certainly not. In fact, many people work with just one
single library for the entire project; that's OK too.

I've got my RTL in lib nz_rtl,
my testbench and top level .sv files in lib nz_top, and my packages in
nz_pkg.

Do you mean the source files are in those directories, or
do you mean that you have used 'vlog' to compile your source files
into ModelSim libraries of those names? If these are simply
the names of directories that contain your source code, then
they are not "libraries" at all and your use of the -L option
is misplaced.
Click to expand...
No. For now, I have all my files in one dir. No sub-dirs. Make will find
all the sources automatically when I do end up moving them into proper subdirs.

I put my sole a typedef package file and the interface file
into nz_pkg and then tell vlog about all the library dirs via -L
nz_rtl -L nz_pkg, etc. However, vlog just complains that 'my_if' is an
undefined variable (which isn't too surprising as I don't know how it
could possibly know it's an interface).

Ahah... Do you *really* mean that it's *vlog* complaining (not vsim) ?
If so, it's simple... You don't want the -L option at that stage,
unless you're using packages. You need the -L option to 'vsim'
to tell it the names of all the libraries into which you've compiled
your various SystemVerilog modules and interfaces.
Click to expand...
Indeed. E.g.

vlog testbench.sv -work /user/modell/proj/xs1_tb/out/nz_tb
-L /user/modell/proj/xs1_tb/out/nz_pkg
-L /user/modell/proj/xs1_tb/out/nz_rtl
-quiet -nologo -novopt -incr -lint -source -hazards
-timescale 1ns/1ps -dpiheader testbench_dpi.h

###### testbench.sv(145): perbus_if pb_if();
** Error: testbench.sv(145): Undefined variable: perbus_if.
** Error: testbench.sv(145): near "pb_if": syntax error, unexpected "IDENTIFIER"

Line 145 contains the attempt to instantiate a perbus_if which is
an interface defined in the nz_pkg lib (created by vlib).

Just as a for-instance...

Suppose you have this file tree:

project_home/
project_home/sim/ ---- working dir for the simulator
project_home/sources/ ---- dir to hold all source code
project_home/sources/nz_pkg/
project_home/sources/nz_pkg/your_interface.sv
project_home/sources/nz_pkg/your_package.sv
project_home/sources/nz_rtl/
project_home/sources/nz_rtl/your_module1.sv
project_home/sources/nz_rtl/your_module2.sv
project_home/sources/nz_top/
project_home/sources/nz_top/your_design_top.sv
project_home/sources/nz_top/your_testbench.sv

File "your_package.sv" contains a package:
package your_package;
...
endpackage : your_package

Most of the other files import it; for example,
file "your_interface.sv" might look like this:

import your_package::*;
interface your_interface;
...
endinterface

And the instance hierarchy will be

your_testbench
|
|__ your_design_top
|
|__ your_module1
|
|__ your_interface
|
|__ your_module2

My compile/load script for ModelSim might look
something like this:

cd project_home/sim
# make a bunch of libraries - only needed on first run of
# the script, will give harmless warnings on later runs
vlib pkg_lib; # make a ModelSim lib for the packages
vlib rtl_lib; # and another for the RTL design
vlib tb_lib; # and a third for the testbench
# compile package first, into pkg_lib
vlog -work pkg_lib ../sources/nz_pkg/your_package.sv
# now compile all the other code, in any order;
# make pkg_lib visible to each compile so they can
# import the package as needed; put design modules
# into "rtl_lib" and testbench modules into "tb_lib"
vlog -work rtl_lib -L pkg_lib ../sources/nz_pkg/your_interface.sv
vlog -work rtl_lib -L pkg_lib ../sources/nz_rtl/*.sv
vlog -work rtl_lib -L pkg_lib ../sources/nz_top/your_design_top.sv
vlog -work tb_lib -L pkg_lib ../sources/nz_top/your_testbench.sv
# OK, now everything compiled, load it into ModelSim
# making sure that the simulator looks in the right libs
vsim -novopt -L pkg_lib -L rtl_lib tb_lib.your_testbench
Click to expand...
This is pretty much what my makefile does too. I do use vmap to map the
long dir name to a shorter name but I think that step could be skipped
as I never actually refer to the short name in any switch usage.

Natch, you may want to add a bunch of other options on some
of these commands. The point I'm really trying to get across
is that a directory full of source code is absolutely NOT the
same as a ModelSim library. (Please, please don't get me
started about Verilog configurations and "libraries", the
Verilog library mapping file [as opposed to ModelSim's
library mapping] and the `uselib directive. That would
take too long, and it's not at all clear my blood pressure
would cope.)

Hope this makes some sense.
Click to expand...
It does and thank you.
--
- Mark
 
On Wed, 12 Sep 2007 13:15:36 GMT,
Mark Odell <mao@gwp4.efd.local> wrote:

vlog testbench.sv -work /user/modell/proj/xs1_tb/out/nz_tb
-L /user/modell/proj/xs1_tb/out/nz_pkg
-L /user/modell/proj/xs1_tb/out/nz_rtl
-quiet -nologo -novopt -incr -lint -source -hazards
-timescale 1ns/1ps -dpiheader testbench_dpi.h

###### testbench.sv(145): perbus_if pb_if();
** Error: testbench.sv(145): Undefined variable: perbus_if.
** Error: testbench.sv(145): near "pb_if": syntax error, unexpected "IDENTIFIER"

Line 145 contains the attempt to instantiate a perbus_if which is
an interface defined in the nz_pkg lib (created by vlib).
Click to expand...
OK. This compile error is NOTHING TO DO WITH THAT. If your
interface instantiation were syntactically OK, then the vlog compiler
would not make any attempt to find your interface definition - as
I mentioned in another post, I think. There is a different, simpler
problem. For example:

- spurious punctuation on some previous line of code
- you're trying to instantiate the interface in some
context where an instance is illegal (e.g. outside
any module or interface body)
- mismatched begin...end somewhere earlier in the code

Can you post the preceding 144 lines of code? I betcha
it's something totally trivial...
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On 2007-09-12, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote:
On Wed, 12 Sep 2007 13:15:36 GMT,
Mark Odell <mao@gwp4.efd.local> wrote:

vlog testbench.sv -work /user/modell/proj/xs1_tb/out/nz_tb
-L /user/modell/proj/xs1_tb/out/nz_pkg
-L /user/modell/proj/xs1_tb/out/nz_rtl
-quiet -nologo -novopt -incr -lint -source -hazards
-timescale 1ns/1ps -dpiheader testbench_dpi.h

###### testbench.sv(145): perbus_if pb_if();
** Error: testbench.sv(145): Undefined variable: perbus_if.
** Error: testbench.sv(145): near "pb_if": syntax error, unexpected "IDENTIFIER"

Line 145 contains the attempt to instantiate a perbus_if which is
an interface defined in the nz_pkg lib (created by vlib).

OK. This compile error is NOTHING TO DO WITH THAT. If your
interface instantiation were syntactically OK, then the vlog compiler
would not make any attempt to find your interface definition - as
I mentioned in another post, I think. There is a different, simpler
problem. For example:

- spurious punctuation on some previous line of code
- you're trying to instantiate the interface in some
context where an instance is illegal (e.g. outside
any module or interface body)
- mismatched begin...end somewhere earlier in the code

Can you post the preceding 144 lines of code? I betcha
it's something totally trivial...
Click to expand...
No need. Your intuition was correct. I fooled around with the
placement of the declaration and got it to compile. The
problem was, other than my ignorance, placing the declaration
within a named initial begin/end block. Apparently, you can't
do that.

In retrospect I suppose having a locally scoped interface
within my initial block doesn't make much sense. I sure
wish vlog could give a more informed error output. After
having gcc explain my errors in helpful detail I'm at a
loss to comprehend the cryptic, misleading, non-contextual
output of the vlog "compiler".

Thank you again for your patient help.
--
- Mark
 
On Wed, 12 Sep 2007 13:47:06 GMT,
Mark Odell <mao@gwp4.efd.local> wrote:

In retrospect I suppose having a locally scoped interface
within my initial block doesn't make much sense.
Click to expand...
Indeed so.

I sure wish vlog could give a more informed error output.
Click to expand...
That's the Verilog experience. It's not entirely the tool's
fault, since *so* much checking must be postponed until
elaboration time. Your bad syntax could so easily be so
many other things - the joys of a language with so little
redundancy in its syntax, I don't think :-(

If it would make you feel any better, you could exploit
the new "extern module" feature in SystemVerilog
(works for interfaces too):

extern module foo
( input [3:0] a
, output logic [15:0] y
);

module test;
logic [3:0] a;
logic [15:0] y;
foo F(.*);
initial begin
a = 0;
repeat(16) #10 a++;
end
endmodule : test

Now you've explicitly specified the "prototype" of module foo
in the same compilation scope as the instance - of course, in
practice you would `include a header file(s) containing all your
extern module declarations. This gives the compiler a much
better chance to check on things like number, data type and
width of port connections - checks that in classic Verilog
would necessarily be postponed until elaboration. Happily,
Questa/ModelSim supports this nice new SystemVerilog feature.

It doesn't help with the specific error you introduced, though;
this is because module names inhabit a different namespace than
other identifiers. Recall that the ONLY place you can legally
have a module name within the body of a module is as part of
a hierarchical name, or as the module name on a module instance.
Your erroneous "instance-in-a-procedural-block" was neither of
these things, so it never crossed the compiler's mind to
imagine that it was a module name.

Yes, yes, I'm making excuses for it :)
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On Wed, 12 Sep 2007 17:32:47 +0100, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

If it would make you feel any better, you could exploit
the new "extern module" feature in SystemVerilog
Click to expand...
Great idea. Works well.

(works for interfaces too):
Click to expand...
Oh no it doesn't. Sorry! No such thing as "extern interface".
(There are good reasons for that.)

Apologies
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top