![\begin{pespace}\nopagebreak[3]\begin{tabular}{l l l}
{\verb\vert<logic-gate>\ver...
...straint>\vert} & {\verb\vert<delay-constraint>\vert}
\end{tabular}\end{pespace}](img2.gif)
Each command is described in the following sections.
University of California
Berkeley
The goal of BLIF is to describe a logic-level hierarchical circuit in textual form. A circuit is an arbitrary combinational or sequential network of logic functions. A circuit can be viewed as a directed graph of combinational logic nodes and sequential logic elements. Each node has a two-level, single-output logic function associated with it. Each feedback loop must contain at least one latch. Each net (or signal) has only a single driver, and either the signal or the gate which drives the signal can be named without ambiguity.
In the following, angle-brackets surround nonterminals, and square-brackets surround optional constructs.
A model is a flattened hierarchical circuit. A BLIF file can contain many
models and references to models described in other BLIF files. A model is
declared as follows:
Each command is described in the following sections.
The BLIF parser allows the .model, .inputs, .outputs, .clock and .end statements to be optional. If .model is not specified, the decl-model-name is assigned the name of the BLIF file being read. It is an error to use the same string for decl-model-name in more than one model. If .inputs is not specified, it can be inferred from the signals which are not the outputs of any other logic block. Similarly, .outputs can be inferred from the signals which are not the inputs to any other blocks. If any .inputs or .outputs are given, no inference is made; a node that is not an output and does not fanout produces a warning message.
If .clock is not specified (e.g., for purely combinational circuits) there are no clocks. .end is implied at end of file or upon encountering another .model.
Important: the first model encountered in the main BLIF file is the one returned to the user. The only .clock, clock-constraint, and timing-constraint constructs retained are the ones in the first model. All subsequent models can be incorporated into the first model using the model-reference construct.
Anywhere in the file a `#' (hash) begins a comment that extends to
the end of the current line.
Note that the character `#' cannot be used in any signal names.
A `\' (backslash) as the last character
of a non-comment line indicates concatenation of the subsequent line to the
current line. No whitespace should follow the `\'.
Example:
Both models ``simple'' and the unnamed model describe the same circuit.
A logic-gate associates a logic function with a signal in the model,
which can be used as an input to other logic functions. A logic-gate
is declared as follows:
A sample logic-gate with its single-output-cover:
In a given row of the single-output-cover, ``1'' means the input is used in uncomplemented form, ``0'' means the input is complemented, and ``-'' means not used. Elements of a row are ANDed together, and then all rows are ORed.
As a result, if the last column (the ``output plane'') of the single-output-cover is all 1's, the first n columns (the ``input plane'') of the single-output-cover can be viewed as the truth table for the logic gate named by the string output. The order of the inputs in the single-output-cover is the same as the order of the strings in-1, in-2, ..., in-n in the .names line. A space between the columns of the ``input plane'' and the ``output plane'' is required.
The translation of the above sample logic-gate into a sum-of-products
notation would be as follows:
To assign the constant ``0'' to some logic gate j, use the
following construct:
To assign the constant ``1'', use the following:
The string output can be used as the input to another logic-gate before the logic-gate for output is itself defined.
For a more complete description of the PLA input format, see espresso(5).
External don't cares are specified as a separate network within a model, and are specified at the end of the model specification. Each external don't care function, which is specified by a .names construct, must be associated with a primary output of the main model and specified as a function of the primary inputs of the main model (hierarchical specification of external don't cares is currently not supported).
The external don't cares are specified as follows:
The following is an example circuit with external don't cares:
The translation of the above example into a sum-of-products
notation would be as follows:
A generic-latch is used to create a delay element in a model. It represents one bit of memory or state information. The generic-latch construct can be used to create any type of latch or flip-flop (see also the library-gate section). A generic-latch is declared as follows:
If a latch does not have a controlling clock specified, it is assumed that it is actually controlled by a single global clock. The behavior of this global clock may be interpreted differently by the various algorithms that may manipulate the model after the model has been read in. Therefore, the user should be aware of these varying interpretations if latches are specified with no controlling clocks.
Important: All feedback loops in a model must go through a generic-latch. Purely combinational-logic cycles are not allowed.
Examples:
A library-gate creates an instance of a technology-dependent logic gate and associates it with a node that represents the output of the logic gate. The logic function of the gate and its known technology dependent delays, drives, etc. are stored with the library-gate. A library-gate is one of the following:
All of the formal parameters of name must be specified in the formal-actual-list and the single output of name must be the last one in the list.
A .gate refers to a two-level representation of an arbitrary input, single output gate in a library. A .gate appears under a technology-independent interpretation as if it were a single logic-gate.
A .mlatch refers to a latch (not necessarily a D flip flop) in a library. A .mlatch appears under a technology-independent interpretation as if it were a single generic-latch and possibly a single logic-gate feeding the data input of that generic-latch.
.gates and .mlatches are used to describe circuits that have been implemented using a specific library of standard logic functions and their technology-dependent properties. The library of library-gates must be read in before a BLIF file containing .gate or .mlatch constructs is read in.
The string name refers to a particular gate or latch in the library.
The names ``nand2,''
``inv,'' and ``jk_rising_edge'' in the following examples are
descriptive names for gates in the library. The following BLIF description:
could also be specified in a technology-independent way (assuming ``nand2''
is a 2-input NAND gate and ``inv'' is an INVERTER) as follows:
Similarly:
could have been specified in a technology-independent way (assuming
``jk_rising_edge'' is a JK rising-edge-triggered flip flop) as follows:
A model-reference is used to insert the logic functions of one model
into the body of another. It is defined as follows:
A .subckt construct can be viewed as creating a copy of the logic functions of the called model model-name, including all of model-name's generic-latches, in the calling model. The hierarchical nature of the BLIF description of the model does not have to be preserved. Subcircuits can be nested, but cannot be self-referential or create a cyclic dependency.
Unlike a library-gate, a model-reference is not limited to one output.
The formals need not be specified in the same order as they are defined in the decl-input-list, decl-output-list, or decl-clock-list; elements of the lists can be intermingled in any order, provided the names are given correctly. Warning messages are printed if elements of the decl-input-list or decl-clock-list are not driven by an actual parameter or if elements of the decl-output-list do not fan out to an actual parameter. Elements of the decl-clock-list and decl-input-list may be driven by any logic function of the calling model.
Example: rather than rewriting the entire BLIF description for a commonly
used subcircuit several times, the subcircuit can be described once and
called as many times as necessary:
A subfile-reference directs the BLIF reader to read in and define all the models in file file-name. A subfile-reference does not have to be inside of a .model. subfile-references can be nested.
Search files would usually be used to hold all the subcircuits referred to in model-references, while the master file merely searches all the subfiles and instantiates all the subcircuits it needs.
A subfile-reference is not equivalent to including the body of subfile file-name in the current file. It does not patch fragments of BLIF into the current file; it pauses reading the current file, reads file-name as an independent, self-contained file, then returns to reading the current file.
The first .model in the master file is always the one returned to the user, regardless of any subfile-references than may precede it.
A sequential circuit can be specified in BLIF logic form, as a finite
state machine, or both. An fsm-description is used to insert a finite
state machine description of the current model. It is intended to represent
the same sequential circuit as the current model (which contains logic), but
in FSM form. The format of an fsm-description is:
<input>
<current-state> <next-state>
<output>'' 4-tuples that follow in the FSM description.
<current-state>'' and ``<next-state>''
columns.
<current-state>''
column.
num-terms and num-states do not have to be specified. If the
reset-state is not given, it is assigned to be the first state
encountered in the ``<current-state>'' column.
The ordering of the bits in the input and output fields will be the same as the ordering of the variables in the .inputs and .outputs constructs if both an fsm-description and logic functions are given.
latch-order-list and code-mapping are meant to be used when both
an fsm-description and a logical description of the model are given.
The two constructs together provide a correspondence between the latches in
the logical description and the state variables in the fsm-description. In a code-mapping, symbolic-name consists of
a symbolic name from the ``<current-state>'' or
``<next-state>'' columns, and encoded-name is the
pattern of bits ({0, 1}) that represent the state encoding for symbolic-name. The code-mapping should only be given if both an fsm-description and logic functions are given. .latch-order
establishes a mapping between the bits of the encoded-names of the
code-mapping construct and the latches of the network. The order of
the bits in the encoded names will be the same as the order of the latch
outputs in the latch-order-list. There should be the same number of
bits in the encoded-name as there are latches if both an fsm-description and a logical description are specified.
If both logic-gates and an fsm-description of the model are given, the logic-gate description of the model should be consistent with the fsm-description, that is, they should describe the same circuit. If they are not consistent there will be no sensible way to interpret the model, which should then cause an error to be returned.
If only the fsm-description of the network is given, it may be run through a state assignment routine and given a logic implementation. A sole fsm-description, having no logic implementation, cannot be inserted into another model by a model-reference; the state assigned network, or a network containing both logic-gates and an fsm-description can.
Example of an fsm-description:
Above example with a consistent fsm-description and logical
description:
A clock-constraint is used to set up the behavior of the simulated
clocks, and to specify how clock events (rising or falling edges) occur
relative to one another. A clock-constraint is one or more of the
following:
% of the cycle-time. In the
unparenthesized form for the clock-event, before and after
are assumed ``0.0.''
All events, event-1 ... event-n, specified in a single .clock_event are to be linked together. A routine changing any one edge should also modify the occurrence time of all the related clock edges.
Example 1:
Example 2:
Both examples specify a nominal time of 50% of the cycle time, that
the rising edge of clock1 must occur at exactly the nominal time, and that
the falling edge of clock2 may occur from 2.0 units before to 5.0 units
after the nominal time.
In Example 1, if r'clock1 is later moved to a different nominal time by some routine then f'clock2 should also be changed. However, in Example 2 changing r'clock1 would not affect f'clock2 even though they originally have the same value of event-percent.
A delay-constraint is used to specify parameters to more accurately
compute the amount of time signals take to propagate from one point to
another in a model. A delay-constraint is one or more of :
There is no actual unit for all the timing and load numbers. Special attention should be given when specifying and interpreting the values. The timing numbers are assumed to be in the same ``unit'' as the cycle-time in the .cycle construct.
This document was generated using the LaTeX2HTML translator Version 2002 (1.62)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 -nonavigation -image_type gif blif
The translation was initiated by CS4861 Class Account on 2004-04-05