Differences

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

--- language:langs:start [2020/04/29 16:53] – [CMOS implementation] rajit
+++ language:langs:start [2022/07/11 11:43] (current) – [Auxillary sub-languages] rajit
@@ Line 1: / Line 1: @@
 ====== Hardware description and specification languages ======
-ACT permits the specification and description of circuits at multiple levels of abstraction. These languages are embedded into ACT as //sublanguages//.
+ACT permits the specification and description of circuits at multiple levels of abstraction. These languages are embedded into ACT as //sub-languages//. These  sub-languages can be used to specify circuits in a variety of ways and at different levels of abstraction. Some sub-languages are only useful when combined with others.
+===== Sub-languages to specify circuits =====
-===== The prs sublanguage =====
+ACT has the following four sub-languages that are used to specify circuits:
-The ''prs'' sublanguage is used to specify production rules. Production rules are the syntax used by ACT to specify pull-up and pull-down networks for a gate. For example, an inverter with input ''a'' and output ''b'' would be specified by the following production rule:
+  * [[chp|Communicating hardware processes]]: a programming language for describing hardware
+  * [[dflow|Dataflow]]: a language for specifying static dataflow graphs
+  * [[hse|Handshaking expansions]]: an intermediate form between CHP and PRS
+  * [[prs|Production rules]]: gate-level and transistor-level circuit specification
-<code>
-   a -> b-
-  ~a -> b+
-</code>
-The left-hand side of a production rule is a Boolean expression, and the right hand side specifies the action to be taken when the Boolean expression is true. A more complete example of an inverter in ACT would be:
+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.
-<code>
+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.
-bool a, b;
-prs {
-   a -> b-
-  ~a -> b+
-}
-</code>
-A two-input NAND gate with inputs ''a'' and ''b'' and output ''c'' would be:
+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.
-<code>
+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.
-prs {
-  a & b -> c-
- ~a | ~b -> c+
-}
-</code>
-A two-input inverting C-element would be:
+  * [[refine|Refinement]]: specifying circuits using sub-components
-<code>
+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.
-prs {
-  a & b -> c-
-~a & ~b -> c+
-}
-</code>
-Note that the expressive power of production rules makes it equally easy to specify state-holding gates (like an inverting C-element) and combinational gates (like a NAND gate).
+===== 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.
-==== The three types of arrows ====
+  * [[sizing|Gate sizing directives]]
+  * [[spec|Specifications]]
-The syntax above is sufficient to be able to specify the Boolean conditions for arbitrary pull-up and pull-down networks, and uses a "simple" arrow (''- >''). In addition, there are two common cases of gates for which the prs language has special syntax.
+===== Selecting sub-language level =====
-The first common case is a combinational gate like an inverter or NAND. In a combinational gate, the Boolean expression for the pull-up is the complement of the Boolean expression for the pull-down. In this case we can simply specify one, and use the ''= >'' arrow to let ACT know that this is a combinational gate---i.e., the second production rule can be automatically generated from the given rule. The following is the same two-input NAND gate specified using a more compact syntax:
+There are four possible levels of detail at which to model a circuit component:
-<code>
+  * CHP, where channels and full expression syntax is permitted
-prs {
+  * HSE, where sequencing can be specified, but all variables are Boolean-valued
-   a & b => c-
+  * 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.
-</code>
-Note that this is the same as specifying
+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>
-prs {
-   ~a | ~b => c+
-}
-</code>
-In both cases, ACT generates the second production rule from the first one by complementing the Boolean expression and changing the direction of the signal transition (''+'' to ''-'' and vice versa).
-The second common case is that of C-elements. To specify the two-input C-element above, you can also write
 <code>
-prs {
+begin level
-   a & b #> c-
+# valid strings are "chp", "hse", "prs", and "device"
-}
+   string default "chp"
-</code>
+end
-In this case, ACT generates the second production rule by complementing each variable in the Boolean expression.
+</code>
-==== Loops ====
+This specifies the default level selected for every process. (Dataflow is treated as fine-grained parallel CHP.)
-When defining parameterized circuits, it is helpful to also have the corresponding parametrized production rules that implement the circuit. There are two loop constructs available that use the same "repetition" syntax within the body of the prs sublanguage.
 <code>
-bool x[5], y[5];
+begin level
+   begin types
-prs {
+   # chp process model
-  (i:5: x[i] => y[i]-)
+     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.
-The example above creates five inverters when the circuit is expanded. ''i'' is the loop variable, and the body of the loop is simply replicated.
-<code>
-bool x[5], y;
-prs {
-  (&i:5: x[i]) => y-
-}
-</code>
-The example above is a 5-input NAND gate. Here the replication construct is used with ''&'' as the separator, which is the same as:
-<code>
-...
-prs {
-  x[0] & x[1] & x[2] & x[3] & x[4] => y-
-}
-</code>
-Similarly, ''|'' can also be used as a separator. Note that these can be combined with other expressions as needed, as in the following example:
-<code>
-prs {
-  en & (|i:5: x[i]) -> y-
-  ~en -> y+
-}
-</code>
-==== CMOS implementation ====
-The ACT tools provide automated support for converting production rules into a transistor-level implementation. This is done in a way that is entirely under user control, so the way the production rules are written is strictly followed when creating the transistors that implement the production rules.
-=== Implementable rules ===
-In what follows, we assume that the production rule expression is written in negation-normal form((Negation-normal form for a Boolean expression corresponds to a Boolean expression where the negation symbol can only appear on a variable. In other words, an expression like ''~(a|b)'' is not in negation-normal form; it can easily be converted to negation-normal form using DeMorgan's rule to obtain ''~a&~b''.)).
-For a production rule to be //CMOS-implementable//, we require that all variables in the pull-up network are inverted, and all variables in the pull-down network are un-inverted. So in the example  below, the first rule is not CMOS-implementable while the second and third rules are.
-<code>
-  a & b -> c+
-  a & b -> d-
-  ~a | ~b -> e+
-</code>
-=== Transistor sizing and flavors ===
-The width, length, flavor, and folding of a transistor can be specified as part of the syntax of production rules. The following examples illustrate the syntax.
-<code>
-  a <10> & b <10> -> c-
-</code>
-In this example, the widths of the transistor for ''a'' and ''b'' are both 10 units. The value is dimensionless, and is converted into physical dimensions using the ''lambda'' parameter specified in the [[config:netlist|netlist configuration options]] file.
-<code>
-  a <20,4> & b <20,4> -> c-
-</code>
-In this example, the transistor specified is one with a width of 20 units and length of 4 units. The default values of width and length for p-type and n-type devices are specified in the [[config:netlist|netlist configuration file]]. In the earlier example, the standard length for the transistors would be used (which is typically set to the minimum valid length for the technology in the case of digital circuits).
-<code>
-  a <10,lvt> & b<10,lvt> -> c-
-</code>
-Transistors come in different //flavors// in a modern technology. The flavors supported by ACT are specified in the top-level ACT [[config:start|configuration]]. Here, the ''lvt'' flavor is being specified. The standard names that we use are ''svt'' (for standard Vt), ''lvt'', and ''hvt'' but these are configuration options.
-Finally, it is often the case that multiple transistors in an expression use the same sizing information.
-<code>
- a <10> & b -> c-
-</code>
-In this example, the sizing for ''b'' is omitted. However, it inherits the sizing for ''a''. This //implicit// sizing only applies to a single production rule.
-=== Gate ordering ===
-A rule of the form
-<code>
- a & b -> c-
-</code>
-it could be implemented with a series transistor chain. However, if the gates of the two series transistors are exchanged, the Boolean expression is still logically the same value although the circuit characteristics (e.g. delay) might be different.
-ACT imposes a strict interpretation on gate ordering, since a circuit designer might have carefully chosen the gate ordering for their circuit. The interpretation is that, since the output is on the right hand side of the production rule, the gate closest to the output corresponds to the rightmost variable. So, in the example above, the gate order would be that ''a'' is closest to ground, and ''b'' is closest to ''c''.
-=== Multi-finger transistors ===
-A multi-fingered transistor can be manually specified if necessary. The example
-<code>
-  (a <10> | a<10>) & (b<10> | b<10>) -> c-
-</code>
-would have the effect of using two multi-fingered transistors, with an effective width of 20 units each. This can be also specified as follows:
-<code>
-  a<20;2> & b<20;2> -> c-
-</code>
-or, using the implicit sizing rules, as
-<code>
- a<20;2> & b -> c-
-</code>