iverilog/iverilog.conf

# The iverilog.conf configuration file provides to the iverilog driver
# strings based on switches that are passed by the user on the command
# line.
#
# Comments start from the hash (#) character and run to the end of the
# line.
#
# Conditions are a list of requirements between [] characters. For the
# set of patterns following a string to b activated, all the
# conditions must be true. Valid conditions are:
#
#     -S          -- The -S flag is passed to iverilog
#     -t<string>  -- The -t<string> parameters is passed to iverilog
#
#
# Patterns have a name and text. The name has the form <key> where the
# key is some key value that is required by iverilog. The commonly
# used keys are:
#
#     <ivl>
#	The string here is the command line needed to take the
#       preprocessor output (ivlpp) and compile it with the
#       target. All target types use this key.
#
# The pattern text includes %<code> substitutions. iverilog
# substitutes values for the %<code> sequences within the text.
#
#     %B  Substitute the base libdir, -B flag of iverilog.
#
#     %f  Substitute the -f flags from the command line.
#
#     %s  Substitute the start module (-s flag) from the user.
#
#     %N  Substitute the value of the -N<path> flag.
#
#     %o  Substitute the value of the -o<path> flag, or the default
#         output path if there is no -o flag.
#
#     %T  Substitute min, typ or max depending on the -T flag from the
#         command line.
#
#
#     %W  Substitute the ivl warning flags.
#
#     %y  Substitute all the -y flags here.
#
#     %[<c><text>]
#       This substitution pattern is magical, and is the only
#       multicharacter pattern. This tests the code <c>, and
#       substitutes <text> into the output only if <c> is true.
#       The <text> may include further substitution strings, and is
#       terminated by a ``]'' character.


# This is the null (no op) target. Thre is a synthesis version and a
# non-synthesis version. Normally, this does not matter, but this can
# be useful and interesting if the -N flag is included.

[-tnull -S]
<ivl>%B/ivl %[v-v] %y %W %[s-s%s] %[N-N%N] %[T-T%T] -tdll -fDLL=%B/null.tgt -- -

[-tnull]
<ivl>%B/ivl %[v-v] %y %W %[s-s%s] %[N-N%N] %[T-T%T] -tdll -fDLL=%B/null.tgt -- -

# --
# The vvp target generates code that the vvp simulation engine can execute.
# These rules support synthesized and non-synthesized variants.

[-tvvp -S]
<ivl>%B/ivl %[v-v] %y %W %[s-s%s] %[N-N%N] %[T-T%T] -tdll -fDLL=%B/vvp.tgt -fVVP_EXECUTABLE=%B/../../bin/vvp -Fsynth -Fsyn-rules -Fcprop -Fnodangle %f %m -o%o -- -

[-tvvp]
<ivl>%B/ivl %[v-v] %y %W %[s-s%s] %[N-N%N] %[T-T%T] -tdll -fDLL=%B/vvp.tgt -fVVP_EXECUTABLE=%B/../../bin/vvp -Fcprop -Fnodangle %f %m -o%o -- -

# --
# The vvm target uses the <ivl> string to take the preprocessed code from
# standard input, compile it with the vvm code generator and write the
# result to %o.cc. The driver assumes this when invoking the C++ compiler
# on the result.

[-tvvm]
<ivl>%B/ivl %[v-v] %y %W %[s-s%s] %[N-N%N] %[T-T%T] -tvvm -Fcprop -Fnodangle -fVPI_MODULE_PATH=%B %f %m -o%o.cc -- -


# This is the XNF code generator.

[-txnf]
<ivl>%B/ivl %y %[v-v] %[s-s%s] %[N-N%N] %[T-T%T] -txnf -Fsynth -Fsyn-rules -Fcprop -Fnodangle -o%o -- -

# And this is another XNF code generator, under development.
[-tfpga]
<ivl>%B/ivl %y %[v-v] %[s-s%s] %[N-N%N] %[T-T%T] %f -tdll -fDLL=%B/fpga.tgt -Fsynth -Fsyn-rules -Fcprop -Fnodangle -o%o -- -

# --
# This is the pal code generator. The target module requires the -fpart=<type>
# flag to specify the part type.
[-tpal]
<ivl>%B/ivl %y %[v-v] %[s-s%s] %[N-N%N] %[T-T%T] -tdll -fDLL=%B/pal.tgt -Fsynth -Fsyn-rules -Fcprop -Fnodangle -o%o -- -