1 <?xml version=
"1.0" encoding=
"ISO-8859-1" ?>
3 <section niv='
1'
><title>Defining Recognition Rules and Actions
</title>
9 <section niv='
2'
><title>Description
</title>
12 <p>&tool; provides a highly efficient way to identify a hierarchical structure
13 within a flat transistor netlist. This process is done by first
14 identifying basic blocks made up exclusively of transistors.
15 Those blocks are then merged by hierarchical rules to a higher level of abstraction.
16 The process is repeated until all the user specified hierarchical rules have been fully exhausted.
17 Each user-specified rule is a model corresponding to a single hierarchical level.
18 Genius will try to find all the instances of each level
19 starting from the models describing the transistor level blocks right up to the top-level
21 In addition, the user is given the possibility of specifying actions which are performed whenever instances
22 of a model are identified within the circuit. This action consists of a C
23 or TCL function which can do practically whatever the user wants.
24 The operation of the
&tool; hierarchical recognition therefore requires a certain amount of user-supplied information and files.
25 To provide this information the user must create a
&tool; library file which basically contains the file names of the models and actions.
</p>
30 <section niv='
2'
><title>The Recognition Models
</title>
35 <section niv='
3'
><title>The Transistor Level Models
</title>
37 <p>The first step in the hierarchical recognition is to identify the blocks at the lowest
38 level. Those blocks are composed exclusively of transistors.
39 The user must therefore provide models for each of the basic blocks to
40 recognize. The actual recognition of these transistor-level blocks is performed by FCL, however this
41 is transparent to the user since the GNS module handles the communication with FCL.
42 The description of the transistor level blocks can be given either as a
43 SPICE netlist or in a structural VHDL file.
</p>
44 <p>The spice netlist is a classical flat transistor netlist but
45 the VHDL description is done by instantiating transistors N or P.
46 For this, there are two special components to describe the transistors:
</p>
51 <cl> grid: IN BIT;
</cl>
52 <cl> source, drain: INOUT BIT);
</cl>
53 <cl>END COMPONENT;
</cl>
57 <cl> grid: in bit;
</cl>
58 <cl> source, drain: inout bit);
</cl>
59 <cl>END COMPONENT;
</cl>
62 <p>From the
&tool; point of view, there is no difference between these
63 representations. For instance, an inverter could be described as:
</p>
66 <cl>ENTITY inverter IS
</cl>
68 <cl> dout: out bit;
</cl>
69 <cl> din: in bit;
</cl>
70 <cl> vdd, vss: in bit);
</cl>
71 <cl>END inverter;
</cl>
73 <cl>ARCHITECTURE structural OF inverter IS
</cl>
75 <cl> COMPONENT tn
</cl>
76 <cl> PORT (grid: IN bit; source, drain: INOUT bit);
</cl>
77 <cl> END COMPONENT;
</cl>
79 <cl> COMPONENT tp
</cl>
80 <cl> PORT (grid: IN bit; source, drain: INOUT bit);
</cl>
81 <cl> END COMPONENT;
</cl>
85 <cl> PORT MAP (grid=
>din, source=
>vss, drain=
>dout);
</cl>
87 <cl> PORT MAP (grid=
>din, source=
>vdd, drain=
>dout);
</cl>
88 <cl>END structural;
</cl>
92 <cl>.SUBCKT inverter dout din vdd vss
</cl>
93 <cl>M1 vdd din dout vdd tp
</cl>
94 <cl>M2 vss din dout vss tn
</cl>
98 <p>The user has the freedom to use whichever format he/she prefers.
99 The library file is used to specify the format to be used for a particular model.
</p>
104 <section niv='
3'
><title>The Hierarchical Models
</title>
107 Once the basic transistor-level blocks have been identified within the circuit, the higher-level hierarchical models can be identified. In order to perform this hierarchical recognition, the user must specify, for each of the hierarchical levels, how the blocks are interconnected. This is done by providing a standard VHDL structural description of how the lower-level blocks are interconnected.
110 Structural VHDL provides a natural way of describing a hierarchical structure. The ENTITY construct effectively serves as a declaration for the recognition rule, as well as providing the interface of the component abstracted by application of the rule. The ARCHITECTURE block specifies the interconnection of blocks from the lower levels required by the rule. As in VHDL, the required lower-level blocks must be declared using the COMPONENT construct, this allows both implicit (order based) and explicit (name based) component instantiations.
111 Anyway, using the format spice_hr rather than VHDL permits the description of a simple hierchical model without all the possibilties of the VHDL model (loops, vectors, ...).
114 For example, the rule required to recognize a bi-stable made up of two NAND gates would be written as follows:
117 <cl>ENTITY bistable IS
</cl>
121 <cl> q: OUT BIT;
</cl>
122 <cl> qn: OUT BIT;
</cl>
123 <cl> vdd, vss: IN BIT);
</cl>
124 <cl>END bistable;
</cl>
126 <cl>ARCHITECTURE nand_based OF bistable IS
</cl>
128 <cl> COMPONENT nand
</cl>
129 <cl> PORT (y: OUT BIT; in1, in2: IN BIT; vdd, vss: IN BIT);
</cl>
130 <cl> END COMPONENT;
</cl>
133 <cl> nand_1: nand
</cl>
134 <cl> PORT MAP (q, r, qn, vdd, vss);
</cl>
135 <cl> nand_2: nand
</cl>
136 <cl> PORT MAP (qn, s, q, vdd, vss);
</cl>
137 <cl>END nand_based;
</cl>
140 However, it is also possible to generate a bi-stable from two NOR gates. The user may therefore require that a single recognition rule consist of alternative internal structures. This is possible by providing multiple ARCHITECTURE blocks for a single ENTITY.
143 To recognize a bistable made up of either NAND or NOR gates, the user would add the following architecture construct to the preceding rule:
146 <cl>ARCHITECTURE nor_based OF bistable IS
</cl>
148 <cl> COMPONENT nor
</cl>
149 <cl> PORT (y: OUT BIT; in1, in2: IN BIT; vdd, vss: IN BIT);
</cl>
150 <cl> END COMPONENT;
</cl>
154 <cl> PORT MAP (q, r, qn, vdd, vss);
</cl>
156 <cl> PORT MAP (qn, s, q, vdd, vss);
</cl>
157 <cl>END nor_based;
</cl>
164 <section niv='
3'
><title>Generic Hierarchical Models
</title>
167 One of the most powerful features of the
&tool; recognition language is the ability to represent interconnections of an arbitrary number of identical structures. Both parallel structures and serial structures can be represented.
170 <item>Parallel structures are those where an arbitrary number of identical blocks share one or more common signal.
</item>
171 <item>Serial structures are those where an arbitrary number of identical blocks are connected in cascade.
</item>
174 This important capability is provided for through the use of VHDL Generics coupled with GENERATE constructs. In standard VHDL a structural model can be made generic in exactly this way; it is the responsibility of the instantiation to specify the actual value of the generic variable. In our semantic, it is the role of the recognition module to identify the value.
177 A typical example of a parallel structure would be a rule to identify a column of an arbitrary number of bit-cells as part of a static RAM:
180 <cl>ENTITY column IS
</cl>
181 <cl> GENERIC (capacity: INTEGER);
</cl>
183 <cl> q, nq: INOUT BIT;
</cl>
184 <cl> com: IN BIT_VECTOR (
1 TO capacity);
</cl>
185 <cl> vdd, vss: IN BIT);
</cl>
188 <cl>ARCHITECTURE structural OF column IS
</cl>
190 <cl> COMPONENT bitcell
</cl>
191 <cl> PORT (q, nq: INOUT BIT; com, vdd, vss: IN BIT);
</cl>
192 <cl> END COMPONENT;
</cl>
195 <cl> loop: FOR i IN
1 TO capacity GENERATE
</cl>
196 <cl> bit_i: bitcell
</cl>
197 <cl> PORT MAP (q, nq, com (i), vdd, vss);
</cl>
198 <cl> END GENERATE;
</cl>
199 <cl>END structural;
</cl>
204 <item>The generic variable must be declared in the ENTITY block.
</item>
205 <item>A GENERATE loop must be defined using the generic variable to define the upper limit.
</item>
206 <item>One or more signals or external connectors must be vectorized using the value of the generic variable to define the range.
</item>
209 Both the loop limits and the vector bounds can be specified as expressions. In this case, the expression for the lower limit must necessarily resolve to a constant and for the upper limit, the generic variable must be the only unknown.
212 In any case, in any one rule, it is not possible to have more than one GENERATE loop for which the limits are specified by a GENERIC whose value is to be identified. However, this is not a real limitation thanks to the unlimited hierarchy of the rules.
215 It is also possible to describe arbitrary numbers of components connected in cascade, for example, a chain of inverters can be represented by the following rule:
218 <cl>ENTITY invchain IS
</cl>
219 <cl> GENERIC (length: INTEGER);
</cl>
221 <cl> q, nq: INOUT BIT;
</cl>
222 <cl> con: IN BIT_VECTOR (
0 TO length);
</cl>
223 <cl> vdd, vss: IN BIT);
</cl>
226 <cl>ARCHITECTURE structural OF invchain IS
</cl>
228 <cl> COMPONENT inverter
</cl>
229 <cl> PORT (y: OUT BIT; a, vdd, vss: IN BIT);
</cl>
230 <cl> END COMPONENT;
</cl>
233 <cl> loop: FOR i IN
1 TO length GENERATE
</cl>
234 <cl> inv_i: inverter
</cl>
235 <cl> PORT MAP (con (i), con (i-
1), vdd, vss);
</cl>
236 <cl> END GENERATE;
</cl>
237 <cl>END structural;
</cl>
244 <section niv='
3'
><title>Exploiting Generic Variables
</title>
247 At each hierarchical rule level it is possible to exploit the value of generic variables obtained from lower levels of the hierarchy. The mechanism for this is identical to standard VHDL apart from the fact that the direction of transmission is from the lower levels upwards rather than from the upper levels downwards.
250 The transmission of generic values is specified using the GENERIC MAP construct. This construct specifies which generic variable in a rule takes the value of a generic variable defined in rule corresponding to an instantiated model.
253 For example, imagine we need the height of a column of bit cells in order to add an inverter in front each of the command inputs. We could use the following rule:
256 <cl>ENTITY buffered_col IS
</cl>
257 <cl> GENERIC (height: INTEGER);
</cl>
259 <cl> q, nq: INOUT BIT;
</cl>
260 <cl> bufcomb: IN BIT;
</cl>
261 <cl> vdd, vss: IN BIT);
</cl>
262 <cl>END bistable;
</cl>
264 <cl>ARCHITECTURE structural OF buffered_col IS
</cl>
266 <cl> COMPONENT column
</cl>
267 <cl> GENERIC (capacity: INTEGER);
</cl>
269 <cl> q, nq: INOUT BIT;
</cl>
270 <cl> com: IN BIT_VECTOR (
1 TO capacity);
</cl>
271 <cl> vdd, vss: IN BIT);
</cl>
272 <cl> END COMPONENT;
</cl>
274 <cl> COMPONENT inverter
</cl>
275 <cl> PORT (out: OUT BIT; a: IN BIT; vdd, vss: IN BIT);
</cl>
276 <cl> END COMPONENT;
</cl>
278 <cl> SIGNAL bufcom: BIT_VECTOR (
1 TO height);
</cl>
281 <cl> column_ins: column
</cl>
282 <cl> GENERIC MAP (height=
>capacity);
</cl>
283 <cl> PORT MAP (q, nq, bufcom, vdd, vss);
</cl>
285 <cl> loop: FOR i IN
1 TO height GENERATE
</cl>
286 <cl> buf_i: inverter
</cl>
287 <cl> PORT MAP (bufcom (i), bufcomb (i), vdd, vss);
</cl>
288 <cl> END GENERATE;
</cl>
290 <cl>END structural;
</cl>
293 As we can see from the above example, in order to exploit a generic variable whose value obtained by a rule at a lower level, is is necessary to:
296 <item>Declare the GENERIC in the COMPONENT corresponding to the lower-level rule.
</item>
297 <item>Supply the appropriate GENERIC MAP with the instantiation of the model corresponding to the lower-level rule.
</item>
300 The GENERIC MAP can be either explicit (as in the above example) or implicit, in which case the association is made based upon the order of the GENERIC declarations in the COMPONENT.
303 Generic variables whose values are obtained through GENERIC MAPs can be used in the same way as generic variables identified in the rule. That is for:
306 <item>Range declarations in signals and/or connectors.
</item>
307 <item>Loop limits in GENERATE statements.
</item>
310 A rule can contain any number of GENERATE statements defined by GENERIC variables obtained in this way, since their limits are precisely defined at the beginning of the validation of the rule.
319 <section niv='
2'
><title>VHDL Recognition Rules Reference
</title>
323 This section contains the complete grammar of the structural VHDL subset used to represent the
&tool; recognition rules. Only entity and structural architecture declarations are required. Before giving the BNF for each of these two parts, we illustrate them with a general example.
326 The legend for the following BNF grammar definitions are:
329 <row><article><name
></article><def>is a syntax construct item
</def></row>
330 <row><article>name
</article><def>is a lexeme
</def></row>
331 <row><article>[
<name
>] or [name]
</article><def>is an optional item
</def></row>
332 <row><article><name
>*
</article><def>is zero or more items
</def></row>
333 <row><article><name
>+
</article><def>is one or more items
</def></row>
334 <row><article><name
> -
></article><def>indicate a syntax definition to an item
</def></row>
335 <row><article> ||
</article><def>introduces an other syntax definition for an item
</def></row>
338 First of all, each rule requires an entity declaration such as:
341 <cl>ENTITY levelA IS
</cl>
342 <cl> GENERIC ( VAR, VAR1, ...: integer );
</cl>
344 <cl> a INOUT BIT;
</cl>
345 <cl> b: IN BIT_VECTOR(
1 TO var);
</cl>
347 <cl> vdd, vss: IN BIT);
</cl>
351 The entity describes the model
"levelA". A model can be instantiated with parameters. All the parameters used later in the architecture part of the model must be present in the model entity. One, and only one, of the generic variables can be the special variable whose value must be determined during execution of the rule.
354 The complete entity grammar allowed is as follows:
357 <cl><entity
> -
> ENTITY
<name_of_model
> IS
</cl>
358 <cl> [GENERIC (
<list_of_variables
>+ );]
</cl>
359 <cl> PORT (
<list_of_ports
>+ );
</cl>
360 <cl> END [
<name_of_model
>];
</cl>
362 <cl><list_of_variables
> -
> <<variable_decl
>;
>*
<variable_decl
></cl>
364 <cl><variable_decl
> -
> [VARIABLE]
<<identifier_list
>: INTEGER
</cl>
366 <cl><identifier_list
> -
> <<identifier
>,
>*
<identifier
></cl>
368 <cl><list_of_ports
> -
> <<port_decl
>;
>*
<port_decl
></cl>
370 <cl><port_decl
> -
> <identifier_list
>:
<port_type
></cl>
372 <cl><port_type
> -
> IN
<mode
></cl>
373 <cl> || OUT
<mode
></cl>
374 <cl> || INOUT
<mode
></cl>
376 <cl><mode
> -
> BIT
</cl>
377 <cl> || BIT_VECTOR
<array
></cl>
379 <cl><array
> -
> (
<expression
> TO
<expression
> )
</cl>
380 <cl> || (
<expression
> DOWNTO
<expression
> )
</cl>
383 The expression in the array statement is a standard arithmetic expression which can depend on all the generic variables defined in the entity, even the special generic variable whose value must be identified during execution of the rule.
386 The architecture section of a rule is composed of
2 parts: the component declarations and the model instantiations in the architecture body. The component of a model should have the same interface and the same generic variables found in the entity statement for the same model. The grammar of the architecture body is elementary.
389 A typical example shows loops instantiating multiple instances and single instantiations:
392 <cl>architecture ArchiLevelA of levelA is
</cl>
394 <cl>COMPONENT levelB1
</cl>
395 <cl> GENERIC (varB2, ...: integer)
</cl>
396 <cl> PORT ( ...
</cl>
397 <cl> q: IN BIT_VECTOR(
1 TO varB2);
</cl>
399 <cl> vdd,vss: IN BIT);
</cl>
400 <cl>END COMPONENT;
</cl>
403 <cl> loop0: FOR i IN
1 TO var GENERATE
</cl>
404 <cl> instB1_i: levelB1
</cl>
405 <cl> GENERIC MAP (varB2=
>var1, ...)
</cl>
406 <cl> PORT MAP ( ... );
</cl>
407 <cl> END GENERATE;
</cl>
409 <cl> loop1: FOR j IN
1 TO var1*
2 GENERATE
</cl>
410 <cl> instD1_j: levelD1
</cl>
411 <cl> GENERIC MAP ( ... )
</cl>
412 <cl> PORT MAP ( ... );
</cl>
413 <cl> END GENERATE;
</cl>
415 <cl> instance_fcl: levelFCL1 GENERIC MAP (...) PORT MAP ( ... );
</cl>
416 <cl> instance_l2: levelC PORT MAP ( ... );
</cl>
420 The complete architecture grammar allowed is as follows:
423 <cl><architecture
> -
></cl>
424 <cl> ARCHITECTURE
<name_of_archi
> OF
<name_of_model
> IS
</cl>
425 <cl> <component
>*
</cl>
426 <cl> <signal_decl
>*
</cl>
427 <cl> <architecture_body
>*
</cl>
429 <cl><signal_decl
> -
> SIGNAL
<identifier_list
>:
<mode
>;
</cl>
431 <cl><component
> -
> COMPONENT
<name_of_model
></cl>
432 <cl> [GENERIC (
<list_of_variables
>+ );]
</cl>
433 <cl> PORT (
<list_of_ports
>+ );
</cl>
434 <cl> END COMPONENT;
</cl>
436 <cl><architecture_body
> -
> BEGIN
</cl>
437 <cl> <architecture_element
>*
</cl>
438 <cl> END [
<name_of_archi
>];
</cl>
440 <cl><architecture_element
> -
> <simple_instantiation
></cl>
441 <cl> ||
<loop_instantiation
></cl>
443 <cl><loop_instantiation
> -
></cl>
444 <cl> <blockname
>:
</cl>
445 <cl> FOR
<identifier
> IN
<expr
> <direction
> <expr
></cl>
447 <cl> <instantiation
>+
</cl>
448 <cl> END GENERATE;
</cl>
450 <cl><simple_instantiation
> -
></cl>
451 <cl> <blockname
>:
<identifier
></cl>
452 <cl> [GENERIC MAP (
<generic_assignment
> )]
</cl>
453 <cl> PORT MAP (
<port_assignment
> );
</cl>
455 <cl><direction
> -
> TO
</cl>
458 <cl><instantiation
> -
> <loop_instantiation
></cl>
459 <cl> ||
<simple_instantiation
></cl>
461 <cl><generic_assignment
> -
> <identifier_list
></cl>
462 <cl> ||
<explicit_assignment_list
></cl>
464 <cl><explicit_assignment_list
> -
></cl>
465 <cl> <<explicit_assignment
>,
>*
<explicit_assignment
></cl>
467 <cl><explicit_assignment
> -
> <identifier
> =
> <identifier
></cl>
469 <cl><port_assignment
> -
> <signal_list
></cl>
470 <cl> ||
<explicit_sig_assign_list
></cl>
472 <cl><signal_list
> -
> <<signal
>,
>*
<signal
></cl>
474 <cl><signal
> -
> <identifier
> [
<array
>]
</cl>
476 <cl><explicit_sig_assign_list
> -
></cl>
477 <cl> <<explicit_sig_assign
>,
>*
<explicit_sig_assign
></cl>
479 <cl><explicit_sig_assign
> -
> <identifier
> =
> <signal
></cl>
482 The instantiation of a model is done by assigning the generic variable of the instance to the local generic variables of the current model and by linking the instance port to the model signals. The
<identifier
> is the model name and
<blockname
> the instance name.
485 The user can also use a
"for" statement to try to instantiate a set of instances whose number is known. In this case, the expressions defining the bound of the
"for" statement have no restriction and can depend on any of the known generic variables.
488 The user may also wish to recognize an unknown number of instances such as cells in parallel or in series. In this case, the left or right expression in the
"for" statement contains an unknown generic variable and at least one of the port vector will depend on this variable. The expression with the generic variable has certain restrictions. The only legal operators are '+', '-', '/' and '*'.
491 When trying to find a number of cells in a
"for" statement, Genius will always try to match as many instances as possible.
497 <section niv='
2'
><title>The Actions
</title>
500 The user can associate an action to a model.
501 This action can be put directly at the end of the VHDL file if it's a C action
502 or in a separate file. If the action is written in TCL it can be defined in the main TCL script.
503 The action is a C or TCL function which has
504 the same name as the model. This function is given the values
505 computed for all the generic variables of the model. Those
506 values are assigned to variables with the same name as the
507 generic variables of the model.
510 For any given model, there can be several versions due to the
511 fact that each recognized instance of
512 a model can differ from another depending on the values attributed to the
513 generic variables used to match the model. A unique name for
514 each version is passed as an argument to the function
515 as a string
"char *model".
518 The action is called for each recognized instances
519 remaining after all the recognition rules have been applied. A unique name for
520 each instance is passed as an argument to the function
524 <cl>void levelA (char *model, char *instance, int VAR, int VAR1, ...)
</cl>
530 In TCL, generic variables are made available as global TCL variables.
531 Be aware that calling TCL script within GNS, affects main TCL script.
534 <cl>proc levelA {} {
</cl>
535 <cl> global model instance VAR VAR1 ...
</cl>
540 The actions are called at the end of the complete recognition phase
541 for all the instances to keep (see Library File) in the circuit. The
542 instances to keep but only used by an higher hierarchical level
543 are destroyed. Their actions will therefore not be executed.
546 The C action function is interpreted by
&tool;, therefore
547 there are certain limitations in what the user can do.
548 However, the action functionality can be expanded by the
549 use of dynamic libraries. Dynamic libraries, containing user-defined functions
550 which can be called from within actions, are easily created with the help of the genapi tool.
554 <section niv='
3'
><title>Types
</title>
557 The action interpreter authorizes use of the following base types:
566 Pointers types or one dimensional arrays types based on the above type ar also recognized.
569 Additionally, any other pointer types can be specified so long as they are only used in user-defined
570 function calls (see dynamic library).
573 Static variables are authorized. They are global to all the actions.
578 <section niv='
3'
><title>Supported Operators
</title>
581 All the basic C arithmetic and logic operations are possible on the authorized interpreter types.
587 <section niv='
3'
><title>Functions
</title>
590 The interpreter can manage the following standard C functions:
594 <item> fprintf
</item>
595 <item> sprintf
</item>
604 The following built-in non standard functions are also implemented:
607 <row type=
"split"><article>FILE *avtfopen(char *name, char *extension, char mode) ....
</article>
608 <def>opens a file taking into account the global configuration file for the seek directories and compression filter. Legal values for the mode are: READ_TEXT and WRITE_TEXT
</def></row>
609 <row type=
"split"><article>int gnsModelVisited(char *model);
</article>
610 <def>Returns
1 if the given model has already been marked as visited,
0 otherwise. Used to avoid duplicating actions.
</def></row>
611 <row type=
"split"><article>void gnsMarkModelVisited(char *model);
</article>
612 <def>Marks the given model as having been visited, to avoid duplicating the action.
</def></row>
613 <row type=
"split"><article>char *char_to_string(int size, char caract);
</article>
614 <def>returns a string which length is 'size'. The string is filled with the character 'caract'.
</def></row>
615 <row type=
"split"><article>char *onehot_to_bit(int size, int bitnum);
</article>
616 <def>returns a string which length is 'size'. The string is filled with the value (
1<<bitnum) in binary format.
</def></row>
617 <row type=
"split"><article>char *onehot_to_hexa(int size, int bitnum);
</article>
618 <def>returns a string which length is 'size'. The string is filled with the value (
1<<bitnum) in hexadecimal format.
</def></row>
619 <row type=
"split"><article>char *onehot_to_octa(int size, int bitnum);
</article>
620 <def>returns a string which length is 'size'. The string is filled with the value (
1<<bitnum) in octal format.
</def></row>
621 <row type=
"split"><article>char *onecold_to_bit(int size, int bitnum);
</article>
622 <def>returns a string which length is 'size'. The string is filled with the value not(
1<<bitnum) in binary format.
</def></row>
623 <row type=
"split"><article>char *onecold_to_hexa(int size, int bitnum);
</article>
624 <def>returns a string which length is 'size'. The string is filled with the value not(
1<<bitnum) in binary hexadecimal format.
</def></row>
625 <row type=
"split"><article>char *onecold_to_octa(int size, int bitnum);
</article>
626 <def>returns a string which length is 'size'. The string is filled with the value not(
1<<bitnum) in octal format.
</def></row>
627 <row type=
"split"><article>char *genius_date();
</article>
628 <def>returns a string containing the current date and time.
</def></row>
631 Note that each of the string generation functions always returns a pointer to the same address. If you wish to keep the string over multiple calls of the same function, you will have to copy the result into another string variable.
637 <section niv='
3'
><title>Loops and conditional statements
</title>
640 Genius interpreter handle the following C loop and conditional constructs:
643 <item>for (...; ...; ...) {...}
</item>
644 <item>do {...} while (...)
</item>
645 <item>while (...) {...}
</item>
646 <item>if (...) {...} else {...}
</item>
650 The reserved words
"return" and
"break" are also supported as well as the standard function call
"exit(<errcommand>)".
656 <section niv='
3'
><title>Dynamic Libraries
</title>
659 The user can create his own dynamic library whose
660 functions can be called from within
&tool; actions.
661 To do so, he has to provide a simplified header file
662 containing the function prototypes. Global variables are not
663 allowed. The use of the tool genapi will automatically
664 generate the dynamic library from the header file and the .c files
673 <section niv='
2'
><title>The Library File
</title>
676 The library file contains a list of all the rule files and supplementary information required by the recognition module.
677 The transistor level models, the hierarchical models and the action
678 files are all referenced here.
679 The library file can also indicate built-in template recognition rules and actions to use in the recognition process.
682 Each line of the library file can have two format. The first one is for the user defined rules and actions and the second
683 one for the template instantiations:
686 <cl> <model_file
> [: [priority=
<num
>]
</cl>
687 <cl> [, keep=
<yes|no
>]
</cl>
688 <cl> [,format=
<spice|vhdl|spice_hr
>] ];
</cl>
692 The names of a model_file does not have to respect a particular format, except if the file is supposed to be a TCL script.
693 In this case the file must be interpreted by TCL the suffix must be
".tcl" else the file is considered to be VHDL or C.
694 The format directive specifies whether a transistor-level recognition rule is in SPICE or VHDL format.
695 In the case of files containing actions, the format must not be specified.
698 The priority defines the order of recognition for models.
699 Lower value means higher priority. Independent recognition rules are applied in order of specified priority. This option can be critical
700 if one model is a subset of another model.
702 <imgHsize namehtml=
"priority.gif" namepdf=
"priority.gif" hpdf=
"452pt" wpdf=
"473pt"/>
704 Finally, the
"keep" flag tells genius whether the user is
705 interested in keeping the recognized instances of a model.
706 The user is generally interested by the top level of his hierarchy
707 but he can keep other recognized instances (see also gnsKeepAllCells configuration).
708 The
<modelname
>_yagroot.
<vhd|spi
> file will contain
709 only the instances whose model keep flag have been set.
712 In the case of template instantiations, the syntax follows:
715 <cl> <model_name
> <model_instance_name
> {
</cl>
716 <cl> [ rule=
<file_spec
> ]
</cl>
717 <cl> [ rules={
<file_spec
> [, ...] } ]
</cl>
718 <cl> [ action=
<file_spec
> ]
</cl>
719 <cl> [ actions={
<file_spec
> [, ...] } ]
</cl>
720 <cl> [
<model_identifier
>=
<new_identifier
> [, ...] ]
</cl>
721 <cl> } [: [priority=
<num
>]
</cl>
722 <cl> [, keep=
<yes|no
>] ];
</cl>
726 The model_name is the name of one of the built-in templates available in the distribution or in the paths given by 'gnsTemplateDir' and 'gnsLibraryDir'
727 variables. The model name can be overridden by model_instance_name but the model_name can be used if the template is instantiated once.
730 By default, the template rules and actions will be used for the recognition but they can also be overridden by specifying a
<file_spec
>
731 which has exactly the same syntax as the user defined rule except the trailing semicolon.
732 Several files can be specified for the rules and the actions, for instance, if different architectures are spread over multiple files.
735 All the identifier
<model_identifier
> of the template rules can be renamed by
<new_identifier
> depending on the user wish.
736 This is handy to change the instance models, connector names or generic variable names in the rules.
739 Finally, an overall priority and keep flag can be specified for the instantiated model. Their meaning is the same as for the user defined
749 <section niv='
2'
><title>Symmetry and Coupling
</title>
752 Due to the nature of bottom up recognition, any symmetry in the identified components can cause recognition difficulties which are not immediately obvious. Cells are identified at a particular hierarchical level without knowing how they will be connected in the higher level. Because of this,
&tool; cannot guarantee the precise ordering of any symmetric cell connectors. In the example below representing the memory cell, the connectors q and nq are symmetric. This means that from the perspective of the individual cell there is nothing to distinguish between these two connectors. When performing the recognition of the memory cell, There is nothing to prevent the memory cell being recognized the other way round to that which the user would have expected.
754 <imgHsize namehtml=
"coupl_sym.gif" namepdf=
"coupl_sym.gif" hpdf=
"314pt" wpdf=
"395pt" />
756 The user must pay careful attention to any possible symmetry in the models to recognize. For example, if the user wants to recognize a column of memory cells connected in parallel, he would provide a rule to identify an arbitrary number of memory cells with the q ports connected together and the qn ports connected together. However, if q and qn ports are symmetric then q ports may be connected to qn ports and vice versa but nonetheless corresponding to a column of memory cells.
759 The case of symmetry also occurs often when dealing with vectors. A user may require the identification of two instances connected together by vectored ports. However, the signal connected to bit(
0) of one of the ports is not necessarily the signal connected to bit(
0) of the other port. The order of the indexing of the vectored ports depend on the order of the recognition algorithm.
762 To cope with this problem of symmetry,
&tool; provides for a mechanism of pragma directives included as comments in the model files. Each pragma directive consists of the list of symmetric connectors. The connectors can be single connectors or the radical of a vectored connector. Use of the radical of a vector implies that all the connectors of the vector are symmetric to each other. Each group of symmetric connectors must be declared in a unique pragma.
765 In VHDL rules, the pragma is declared in the model entity after the port declarations as follows:
767 <code> -- pragma symmetric [
<single_connector
>|
<connector_radical]+
</code>
769 In SPICE, for symmetric connector in transistor-level cells, the pragma can be placed anywhere as follows:
771 <code>* pragma symmetric [
<single_connector
>|
<connector_radical]+
</code>
773 With symmetry comes the additional difficulty of coupled symmetry. When
&tool; tries to match together recognized instances with symmetric connectors and the initial match fails, it only knows that there are connectors which can be swapped. It will then try to swap around the symmetric connectors until a match is found. In reality, the symmetry handling is more efficient than this, but that's the basic idea.
776 In the above example of a column multiplexer, there are
2 sets of symmetric connectors:
779 <item>i0 is symmetric with i1
</item>
780 <item>a0 is symmetric with a1
</item>
783 In the example i0 depends on a0 and i1 depends on a1. It's obvious that if i0 and i1 are swapped, a0 and a1 must also be swapped. a0 is effectively coupled with i0 and a1 is coupled with i1. If the coupling dependencies are not explicitly stated,
&tool; may swap the connectors in one of the symmetric sets but not the other, thus corrupting the connectivity of the recognized instance.
786 The user must therefore also be careful about the coupled symmetric connectors in a model else
&tool; will be able be match instances for which the connectivity described by the rule is not respected.
789 In the same way as for standard symmetric connectors, pragma directives must be used to define the couplings:
792 In VHDL rules, the pragma is declared in the model entity after the port declarations as follows:
794 <code> -- pragma coupled [
<single_connector
>|
<connector_radical]+
</code>
796 In SPICE, for symmetric connector in transistor-level cells, the pragma can be placed anywhere as follows:
798 <code> * pragma coupled [
<single_connector
>|
<connector_radical]+
</code>
800 The entity declaration for the multiplexer would therefore be as follows:
803 <cl>ENTITY mux IS
</cl>
805 <cl> i0, i1: INOUT BIT;
</cl>
806 <cl> a0, a1: INOUT BIT
</cl>
808 <cl>-- pragma symmetric i0 i1
</cl>
809 <cl>-- pragma symmetric a0 a1
</cl>
810 <cl>-- pragma coupled i0 a0
</cl>
811 <cl>-- pragma coupled i1 a1
</cl>
815 The user should be aware that symmetric connector imposes a restriction on how the rules can be written. If a particular rule contains a loop instantiation (of the special kind which determines the value of a generic) and the instances in the loop are connected together by symmetric connectors, then is not possible, in the same rule, to connect these connectors to anything outside the loop apart from a set of symmetric connectors.
818 This is not actually a restriction on what can be recognized since structures which require this kind of description can always be handled by introducing an additional rule hierarchy.
824 <section niv='
2'
><title>Other PRAGMAs
</title>
826 <code> -- pragma without
<name0
> [
<name1]*
</code>
828 Matches the hierarchical recognition rule only in no correspondance is found for the given instances or transistors.
830 <code> -- pragma exclude
<name0
> [
<name1]*
</code>
832 After the each recognition of the rule, the given instances are put back in the available instance list so they can be used again in the recognition rules (even the current one). This permits sharing of instances/transistors between rules.
834 <code> -- pragma exclude_at_end
<name0
> [
<name1]*
</code>
836 The same as
"exclude" but the given instances can not be reused by the current rule. They will be available for the next ones.
838 <code> -- pragma forcematch
<name0
> [
<name1]*
</code>
840 The given names apply to transistor, instances and net names. This option, will match the names in the rule if they are in the given list. Name match for instances won't work for GNS recognized instances as their name is automatically generated. Instead blackboxed instances can use this option. If '_' is used in a given name, it can be matched with a hierarchy separator. eg. circuit blackbox instance xlevel.xcells will be matched by xlevel_cells.
842 <code> -- pragma unused
<name0
> [
<name1]*
</code>
844 Each connector in the given list is unused meaning there is no real correspondance to them in the netlist.
projects / tas-yagle.git / blob