Simulink IC Design Flow Manifesto

last modified 1/21/00

This page describes the limitations we place on Simulink systems, subsystems, libraries and stateflow blocks in order to ease the development of a "push-button" IC design flow. These requirements are still under development, so stay tuned...

Topics:

• Naming Restrictions
• Levels of Specification
• Subsystem Mask Requirements
• Stateflow Block Requirements

Naming Restrictions

Many CAD tools place restrictions on names, making it rather difficult to translate design data between tools. In order to make sure that a Simulink design will not cause problems with CAD tools later on, all systems, subsystems, libraries, blocks, ports, variables, etc. should adhere to the following naming restrictions:

1. Names must be 1 to 255 characters in length (preferably 5 or fewer characters).
2. Names must begin with a letter of the alphabet.
3. Names can contain letters, digits, and the underscore character "_". No other characters should be used. This means no white-space characters!
4. Names must be treated as case-sensitive.
5. Names must be unique within their scope, even if a tool treats them as case-insensitive. For example, a library should not contain two cells named "adder" and "Adder".

Levels of Specification

Subsystems are the basic element of design for our design flow.  This means that Systems and Libraries themselves are not considered to be design units.  The design flow will guarantee that an IC implementation of any subsystem can be created "by the push of a button" so long as it is fully specified at each of the following levels:

• Function Level - the basic input-output functionality of the subsystem is well defined.
• Signal Level - the signals that will exist on the chip are well defined.  This includes analog and digital voltages and the cycle-based timing associated with them.
• Circuit Level - the transistors and/or other physical components of the design and the connections between them are well defined.
• Floorplan Level - the placements of the physical components are well defined.

The details of what it means to be "well defined" at each one of these levels will be forthcoming...

Subsystem Mask Requirements

Simulink allows us to embed parameters in subsystem masks.  For each parameter, we can specify a variable name, a prompt, a control type, and an assignment mode.  Mask parameters used by the design flow must adhere to the following restrictions:

1. Variable name must be prefixed by "bjc".
2. Variable name must adhere to the naming restrictions.
3. Prompt must be identical to the variable name.
4. Control type must be "edit"
5. Assignment mode must be "literal"

Even though the assignment mode for these parameters is "literal", they will still be assumed to have "literal" and "evaluated" values.  The EDIF netlister will evaluate these parameters according to the following syntax:

1. If the value of a parameter includes a dollar-sign ($) which is followed by the name of a regular mask parameter which occurs earlier in the parameter list, then the literal value of that parameter will be substituted in the string. 
2. If the name following the dollar-sign ($) is that of a "bjc" parameter which occurs earlier in the parameter list, then the evaluated value of that parameter willbe substituted in the string.
3. The following special variables are determined by the netlister and will be expanded when determining a "bjc" parameter's evaluated value:
   • %PortDimIn#.IsSigned - "1" if input port # is signed, "0" if not
   • %PortDimIn#.MantBits - a decimal integer string containing the mantissa bits of input port #
   • %PortDimIn#.GuardBits - a decimal integer string containing the guard bits of input port #
   • %PortDimOut#.IsSigned - "1" if output port # is signed, "0" if not
   • %PortDimOut#.MantBits - a decimal integer string containing the mantissa bits of output port #
   • %PortDimOut#.GuardBits - a decimal integer string containing the guard bits of output port #
   • %LibName - the library name associated with the subsystem in the EDIF file
   • %CellName - the cell name associated with the subsystem in the EDIF file
   • %ViewName - the view name associated with the subsystem in the EDIF file
   • %InstName - the instance name associated with the subsystem in the EDIF file

The EDIF netlister will handle these properties in the following way:

1. If the netlister finds a mask parameter whose variable name is prefixed by "bjcView_", then it will add a property to the view (in the EDIF file) associated with the masked subsystem. 
2. If the netlister finds a mask parameter whose variable name is prefixed by "bjcInst_", then it will add a property to the instance (in the EDIF file) associated with the masked subsystem.
3. The name of the EDIF property will be identical to the mask parameter's variable name.  
4. The EDIF property will be of type string.
5. The value of the EDIF property will be identical to the evaluated value of the parameter.

The following semantics will be associated with the parameters:

1. If a subsystem mask contains the parameter bjcICType, then value will be interpreted as follows:
   • "ICMacro" - the system underlying the subsystem mask will not be processed further.  The corresponding cell will occur in an external library definition in the EDIF file.
   • "ICDesign" - the system underlying the subsystem mask defines the top-level cell in the design hierarchy.  The corresponding cell will occur in the design section of the EDIF file.
   • "ICWire" - the subsystem is a special command to the netlister, and the system underlying the subsystem mask will not be processed.  The input and output connections to the subsystem will be part of the same group of nets in the EDIF file.
2. For now, if the bjcICType is "ICDesign", then the mask must also contain a bjcPortTypeIn# parameter for every input port which contains the fixed-point data type assumed for that port.
3. Other mask parameters may be required, depending on the value of  these and other parameters.  If a required variable is not included in the mask, then it will be assumed to take a default value.
4. The complete list of the design flow mask variables will be defined in the Simulink Design Flow Parameter Reference.

Stateflow Block Requirements

1. For now, no two Stateflow charts in the same design may have the same chart name.
2. For now, the variables and ports into a Stateflow chart may not use VHDL reserved words:

   abs access after alias all and architecture array assert attribute begin block body buffer bus case component configuration constant disconnect downto else elsif end entity

   exit file for function generate generic group guarded if impure in inertial inout is label library linkage literal loop map mod nand

   new next nor not null of on open or others out package port postponed procedure process pure range record register reject rem report return rol ror

   select severity shared signal sla sll sra sr subtype then to transport type unaffected units until use variable wait when while with xnor xor

maintained by Rhett Davis
wrdavis@eecs.berkeley.edu