| |
|
|
   Next: Semantics Up: BLIF-MV Previous: BLIF-MV
Syntax
ModelsA model is a system that can be used in defining a hierarchical system. Any BLIF-MV file contains one or more model definitions. If there is more than one model definition, one model is specified as the root model by putting the .root construct in the next line of the .model declaration. An entire hierarchy is created from this model recursively. If no model is declared as the root model, the first model serves as the root mode. The .root construct can optionally have an argument, which specifies the instance name of the root node. If no argument is used, the instance name is the same as the model name. A model is declared as follows:
.model <model-name> .inputs <input-list> .outputs <output-list> <command> ... <command> .end
Multi-valued Variables
A multi-valued variable is a variable that can take
a finite number of values.
There are two classes of multi-valued variables.
The class of enumerative variables
are variables whose domain is the
.mv <variable-name-list> <number-of-values>
The second class, symbolic variables, is more general than the first one. A symbolic variable can take a set of arbitrary values. For example, a variable that takes three values red, green, and blue is a symbolic variable. Symbolic variables are declared as follows.
.mv <variable-name-list> <number-of-values> <value-list>
If a variable is not defined using .mv in a model, then the variable is assumed to be a Boolean variable. Two variables are said to have the same type if
.mv x 2 .mv y 2 red blue  and  are not of the same type because
is an enumerative variable and is a symbolic variable
although both are two-valued variables.
.mv x 2 red blue .mv y 2 blue red and in the above example are not of the same type
because symbolic values are defined in different orders.
TablesA table is an abstract representation of a physical gate. A table is driven by inputs and generates outputs following its functionality. Although a real gate generates an output deterministically depending on what inputs are supplied, tables in BLIF-MV can represent non-deterministic behaviors as well. The functionality of the table is described as a symbolic relation, i.e. the table enumerates symbolically all the valid combination of values among the inputs and the outputs. Note that BLIF-MV can handle multi-output tables, unlike BLIF, where every table is single-output. A table without input represents a constant generator. If the table allows more than one value for its output, then the table is a nondeterministic constant generator, which we call pseudo input. Tables are declared in the following way.
.table <in-1> <in-2> ... <in-n> -> <out-1> <out-2>... <out-m> <relation> ... <relation>
A relation is a white-space separated non-null list of
Let
If a variable is a symbolic variable, the range construct in the above cannot be used since {red-green}, for example, does not make sense. Let us consider the following example.
.mv x,y 4
.table x -> y
!2 {1-3}
- 0
2 (0,3)
The relation specified in this table is:
= Construct
One can also use the = construct
in table specifications.
Assume that in the column
corresponding to variable
.table x -> y - =x
The interpretation of this construct is that
the value of .mv select 2 .mv data0,data1,output 256 .table select data0 data1 -> output 0 - - =data0 1 - - =data1Note that two variables related with the = construct should be of the same type. Any variable referred to with the = construct must be an input of the table.
Default Output
It is sometimes convenient to define
a default output for the input patterns
not specified in a given relation.
The .default construct is used for this purpose.
In the following example,
no relation is specified for the case where either
.mv x1,x2,y1,y2 2 .table x1 x2 -> y1 y2 .default 0 0 1 1 1 1 The .default construct can be used even for tables without inputs. However, one has to be careful about the semantics. There are two possible cases. One case is that a table has a default declaration, but has no relation specified, where the interpretation of the table is that it always takes the default. The other case is that a table has both a default declaration and a non-null relation specified, then the default can be simply ignored.
Latches and Reset TablesA latch is a storage element which updates its stored value at every clock tick. A latch has an input and an output. At each clock tick the latch output is set to the latch input value before the tick, and keep the value till the next clock tick. Every latch has to be initialized although the latch is allowed to have more than one initial value, in which case the latch takes an initial value nondeterministically from the specified values. A latch can be seen as a multi-valued flip-flop with possibly multiple initial states. In BLIF-MV, there is an implicit assumption that the whole system is clocked by a single global clock although the clock is never declared in BLIF-MV declarations. A latch is declared as follows.
.latch <latch-input> <latch-output> latch input and latch output are strings, giving the name of the latch input and the latch output. The two variables should be of the same type. A latch must have one reset table, which is used to initialize the latch output at the beginning. A reset table is a single output table whose only output is the output of a latch. Notice that we use .reset instead of .table for reset tables. If a latch is reset to a constant value, then the latch table has no input. The following example is for the latch latch_output whose reset state is 0.
.reset latch_output 0 One can specify multiple initial states by specifying more than one value in the latch output. Adding one more line to the above example, the latch has now two initial states.
.reset latch_output 0 1
This is one way to introduce non-determinism in system descriptions.
Also, one could create complex reset circuitry sensitive to
other variables by introducing inputs to the latch table.
The following .reset statement
initializes the latch to 1 if
.reset x latch_output 0 1 1 0
SubcircuitsIn a model, another model can be instantiated as a subcircuit using the .subckt construct.
.subckt <model-name> <instance-name> <formal-actual-list> This construct instantiates a reference model model-name as an instance instance-name in the current model. formal-actual-list specifies the association between each formal variable in model-name and its corresponding actual variable in the current model. Formal variables are declared in the reference model, while actual variables are variables declared in the current model. formal-actual-list is a list of assignments separated by a white space. The declaration of formal-actual-list is of form:
formal-1 = actual-1 formal-2 = actual-2 ... formal-n = actual-n The order of formal variables is unimportant.
Miscellaneous Features
CommentsAny line starting from # is a comment. It is ignored by the parser.
Including FilesThe .include construct can be used to include another file from a file being read. The syntax is .include fileName.
Old SyntaxPreviously, the three constructs .table, .default, .reset were called .names, .def, .r respectively. The read_blif_mv command in VIS supports these old constructs as well.
Next: Semantics Up: BLIF-MV Previous: BLIF-MV
Stephen Anthony Edwards Fri Nov 22 19:07:27 PST 1996 |
| Contact |
| ©2002-2018 U.C. Regents |
integers
.
Note that Boolean variables are enumerative variables where 
.
Enumerative variables
are declared as follows.
strings,
giving a valid combination of values among inputs and outputs.
The 
-th string in a relation specifies a set of values for the 
, or
, which is the universe, or
, or
, where 
(
) is a set of values, or
, which is a complement of a set of values 
.
.
as in the following example.
or 
is 0.
Since we have a default statement in the table,
output 00 is related for those unspecified input patterns.
Therefore, the relation of this table is:
.
Each table can have at most one .default declaration.