Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| language:langs:sizing [2020/05/02 15:53] – created rajit | language:langs:sizing [2025/08/31 16:04] (current) – [Specifying flavors and multi-fingered devices] rajit | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Sizing sub-language ====== | ====== Sizing sub-language ====== | ||
| - | The sizing sub-language is used to simplify gate sizing specifications. The [[prs|prs]] sub-language already provides a mechanism to specify sizing, but this can be very verbose. | + | The sizing sub-language is used to simplify gate sizing specifications. The [[prs|prs]] sub-language already provides a mechanism to specify sizing, but this can become |
| + | <code act> | ||
| + | prs { | ||
| + | in => out- | ||
| + | } | ||
| + | </ | ||
| + | Now, if we want the pull-up network to have width 20 units and the pull-down to have width 10 units, this gets turned into: | ||
| + | <code act> | ||
| + | prs { | ||
| + | in< | ||
| + | | ||
| + | } | ||
| + | </ | ||
| + | Note that the convenience of specifying combinational logic is lost, as two production rules have to be specified to | ||
| + | control the sizes of all the gates. | ||
| + | |||
| + | Often all one is interested in is sizing the gates so that they have some unit drive strength, where the unit selected is technology/ | ||
| + | <code act> | ||
| + | prs { | ||
| + | in => out- | ||
| + | } | ||
| + | sizing { | ||
| + | out {-1} | ||
| + | } | ||
| + | </ | ||
| + | |||
| + | The sizing body is a semi-colon separated list of directives. In the example above, the directive '' | ||
| + | |||
| + | This has the same effect as: | ||
| + | <code act> | ||
| + | prs { | ||
| + | in <10> -> out- | ||
| + | ~in <20> -> out+ | ||
| + | } | ||
| + | </ | ||
| + | The p-to-n ratio is automatically used to size the pull-up network differently from the pull-down network. | ||
| + | |||
| + | <code act> | ||
| + | prs { | ||
| + | a & b => c- | ||
| + | ~c => d- | ||
| + | } | ||
| + | sizing { | ||
| + | c {-1}; d{-1} | ||
| + | } | ||
| + | </ | ||
| + | |||
| + | The example above results in the following sizing: | ||
| + | <code act> | ||
| + | prs { | ||
| + | a<20> & b<20> -> c- | ||
| + | ~a <20> | ~b <20> -> c+ | ||
| + | c <10> -> d- | ||
| + | ~c <20> -> d+ | ||
| + | } | ||
| + | </ | ||
| + | Note that that series transistors are appropriately sized, as are the parallel ones. Note that the default standard length is used for all transistors. | ||
| + | |||
| + | Specifying sizing for a production rule that has manual sizing specified is a warning; in this case, the sizing directive is ignored. | ||
| + | |||
| + | ===== Specifying flavors and multi-fingered devices ===== | ||
| + | |||
| + | An example of the general form of the sizing directive is: | ||
| + | <code act> | ||
| + | | ||
| + | out {-5,lvt,2 ; +4,lvt,2 } | ||
| + | } | ||
| + | </ | ||
| + | This says that the pull-down network should be sized with 5 times the drive strength, and all gates should use two fingers and '' | ||
| + | <code act> | ||
| + | sizing { | ||
| + | out {+4,lvt,2 ; -5,lvt,2 } | ||
| + | } | ||
| + | </ | ||
| + | |||
| + | If a circuit wants to use a different unit width, that can also be specified as follows: | ||
| + | |||
| + | <code act> | ||
| + | sizing { | ||
| + | unit_n <- 20; | ||
| + | out {-1}; | ||
| + | } | ||
| + | </ | ||
| + | This says that the unit n-transistor is 20 lambda wide. | ||
| + | |||
| + | ===== Syntactic replication ===== | ||
| + | |||
| + | Syntactic replication can be used within the sizing body to, for example, specify drive strengths for an array of signals. | ||
| + | <code act> | ||
| + | sizing { | ||
| + | unit_n <- 5; | ||
| + | (; i : 10 : out[i]{-1}) | ||
| + | } | ||
| + | </ | ||
| + | |||
| + | |||
| + | ===== Example using implementation relation ===== | ||
| + | |||
| + | The benefits of a sizing body are best illustrated when combined with the implementation relation. Consider the following example: | ||
| + | |||
| + | <code act> | ||
| + | defproc inv (bool? i; bool! o) | ||
| + | { | ||
| + | prs { | ||
| + | i => o- | ||
| + | } | ||
| + | } | ||
| + | |||
| + | template< | ||
| + | defproc szinv <: inv() | ||
| + | { | ||
| + | sizing { | ||
| + | o {-drive} | ||
| + | } | ||
| + | } | ||
| + | |||
| + | defproc INVX1 <: szinv< | ||
| + | defproc INVX2 <: szinv< | ||
| + | </ | ||
| + | |||
| + | This is an example of defining two standard inverters, that correspond to the same logical production rules but having different sizing. | ||
| + | |||
| + | ===== P/N ratios ===== | ||
| + | |||
| + | The default sizing equalizes drive strengths for the pull-up and pull-down network. For gates used in cyclic control logic in asynchronous design, the optimal drive strengths are different. To use the optimal ratio, you can add: | ||
| + | |||
| + | <code act> | ||
| + | |||
| + | prs { | ||
| + | in[1] & in[0] #> out- | ||
| + | } | ||
| + | sizing { | ||
| + | p_n_mode <- 1; /* this modifies the sizing */ | ||
| + | out {-1} | ||
| + | } | ||
| + | </ | ||
| + | |||
| + | The ratio will be computed using parameters in the netlist section of the ACT [[config: | ||
| + | |||
| + | |||
| + | ===== Low leak addition on channel length ===== | ||
| + | |||
| + | In some technologies, | ||
| + | |||
| + | For adding a specified additional length to the minimum length of your transistors, | ||
| + | |||
| + | <code act> | ||
| + | prs { | ||
| + | in => out- | ||
| + | } | ||
| + | sizing { | ||
| + | | ||
| + | | ||
| + | } | ||
| + | </ | ||
| + | |||
| + | To configure how much is added add this line to the configuration | ||
| + | |||
| + | < | ||
| + | # add to length for leakage management [used if l=min length] | ||
| + | real leakage_adjust 15e-9 | ||
| + | </ | ||
| + | |||
| + | The length unit here is absolute (i.e. not scaled), so the amount specified above is 15nm. | ||