`include "module.v"

[Andy Peters]

Help!

How do I convince some fellow engineers that `include-ing a Verilog
source file into another source file is just bad form? The argument,
"well, you wouldn't #include a C source into another C source file,
now, wouldya?" doesn't seem to do the trick.

Here's the usual set-up that I've been seeing:

`include "defines.h" // this "header" has a bunch of `defines
`define THIS `foo // `foo `defined in defines.h
`define THAT `bar // likewise

`include "module_a.v"
`include "module_b.v"

module toplevel (
signal1,
signal2,
signal3,
... etc
);

module_a u1
();

module_b u2
();

endmodule // toplevel

 

[John_H]

The sad thing is their approach makes sense from a hierarchical perspective.
I sometimes end up with more than one module defined in one file when the
lower modules are always part of the upper module's hierarchy; the approach
is similar to adding the 'include files. On the opposite side of the coin,
I end up with the synthesizer complaining when I forget a module down in the
hierarchy when I'm putting together a fresh compile environment.

The one thing in favor of keeping the `includes out of the design is that
the technique is prone to errors for archiving and moving the full set of
files. I often grep my synthesis project file to make sure I copy over all
the necessary files. I must always, however, keep track of what files I
`include in the design (init_regs.h, for instance) to have all the files
together to fully rebuild. A quick grep for "include" on my Verilog files
will turn those up.

Maybe saying "Bad Engineer!" in a commanding voice will wear them down after
a while.


"Andy Peters" <Bassman59a@yahoo.com> wrote in message
news:9a2c3a75.0410041042.33222e37@posting.google.com...

Help!

How do I convince some fellow engineers that `include-ing a Verilog
source file into another source file is just bad form? The argument,
"well, you wouldn't #include a C source into another C source file,
now, wouldya?" doesn't seem to do the trick.

Here's the usual set-up that I've been seeing:

`include "defines.h" // this "header" has a bunch of `defines
`define THIS `foo // `foo `defined in defines.h
`define THAT `bar // likewise

`include "module_a.v"
`include "module_b.v"

module toplevel (
signal1,
signal2,
signal3,
... etc
);

module_a u1
();

module_b u2
();

endmodule // toplevel

 

[Petter Gustad]

Bassman59a@yahoo.com (Andy Peters) writes:

How do I convince some fellow engineers that `include-ing a Verilog
source file into another source file is just bad form? The argument,

You don't need them and they can cause problems.

Let us say you have to integrate some verification environment that
happens to use a file called defines.h (or some other common name).
Then you will have to revert to some +incdir type of list of
directories to search for include files. It will obviously hit one of
the two (or more) first and use that, which will be the wrong one in
at least one of the cases.

If you use pathnames (I usually use relative pathnames since the
design can be checked out from CVS etc. at any place in the file
system), on your verilog simulator invokation command line you can
avoid this problem.

verilog /path/to/sys1/define.h /path/to/sys1/some.v /path/to/sys2/define.h /path/to/sys2/someother.v

`include "defines.h" // this "header" has a bunch of `defines
`define THIS `foo // `foo `defined in defines.h
`define THAT `bar // likewise

`include "module_a.v"
`include "module_b.v"

module toplevel (
signal1,
signal2,
signal3,
... etc
);

module_a u1
();

module_b u2
();

You could do

verilog +define+THIS=something+THAT=somethingelse defines.v module_a.v module_b.v

Do you really need the foo and bar from defines.h or can they be
defined directly rather than indirectly?


I guess some users prefer to make a single large verilog file with
lots of includes rather than wrapping a script in their favorite
scripting language around the verilog invocation.

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?

 

[John_H]

The one situation I can think of is when a module is a submodule in more
than one location.

If the module "myfifo" is instantiated in three different files, the
tendency of the "include" designer would be to include the file in each of
those three files. When the compiler puts everything together at the end,
it will see the same myfifo module *defined* three different times, erroring
out.

"John_H" <johnhandwork@mail.com> wrote in message
news:4vj8d.10$Be6.382@news-west.eli.net...

