Re: [Iverilog-devel] Include file search path.

[Jeremy B. <je...@je...>]

On Fri, 2009-01-30 at 14:29 -0800, Cary R. wrote:
> --- On Fri, 1/30/09, Jeremy Bennett <je...@je...> wrote:
> 
> > Icarus Verilog is NOT an alternative to GCC. It is an
> > event-drive HDL
> > simulator and alternative to NC, VCS, ModelSim, VTOC,
> > SpeedCompiler,
> > Verilator etc. So you should look to all the Verilog tools.
> 
> Yes, that's correct, it's just a shame we can't learn from
> something that has had much more thought put into the flow.
> Enlightenment is good, but it often comes with a costs.

Hi Cary,

Some more thoughts to help your decision making.

I don't think you will win hearts and minds by suggesting hardware
engineers do not think about their flows. In my experience most
organizations have more people working on their hardware CAD flows than
software CAD.

GCC isn't that good a starting place. They changed their include policy
in 4.3.0 (because they hadn't been following the standard). That broke
plenty of software, including SystemC.

> > Where behavior is not clear in IEEE 1364 (the detailed
> > interpretation of
> > `include is not covered), all the manufacturers mimic
> > Verilog-XL
> > (because it was the first HDL simulator). It states:
> > 
> > "The `include compiler directive works in the
> > following way:
> >  1. Verilog-XL searches for the file specified by the
> > compiler
> > directive, relative to the current working directory.
> 
> Is working directory defined to be the directory that
> you are running the simulation in? I'm assuming it is,
> but I could also argue the working directory could
> change with the file being processed. The answer to
> this determines which interpretation is correct.

Working directory has only one meaning. It means the directory from
which you executed the command. Absolutely no wriggle room here.

<stuff deleted>
> 
> If we assume the working directory is only the directory you
> are running the simulation in, what concerns me about this
> statement is that the local file directory is not considered.
> For example if I run iverilog subdir/code.v and code.v
> includes header.vh it will not look for that file in subdir
> which to me is completely counter intuitive. Maybe my
> programming exposure is getting in the way, but this seems
> like incorrect behavior!

But in this case you should run

        iverilog +incdir+subdir subdir/code.v.
        
Or even module hierarchy discovery with:

        iverilog -y subdir

Come to think of it why doesn't g++ automatically look for a class
called "Fred" in "Fred.cc". Perhaps GCC could be improved by doing
things the hardware way :-)

As noted hardware engineering is based on pedantic tedium, to avoid
those multi-million dollar respins. You'd better specify explicitly
exactly which source files make up your design and exactly which
directories provide the headers and in which order.

<stuff deleted>

> I'm very familiar with how this all works. I guess the problem
> is that someone created a gold set with all the files in one
> place and then because of the local directory first rule we
> currently have you can not override any files. This could
> have been addressed by putting the include files in a
> sub-directory that was then included with +incdir. This
> would allow the user to put the new include directory ahead
> of the original one and get basically what you wanted. Nested
> includes would require copying a few potential unchanged files
> to get the search order correct.

But that's not the way the world is. 90% (at least) of a new chip is
reuse of existing RTL IP, complete with test benches, scripts, back-end
tools etc.

Icarus Verilog will happily simulate very large designs, but it will be
a big blocker to adoption if that simulation requires a complete
restructuring of existing Verilog source AND propagating that change to
all the other tools using the hierarchy.

I'm currently using Icarus Verilog on a small SoC (150k gates) written
about 8 years ago. The DUT and test bench comprise 1,350 files,
amounting to around 170k lines of Verilog. Restructuring as you suggest
is not just about moving files and directories. I would also need to
rewrite all the test benches and scripts that know where to look for
various files. For example, C code headers (for embedded code) generated
by relative sed scripts on the Verilog headers:

        sed < ../../rtl/verilog/wibble.vh > ./wibble-for-c.h ...

Then I'd need to alter all the synthesis tools...

> I'm willing to change this however it needs to be changed,
> but I spent a fair amount of time thinking about why things
> should work this way and I want to make sure everyone
> understands the trade offs before we decide one way vs the
> other.

If the hardware engineers on this mailing list would like to contribute,
their voices would be useful.

> I disagree with Martin concerning making this an option.
> I think we need one true way whatever that is. I will argue
> that if we omit the local directory first rule we should
> add a -W warning when a file is overridden by a local one.
> 
> So if ../gold/one.vh includes two.vh and we use the local
> version vs the one in gold we should print a warning that
> this files is being overridden. Otherwise you could easily
> override a file and get all kinds of strange compile
> problems. I think this would only apply to files that are
> from the include search path.

Warning's are fine, but you may want to make this something that has to
be turned on (and you certainly need to be able to turn it off).

Most users will first come to Icarus Verilog with a small example they
know works. Generating warnings about stuff that is silently accepted
with mainstream simulators can be a turn off. It's not the moment to be
persuading potential new users that GCC knows best.

HTH,

Jeremy
-- 
Tel:      +44 (1202) 417007
Cell:     +44 (7970) 676050
SkypeID: jeremybennett
Email:   je...@je...
Web:     www.jeremybennett.com