| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| tools:start [2023/04/07 12:54] – [Expanded names] rajit | tools:start [2025/05/20 11:52] (current) – rajit |
|---|
| * [[prs2sim|prs2sim]]: a production rule to sim file converter | * [[prs2sim|prs2sim]]: a production rule to sim file converter |
| * [[ext2sp|ext2sp]]: converts magic extract files into a hierarchical spice file | * [[ext2sp|ext2sp]]: converts magic extract files into a hierarchical spice file |
| | * [[tools:layout:|Layout generation]] |
| * [[lvp|lvp]]: layout versus production rules | * [[lvp|lvp]]: layout versus production rules |
| | * [[act2lef|act2lef]]: Generate LEF/DEF from an ACT design |
| | * [[act2v|act2v]]: Convert ACT file into a Verilog netlist |
| | * [[adepend|adepend]]: Print dependencies of an ACT file |
| | * [[chp2prs|chp2prs]]: convert CHP to production rules |
| | * [[interact|interact]]: Interactive ACT |
| | * [[prs2cells|prs2cells]]: extract ACT cells needed to implement a design |
| | * [[v2act|v2act]]: Translate a Verilog netlist into an ACT file |
| | * [[asic:timing:xcell:start|xcell]]: Cell library characterizer |
| |
| These are core ACT tools--i.e. tools that use the core ACT library and take ACT files as input. They also accept the standard ACT [[:stdoptions:start|command-line arguments]], in addition to their own arguments. The standard ACT options include ways to specify technology-specific information, as well as local configuration overrides. | These are core ACT tools--i.e. tools that use the core ACT library and take ACT files as input. They also accept the standard ACT [[:stdoptions:start|command-line arguments]], in addition to their own arguments. The standard ACT options include ways to specify technology-specific information, as well as local configuration overrides. |
| * [[http://opencircuitdesign.com/magic/index.html|magic]]: The Magic VLSI layout editor | * [[http://opencircuitdesign.com/magic/index.html|magic]]: The Magic VLSI layout editor |
| * [[http://opencircuitdesign.com/irsim/index.html|irsim]]: A switch-level circuit simulator | * [[http://opencircuitdesign.com/irsim/index.html|irsim]]: A switch-level circuit simulator |
| * Gemini: a netlist comparison for strict layout-versus-schematic checking {{:tools:gemini-2.7.2.tar.gz|Gemini}} | * Layout versus schematic (LVS) checking: |
| | * Gemini: a netlist comparison for strict layout-versus-schematic checking {{:tools:gemini-2.7.2.tar.gz|Gemini}} |
| ===== Expanded names ===== | * [[http://opencircuitdesign.com/netgen/index.html|netgen]]: another tool for LVS |
| | |
| A concept one should be familiar with, especially when debugging and/or understanding error messages is the notion of expanded names. This is best illustrated with an example. Consider the following templated process definition: | |
| <code act> | |
| template<pint A; pbool B; pint C[A]> defproc example(...) { ... } | |
| | |
| example<1+1,true,{1,5}> e1; | |
| example<1,false,{2}> e2; | |
| </code> | |
| The type of the process defined is ''example'', but the instances ''e1'' and ''e2'' include specific template parameters. After the design is expanded and all template parameters are substituted, different variations of ''example'' are created for ''e1'' and ''e2''. These //expanded// versions of types are given different names within the ACT framework. In particular, the expanded type for ''e1'' would be ''example<2,t,{1,5}>'' (here ''t'' is used as a stand-in for the value of the Boolean parameter ''true''). If ''example'' did not take on any template parameters, the expanded version of the type would be named ''example<>''. | |
| | |
| If the template list contains multi-dimensional arrays, the expanded name contains a linear list of the parameters separated by commas. | |
| |
| | Two useful concepts to keep in mind when using the ACT tools are [[intro_example:name_mangling|expanded names and mangled names]]. |
| |