Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
language:langs:start [2022/06/23 17:48]
rajit [Sub-languages to specify circuits]
language:langs:start [2022/07/11 07:43] (current)
rajit [Auxillary sub-languages]
Line 5: Line 5:
 ===== Sub-languages to specify circuits ===== ===== Sub-languages to specify circuits =====
  
-ACT has the following five sub-languages that are used to specify circuits:+ACT has the following four sub-languages that are used to specify circuits:
  
   * [[chp|Communicating hardware processes]]: a programming language for describing hardware   * [[chp|Communicating hardware processes]]: a programming language for describing hardware
Line 11: Line 11:
   * [[hse|Handshaking expansions]]: an intermediate form between CHP and PRS   * [[hse|Handshaking expansions]]: an intermediate form between CHP and PRS
   * [[prs|Production rules]]: gate-level and transistor-level circuit specification   * [[prs|Production rules]]: gate-level and transistor-level circuit specification
-  * [[refine|Refinement]]: specifying circuits using sub-components 
  
-When simulating a design or translating the circuit to an implementation, the designer must //select// **one** of the five options for a process. The default level of abstraction selected is PRS followed by HSE (if PRS doesn't exist) followed by CHP (if HSE doesn't exist). Note that dataflow can be viewed as subset of CHP.+ 
 +When simulating a design or translating the circuit to an implementation, the designer must //select// **one** of the descriptions in a process. The default level of abstraction selected is PRS followed by HSE (if PRS doesn't exist) followed by CHP (if HSE doesn't exist). Note that dataflow can be viewed as subset of CHP. Often the selection of the sub-language is implicit in the functionality provided by a particular ACT tool/transform. For example, generation of SPICE output selects the PRS level of abstraction; translation of CHP to PRS selects the CHP level of abstraction. In the case of simulation, configuration files can be used to specify the level of abstraction selected when there is more than one option for a process.
  
 The CHP sub-language is used to describe the circuits using a programming notation. The HSE sub-language operates on Boolean-valued variables, and has syntax similar to the CHP block. A process can have at most one CHP block and at most one HSE block; if multiple blocks of the same type are detected, an error will be flagged. The CHP sub-language is used to describe the circuits using a programming notation. The HSE sub-language operates on Boolean-valued variables, and has syntax similar to the CHP block. A process can have at most one CHP block and at most one HSE block; if multiple blocks of the same type are detected, an error will be flagged.
  
 The dataflow sub-language can be used to specify computations as a static dataflow graph. The PRS sub-language can be used to specify gates as well as transistor-level implementations of circuits. These blocks can be repeated in a process, and the result is the concurrent composition of the blocks. The dataflow sub-language can be used to specify computations as a static dataflow graph. The PRS sub-language can be used to specify gates as well as transistor-level implementations of circuits. These blocks can be repeated in a process, and the result is the concurrent composition of the blocks.
-===== Auxillary sub-languages =====+ 
 +When translating circuits from one level of abstraction to another (especially going down to production rules), it may be helpful to add additional levels of design hierarchy (e.g. by instantiating standard gates). To support this, ACT includes a refinement body. 
 + 
 +  * [[refine|Refinement]]: specifying circuits using sub-components 
 + 
 +The refinement body is simply a standard ACT body. When the refinement body is selected, the other circuit languages are omitted. Similarly when one of CHP/HSE/PRS are selected, the refinement body is omitted. The refinement body can be selected using the ''-ref=N'' [[stdoptions:start|command-line option]] for any ACT tool. 
 + 
 +===== Auxiliary sub-languages ===== 
 + 
 +Auxiliary sub-languages augment the circuit specification in some way. The sizing sub-language can be used to specify gate sizing directives that apply to the ''prs'' sub-language.  The ''spec'' sub-language can be used to apply a range of directives to Boolean-valued variables. These directives include timing requirements, mutual exclusion requirements, and specifications of signals that can have switching hazards.
  
   * [[sizing|Gate sizing directives]]   * [[sizing|Gate sizing directives]]
   * [[spec|Specifications]]   * [[spec|Specifications]]
  
 +===== Selecting sub-language level =====
 +
 +There are four possible levels of detail at which to model a circuit component:
 +  * CHP, where channels and full expression syntax is permitted
 +  * HSE, where sequencing can be specified, but all variables are Boolean-valued
 +  * PRS, which corresponds to individual pull-up and pull-down networks (gates)
 +  * device, which corresponds to the transistor-level implementation of the gates. The device level doesn't have an explicit syntax, as the PRS language has enough detail to be able to capture this level of abstraction.
 +
 +A configuration file can be specified that selects the level of detail for a process  type / instance name. This file is typically passed via the command-line option ''-cnf=file.conf'' to ACT tools. The parameters you can specify are:
 +
 +<code>
 +begin level
 +# valid strings are "chp", "hse", "prs", and "device"
 +   string default "chp"
 +end
 +</code>   
 +This specifies the default level selected for every process. (Dataflow is treated as fine-grained parallel CHP.)
 +
 +<code>
 +begin level
 +   begin types
 +   # chp process model
 +     string_table chp "procname<5>"  "proc2<>"
 +   # prs process model
 +     string_table prs "proc3<>"
 +   end
 +end
 +</code>
 +This specifies that the particular process names should be modeled at the specified level of abstraction.