Man page for bcc

NAME

bcc, the Berkeley Cross Compiler (v1.2.1)

SYNOPSIS

bcc [-{G|S|P|I}] [-d] [-V]
    [-t output_type] [-s stages_string] [-u level]
    [-L libPath] [-o output_name] -c top_cell_name file

DESCRIPTION

bcc is a program that will take as input a text file (.mdl) file produced by Simulink, compiles it, and generates output file(s) according to the command line argument.  The file(s) produced are used to drive the rest of a design flow.  As of version 1.2.1, there are four major type of files that bcc can produce:
  1. a EDIF (.edif) file used for IC design flow
  2. a profile file (.profile) used for high level estimation of circuit performance
  3. a dot file (.dot) that is used for the program dot
  4. a statistic file (.stats) that contains statistics about a design
After parsing in the design from the necessary .mdl files, bcc can perform one or more modification (stage) to the design heiriachy.  These stages includes:
  1. Name resolution (Resolve) -- In this stage, all textual names in the Simulink .mdl file are resolved.  Necessary external library files are read.
  2. Clock Generation (GenClock) -- In this stage, the design is modified to add a clock tree.  As of version 1.2.1, only one type of clock tree generation methodology is supported, namely, two phase non-overlapping clock tree.  The exact defintion of how clock tree is generated can be found from the IC design flow page.
  3. Reference Block Differentiateion (DiffRefBlock) -- In this stage, the libraray heirachy of the design is modified to reflect certain differentiation of subsystems that is necessary in physical design (IC) but not in logical design (Simulink).  For example, a 8-bits adder is physically different from a 12-bit adder on an IC, but not in Simulink.  The goal of this stage is to identify such descrepancy, and performe neccessary changes (e.g. distinguish the two kinds of adder, as well as make the ennclosing subsystem different, etc).  The exact behavior of block differenciation depends on a global variable set using the -u switch.
  4. Wire macro expansion (ExpandHardwire) -- In this stage, macros that correspond to pure wire in physical design are eliminated and are replaced by the corresponding wire connection.  Such macro includes constant shift, constant, ripper, and  compare-with-zero.
  5. Output stage -- output file(s) are generated according to the output type in this final stage


The execution of stage 1 and 5 is mandatory.  Stage 2 to 4 can be selectively run (or prohibit) by using the -s switch in command line.

OPTIONS

bcc supports a number of command line options.

The -c switch is required, and should be followed by the top level cell name of the design.  The last argument must be the input file name.

Other optional switches control the output format desired and also the detail stage execution order.  Normal user should use  -I, -P, -G, and -S switch, which are shorthand (or combo) for a set of other more advance switches (see blow).  If no options are specified, the -I switch is assumed.

Basic Options

-I Tells bcc to produce EDIF output for IC design flow.  It is equivalent to "-t edif -s cde -u 0 -o top_cell_name.edif"  It is the default if no options are provided
-P Tells bcc to produce .profile output for high level profiling.  It is equivalent to "-t profile -s d -u 2 -o top_cell_name.edif"
-G Tells bcc to produce a .dot output file for graph visualization of the design.  Equlvalent to "-t dot -s d -u 2 -o top_cell_name.dot"
-S Tells bcc to print a statistic of the design in a .stats file.  Can be combined with -s switch to get statistics after the execution of some subset of stage

Advance Options

-o output_name Specify the output file name
-L path  Specify the path to search for Simulink libray file when loading up a design
-t type Specify the output type, valid value for type is {edif, profile, dot, stats}
-s stages_string Specify what stage to be executed, and the order they should be executed.  The value of stages_string is a string consist of characters that denote the stage to be executed.  Stages are executed from left to right.  Valid stage characters are:
c == GenClock
d == DiffRefBlock
e == ExpandHardwire
Note that there are restriction in the ordering.  In particular 'e' must be after 'd'.  Also, 'c' must be used with -u level not equal to 1 (see below)
-u level Specify the level of "uniqueness" when differentiating blocks for physical heirachy
 
Level
Description
0 bcc will do minimum differentiation on all blocks and subsystems.  IC macros are differentiate.  Sub-systems with identical contents are not differentiate for maximum reusage in physical heirachy.
1 Opposite of level = 0, bcc will do a maximum differentiation on blocks.  Every blocks are considered different, regardless of their detail. (This level has not been found useful in real life application :)
2 bcc will do minimum differentiation on IC Macro blocks (adder, multiplier, etc).  However, it will relax the subsystem differentiation and regard each subsystem different.  The result is that after this stage, the number of block instance in the design is exactly the same as a flatten design.  It is useful when doing profiling (counting number of instance of a block), or when a flatten view of the design is desired (producing dataflow plot)
-d Print a whole lot of unneccesary and potentially unreadable debugging messages to standard error
-V Print version number of bcc

BUGS AND FEATURES

Although bcc has been used for a while, buglessly, I still consider it in beta stage.  Therefore it is normal for you to experience unpredicted behaviors.  (especially when you start changing the values of -s and -u switches, I haven't tested all combinations:)

Of course, these are just "features" of bcc, not bugs.   However, I'd love to hear about these "features".  :)
 

AUTHOR

Hayden So (skhay@eecs.berkeley.edu)

3/13/2000