The sad thing is their approach makes sense from a hierarchical
perspective.
I sometimes end up with more than one module defined in one file when the
lower modules are always part of the upper module's hierarchy; the
approach
is similar to adding the 'include files. On the opposite side of the
coin,
I end up with the synthesizer complaining when I forget a module down in
the
hierarchy when I'm putting together a fresh compile environment.

The one thing in favor of keeping the `includes out of the design is that
the technique is prone to errors for archiving and moving the full set of
files. I often grep my synthesis project file to make sure I copy over
all
the necessary files. I must always, however, keep track of what files I
`include in the design (init_regs.h, for instance) to have all the files
together to fully rebuild. A quick grep for "include" on my Verilog files
will turn those up.

Maybe saying "Bad Engineer!" in a commanding voice will wear them down
after
a while.


"Andy Peters" <Bassman59a@yahoo.com> wrote in message
news:9a2c3a75.0410041042.33222e37@posting.google.com...
Help!

How do I convince some fellow engineers that `include-ing a Verilog
source file into another source file is just bad form? The argument,
"well, you wouldn't #include a C source into another C source file,
now, wouldya?" doesn't seem to do the trick.

Here's the usual set-up that I've been seeing:

`include "defines.h" // this "header" has a bunch of `defines
`define THIS `foo // `foo `defined in defines.h
`define THAT `bar // likewise

`include "module_a.v"
`include "module_b.v"

module toplevel (
signal1,
signal2,
signal3,
... etc
);

module_a u1
();

module_b u2
();

endmodule // toplevel

 

[Anthony J Bybell]

"John_H" <johnhandwork@mail.com> wrote in message news:<4vj8d.10$Be6.382@news-west.eli.net>...

The one thing in favor of keeping the `includes out of the design is that
the technique is prone to errors for archiving and moving the full set of
files. I often grep my synthesis project file to make sure I copy over all
the necessary files. I must always, however, keep track of what files I
`include in the design (init_regs.h, for instance) to have all the files
together to fully rebuild. A quick grep for "include" on my Verilog files
will turn those up.

Trivial example below as all the files are in one directory, but it
does help to have tools which will generate a so-called "bill of
materials" and/or a compile file trace. (Yes, I used to use a
sorted/uniq'd list with tar's -T flag for just what you say.)

I'm sure such a thing could be done with a really clever perl script
and/or it'd be easily hackable in iverilog or cver or even through
LD_LIBRARY_PRELOAD fun where you're replace the libc open() with your
own invocation to the real one: I actually did that once to determine
which files win4lin was reading on my virtual my ~/win/ drive for the
specific app I needed and deleted everything else. Worked like a
charm.

-t


27 :/tmp> /home/bybell/vertex/t /dosc/pci/pci/rtl/verilog/top.v
+incdir+/dosc/pci/pci/rtl/verilog +libext+.v -y
/dosc/pci/pci/rtl/verilog
Vertex: Verilog Parser v0.0.8 (w)1999-2002 BSI

Processing file '/dosc/pci/pci/rtl/verilog/top.v' ...
Processing include file '/dosc/pci/pci/rtl/verilog/timescale.v' ...
.... returning to file '/dosc/pci/pci/rtl/verilog/top.v' line 60
Processing file "/dosc/pci/pci/rtl/verilog/PCI_BRIDGE32.v" ...
Processing include file '/dosc/pci/pci/rtl/verilog/pci_constants.v'
....
Processing include file
'/dosc/pci/pci/rtl/verilog/pci_user_constants.v' ...
.... returning to file '/dosc/pci/pci/rtl/verilog/pci_constants.v' line
60
.... returning to file '/dosc/pci/pci/rtl/verilog/PCI_BRIDGE32.v' line
57
Processing include file '/dosc/pci/pci/rtl/verilog/timescale.v' ...
.... returning to file '/dosc/pci/pci/rtl/verilog/PCI_BRIDGE32.v' line
60
Processing file "/dosc/pci/pci/rtl/verilog/PCI_IN_REG.v" ...
<etc>

 

