Why (or why not) one module per file? 
Author Message
 Why (or why not) one module per file?

Hello,

I would like to open the "one module per file" rule to discussion.
Our company has this rule, presumeably to simplify Perl script
processing.

However, that rule was not 100% complied with in the previous project
and all the scripts were modifed to cope with multiple module files.

Now, a new member of the team has arrived on the scene and he likes
to partition some logic into multiple modules to deal with late arriving

signals and thinks it's silly to have so many files lying around.

Can anyone tell me any further rationale for the one module/file rule,
aside from the script processing, which we seem to have addressed?

Thanks, Tom



Sun, 14 Oct 2001 03:00:00 GMT  
 Why (or why not) one module per file?
This also becomes necessary when providing libraries.  In this
case, each file name must match the module name.  Within the
file, the module is encompassed between `celldefine and
`endcelldefine.

I don't know rule of thumb, but this seems to be standard way
when dealing with a library of components.

Quote:

> Hello,

> I would like to open the "one module per file" rule to discussion.
> Our company has this rule, presumeably to simplify Perl script
> processing.

> However, that rule was not 100% complied with in the previous project
> and all the scripts were modifed to cope with multiple module files.

> Now, a new member of the team has arrived on the scene and he likes
> to partition some logic into multiple modules to deal with late arriving

> signals and thinks it's silly to have so many files lying around.

> Can anyone tell me any further rationale for the one module/file rule,
> aside from the script processing, which we seem to have addressed?

> Thanks, Tom

--
Paulo                                      //\\\\
                                           | ~ ~ |
                                          (  O O  )
 __________________________________oOOo______( )_____oOOo_______
|                                             .                 |


| / /    2100 Logic Drive                    (800) 255-7778     |  
| \_\/.\ San Jose, California 95124-3450 USA                    |
|                                                  Oooo         |
|________________________________________oooO______(  )_________|
                                         (  )       ) /
                                          \ (      (_/
                                           \_)


Sun, 14 Oct 2001 03:00:00 GMT  
 Why (or why not) one module per file?

Quote:

> Can anyone tell me any further rationale for the one module/file rule,
> aside from the script processing, which we seem to have addressed?

For several reasons:

1. When I look for a module, I like to be able to tell where it
is from a simple 'ls' command...

2. Since modules are independent, they have no reasons to be in the
same file.

3. Some like to use the -y option to load missing modules which
requires separate files.

4. It's only a guideline. If you have reasons to do otherwise
(hiding internal structure, distribution, compilation order), go ahead.

5. It's just the Right Thing to do.

I'm not sure about the rational of this new designer.... Usually,
a large number of small modules indicates schematic capture
thinking, not taking advantage of RTL synthesis... but this case
could be different. How exactly is creating these small, numerous
modules helping to solve the late arriving problem???



Sun, 14 Oct 2001 03:00:00 GMT  
 Why (or why not) one module per file?

Quote:

> This also becomes necessary when providing libraries.  In this
> case, each file name must match the module name.  Within the
> file, the module is encompassed between `celldefine and
> `endcelldefine.

> I don't know rule of thumb, but this seems to be standard way
> when dealing with a library of components.
> > Now, a new member of the team has arrived on the scene and he likes
> > to partition some logic into multiple modules to deal with late arriving
> > signals and thinks it's silly to have so many files lying around.

BTW, the whole point of guidelines is to make code look similar within
a group of authors, reguardless of who wrote it. The value is in the
group's understanding and expectations of where code should be and
where it should reside. They are functionally irrelevant and are not
good nor bad. What is good or bad is the adherence (or lack thereof)
to them.

I'm afraid that his opinion of it being "silly" is irrelevant.
That's the way the group does things, that's the way he should
do them too. Saving a few inodes in the file systems is not
worth it.



Sun, 14 Oct 2001 03:00:00 GMT  
 Why (or why not) one module per file?

Quote:

>Hello,

>I would like to open the "one module per file" rule to discussion.
>Our company has this rule, presumeably to simplify Perl script
>processing.

>However, that rule was not 100% complied with in the previous project
>and all the scripts were modifed to cope with multiple module files.

>Now, a new member of the team has arrived on the scene and he likes
>to partition some logic into multiple modules to deal with late arriving

>signals and thinks it's silly to have so many files lying around.

>Can anyone tell me any further rationale for the one module/file rule,
>aside from the script processing, which we seem to have addressed?

>Thanks, Tom

Tom,
 In any methodology there are always some guidelines that stem from long
time experience of other guys. Most of them have a good reason, but when you
forget what it was you chathegorize the guideline as "just do it". This is
probably the case of one-module-per-file. I call it "good practice".
Now seriously. I use VCS and the one-module-per-file fits naturally the
concept of the simulator when it needs to find all the modules necessary for
a design. The tool looks for files whose names are identical to the
unresolved module names using various compile-time flags (like +libext+, -y,
etc).  One-module-per-file also helps me make sure I have always one, and
only one version of a  module. This concept becomes more acute when you have
a team of designers, especially when it comes to the integration phase when
modules need be exchanged between the team members. I am not warried about a
large number of files. In unix environment, as I work, numerous files have
never been a burden, since you always work in a structured, directory tree.
Last, and most important is synthesis. I use synopsys, and for performance
optimization I often need to redesign a module. Automatic scripts, together
with synopsys' cache concept (based on modification date) is able to
identify "dirty" (new) modules and recompile only them.
I can probably find more reasons, but as a designer fellow I recommand you :
"Just do it !"

Andi Carmon



Mon, 15 Oct 2001 03:00:00 GMT  
 Why (or why not) one module per file?

Quote:

> Hello,

> I would like to open the "one module per file" rule to discussion.
> Our company has this rule, presumeably to simplify Perl script
> processing.

> However, that rule was not 100% complied with in the previous project
> and all the scripts were modifed to cope with multiple module files.

> Now, a new member of the team has arrived on the scene and he likes
> to partition some logic into multiple modules to deal with late arriving

> signals and thinks it's silly to have so many files lying around.

> Can anyone tell me any further rationale for the one module/file rule,
> aside from the script processing, which we seem to have addressed?

> Thanks, Tom

It helps recompiling what is needed and only what is needed when you
modify some files. Writing Makefiles for simulation or synthesis is
easier. Project management is easier.
--
Renaud Pacalet, ENST / COMELEC, 46 rue Barrault 75634 Paris Cedex 13



Mon, 15 Oct 2001 03:00:00 GMT  
 Why (or why not) one module per file?


Quote:

>> Can anyone tell me any further rationale for the one module/file rule,
>> aside from the script processing, which we seem to have addressed?

>For several reasons:

6. For a compiled simulator like NC or VCS, it's nice to have one module
   per file to allow Makefiles to handle dependencies properly and avoid
   compiling unnecessary stuff.  Also makes writing the dependancies
   for those Makefiles a lot easier too.

--
--

ADG, MBD                        (503) 627-2140
Tektronix, Inc.                 MS 39-515       (2ndFloor-D3)
Beaverton, OR



Tue, 16 Oct 2001 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. why why why oh why why baby

2. One module per file?

3. Enterprise Edition - Why/Why not???

4. why TCL and why not TCL with JAVA

5. Why does one form work yet the other does not

6. Why should one NOT use globals?

7. Why, Why Why????

8. why why why (mouse related question)

9. Module rfc822 - uses file-objects - why?

10. Why can I not delete my test file?

11. Why not include all *.h files?

12. Why not include all *.h files?

 

 
Powered by phpBB® Forum Software