SSHAFT Technology File Reference

BWRC
Home

SSHAFT
Home

Reference
Manual

• File Structure

• Variables

  • SSHAFT API

  • ICMake

  • Cadence

  • Macro Generation

  • Stitch

  • Logic CTGen

File Structure

The technology files are collected in various subdirectories of the tech repository directory.  

The location of the tech-file is defined in the SSHAFT_TECHFILE environment variable.  This variable should be set to the full path-name of the technology file in the repository shadow.

The value of technology variables can be retrieved with the gettechvar command from the SSHAFT API or with the getTechVar.pl Perl script (for debugging purposes).  All Technology variables have string values.

Technology variables are defined in the following way:

[variable name] = [value]
+ [value]
...

where the variable name can contain only letters, numbers, and the underscore "_" character.  Values can contain any string character and are assumed to start from the first non-whitespace character on a line and end with the last non-whitespace character.  A plus "+" character at the beginning of the following line indicates a continuation of the previous line.  The two values will be joined with a single space character.

Values can contain references to variables defined earlier in the tech-file by using the dollar-sign "$" followed by the variable name, similar to Perl string substitution syntax.  The variable name should be enclosed in curly-brackets {} if  needed for delimitation.  For example, if the tech-file variable TechName is defined as HCMOS8, then the following substitutions could be used:

• $TechName.lib  => evaluates to HCMOS8.lib

• ${TechName}.lib  => evaluates to HCMOS8.lib

• $TechNameD => results in error if TechNameD is not previously defined

• ${TechName}D => results in HCMOS8D 

Variables

The currently defined tech-file variables are listed here.  Eventually, we will also include brief explanations of their use.

SSHAFT API

• SshaftTechDir - This variable is not used by any part of the flow, but is instead referenced by other techfile variables.  The intent is that the root directory for the technology can be easily changed (for debugging purposes) by modifying this variable.

• SshaftCdsLibTemplate - This variable gives the path to the initial cds.lib file that will be copied into the run/cds directory when it is created the first time by the dir_init API function.

• SshaftCdsinitTemplate - This variable gives the path to the initial .cdsinit file that will be copied into the run/cds directory when it is created the first time by the dir_init API function.

• SshaftCdsEtcDir - This variable gives the path to a directory that will be symbolically linked to the run/cds/etc directory when it is created the first time by the dir_init API function.  This was found to be necessary to avoid getting tons of meaningless error messages when running programs compiled from C-code that uses the DFII Integrator's Toolkit (itkDB), such as logic_ctgen.

• SshaftSynDCSetupTemplate

• SshaftSynLibTemplate

• SshaftPdpLocalDPUXTemplate

• SshaftPdpHldLocalTemplate

• SshaftPdpLibDirPrefix

• SshaftSynMCEnvTemplate

• SshaftGlobalSupplyNetName

• SshaftGlobalGroundNetName

• SshaftSiGlobalMapFile

• SshaftArcadiaRCControlFile

• SshaftArcadiaNetlisterControlFile

• SshaftOpCondStrings - This variable defines strings returned by the getopcstr API function.  The syntax for the function is getopcstr(string_ident,opc_ident), where string_ident gives an identifier for the string and opc_ident gives an identifier for the operating condition.  The intent of this function is that a wrapper script uses it with a particular string_ident, and then users of the wrapper script specify the opc_ident.  If a user leaves opc_ident unspecified, then a default is chosen.  If opc_ident is specified but not found, then descriptions of all available operating conditions for that particular string_ident are printed.  
  
  The techfile variable is formatted like a lisp-list, as shown here:
  
  ( string_ident 
      ( opc_ident description value [t] )
      ...
  )
  ...
  
  where description gives a description of the operating condition to be printed and value gives the string to be used by the wrapper script.  The optional t at the end of the list indicates that this particular operating condition is the default.  Note that string_ident and opc_ident are both lisp-symbols, which means that they must follow the naming restrictions of lisp symbols (i.e. must start with a letter and cannot contain spaces).  Also, description and value are strings and must be delimited with double-quotes.

ICMake

• MDLLIB

Cadence

• CdsDir - Like the SshaftTechDir variable, this variable is not used by the flow but is referenced by other tech file variables.

• CdsEdifInProg - This variable gives the path to the DFII EDIF reader executable.  It is needed because the name of this executable ("edifin") conflicts with the Synopsys EDIF reader, which appears earlier in the path.  It is used only by the edifIn.pl step.

• CdsTechLib - This variable gives the name of the DFII technology library, to which all libraries created by the flow will be attached.  It is used by the create_library API function and also by the bjcReplaceViews step, which replaces vias imported from Design Planner/Pillar with symbolic vias from the technology library.

Macro Generation

• MacroGenTypes - This variable defines the generators for macros that use the bjcView_Implementation directive.  The basic format is the following:
  
  ( "library_name.block_name" 
      ( "implementation" platform generator ) 
      ...
  )
  ...
  
  ...where library_name refers to the name of the Simulink library, block_name refers to the Simulink block name, implementation refers to the number of the implementation (1,2, etc., only numbers are supported as identifiers), platform refers to the generator platform (must be skill_step at the moment), and generator refers to the command used to generate the macro.

• MacroGenStateflowTopResetPort

• MacroGenStateflowGlobalResetNet

• MacroGenStateflowResetPort

• MacroGenStateflowClockPort

• MacroGenSingleGateAndCell

• MacroGenSingleGateNandCell

• MacroGenSingleGateOrCell

• MacroGenSingleGateNorCell

• MacroGenSingleGateXorCell

• MacroGenSingleGateXnorCell

• MacroGenSingleGateNotCell

Stitch

• StitchTopScanInPort

• StitchTopScanOutPort

• StitchTopScanEnablePort

• StitchScanEnableGlobalNetName

Logic CTGen

• LogicCTGenTopClockPortName

• LogicCTGenTopClockNetName

• LogicCTGenSecClockNetPrefix

• LogicCTGenClockGaterPrefix