[Andy Peters]

Petter Gustad <newsmailcomp6@gustad.com> wrote in message news:<877jq6nmbl.fsf@parish.home.gustad.com>...

Bassman59a@yahoo.com (Andy Peters) writes:

How do I convince some fellow engineers that `include-ing a Verilog
source file into another source file is just bad form? The argument,

You don't need them and they can cause problems.

Let us say you have to integrate some verification environment that
happens to use a file called defines.h (or some other common name).
Then you will have to revert to some +incdir type of list of
directories to search for include files. It will obviously hit one of
the two (or more) first and use that, which will be the wrong one in
at least one of the cases.

If you use pathnames (I usually use relative pathnames since the
design can be checked out from CVS etc. at any place in the file
system), on your verilog simulator invokation command line you can
avoid this problem.

verilog /path/to/sys1/define.h /path/to/sys1/some.v /path/to/sys2/define.h /path/to/sys2/someother.v

Part of the problem is that there's this move towards creating a bunch
of common source files, stored in a common library directory, that one
can include in a design. Of course, it's not under any kind of
source-code control, so you can imagine the problems.

I'm a believer in having all sources for a particular design available
in that design's tree. What's sort of evolved is this nightmare where
there's this one shared directory that has a bunch of sources with
similar names:

foo.v (which has module foo)
foo1.v (which has another version of foo)

and so forth. What happens is that the particular file holding foo is
`included in the source.

Drives me bonkers.

You could do

verilog +define+THIS=something+THAT=somethingelse defines.v module_a.v module_b.v

Do you really need the foo and bar from defines.h or can they be
defined directly rather than indirectly?

In most cases, they shouldn't even be `defined -- they should be
parameters!

And yes, the parameters should be overriden in a script/via command
line, rather than `include-ing a "header" that overrides the `defines.
It's horrific! I know all this -- it's convincing others of the
errors of their ways.

I guess some users prefer to make a single large verilog file with
lots of includes rather than wrapping a script in their favorite
scripting language around the verilog invocation.

Exactly. What you end up with is a big mess.

-a

 

[Me]

Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0410041042.33222e37@posting.google.com>...

Help!

How do I convince some fellow engineers that `include-ing a Verilog
source file into another source file is just bad form? The argument,
"well, you wouldn't #include a C source into another C source file,
now, wouldya?" doesn't seem to do the trick.

I don't understand what are the problems of using includes in the
verilog source versus listing all your source files in the command
line. All my files are in a single directory structure and I use
includes in my source files. Does someone want to enlighten me on why
it's bad?


Glenn

 

[J o h n _ E a t o n (at)]

Me wrote:

Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0410041042.33222e37@posting.google.com>...

Help!

How do I convince some fellow engineers that `include-ing a Verilog
source file into another source file is just bad form? The argument,
"well, you wouldn't #include a C source into another C source file,
now, wouldya?" doesn't seem to do the trick.



I don't understand what are the problems of using includes in the
verilog source versus listing all your source files in the command
line. All my files are in a single directory structure and I use
includes in my source files. Does someone want to enlighten me on why
it's bad?


Glenn

Actually it's not. If you are the sole designer and are doing your own
synthesis on a small design then `include and parameters are useful for
creating your code in a way that makes it easy to reconfigure and create
design variants.

If you are part of a large design team then the designers usually do not
synthesize their own code and using `includes and paramters can cause serious
problems when you hand off to the synthesizers and they have to ensure that
they are building exactly what you designed. They are the ones trying to ban
verilog macros.

The best solution is to use whatever features in the front end that you want
to create your code and then run a verilog preprocessor at the end that
replaces all your 'includes and parameters with their actual values.
You want a completely unambigous delivery that does not depend on loading
the right files in the right order. The flexability that is so useful in
the front end can cause errors in the back end. So design anyway you want
but deliver something that is to simple to mess up.