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-04-2004, 07:42 PM
Andy Peters
Guest
 
Posts: n/a
Default `include "module.v"

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
Reply With Quote
  #2 (permalink)  
Old 10-04-2004, 10:44 PM
John_H
Guest
 
Posts: n/a
Default Re: `include "module.v"

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" <[email protected]> wrote in message
news:[email protected] om...
> 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



Reply With Quote
  #3 (permalink)  
Old 10-04-2004, 11:35 PM
Petter Gustad
Guest
 
Posts: n/a
Default Re: `include "module.v"

[email protected] (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?
Reply With Quote
  #4 (permalink)  
Old 10-05-2004, 12:29 AM
John_H
Guest
 
Posts: n/a
Default Re: `include "module.v"

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" <[email protected]> wrote in message
news:[email protected]
> 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" <[email protected]> wrote in message
> news:[email protected] om...
> > 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

>
>



Reply With Quote
  #5 (permalink)  
Old 10-05-2004, 03:27 AM
Anthony J Bybell
Guest
 
Posts: n/a
Default Re: `include "module.v"

"John_H" <[email protected]> wrote in message news:<[email protected]>...

> 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>
Reply With Quote
  #6 (permalink)  
Old 10-05-2004, 07:03 AM
Petter Gustad
Guest
 
Posts: n/a
Default Re: `include "module.v"

"John_H" <[email protected]> writes:

> 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,



I would suggest using CVS or a simular source code control system
rather than copying the files around.

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?
Reply With Quote
  #7 (permalink)  
Old 10-05-2004, 05:14 PM
John_H
Guest
 
Posts: n/a
Default Re: `include "module.v"

"Petter Gustad" <[email protected]> wrote in message
news:[email protected]
> "John_H" <[email protected]> writes:
>
> > 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,

>
>
> I would suggest using CVS or a simular source code control system
> rather than copying the files around.
>
> 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?


A: Because my mail reader and composer are oriented for threaded
conversations and start at the top of each post; scrolling each post to the
bottom of a thread I already know is often not worth the effort when the
topic has become uninteresting.
Q: Why is bottom posting unnatural?

But then what happens when I have a file that's no longer in the project?

If I split the development off from the current track (a chip in a shipping
product) to start a new product, I can check out a fresh set of files but
I'd need to reimplement the version control in the new location anyway.
Perhaps there are nicer ways of keeping parallel developments going but this
is a one-designer chip.


Reply With Quote
  #8 (permalink)  
Old 10-05-2004, 06:28 PM
Petter Gustad
Guest
 
Posts: n/a
Default Re: `include "module.v"

"John_H" <[email protected]> writes:

> But then what happens when I have a file that's no longer in the
> project?


You mean you want to delete it? In CVS you can do cvs remove.


> If I split the development off from the current track (a chip in a
> shipping product) to start a new product, I can check out a fresh
> set of files but I'd need to reimplement the version control in the
> new location anyway. Perhaps there are nicer ways of keeping
> parallel developments going but this is a one-designer chip.


If it's a shipping product you can use cvs tag to mark the versions of
all the files used to sign off the chip. You can then continue the
development, possibly bumping the verion numbers of all the files to
2.0 or similar.

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?
Reply With Quote
  #9 (permalink)  
Old 10-05-2004, 10:18 PM
Andy Peters
Guest
 
Posts: n/a
Default Re: `include "module.v"

Petter Gustad <[email protected]> wrote in message news:<[email protected]>...
> [email protected] (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
Reply With Quote
  #10 (permalink)  
Old 10-06-2004, 08:40 AM
Petter Gustad
Guest
 
Posts: n/a
Default Re: `include "module.v"

"John_H" <[email protected]> writes:

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


Try this:

http://www.gustad.com/pics/badesign.gif

:-)

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?
Reply With Quote
  #11 (permalink)  
Old 10-06-2004, 09:08 AM
Petter Gustad
Guest
 
Posts: n/a
Default Re: `include "module.v"

[email protected] (Andy Peters) writes:

> 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.


Sounds very frustrating. I think they might have to experience the
problem to understand it. It's a pain to clean up such a mess
afterwords. I found this message written by myself some time ago, most
likely after been through such a process:

http://tinyurl.com/4yyxm

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?
Reply With Quote
  #12 (permalink)  
Old 10-06-2004, 02:37 PM
Me
Guest
 
Posts: n/a
Default Re: `include "module.v"

[email protected] (Andy Peters) wrote in message news:<[email protected] 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
Reply With Quote
  #13 (permalink)  
Old 10-06-2004, 05:02 PM
John_H
Guest
 
Posts: n/a
Default Re: `include "module.v"

"Petter Gustad" <[email protected]> wrote in message
news:[email protected]
> "John_H" <[email protected]> writes:
>
> > Maybe saying "Bad Engineer!" in a commanding voice will wear them
> > down after a while.

>
> Try this:
>
> http://www.gustad.com/pics/badesign.gif


LOLOL !!
- Thanks.


Reply With Quote
  #14 (permalink)  
Old 10-07-2004, 08:26 PM
J o h n _ E a t o n (at) hp . com (no spaces)
Guest
 
Posts: n/a
Default Re: `include "module.v"

Me wrote:
> [email protected] (Andy Peters) wrote in message news:<[email protected] 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.




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
*RANT* Ridiculous EDA software "user license agreements"? license_rant_master Verilog 35 04-29-2005 04:48 PM
Why do we need "check" "call" "misc" in PLI? Lee Verilog 1 05-17-2004 03:42 PM
problem running icarus verilog 0.7 - "target_design entry point is missing" malexgreen Verilog 0 11-20-2003 06:03 AM
Can't find companion website for the "Ciletti" Verilog book. Teece Verilog 1 11-12-2003 05:55 PM
SystemVerilog: "logic" or "ulogic?" Cliff Cummings Verilog 1 09-20-2003 11:55 PM


All times are GMT +1. The time now is 02:23 PM.


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