To get the most out of formal analysis, one thing that can be done is to highly parameterize a design.  Some Cadence guidelines for parameterization include the following:

❑ Pass down all parameters from top to bottom.
❑ Vectors that can affect size and diameter, which impacts complexity, should be
parameterized.
❑ Every parameter should be orthogonal to other parameters.
❑ Compute dependent parameters as functions of independent parameters.
❑ Include system-wide/protocol requirements as parameters even if they would never change between reuses of the design.

For example, if every packet of data should be no greater than 256 bytes or data
should be divided up into bursts of 64 bytes or less, then 256 and 64 should be
parameters, not hard-coded numbers.
❑ Parameterize number of interfaces to replicated blocks.
For example, for an arbiter, use N arbitration interfaces instead of a fixed number.
❑ Design logic so that it works for any width of bus.
For example, for a data bus (8, 16, 32-bits, and so on), define a parameterized byte width.

Using HDL parameters is not the only way to “parameterize” a design, defines can also be used.  I use defines for global constants that are not changed on a module by module instantiation.  I use parameters when a module’s constants need to be changed on an instance by instance basis.  The goal being that a top-level parameter can be changed in one spot and the entire design is updated accordingly because the lower level parameters are orthogonal.

Parameterizing a design often times allows one to easily shrink a design down enough such that the properties in the design can be proved by a formal analysis tool like IFV.

A highly parameterized design often times comes with requirements of using some of the constructs introduced to Verilog in Verilog 2001 including generates, indexed part-selects, and multi-dimensional wires.  Also, one tends to write with a very different style.  The resulting code sometimes ends up looking more like a program than a hardware description.  This style is not always the easiest to read for people who are used to other styles that make gates easier to “see”.  Also, you may find your occasional tool bug with Verilog 2001 constructs since they are not as widely used.

Vectors sometimes get to be very wide because there isn’t an easy way to change the number of input vectors to a module.  For instance, you may need a mux module that has a parameterized number of inputs.  This would lead to an interface definition like the following:

parameter

DATA_W=10,

INPUTS=4

…

input [(DATA_W*INPUTS)-1:0] concat_data;

vs. the typical:

parameter DATA_W=10;

…

input [DATA_W-1:0] data0,

input [DATA_W-1:0] data1,

input [DATA_W-1:0] data2,

input [DATA_W-1:0] data3,

A highly parameterized design is not just good from formal analysis, it also leads to a more flexible and reusable design.  These benefits go well beyond formal analysis.