ICMake Tutorial part 2

Macro Development and Function Verification using Module Compiler

last updated 10/12/2001

This is the second in a series of planned tutorials for the SSHAFT design flow.  This tutorial takes you through the basic steps of macro synthesis with Module Compiler, cross-check simulation and pre-layout power analysis with EPIC PowerMill, parasitic extraction with Arcadia, and post-layout power analysis with PowerMill.  It also touches on the topics of design hierarchy, clock skew, static timing analysis and altering the flow.

Topics:

Setting up your environment

If you have not done so already follow the setup instructions on the SSHAFT Setup Page.  This will set up your UNIX and Windows NT environments to run this tutorial.

Quick run instructions

If you would like to run through this tutorial quickly, follow these simple instructions:

  1. Log in to a UNIX compute server.
  2. Create and change to a run directory for the tutorial.
  3. type the following command:
            cp -r /tools/sshaft/design/tut2/* .
    (Afterwards, you can remove the CVS directory. It isn't required)
  4. Follow the instructions in the ICMakefile

The rest of this tutorial is currently under construction...

Creating the MCL code

Login to a UNIX compute server and create an ICMake run directory for this tutorial similar to the way you did in Tutorial 1.  Copy the files addreg.mcl, ICMakefile, and parameters.bccp  from /tools/sshaft/design/tut2 into this directory.

Look at addreg.mcl.  It is quite small, containing a module which is simply an adder followed by a register. 

module ADDREG (Z, A, B, w, fa);
integer w=12;
string fa="ripple";
directive (fatype=fa);
input [w] A, B;
output [w] Z;
wire [w] sum = A + B;
Z = sreg(sum);
endmodule

This file defines the new module that we would like to layout and characterize.  We also want to create a Simulink model for the module so that others who want to use this block don't have to understand Module Compiler in order to use it.  We call this module a "complex macro" because it is more complex than the simple adder and register macros from the fundamental library that we used in Tutorial 1.  It is still a leaf-cell as far as the flow is concerned and is no different from an adder or register in the way it is handled by the flow.

Because the flow expects all designs to start from Simulink, we'll have to create a Simulink model which matches the interface for this module.  Note that ADDREG has two input named A and B and a single output named Z.  The ports on the Simulink model will have to match these names exactly in order to function properly.

Note also the word-length parameter w.  The default word length is set to 12.  We'll have to take steps to ensure that the word lengths of the Simulink model match those of the MCL code, or problems will occur later in the flow.

Creating the Simulink model and test vectors

Creating the parameters.bccp entry

Create a Matlab run directory for this tutorial as you did in Tutorial 1 and copy the files macrolib.mdl, tut2.mdl, tb.mdl and writevec.mdl from /tools/sshaft/design/tut2/matlab into this directory.  Then start Matlab, change to this directory and type "macrolib" at the Matlab prompt.  The macrolib library is a new library we have created for macros, like your own private fundamental library.  This macro has a fixed-point add followed by a fixed-point until delay, effectively modeling an adder followed by a register, just like the Module Compiler code above.  Double click on the AddReg subsystem block to open its parameters.  You'll notice that its bjcType parameter is set to ICMacro, just as Add and Reg were in Tutorial 1. 

In order to make this new block work as a macro in our flow, we have to create an entry for it in the parameters.bccp file.  Look at the parameters.bccp file in your ICMake run directory.  You should recognize the settings for the tut2/mychip block from Tutorial 1, but the settings for macrolib/AddReg are new.  

==> macrolib/AddReg <==
        bjcPortTypeOut1 =    $out_type
        bjcView_Scan =       1
        bjcView_Generator =  bjcMCSynth( \"../../addreg.mcl\" \"ADDREG\" ?par \"w=12\" ?clk \"CLK\")

First of all, just as we had to set bjcPortTypeIn parameters for each input to the top level, we must add bjcPortTypeOut parameters for each output of the macros.  In this case we have referenced the variable "out_type" which you will notice has been defined in the subsystem mask of AddReg in the macrolib library (if you check).  This substitution is nearly identical to the substitution demonstrated in Tutorial 1.  The only difference here is that "out_type" will be evaluated to "bitwidth" which will be evaluated to "sfrac(12)".  This example has one more level of "in-direction" than Tutorial 1.  There is no limit to the number of "in-direction" levels that BCC can recognize.

Next, the parameter bjcView_Scan is used to indicate that this block should be inserted in the scan chain.  If this parameter is not 1 or is omitted, the block will not be inserted into the scan chain.  This will make your block smaller and allow it to consume less power, but it may no longer be testable.

The last parameter is also new.  All macros must have an associated generator, and the bjcView_Generator parameter is one way to specify it.  In general, a generator is a function that can create a netlist of routable subcells (abstracts) for a macro.  In this case, we use the SKILL function bjcMCSynth() which creates a netlist of standard cells from MCL code.  The arguments to bjcMCSynth() are as follows:

Note that all double-quote characters have been escaped with the backslash character.  This is a limitation of BCC which needs to be fixed.  The only other character which causes problems is the percent sign %, which, at present, cannot be used at all.

Hierarchy Mapping

The one thing we didn't explain about the parameters.bccp entry is how we came up with the first line, "==> macrolib/AddReg <==".  This line must contain the full Simulink hierarchical name for the block relative to the file which contains the definition for the block.  This is a little complex, so we'll illustrate this concept with an example.

Close the macrolib library and open the tut2 library by typing "tut2" at the prompt.  Look at the parameters for the mychip block, and you'll notice that its bjcType parameter is set to ICDesign, signifying it as the top of the design hierarchy.  Now look under the mask, and you will see that this design contains only one block.

Look at the parameters of the AddReg block.  You will notice the words "(link)" in the upper left hand corner of the parameters dialog box, indicating that it is a link a block in another file.  This means that the data which defines this block is not located in the "tut2.mdl" file.  To find out which file contains the definition for this block, choose Edit -> Go To Library Link.  The AddReg block in the macrolib library will be highlighted, meaning that AddReg is defined in "macrolib.mdl".  If you follow this same procedure for the add and unit-delay blocks in the AddReg block, you will find that they are linked to blocks in the fixptlib library, which is a Simulink system library.  This hierarchy is illustrated in the figure below.

The BCC program reads the parameters.bccp file and maps a Simulink hierarchy to an EDIF file hierarchy depending on library links. The simplest kind of mapping occurs when a macro linked to a subsystem in a different library, as is the case here.  The table below shows the expected entry in the parameters.bccp file and the name of the library and cell in the resulting EDIF file.

Simulink Hierarchy parameters.bccp file entry EDIF library name EDIF cell name
tut2/mychip/AddReg linked to macrolib/AddReg ==> macrolib/AddReg <== macrolib AddReg

If you break the library link for the AddReg block in the mychip system, then BCC expects something else.  In this case, we would have the hierarchy illustrated here:

AddReg is now defined in the tut2 library.  The full hierarchical name of the block relative to the "tut2.mdl" file is "tut2/mychip/AddReg".  To avoid name conflicts with other subsystems which might be named "AddReg", BCC concatenates the name of the AddReg block with the name of the containing block mychip in the EDIF file.  To further complicate matters, AddReg is a leaf-cell while mychip is the top level cell.  In the EDIF format, it is illegal for leaf-cells and design cells to be defined in the same library (this is because one must be defined in a library expression, while the other must be defined in an external expression).  To get around this problem, BCC adds the suffix "_extern" to the name of the library containing AddReg.  See the table below for a summary of what BCC expects and produces for this case.

Simulink Hierarchy parameters.bccp file entry EDIF library name EDIF cell name
tut2/mychip/AddReg is not a link ==> tut2/mychip/AddReg <== tut2_extern mychip_AddReg

If this seems terribly confusing, then it can all be avoided by always making sure that your macros are defined in different Simulink libraries from your higher levels of hierarchy.  Also make sure that you don't break any library links.

Creating Test Vectors

The files we have seen so far are sufficient to run ICMake to route the system as we did in Tutorial 1.  But to run EPIC PowerMill simulations, we need to create test vectors.  To generate the vectors, a test bench has been created which uses the tut2/mychip design.  Close the tut2 library and open the tb model by typing "tb" at the Matlab prompt.

Running ICMake and creating the floorplan

Cross-check simulation with EPIC PowerMill

Routing, extracting and re-simulating

Measuring the clock skew

Static timing analysis with EPIC PathMill

Summary

 

maintained by Rhett Davis
wrdavis@eecs.berkeley.edu