ICMake Tutorial part 1

Getting started with ICMake using the Fundamental Libraries

last updated 3/15/01

This is the first in a series of planned tutorials for the SSHAFT design flow, which uses the ICMake program as an entry point.  This tutorial takes you through the basic steps of building a Simulink design with macros from the fundamental library, basic floorplanning, place & route and physical verification.

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.

These setup instructions and this tutorial assume that you are running Matlab/Simulink on a Windows NT/2000 workstation while running ICMake on a UNIX compute server through a terminal window.  It is also assumed that both Windows and UNIX file systems are accessible from each operating system.  The flow will also work in an all-UNIX mode.  Special notes about different directory setups will be made throughout this tutorial.

This tutorial also assumes that the SSHAFT flow files are installed at the root directory /tools/sshaft/.  Substitute the installation path for your site where this name appears below.

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/tut1/* .
    (Afterwards, you can remove the CVS directories. They aren't required)
  4. Follow the instructions in the ICMakefile

Creating a Simulink library

Login to a UNIX computer server.  Create and change to a run directory for this tutorial.  This directory will be the root of a tree created by ICMake and will be referred to as the "ICMake run directory".  Note that a subdirectory called run will be created in the ICMake run directory.  This sub-tree contains run directories for every tool in the flow except ICMake.  Always run ICMake from this first directory you have created yourself, and not the run sub-directory.  You should also run Exceed (or another X-Windows emulator) and set your DISPLAY environment variable.  X-Windows is required for the floorplanning portions of the flow.

Next, in your Windows home directory, create a subdirectory for this tutorial.  Start Matlab and change to this directory.  This directory will hold the Simulink source files for this tutorial and will be referred to as the "Matlab directory".

NOTE: If using the UNIX version of Matlab, then create a subdirectory called "matlab" in your ICMake run directory (this name is not mandatory, but it matches the default in the tutorial source files).  Change into this directory and start Matlab.

The rest of this section details the creation of a Simulink library.  To skip this part, simply copy the file /tools/sshaft/design/tut1/matlab/tut1.mdl into your Matlab directory.  To make this file yourself, type the following commands in Matlab:

  1. simulink
  2. fundamental
  3. icwire
  4. template

These commands start the Simulink Library Browser as well as our fundamental, icwire, and template libraries.  The fundamental library contains very basic blocks, perhaps too simple to build a real system but enough for this tutorial. The icwire library contains cells which will be mapped to nets rather than transistors (including constants and bus rippers).  We won't use this library in this tutorial. This example uses only the Add and Reg blocks from the fundamental library and the mychip block from the template library.

  1. In the fundamental library window, choose File -> New -> Library
  2. Drag and drop the mychip block from the template library into your new library.
  3. Double click on mychip to look at the subsystem block parameters



    The block mychip is a template for the top-level of hierarchy needed for ICMake.  The block parameters show that the mychip block is of type Subsystem.  Subsystem blocks are the basic hierarchy unit of Simulink.  The word "mask" in parentheses indicates that this subsystem has a mask, which is an interface to higher-level systems.  This subsystem mask allows us to add parameters to a subsystem, of which two are shown.  You can change the values of these parameters by typing in the text-boxes shown.  Here's what the parameters mean:
  4. Note the word "link" in parentheses near the top of the block parameters dialog box.  This indicates that this subsystem is actually a reference or "link" to the mychip block in the fundamental library.  Before we can edit this design, we need to right-click on mychip and choose "Break Library Link".  After breaking the link, if you cancel and re-open the block parameters dialog for mychip, you will notice that the word "link" has disappeared.  In effect, we have just copied the mychip system into the new library, destroying the reference. MatlabR12: Select "Link options"->"Disable link" followed by "Link options" -> "Break link".
  5. Right-click on mychip again and choose "Look Under Mask".  This opens the system we just copied for editing.



    Note that this system contains nothing but one input port and one output port.  The names correspond the the names seen in the top-level block.
  6. Make a copy of the in-port.  This can be done by right clicking, dragging and dropping the port in the mychip window.
  7. Drag and drop Add and Reg from the fundamental library into mychip. Do not break the library links for these blocks.  For them to synthesize properly later, they must remain as references to the fundamental library.
  8. Connect the subsystem and rename the ports as shown below:



    This system will create a chip which contains one adder and one register.  We call Add and Reg "macros" because they will correspond to layout views which contain transistors in the final design.

    Next, we must create some more parameters to ensure that the system can go through the flow error-free.
  9. In the main library window, left-click on mychip and choose Edit -> Edit Mask.  Click on the "Initialization" tab in the popup window and add the following mask variable:
    Prompt Variable Control Type Assignment
    Bit Width bitwidth Edit Evaluate



    The variable bitwidth, is in evaluate mode, which means that it will be used by Simulink for simulation.  We will use this variable to specify the bit width of both the adder and the register in our system.  Note that the variable bjcType is in literal mode, which means that its value will not be evaluated during simulation.  This is necessary, because the value "ICDesign" would otherwise cause a syntax error.

  10. Double-click on mychip in the main library window to edit the values for the parameter you just added.  Set the value for "Bit Width" as shown below.



    In this example, Bit Width specifies a parameter which we will use to specify the bit width of both the adder and the register in our system (in the next step).  In this case, we have chosen a signed fraction of length 12.  See the Simulink Fixed Point Blockset documentation for more information about fixed point types.  The SSHAFT flow recognizes the types sint, uint, sfrac, and ufrac.
  11. In the mychip window, double click on the Add block and set the Output Data Type to bitwidth.  Also, double-click on Reg and set the Data Type to bitwidth and Scanable from 0 to 1.


    Here's what the parameters mean:
  12. The design is done!  Save the library as "tut1".  You can open this design the next time you run Simulink by going to this directory and typing "tut1" at the Matlab prompt.  Note that Simulink automatically opens all libraries in read-only mode.  To edit your design, you will have to choose Edit -> Unlock Library.

You may now instantiate this chip in a Simulink model and use it in conjunction with any other Simulink blocks to create a simulation.  

Creating the parameters.bccp file

There are a few more subsystem mask parameters to add before the flow will run properly.  Since these parameters do not affect the Simulink simulation in any way, however, it is convenient to add them in a separate file rather than through the subsystem mask dialog boxes.  By convention, this file is called parameters.bccp and must be in the ICMake run directory.  Note that the flow would function perfectly if you removed this file and added the same parameters in Simulink.

Copy the file /tools/sshaft/design/tut1/parameters.bccp to your ICMake run directory.  View the file, and you will see the following:

    ==> tut1/mychip <==
            bjcPortTypeIn1 = $bitwidth
            bjcPortTypeIn2 = $bitwidth

The first line indicates that the following parameters are to be added to the block "mychip" in the library "tut1".  The next two lines set the bjcPortTypeIn1 and bjcPortTypeIn2 mask variables.  These parameters give the Simulink fixed point types of the input ports.  The fixed-point types of ALL input ports for the top level of hierarchy must be specified here in order for ICMake to correctly derive the connectivity of the design.  Inputs for lower levels of hierarchy are inferred from the driving port.  

Note that we have referred to the bitwidth variable defined earlier by using the "$" character in front of it.  The ICMake design flow allows this type of reference for any mask variable which precedes the current variable in the mask variable list.  The variable bitwidth is assumed to come earlier because it was defined in Simulink, but (for example) we could also have set bjcPortTypeIn2 to be "$bjcPortTypeIn1".

NOTE:  Be sure that the fixed-point types of the signals entering the chip are the same as the types listed in bjcPortTypeIn# variables which you added to the top-level subsystem mask.  Failure to do so will create errors in the logic-verification steps of the flow.

NOTE TO MACRO DESIGNERS:  The environment variable BCC_PFILE_PATH is set to a file which contains global parameters to be loaded each time the flow runs. When adding blocks to the fundamental library or creating new libraries for global use, add your new parameters to this file or create a new file and change the value of the environment variable.

Creating the ICMakefile

Copy the file /tools/sshaft/design/tut1/ICMakefile into your ICMake run directory.  This file defines the SSHAFT flow as described and illustrated on the SSHAFT Chip Assembly page.  As your designs become more complex, needing more than one place and route step, you may have to edit the flow in this file.  For now, however, you should only need to modify one line, but it's helpful to learn a little about the syntax.

Open the ICMakefile in your favorite text editor and find the following line:

    TOPLIB=tut1
    TOPCELL=mychip
    MDLPATH=matlab
    MDLSRC=$MDLPATH/$TOPLIB.mdl

If you are using the UNIX version of Matlab and have your Simulink source files in the directory [ICMake run dir]/matlab, then this line need not be changed.  Otherwise, set the MDLPATH to be the name of your Windows Matlab directory referenced from UNIX.  On our system, this path would be something like /tools/users/[username]/[Matlab dir].  Notice that by changing the MDLPATH variable, you have effectively updated the MDLSRC variable to be the path of your top level Simulink file.

If you're in a hurry, you can skip to the next section.  Otherwise, look a bit further down in the ICMakefile, and you will see the following lines:

bcc: $MDLSRC parameters.bccp
	TARGET $TOPCELL.edif
	PLATFORM unix_prog
	COMMAND bcc -t edif -u 0 -s de -o %TARGET 
	+ -L $MDLLIB -L $MDLPATH -c $TOPCELL %DEP[0] >& log/%STEP.log
	LOG log/%STEP.log
	LOGCHECK /ERROR/
	CHECKMODE fail
	DIRS log

ICMake is modeled after the popular UNIX program Make.  Just as Make reads a Makefile to define dependencies and commands to update targets, ICMake reads an ICMakefile to define steps, dependencies, and commands to update targets.  The lines shown here define a step called "bcc" and list two dependencies, the Simulink source file and the parameters.bccp file.  The next line defines the target for this step to be mychip.edif.  This means that this step will be run only if the file mychip.edif does not exist or is out of date with respect to the dependencies.  We'll demonstrate this when we run ICMake in the next section.

The lines PLATFORM and COMMAND define the command used to update the target.  The platform string "unix_prog" denotes that this is a generic UNIX program, and the command string shows that the program bcc will be executed with a long list of arguments.  There are several aspects of this command line which are worthy of note:

  1. The %TARGET string indicates that this step's TARGET string will be substituted.  The "%" character is used to reference variables defined for this step, while the "$" character references variables defined for the entire flow.  Likewise, %DEP[0] references the first dependency.  If multiple targets were used, you could just as easily use %TARGET[0] to reference the first target, %TARGET[1] to reference the second, etc.
  2. The "+" character at the beginning of the next line indicates line continuation.  Whitespace before and after the plus character is ignored.  Lines are joined with a single space character.
  3. The ">&" characters and the rest of the command string indicate that STDOUT and STDERR should be redirected to the file log/bcc.log.  The redirection strings ">",">>" and ">>&" can also be used.

The next three lines define some error trapping for this step.  In order to determine if this step ran correctly, we need to examine the log file for an indication of success or failure.  The LOG variable defines what file should be checked.  LOGCHECK is a Perl-style regular expression to be evaluated on every line of the log file.  The CHECKMODE variable defines what to do if the regular expression ever evaluates true.  In this case, ICMake will search the log file for the string "ERROR" and fail if it is found.  This is important to know, in case you happened to have a macro named something like "ERRORBlock".  If bcc reports any log message which mentions the name of this macro, then ICMake will assume that the step failed.  This is a prime example of an automation hazard.  The philosophy of the SSHAFT flow is to make such hazards visible and recoverable by putting them in the ICMakefile.  Incidentally, the error status is checked any time the dependencies are checked.  This means that when re-running ICMake, if the log check fails, the step will be executed again, even though mychip.edif may be up-to-date with respect to its dependencies.  This makes it easier to recover from an error where the target file is partially or incorrectly written.

The DIRS variable defines directories to be created when executing this step.  Obviously, the command string as shown would fail if the log directory did not exist.

The last thing to note in the ICMakefile is a line which occurs earlier in the file:

    all: @skel_fpgen

Just like the UNIX Make program, ICMake will attempt to make "all" if no target step is specified.  This line defines the "all" step.  In this case, "all" has a single dependency.  Normally, dependencies are files.  The "@" character here indicates that this dependency is a step, rather than a file.  In effect, the target(s) for the indicated step are substituted for the dependencies of the step "all".  Also, since no target is listed, this step will always be executed.  The net effect is the same as if "skel_fpgen" had been specified when invoking ICMake.  As you develop the need for a special design flow, you can change this line to be any step (or file) you like to make your life more convenient.

Running ICMake and viewing the results

From the ICMake run directory, type "icmake bcc".  The flow should run in less than a second, running only the first step.  Note that several files have been created, including the ICMake log file icmake.bcc.log, the step target mychip.edif, and the bcc logfile log/bcc.log.  Open icmake.bcc.log and you should see something like the following:

    Begin icmake
    Performing step: bcc
    Executing: bcc -t edif -u 0 -s de -o mychip.edif  -L /tools/sshaft/lib/icmake/mdl/R11
     -L matlab -c mychip matlab/tut1.mdl  >& log/bcc.log
    bcc returned with value 0
    Finished icmake (elapsed time: 0h 0m 1s actual 0h 0m 0s user 0h 0m 0s system)

The most important line is the very last one.  The words "Finished icmake" indicate that the flow ran successfully.  If there had been an error, the words "Terminated icmake" would appear.  You would then scroll up in the log file looking for messages that describe the source of the error.

The log file lists the steps and substeps of the flow as they execute.  Here the primary step icmake is executing one substep bcc.  The entire command line of the substep is printed in case you need to debug the ICMakefile.  Some steps (such as ICMake, the primary step) will time themselves, giving actual elapsed time, and the user and system times (as returned from the UNIX time command)  It can be very useful to have data on the execution time of the flow.  It helps you to schedule your work day when running the flow on designs which may take several hours to complete.

Now type "icmake bcc" again.  Look at the icmake.bcc.log file again, and you should see the following:

    Begin icmake
    Performing step: bcc
    Target(s) up-to-date: Skipping substep
    Finished icmake (elapsed time: 0h 0m 0s actual 0h 0m 0s user 0h 0m 0s system)

Note that the flow ran again from the beginning, but that the bcc substep was skipped.  This is because the target mychip.edif is up-to-date with respect to the source files.  To force the step to execute again, you must do one of two things.

  1. Change the modification date of one of the bcc dependencies.  For example, type "touch parameters.bccp".
  2. Delete the target.  Type "rm mychip.edif".

Try one of these two options and run "icmake bcc" a third time.  The icmake.bcc.log file should now be identical to the first time you issued this command.

Now, let's run the flow on the default target.  From the ICMake run directory, type "icmake &".  You can view the progress of the flow by typing "tail -f icmake.log".  The flow completes in about 2 minutes on our fastest compute server.  The flow dumps quite a large number of files and subdirectories in the ICMake run directory.  See the SSHAFT Chip Assembly page for more info about what these directories are for.  You can delete all of the generated files and directories (except for icmake.log) by typing "icmake clean".  For now, however, we'll leave them as they are and peruse the results.

NOTE: If you see an error message which reports an error like "Unable to open Display", then you need to run Exceed and set your DISPLAY variable properly.  Afterwards, you can simply type "icmake &" again, and the flow will pick up where it left off.

Look at the file icmake.log.  Skip ahead to the line which reads "Performing step: macro_gen".  

    Performing step: macro_gen
    Chdir run/cds
    Creating SKILL script "exe.il" for command: bjcMacroGen( ?src list( "tut1" "mychip" 
    "raw" ) ?stepargs list( "../../icmake.log" 5 1 "low" ))
    Executing: icfb -log CDS.log -nograph -replay exe.il
	    Begin bjcMacroGen

In this step of the flow, the generators for all macros are executed.  Since this step is written in SKILL (the Cadence Design Framework II -- DFII -- scripting language), ICMake changes into a Cadence run directory "run/cds" (created in an earlier substep) and writes a small file called "exe.il" for Cadence to execute.  Cadence is then invoked with the "icfb" command.  Once Cadence starts, the substep "bjcMacroGen" begins to write messages to the log file.  The tab indentation before the message "Begin bjcMacroGen" indicates that this message is being written by a substep.  All of this information serves to help you track any errors that may occur in the flow.  Changing into the wrong or non-existent directories is a common design flow hazard.  Also, if the bjcMacroGen substep fails, we need to know which log file to look in for more information.  If the flow had halted at this step, we would look in the run/cds/CDS.log file for more information.

Reading on in the icmake.log file, you will notice that the design hierarchy is traversed from the top down.  For each of the macros (Add and Reg in the fundamental library), VHDL code is created, Synopsys Design Compiler is invoked for synthesis, and the resulting EDIF file is read into DFII.  These intermediate files have been saved in the directories data/other/fundamental/Add and .../Reg as the files source.vhd and synth.edif.  From this directory you can also peruse the Design Compiler log file, in case there was an error during synthesis.

Lastly, let's look at the skeleton floorplan.  Go to the run/dp directory and start Design Planner with the command "areaPdp &".

Once the Pillar window appears, open the autoLayout view of cell mychip in library tut1.  You can do this by choosing File -> Open... in the Pillar window followed by Libraries -> mychip in the Open File pop-up window.  Then double-click first on mychip, then on autoLayout.  This opens a file in edit mode.  If you want to view a file in read-only mode, you must use File -> Browse... instead of File -> Open.... Once opened, you should something like the figure below.  As with Design Framework II, you can zoom by right-clicking and dragging and use the "f" key to fit the entire design in the window.  If your view does not look like the view shown below, then perhaps you need only to click the L1 or LAll button on the right to display more levels of hierarchy.  The colors may vary depending on your technology.

Left click on any of the instances on the right to select it.  Note that the name of instance appears in the lower-left hand corner of the window.  Most instances names have the prefix "Add|" or "Reg|".  This is an artifact of the flattening process.  The instance name of the each cell is prepended to the contained instance names when flattening.  There is one cell called simply "lctgEN0".  This is the root of the clock tree.  Clock tree design will be discussed more in tutorials 2 and 3.  

Deselect all instances by clicking on empty space and look at the cellview properties by hitting "q" key.  Note that the bjcType property appears here, just as it did in Simulink. There are also a number of other "bjc" properties defined.  These are used by the flow to store information about the cell from one step to the next.  

You can list all of the instances in the cell by typing the command "(listinst)" in the areaPdp window.  You can find any one of the named instances by clicking the "By name..." button on the right of the design window.  Type the name in the "Name" field, make sure that "Type" is set to "inst", and click the "Type+" button.  If you're feeling adventurous, you can also use the commands "(listterm)" to list the terminals (ports) of the cell and "(listnet)" to list all nets in the cell.  Hit "q" to view the properties of any selected instances, nets, etc.

Lastly, zoom in on the big green square.  This is the prBoundary (place & route boundary) for the design.  All cells must be placed inside this box before routing can proceed.  Lastly, zoom in on the upper left-hand corner of the prBoundary.  Here you will see the I/O pins for this design.  These pins will be placed automatically, so don't worry about them for now.  Let's proceed with the floorplan.

Creating and saving the floorplan

  1. Open the "tut1" "mychip" "autoLayout" cell in Design Planner and type the following command in the command window:
            (bjcDrawRows)
    This draws standard cell rows with a target row utilization of 80% and an aspect ratio of 1.0.  The procedure will attempt to draw rows which meet your specifications as closely as possible.  Check the log window for the resuling density and aspect ratio.
  2. Position the cursor in the edit window and hit the "b" key.  This will compact the PRBoundary shape around the rows you have just drawn.
  3. Type the following command in the Design Planner command window:
            (bjcQP ?pinopt t)
    This invokes the QPlace placement tool and instructs it to optimize the pin positions while it places cells.
  4. Design Planner will print many messages to the log window and eventually  return unsuccessfully.  If you scroll up in the window, you will eventually find a message like the following:
            The site utilization is = 118.2 is too high!
            *ERROR* Impossible to place without overlaps!
    This error occurs because the floorplan is too dense.  The bjcDrawRows function takes into account cell area but not pin area when determining density.  The ratio of pin area to total area is related to the ratio of perimeter to area, so this ratio is higher for smaller cells.  While 80% and even 95% densities are reasonable for large cells, we should probably use 50% or lower for a cell this size.
  5. Choose SSHAFT -> FP Init.  This will re-initialize the cell-view and erase the rows you just drew.  This command also closes the cell-view, so you will have to re-open it.
  6. Type the following command in the command window:
            (bjcDrawRows ?density 0.5)
    Then compact the PR Boundary as in steps 2.
  7. Run QPlace again as in step 3.  The Cells should be placed successfully.  Hit the "f" key to fit the entire design to the window.  Your design should look similar to the one below.
  8. Choose SSHAFT -> FP Save to save your floorplan.  This not only saves the Pillar "autoLayout" view but also saves the placement information in a "floorplan" view converts the "floorplan" view to DFII.  You may note in the ICMakefile that the file data/dfII/tut1/mychip/floorplan/stranger.cdb is a dependecy.  Thus, if you do not save the floorplan as indicated here, the flow will terminate in error because one of the dependencies does not exist. 
  9. Exit Design Planner and change back to ICMake run directory.

Routing with ICMake

Change back to the ICMake run directory and type the command "icmake verify &".  This runs the flow through to the "verify" step.  Note that the log file is now called icmake.verify.log.  You may notice that a number of steps are skipped because the targets are up-to-date.  This time, however, the steps "skel_ctgen" and "skel_fpgen" are not executed.  Instead, the steps "phys_ctgen" and "fpmerge" are executed.  The "phys_ctgen" step builds a clock tree and uses the floorplan for clock sink placement information.  This will be discussed more in tutorial 3.  Next, the floorplan placement information is merged with the new physical design into an updated autoLayout view.  In a real design, the new clock-tree cells would have to be placed, but for this tutorial, clock tree generation has been turned off.  This simplification allows the new autoLayout view to be routed and then verified without worrying about any new cells.  The flow should complete in 3 to 4 minutes.

View the file icmake.verify.log.  There are two lines which we care the most about.  Both should appear near the end of the file.

Congratulations!  You have completed Tutorial 1.  You can view the fruits of your labor by going to the run/cds directory, typing "icfb &" to start the Cadence design framework II, and open the cell "tut1" "mychip" "layout".  Hit Shift-"f" to expand all levels of the hierarchy, or use Ctrl-"f" to view only the top level.  As with Design Planner, you can zoom in and out by right-clicking and dragging a box and by hitting "f" to fit the entire design in the window.  Similar to Design Planner, you can use the commands "listinst", "listterm" and "listnet" to view details of the design.  Click on a wire and hit "q" to view its properties.  Click on "Connectivity" to view the net name of this wire.  This net name matches the name in the EDIF file and the Design Planner autoLayout view.  You can also zoom in on the boundary pins to see the labels of the pin names.

 

Viewing Design Rule and LVS Errors

Go to the run/cds directory and type "icfb &".  Once the framework starts, type the following command in the CIW (Command Interpreter Window):

        loadi("calibre.skl")

This loads the code which interfaces Calibre and DFII.  This code is not loaded automatically because it needs ownership of the the UNIX socket 9189 in order to function properly.  That means that only one person per machine can view Calibre results at a time.  When you are done, please exit the design framework so that other users are not blocked.

Next, open the layout view of cell mychip in library tut1 in either edit or read-only mode.  You should see a new "Calibre" menu.  Choose "Start RVE" from this menu and click the "Open DB..." button.

To view DRC markers, click the DRC button in the "Open DB" window and browse for the results database.  The results will be stored in the file ../../data/other/tut1/mychip/drc.db.  Select this file and click "OK" on the "Browse" window followed by "OK" on the "Open DB" window.  A window will pop up listing all of the design rules and the violations.  clicking on a violation in this window will list the coordinates of the error.  Double clicking will highlight the marker in the Cadence Virtuoso window.

To view LVS markers, click the Hierarchical LVS button  in the "Open DB" window and browse for the results directory (not a file, a directory).  The results will be stored in the directory ../clbr/svdb.  Select this directory and click "OK" on the "Browse" window followed by "OK" on the "Open DB" window.  A window will pop up listing all of the nets which did not match.  Right clicking on layout allows highlighting the net in the Cadence Virtuoso window.  There are also ways to highlight named nets.  See the Calibre manual for more information.

If you find the source of an error and can fix it by hand, then save the cell, exit the design framework, go back to the ICMake run directory, and issue the command "icmake verify &" again. The flow will take your modified design and run DRC and LVS checks again generating a new set of error markers.

Finding the owner of the Calibre Socket

If you have any problems starting the Calibre results viewing environment (RVE), then perhaps someone else owns the socket.  You can find out with the following steps:

  1. Type "netstat -a | grep 9189".  If you get a line of the form...
            *.9189      *.*     0     0      0     0     LISTEN
    ...then someone is currently using the RVE.  Try logging in to a different compute server.  If no line beginning with "*.9189" is found, then you are free to run the RVE.
  2. If no other compute servers are available, you may need to find out who is running the RVE.  Use the command "lsof -i | grep 9189" (this command can take quite a while to run).  This will tell you who currently has opened TCP socket number 9189, and gives a line like...
            tclsh7.6     4609      wrdavis     3u     inet      0x62527ce8     0t0      TCP     *:9189      (LISTEN)
    ...which shows that user wrdavis currently owns socket 9189.  Find him and tell him to knock it off!

Summary

This tutorial has described the basic steps necessary to create mask layout from a Simulink design.  The flow was broken into two steps because no initial floorplan existed.  Once a floorplan has been created and saved, however, the entire flow can be run in one step.  If you make changes to the Simulink design, instead of starting from scratch, you can use the command "icmake fpmerge &".  This will generate a new autoLayout view which uses as much of the floorplan as possible.  You can then place new cells and save a new floorplan.  In this way, the floorplan can be developed along with the Simulink design instead of being developed independently.

It is also important to note that this tutorial generates a design from Simulink but does not really guarantee that the generated design behaves exactly the same as the Simulink system.  In order to verify that the Simulink system and generated design match, you must run cross-check simulations.  This process is described in ICMake Tutorial part 2: Macro Development and Function Verification using Module Compiler.

maintained by Rhett Davis
wrdavis@eecs.berkeley.edu