Structural integration is
often considered both boring and error-prone process. There are number of tools
on the market that assist designers in performing this task, providing a GUI-based
connection methodology. However, if number of ports and wires grows, it is
difficult enough to navigate through the forest of nets and pins in the GUI.
Another approach is to create connections based on pins and ports naming
conventions. This methodology restricts designer to very specific naming
conventions, requires home-made scripts that are not always reusable and,
finally, cannot solve all connectivity problems, when multiple instances of the
same module must be created.
In our methodology, based on
make_top and make_top_complete
scripts, the following concepts are used:
·
Working with
text, not with graphics, is preferable approach.
·
Script, by
itself, cannot make any decisions how to connect. However, it provides useful
assistance and integration templates.
There are two steps of a structural verilog creation process:
·
Structural Template Generation. This template is generated looking at the interface
of all modules that should be instantiated.
·
Manual Structural Template editing and
final netlist correction.
In order to createa structural template, use make_top script in the following way:
make_top [-divide_io] +<inst_name1>
<path to verilog file1> +<inst_name2>
<path to verilog file2> … +<top_module_name> <structural template name>
User can use any number of
instances, as well as any number of +<inst_name1>
<path to verilog file1> pairs. The last
pair in the argument list should always be: <top_module_name>
<structural template name>.
For example, in order to
create a structural template for the 2-port switch chip that contains 2 ports
and switching fabric, the following command line switches must be used:
make_top +p1 port.v +p2 port.v +sf fabric.v
+chip chip.v
It means that two instances
of an endpoint module port.v and one instance of a
switching fabric fabric.v will be instantiated using
instance names p1, p2 and sf.
The structural template of a module “chip” will be written into the file chip.v (in our case, I renamed it to chip.v.init to
differentiate between the pre- and post- edited files)
Command line options:
-divide_io : Separates input pins from the output pins
during module instantiation.
By default, script preserves pins ordering in
module's instanse to be exacltly
the same as they were defined in the module interface.
Integration template is
built in the following way:
·
All given
modules appear as instances with a predefined instance name
·
All input pins
of instantiated blocks are left disconnected.
·
For each output
pin of each instance, the wire with a name <module’s instance
name>_<output pin name> will be created and connected to the corresponding
pin. For example, output pin rx_prio of instance p1
will be connected to the wire p1_rx_prio. This naming convention for wires is
convenient during the manual interconnection process: each wire has information
about it’s source. In order to maintain relatively
small wire names, use short instance names (in our design practice, we are
using maximum 3 letters for instance names). Each wire has the same bit width
as a pin it connects to. Input and output pins of instances are separated into
different groups, and comment about each pin bit width will be added. (Example:
chip.v)
The second step is manual
editing of integration template. User must provide all needed interconnections.
It is convenient to use emacs editor in 2-frame mode
for this process. For each instance, pass all the input pins only. If input pin
is connected to the already existed wire (internal connection), put the name of
this wire. If input pin is connected to the
Note: There is no need to touch (add/delete) any wire /
top level port definitions.
For example, after manual
editing of our original template chip.v.init we’ll have the file chip.v
Then, use make_top_complete script once more in order to
delete unneeded wires and create top module interface. The top module interface
definition is based on PI/PO comments information.
This time, the syntax should
be:
make_top_complete <path to already edited
integration template>.
As a result, the final
module will be created; the name of this file will not have .complete
suffix.
For example, in order to
create the final version of our integration module, run the following command:
make_top_complete chip.v
As a result, the file chip.v.complete will be created.
·
port.v
·
fabric.v
·
chip.v
·
make_top
Note: Edit the first line
of scripts in order to set correct path to tclsh
executable (tclsh version should be newer than 8.2)