University of Portland
School of Engineering
5000 N. Willamette Blvd.
Portland, OR 97203-5798
Phone 503 943 7314
Fax 503 943 7316
Theory of Operations
Project BAT: B2 Logic to ABEL
Translator
Contributors:
Jamie Quint
Ian Tagge
Approvals
Name
√
Dr. Vegdahl
Date
2/23/07
Name
√
Dr. Lillevik
Date
2/23/07
Insert checkmark (√) next to name when approved.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
.
Revision History
.
.
Rev.
Date.
0.1
12/03/06 .
THEORY OF OPERATIONS
PROJECT BAT
0.9
0.95
1.0
1.0a
1.1
02/08/07
02/18/07
02/22/07
02/23/07
04/17/07
UNIVERSITY OF PORTLAND
REV. 1.0
PAGE II
Author
J. Quint
I. Tagge
I. Tagge
I. Tagge
I. Tagge
J. Quint
Reason for Changes
Initial Draft
0.9 Release
0.95 Release
1.0 Release
1.0a Release
1.1 Release
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
.
Table of Contents
.
.
Summary.......................................................................................................................
1
.
.
Introduction ..................................................................................................................
2
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE III
Background .................................................................................................................. 3
Architecture .................................................................................................................. 4
Architectural Style....................................................................................................................................4
General Description ................................................................................................................................4
Technologies ...........................................................................................................................................4
B2 Logic 3.1 ......................................................................................................................................4
ABEL 7.0...........................................................................................................................................5
Ruby..................................................................................................................................................5
Design Overview.......................................................................................................... 6
System Block Diagrams..........................................................................................................................6
Parser Component ..................................................................................................................................7
Connection List Component ...................................................................................................................9
Component Integration ........................................................................................................................ 10
Conclusions ...............................................................................................................11
Appendices.................................................................................................................12
Appendix A: Development Process .................................................................................................... 12
Appendix B: Use Case: File Conversion............................................................................................. 12
Appendix C: Architectural Style and Component Specification ......................................................... 14
Appendix D: Library Function Details .................................................................................................. 15
Appendix E: Parser UML ..................................................................................................................... 19
Appendix F: BAT Processing Narrative .............................................. Error! Bookmark not defined.
Appendix G: EDF BNF......................................................................................................................... 20
Appendix H: ABEL BNF ....................................................................................................................... 22
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
Appendix I: Data Flow Diagrams ......................................................................................................... 23
.
.
Appendix J: Inheritance Hierarchy ...................................................................................................... 24
.
.
Appendix K: Design Examples
............................................................................................................ 26
.
THEORY OF OPERATIONS
PROJECT BAT
UNIVERSITY OF PORTLAND
REV. 1.0
SCHOOL OF ENGINEERING
PAGE IV
CONTACT: I. TAGGE
.
.
.
.
List of Figures.
.
. Diagram – Project BAT. ............................... Error! Bookmark not defined.
Figure 1. Level 0 Data Flow
.
Figure 2. System Block Diagram
. of BAT Product ..................................... Error! Bookmark not defined.
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE V
Figure 3. Detailed Block Diagram of BAT Product. ................................... Error! Bookmark not defined.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
THEORY OF OPERATIONS
PROJECT BAT
Chapter
1
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 1
Summary
Project BAT uses a data flow architectural model. This implementation can be broken
down into two main components: a parser, and a connection list. The parser receives input
in the form an EDF file and parses it into the connection list data structure, which is
composed of the Inst and Port classes.
The parser extracts meaningful data from the EDF netlist according to known keywords
and structure within the file. Each component in the circuit is identified, and a new object
of class Inst is created corresponding the to type of the component. Each component also
has a preset number of pins, each of which are created as Port objects. These are
created at the time of each Inst creation. Next, the parser reads through the netlists
themselves to identify connections between each pin and create the corresponding
connections between the Port objects. Upon successful parsing, ABEL code is written to
a buffer for each component, describing the logic it represents within the circuit. Finally the
ABEL code is written to a file if no errors occurred during processing.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
THEORY OF OPERATIONS
PROJECT BAT
Chapter
2
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 2
Introduction
This document specifies the operational details of Project BAT. Its primary purpose is to
explain the system architecture and implementation in detail, providing a full explanation of
how the product functions at the component level. It is intended for other members of the
design team or those who desire to extend the product or integrate it into other systems.
After reading this document, the reader should have a full understanding of the program
architecture, its components, and how those components function. It is not intended to be
used as a manual or tool for gaining a high-level understanding of BAT.
This document explores BAT’s implementation throughout two main sections: Chapter 4,
Architecture, and Chapter 5, Design Overview.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
THEORY OF OPERATIONS
PROJECT BAT
Chapter
3
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 3
Background
Project BAT is a B2 Logic-to-ABEL translator. It facilitates the design-to-production function
of integrated circuits (ICs) by allowing the conversion of a visual schematic to ABEL
hardware description language (HDL) code. (See Appendix B for an in depth description
of program functionality.)
The intended user of this software is any user of the B2 Logic design program who wants
to translate their design into HDL code, most likely electrical engineering students;
however, professionals may find this product useful as well. The user benefits by saving
the time normally required to complete this process by hand.
The long-term purpose of this project is to allow B2 Logic circuit schematics to be
completely translatable to ABEL for all chips that ABEL can program. This allows the enduser to complete the entire design function in B2 Logic and subsequently use the
translation application to generate the HDL code, which can be opened in ABEL.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
THEORY OF OPERATIONS
PROJECT BAT
Chapter
4
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 4
Architecture
This Chapter describes the architectural foundation of the Project BAT design and
provides a high level overview of the design.
Architectural Style
Project BAT implements a data flow architectural model. It takes data from an input and
pipes it through filters to produce a different type of data as output.
General Description
Figure 1 describes the data flow for Project BAT. This is a high level overview, which is further
described in later sections of this document.
Figure 1. Level 0 Data Flow Diagram – Project BAT.
Technologies
B2 Logic 3.1
B2 Logic is a powerful tool for designing and testing schematics for digital logic circuits in a
visual environment. It provides the ability to export designs in the form of an EDF netlist file.
(See Appendix G for a full description of the EDF input syntax.) This is the file type that Project
BAT uses as input.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
ABEL 7.0
.
. for Advanced Boolean Expression Language, is a hardware design
ABEL, an acronym
.whose code can be tested and output in a format that can be converted
language (HDL) .
directly to an integrated circuit (IC). It supports both concurrent equation and truth table logic
.
formats, as well a sequential state machine description format. (Proper ABEL syntax can be
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 5
found in Appendix H.)
Ruby
Ruby is a reflective, object-oriented programming language. It combines syntax inspired by
Perl with Smalltalk-like object-oriented features. It is a single-pass interpreted language. It was
chosen for the purposes of this project because it supports Perl compatible regular
expressions while also being fully object oriented.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
THEORY OF OPERATIONS
PROJECT BAT
Chapter
5
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 6
Design Overview
This chapter describes how the architecture of Project BAT functions on a component
level. It begins with a high-level system block diagram and explains how it is broken into
components, then provides technical details on how each component is implemented.
System Block Diagrams
Error! Reference source not found. is a general overview of the system from a dataflow
standpoint and describes the inputs and outputs of the system from an external
standpoint.
Figure 2. System Block Diagram of BAT Product
Error! Reference source not found. is a more detailed version of Error! Reference
source not found. where the BAT block has been expanded to show the data flow within
the program itself. The "Parser" step takes the input EDF file and converts it into a data
structure in a form that is easy to manipulate. This data structure is known as our
"Connection List". These connections are then processed through the "Library Functions"
which are coded methods of the Inst class which output ABEL compatible HDL code. An
overview of the program architecture from a data flow view can be found in Appendix I.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
Each of the parts described in Error! Reference source not found. is a primary
.
component of Project BAT, these are described in further detail below.
.
.
.
.
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 7
Figure 3. Detailed Block Diagram of BAT Product.
Parser Component
The parser takes the EDF input file and first reads it into an array, where each line is an
element in the array. Each line in the array is searched to find the word "interface" which
determines the beginning of the relevant part of the EDF file. The line number for this is
then stored in a @startline variable. The array continues to be searched until the line
containing "design root" is found. This indicates the end of the relevant part of the EDF file
and its line number, minus two to account for a zero-based array and the fact that this
current line should be omitted from the relevant portion of the array, is stored in an
@endline variable.
Next, using the start and end variables that are set to determine the appropriate start and
end points, the parser truncates the array to contain only the line elements that are
important to BAT's functionality. The parser then iterates through the truncated array
looking for keywords that indicate the line is the beginning of a relevant portion of code,
these keyword identifiers are "(port ", "(instance ", and "(net ."
When one of these identifiers is found, the parser checks that line for matching
parentheses (meaning there are the same number of right parentheses as left
parentheses), if the line is found to have matching parentheses the parser places it as an
element in a new array "valid_edf." If the line does not have matching parentheses, the
parser concatenates the next line in the array to the string and checks it again. This
continues until the parentheses match, or the parser reaches the end of the array. Once a
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
full set of matching parentheses is found the concatenated lines are stored as a single
.
element in the array. At the end of this process, the "valid_edf" array contains one element
.
for each important keyword in the EDF document.
.
For example .
.(Truncated List):
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 8
(port In0 (direction input))
(instance INST4(viewRef viewnamedefault(cellRef DFFPC)))
(net Net9(joined(portRef P0 (instanceRef INST7))(portRef P1 (instanceRef INST8))))
The parser then iterates through the "valid_edf" array looking for keyword identifiers.
When "(port " is found, the parser looks for a number before "(direction", if one is found the
parser stores the number in the variable and then looks for the input/output identifier found
after "direction." The parser then gets the port identifier found after the "(port " keyword
and then loops with the number found earlier to create Inst objects with the name being a
concatenation of the port identifier and member number (all lowercase) and the type being
the type identified by the input/output identifier.
For example:
(port In0 3(direction input))
For this input (named In0 with three members), the parser would create Inst objects of
type "input" (by instantiating a new Input object, a subclass of class Inst) named
in0m0, in0m1, and in0m2.
If there is not a number found before "(direction" the parser simply creates an Inst of
the type defined by the input/output identifier with the name of the port identifier.
For example:
(port In1 (direction input))
For this input (named In1 with no members), the parser would create an Inst object of
type "input" (by instantiating a new Input object, a subclass of class Inst) named in1.
When "(instance " is found by the parser, it performs the same action as if a "(port "
keyword. However in this instance, it looks for the type identifier after "(cellRef" instead of
after "(direction."
For example:
(instance INST4(viewRef viewnamedefault(cellRef DFFPC)))
For this input (named INST4 of type DFFPC), the parser would create an Inst object
of type "dffpc" (by instantiating a new Dffpc object, a subclass of class Inst)
When "(net " is found the parser passes the first full set of parentheses after the "(joined"
keyword to a method which converts it to its port name.
For Example:
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
(net Net3(joined(portRef P0 (instanceRef INST4))(portRef Set)))
.
.
The parser passes (portRef P0 (instanceRef INST4)) to a method which returns
inst4p0. .
.
. then continues to pass in matching sets of parentheses to the port-nameThe parser
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 9
generating method, this continues until no more matching parentheses are found,
signifying the end of a net. These port names are returned in an array to the parser
and are iterated through by checking their types. Two subarrays are created, one for
input ports and one for output ports, then each port name is split into its Inst name and
port identifying component. Until the list of port names is exhausted, the first item in
the output port array is cross connected with each of the items in the input port array
by calling the add_connection method in each direction to associate the parts.
Library Functions Component
The library functions component is responsible for generating the final program output.
Once the EDF file processing has been completed by the parser (and the connection list
component concurrently created), the library functions component goes through a series
of loops outputting the final ABEL code to the output file. There are six steps:
1. Write ABEL Header.
2. Iterate through Inst objects, calling the input accessor method and writing the data to
the output file.
3. Iterate through Inst objects, calling the output accessor method and writing the data to
the output file.
4. Iterate through Inst objects, calling the nodes accessor method and writing the data to
the output file.
5. Iterate through Inst objects, calling the abelout method and writing the data to the
output file.
6. Write ABEL Closer.
Connection List Component
The connection list component is a data structure that represents the information in the
EDF file. It is composed of the Inst and Port objects. The data structure includes cyclic
references, and is therefore a graph representation in its final form (after parsing is
complete). The connection list relies on the parser to find tokens in the input EDF file to
generate connection list data. (See Appendix E for a further description of how this data is
to be organized, and Appendix C for component test cases.) It also is responsible for
providing the “library functions,” methods contained within each subclass object of the Inst
superclass which produce ABEL HDL compatible code. Each object of the Inst class
contains several methods which allow for this connectivity, an Inst object is able to
determine the connections it has on any given port and store its name, and type. Port
objects store a list of other ports they are connected to, as well as knowing their own name
and type. (See Appendix E)
The connection list component’s primary purpose is to facilitate the production of ABEL
code. There are four distinct sections of ABEL output: inputs, outputs, nodes, and
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
equations. Each Inst object contains a string that holds the value for that object’s ABEL
.
data for inputs, outputs, or nodes. This data is stored as a string and is empty if that
particular Inst.object does not have a value for input, output, or node. There are also
. accessor methods on each Inst which allow it to return this data to the
corresponding
. object also has a method called abelout which queries its own
caller. Each Inst
connections and
. returns the appropriate ABEL code in string form to the caller based on
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 10
this data.
Component Integration
The parser and the connection list components are tightly integrated. Using the
capabilities Ruby possesses as a reflective language, the connection list component is
actually built while parsing occurs. Integration is accomplished simply by calling necessary
methods to build the connection list component while parsing is occurring.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
THEORY OF OPERATIONS
PROJECT BAT
Chapter
6
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 11
Conclusions
Project BAT has been designed to create a product that is well defined and
understandable. This design produces code that is easily maintainable and extensible to
those who might wish to modify it in the future.
Future work on BAT may include extending its functionality to handle a larger library of B2
Logic components. This could be done by simply adding more definitions to the Inst class,
as well as modifying the parser to recognize the new components. BAT could also be
modified to output a variety of hardware description languages or optimize the resulting
HDL for specific CPLC architectures.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
THEORY OF OPERATIONS
PROJECT BAT
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 12
Appendices
The appendices include extended and in-depth discussions and descriptions of various
parts of BAT.
Appendix A: Development Process
A Test Driven Development strategy was used, writing unit tests and code in parallel
whenever possible. The overall development process described here is also depicted in
Figure A.1 below. The Parser/Connection List is initially tested in standalone fashion
using the methods described in Appendix C. Once the Parser/Connection List part is
complete, integration with the Library Functions begins. (This functions as described in the
Processing Narrative) Finally, the integrated program is tested with functional tests, before
it is tested using actual designs to confirm full expected functionality.
Figure A. 1 – Development Process Diagram
Appendix B: Use Case: File Conversion
Primary Actor: Electrical Engineer.
Goals: To convert an EDF file to ABEL HDL code.
Preconditions: Engineer has completed design of a digital logic circuit in B2 Logic and
desires to implement this design on an integrated circuit. Engineer has terminal window
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
open on a system which has the BAT program installed and is at a blank command
.
prompt.
.
Trigger: The.engineer decides to convert EDF file exported from B2 Logic to ABEL HDL
.
code.
.
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 13
Scenario:
1. Engineer: activates the BAT program by typing in the command "bat chip inputfilepath"
where inputfilepath is a complete file path to the desired input file or a file in the current
working directory. Chip represents the type of chip to be programmed.
2. Engineer: observes success message indicating the inputted file has been successfully
converted and outputted.
Exceptions:
1. No chip/input/output name given (program returns error message indicating correct
program syntax): engineer repeats scenario with proper inputs.
2. Invalid chip name given (program returns a list of compatible chip names): engineer
repeats scenario with a valid chip name.
3. Output file name already exists (program prompts user to overwrite): engineer chooses
to overwrite file, or renames existing file and repeats scenario.
4. Not enough disk space to output file (program returns error message indicating lack of
disk space): engineer deletes files to make space and then repeats scenario.
5. No permissions to write given output file or read given input file (program returns error
message indicating lack of permissions): engineer acquires appropriate permissions or
selects input and output files for which he or she has proper permissions and repeats
scenario.
6. No inputs given (program returns error message indicating correct program syntax):
engineer repeats scenario with proper inputs.
7. Unreadable or corrupted input file (program returns error message indicating input file is
unreadable): engineer repeats scenario with compatible file.
8. Input file does not exist (program returns error message indicating input file cannot be
found): engineer repeats scenario with an existing file.
9. Too many arguments given (program returns error message indicating too many
arguments were given and that the program does not support multiple file conversions at
one time): engineer repeats scenario with proper number of file arguments.
Priority: Essential
When Available: First Version
Frequency of Use: Irregularly Frequent (may not be used for months at a time, but may
be used many times in a small time period)
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
Channel to actor: Via terminal command prompt
.
.
Secondary Actors: None
.
Open Issues:. None
.
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 14
Use Case Diagram
Figure B.1 is a visual description of the above use case at a higher level of abstraction.
Figure B.1 – Use Case Diagram
Appendix C: Architectural Style and Component Specification
Architectural Style
Project BAT uses the data flow architectural model because our program is a perfect fit to
what that model describes. We are simply taking data from an input and piping it through
filters to produce a different type of data as output.
Program Components
Parser
This component takes input in the form of a B2 Logic EDF File and produce a connection
list (see next component).
Test Case:
Input - B2 Logic EDF File
Output - Text output to stdout of all tokens as they are found, one per line.
This test case allows for the comparison of the B2 Logic EDF file with the parser outUNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
put to assure that tokens are being parsed correctly.
.
.
Connection List
.
. structure that holds the data produced by the compiler in a form easily
This is a data
usable by the. rest of the system. It includes the INST class (and all its subclasses), and
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 15
the PORT class. Each subclass of the INST superclass represents a different part in the
BLT/MOSIS library and contains a function (library function) that can be called to produce
the required ABEL output. (See Appendix J for full class hierarchy)
Test Case:
Input - B2 Logic EDF File
Output - Output file with ABEL compatible code that accurately describes the input EDF
file.
Appendix D: Library Function Details
The Library Functions can be split into two parts, those that are implemented as a function
within their subclass of the INST class, and those that are already implemented by default
in the EDF file. Parts are listed below in the following format: Part Name - EDF Identifier
(where applicable).
Already Implemented in EDF File
1-to-2 Bus Connector
1-to-3 Bus Connector
1-to-4 Bus Connector
1-to-8 Bus Connector
2-to-1 Bus Connector
3-to-1 Bus Connector
4-to-1 Bus Connector
8-to-1 Bus Connector
Net Connector
The parts that are already implemented by default in the EDF file are considered to be
connection specific. They do not need to be implemented in any way because the
information they provide is already integrated into the EDF file and is automatically picked
up upon parsing. The remaining parts are subclasses of the INST superclass, and have a
common function that they inherit and override, which allows them to output the correct
ABEL code. The code they output is simply proper ABEL code expressing their output
value as a function of their inputs, where their inputs are each defined as the name of the
INST object their inputs are connected to.
Implemented as Functions
Input Pad - IN
Input Pad Clock - Specification Incomplete
Output Pad - OUT
High Voltage - VDD
Ground - GND
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
Buffer - BUF1
.
Inverter - INV
Exclusive OR.- XOR2
.
2 Input OR - NOR2C
2 Input NOR -.NOR2
2 Input NAND. - NAND2
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 16
2 Input AND - NAND2C
3 Input NOR - NOR3
3 Input NAND - NAND3
3 Input AND - NAND3C
4 Input NAND - NAND4
4 Input AND - NAND4C
D Flip Flop - DFFPC
Tri-State Buffer - BUFZ
Multiplexer 1-of-2 - MUX2
Buffer
p0 -> Input
p1 -> Output
Truth Table
P0 s
P1 s
Tri-State Buffer
p0 -> Enable 0 => Output 0
p1 -> Input 0 => Output 0
p2 -> Enable 1 => Output 1
p3 -> Input 1 => Output 1
p4 -> Enable 2 => Output 2
p5 -> Input 2 => Output 2
p6 -> Enable 3 => Output 3
p7 -> Input 3 => Output 3
p8 -> Output 0
p9 -> Output 1
p10 -> Output 2
p11 -> Output 3
Truth Table
P0 0
P1 s
P2 0
P3 s
P4 0
P5 s
P6 0
P7 s
P8 z
P9 z
P10 z
P11 z
1
s
1
s
1
s
1
s
s
s
s
s
D Flip Flop
p0 -> Asynchronous Set
p1 -> Clock
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
p2 -> Input (D)
.
p3 -> Asynchronous Reset
p4 -> Output .
p5 -> Inverted.Output
.
Truth Table .
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 17
(output shown appears after clock cycle when P0 and P3 are 1)
P0 1
0
1
P1 clk
clk
clk
P2 s
s
s
P3 0
1
1
P4 0
1
s
P5 1
0
!s
Inverter
Inputs - P0
Outputs - P1
Truth Table:
P0 s
P1 !s
2 Input Exclusive OR
Inputs - P0,P1
Outputs - P2
Truth Table:
P0 !s
s
P1 !s
!s
P2 !s
s
!s
s
s
s
s
!s
!s
s
s
s
s
s
!s
s
!s
s
s
!s
2 Input OR
Inputs - P0,P1
Outputs - P2
Truth Table:
P0 !s
s
P1 !s
!s
P2 !s
s
2 Input NOR
Inputs - P0,P1
Outputs - P2
Truth Table:
P0 !s
s
P1 !s
!s
P2 s
!s
2 Input NAND
Inputs - P0,P1
Outputs - P2
Truth Table:
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
P0 !s
s
.
P1 !s
!s
P2 s
s.
.
2 Input AND .
Inputs - P0,P1.
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 18
!s
s
s
s
s
!s
!s
s
!s
s
s
s
!s
s
!s
!s
s
s
!s
!s
!s
!s
s
!s
s
!s
s
!s
!s
s
s
!s
s
s
s
!s
!s
s
!s
s
s
s
!s
s
!s
!s
s
s
s
!s
s
s
!s
s
s
s
s
s
s
!s
!s
s
!s
!s
s
s
!s
!s
!s
!s
s
!s
s
!s
s
!s
!s
s
s
!s
s
s
s
s
Truth Table:
P0 !s
s
P1 !s
!s
P2 !s
!s
P3 !s
!s
P4 s
s
!s
s
!s
!s
s
s
s
!s
!s
s
!s
!s
s
!s
s
s
!s
s
!s
s
!s
s
s
!s
s
s
s
s
!s
s
P0 !s
!s
s
!s
s
!s
s
Outputs - P2
Truth Table:
P0 !s
s
P1 !s
!s
P2 !s
!s
3 Input NOR
Inputs - P0,P1,P2
Outputs - P3
Truth Table:
P0 !s
s
P1 !s
!s
P2 !s
!s
P3 s
!s
3 Input NAND
Inputs - P0,P1,P2
Outputs - P3
Truth Table:
P0 !s
s
P1 !s
!s
P2 !s
!s
P3 s
s
3 Input AND
Inputs - P0,P1,P2
Outputs - P3
Truth Table:
P0 !s
s
P1 !s
!s
P2 !s
!s
P3 !s
!s
4 Input NAND
Inputs - P0,P1,P2,P3
Outputs - P4
UNIVERSITY OF PORTLAND
s
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
P1 !s
!s
.
P2 !s
!s
P3 s
s.
P5 s
s.
.
4 Input AND .
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 19
s
!s
s
s
s
!s
s
s
!s
s
s
s
!s
s
s
s
s
s
s
s
s
s
s
!s
Truth Table:
P0 !s
s
P1 !s
!s
P2 !s
!s
P3 !s
!s
P4 !s
!s
!s
s
!s
!s
!s
s
s
!s
!s
!s
!s
!s
s
!s
!s
s
!s
s
!s
!s
!s
s
s
!s
!s
s
s
s
!s
!s
P0
P1
P2
P3
P4
!s
s
!s
s
!s
s
s
!s
s
!s
!s
!s
s
s
!s
s
!s
s
s
!s
!s
s
s
s
!s
s
s
s
s
s
Inputs - P0,P1,P2,P3
Outputs - P4
!s
!s
!s
s
!s
s
!s
!s
s
!s
Multiplexer
Inputs - P0,P1,P2
Outputs - P3
Truth Table:
P0 a
a
P1 b
b
P2 0
1
P3 a
b
Appendix E: Parser UML
See Appendix I for a full description of the INST class hierarchy
Inst Methods
abelout() - Returns ABEL equations code
nodes() – Returns ABEL nodes code
input() – Returns ABEL input code
output() – Returns ABEL output code
name() – Returns the name of the given Inst
get_port(“portname”) – Returns a reference to the port object of the given portname
Port Methods
type() - Returns the type of the port (either input or output)
name() – Returns the name of the port object
inst() - Returns the INST that the port object belongs to
inst=(&inst) - Setter for INST
add_connection(&port) - Adds a port object to the port array
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
connections() – Returns an array of port objects that are connected to the given Port
.
.
.
UML Description
.
. the class structure that the parser used to create objects as it processes
Figure E.1 shows
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 20
the EDF file.
UML Diagram
Figure E. 1 – UML Diagram
The parser should create a new “Inst” object for each input, output, and other part that it
finds in the EDF file. As these objects are created, they should be named consistently with
their names corresponding to the part’s “instance-name” (See EDF BNF) Each “Inst”
object is instantiated as a subclass of INST corresponding to the “type” of that particular
object (see EDF BNF) which describes that part. Each “Inst” also has a number of “port”s
(the exact number is defined by the INST subclass the object is instantiated as, and
therefore is based on the object’s “type”) and references to existing “port” objects that are
a part of the given “Inst.”
Each port stores a reference to the “inst” object it is connected to. “Inst”s also store an
array of references to the port objects they are connected to at each respective port.(See
Appendix F for further details)
Appendix F: EDF BNF
This appendix describes the input EDF file in Backus–Naur form. It defines separations
between syntactic grammar and lexical grammar, where lexical grammar is the syntax of
the tokens and syntactic grammar describes the way these tokens are put together to form
the syntax of the EDF file.
Setup information and design-root are both parts of the EDF file that are ignored by the
program as they are extraneous to the correct interpretation of the EDF file. Therefore,
they have been omitted from this description.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
Syntactic Grammar
.
. <input/output-definition> <contents> <design-root>
<EDF> ::= <setup>
.
.
<input/output-definition>
::=
"(" "cell" "toplevel"
"(" "cellType" "generic" ")" ")"
.
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 21
"(" "view view_1" "(" "viewType" "netlist" ")" ")"
"(" "interface"
{<port-info>}
")"
<contents> ::=
"(" "contents"
{<instances>}
{<netlist>}
")"
<instances> ::=
"(" "instance" <instance-name>
"(" "viewRef" "viewnamedefault"
"(" "cellRef" <cell-name> ")"
")" ")"
<netlist> ::=
"(" "net" <net-name>
"(" "joined"
{<connection>}
")" ")"
<port-info> ::= "(" "port" <port-name> {<digit>} "(" "direction" <direction> ")" ")"
<connection> ::= "(" "portref" {<port-name>}
"(" <port-type> (<instance-name> | (<port-name> <digit>)) ")" ")"
<direction> ::= "input" | "output"
<port-type> ::= "instanceref" | "member"
Lexical Grammar
<instance-name> ::= "INST"<digit>+
<net-name> ::= "Net"<digit>+
<port-name> ::= "IN"<digit>+ | "OUT"<digit>+ | "P"<digit>+ | (<digit>|<letter>)+
<digit> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<letter> ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
"q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" | "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
"J" | "K" | "L" | "M" | "N" | "O" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
<cell-name> ::= "VDD" | “GND” | “BUF1” | “INV” | “XOR2” | “NOR2C” | “NOR2” | “NAND2” |
.
“NAND2C” | “NOR3” | “NAND3” | “NAND3C” | “NAND4” | “NAND4C” | “DFFPC” | “BUFZ” |
.
“MUX2”
.
.
. BNF
Appendix G: ABEL
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 22
This appendix describes the ABEL HDL output file syntax in Backus–Naur form.
<abelcode>::= <headerline1> <headerline2> <headerline3> <inputdefs>+ <outputdefs>+
[<sets>+] <logic> <end>
<headerline1> ::= "MODULE" <module_name> <EOL>
<headerline2> ::= "TITLE" "'" <project title> "'" <EOL>
<headerline3> ::= "U1 device " "'" <partname> "';" <EOL>
<inputdefs> ::= <inputname> "pin" <pinnumber> ["istype" <type>] ";" <EOL>
<outputdefs> ::= <outputname> "pin" <pinnumber> ["istype" <type>] ";" <EOL>
<type> ::= "attr" | "com" | "reg" | "neg" | "pos" | "buffer" | "dc" | "invert" | "reg_D"
| "reg_T" | "reg_SR" | "reg_JK" | "reg_G" | "retain" | "xor"
<pinnumber> ::= 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19
<sets> ::= <setname> "=[" <varstart> ".." <varend> "];"
<varstart> ::= <inputname> | <outputname>
<varend> ::= <inputname> | <outputname>
<logic> ::= "equations" <EOL> {<equations>}
<equations> ::= <boolean> | <truth_table> | <combo>
<boolean> ::= <var> "=" ([<operator>] <var> <operator> <var>)* <EOL>
<combo> ::= "WHEN" <condition> "THEN" <var> "=" <var> "ELSE" <var> "=" <var>
<condition> ::= <var> | (<var> "=" <var> | <num>)
<num> ::= <digit>+
<digit> ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
<var> ::= (<inputname> | <outputname> | <setname> | <constants>) [<dotext>]
<dotext> ::= "." ("J" | "K" | "R" | "S" | "T" | "Q" | "PR" | "RE" |"ACLR" | "ASET" | "CLR" |
"SET"
| "AR" | "AP" | "SR" | "SP" | "LE" | "LH" | "CE" | "OE" | "FC" | "COM")
<constants> ::= "." ("C" | "K" | "U" | "D" | "F" | "P" | "SVn" | "X" | "Z") "."
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
.
<operator> ::= "!" | "&" | "#" | "$" | "!$" | "-" | "+" | "*" | "/" | "%" | "<<"
|."<<" | "==" | "!=" | "<" | "<=" | ">" | ">=" | "=" | "?="
|.":+=" | "?:="
.
<*name> ::= <string>
.
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 23
<string> ::= (<digit> | <letter>) (<digit> | "_" | <letter>)+
<letter> ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r"
| "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" | "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" |
"L" | "M" | "N" | "O" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
<end> ::= "END" <module_name>
Appendix H: Data Flow Diagrams
Figure H.1 diagrams the data from start to finish in BAT. The Level 0 diagram gives a very
top-level description of data flow, whereas the Level 1 diagram shows more detail about
what happens within the system.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
THEORY OF OPERATIONS
PROJECT BAT
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 24
Figure H.1 – Data Flow diagrams
Appendix I: Inheritance Hierarchy
Figure I.1 graphically represents the BAT inheritance hierarchy as a UML class diagram.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
THEORY OF OPERATIONS
PROJECT BAT
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 25
Figure I.1 – Inheritance Hierarchy
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
.
.
. Examples
Appendix J: Design
.
.
Design examples are included to give a clearer picture of how each part of BAT and the
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 26
input and output data are related. Figure J.1 (Figure J.3 in example 2) descibes the first
circuit that will be analyzed, its corresponding nondirected is shown in Figure J.2 (Figure
J.4 in example 2). The nondirected graph in Fig. J.1 shows how the objects are
connected within BAT once parsing is complete. ABEL HDL generated by BAT is also
included for both examples.
Example 1:
Figure J.1 is a screenshot of a very simple circuit implemented in B2 Logic. This circuit
generates an EDF text output file that is read as input to BAT. BAT’s parser (see Chapter
5 – Design Overview – Parser Component for more details) breaks up the EDF and
identifies the components and connections within the circuit. Each component is created
with all of its corresponding port objects as soon as the parser sees that the component is
in the EDF. Each port of a component is stored in a hash whose keys are the instance
names found in the EDF with the appropriate port number appended (e.g. “inst11p0” or
“inst6p3”).
Figure J.1 – B2 Logic Schematic
Next the parser analyzes the net lists in the EDF (below) to determine and define all of the
connections between port objects. Figure J.2 demonstrates how each component is
connected to its ports and how the nets are defined between the appropriate ports.
EDF:
(edif connectivity
(edifVersion 2 0 0)
(edifLevel 0)
(keywordMap (keywordLevel 0))
(library b2logic
(edifLevel 0)
(technology (numberDefinition
(scale 1 (E 1 -12) (unit CAPACITANCE))))
(cell NAND2C
(cellType generic)
(view viewnamedefault
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
THEORY OF OPERATIONS
PROJECT BAT
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 27
(viewtype netlist)
(interface
(port p0 (direction input))
(port p1 (direction input))
(port p2 (direction output))
)))
(cell NOR2C
(cellType generic)
(view viewnamedefault
(viewtype netlist)
(interface
(port p0 (direction input))
(port p1 (direction input))
(port p2 (direction output))
)))
**The stripped down EDF begins here**
(cell toplevel (cellType generic)
(view view_1 (viewType netlist)
(interface
(port In0 (direction input))
(port In1 (direction input))
(port Out0 (direction output))
)
(contents
(instance INST2
(viewRef viewnamedefault
(cellRef NAND2C)
))
(instance INST3
(viewRef viewnamedefault
(cellRef NOR2C)
))
(net Net0
(joined
(portRef In0)
(portRef P0 (instanceRef INST2))
))
(net Net1
(joined
(portRef In1)
(portRef P1 (instanceRef INST2))
(portRef P1 (instanceRef INST3))
))
(net Net2
(joined
(portRef P2 (instanceRef INST2))
(portRef P0 (instanceRef INST3))
))
(net Net3
(joined
(portRef P2 (instanceRef INST3))
(portRef Out0)
))
))))
(design root
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
(cellref toplevel
. (libraryRef b2logic))))
.
Parser Analysis:
. first strips the EDF down as described in Chapter 5. Here, “in0” is found
First, the parser
. named ‘in0’ is created. Its pin is also created and named ‘in0p0’.
and a new instance
Since it is an .
external pin no node is created, but “in0p0 pin;” is added to the ‘inputs’
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 28
string. Next “in1” is found; a new instance is created named ‘in1’ and its port is named
‘in1p0’. A new line of code is appended to the ‘inputs’ string that reads “in1p0 pin;”. Next
‘out0’ is found; an instance named “out0” is created and its port is created and named
“out0p0”. Its code is appended to the ‘outputs’ string and reads “out0p0 pin;”.
All of the external pins are now created and their code defined.
‘Inst2’ is found and a new instance of type NAND2C named ‘inst2’ is created . It’s ports
are created as ‘inst2p0’, ‘inst2p1’, and ‘inst2p2’. The string “inst2p2 node;” is appended to
the ‘nodes’ string because it is the output of inst2.
‘Inst3’ is found and a new instance of type NOR2C named ‘inst3’ is created . It’s ports are
created as ‘inst3p0’, ‘inst3p1’, and ‘inst3p2’. The string “inst3p2 node;” is appended to the
‘nodes’ string because it is the output of inst3.
All the instances and their ports and nodes where applicable are now created.
Net0 defines how ‘in0’ is connected to ‘inst2’. The net states that ‘in0’ is connected to
port2 of inst2, so a connection is defined in the connection array of ‘in0p0’ by adding
“inst2p0” to the array, and vice versa for ‘inst2p0’.
Net1 defines ‘in1’s connections. It is connected to port1 on both ‘inst2’ and ‘inst3’. “in1p0”
is appended to the connections array of both “inst2p1” and “inst3p1”. Likewise, “inst2p1”
and “inst2p1” are appended to the connections array of ‘in1p0’.
Net2 defines the connection between the output of ‘inst2’ and one of the inputs of ‘inst3’.
Port 2 of ‘inst2’ is connected to port 0 of ‘inst3’ so “inst2p2” is appended to the connections
array of ‘inst3p0’ and “inst3p0” is appended to the connections array of ‘inst2p2’.
Net3 defines the connection between the output of ‘inst3’ and ‘out0’. Port 2 of ‘inst3’
connects to port 0 of out0, so “inst3p2” is appended to the connections array of ‘out0p0’
and “out0p0” is appended to the connections of ‘out0p0’ .
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
.
.
.
.
.
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 29
Figure J.2 - Visual representation of object relationships and connections
The ABEL HDL Code is created in six steps as outlined in Chapter 5. A method is called
that outputs standard ABEL header text “Module BATcode”. Other methods are then
called that output the ‘input’ string, ‘output’ string and ‘node’ string, each of which begins
with a comment ‘“inputs’, ‘“outputs’, and ‘“nodes’, respectively.
The ABEL keyword “equations” will be appended to the end of the nodes string to indicate
the beginning of logic equations.
Next, the abelout method is called on each instance. Each subclass has its own method
that pipes appropriate variables into prefab code.
In0 and in1 are external inputs, so they are not evaluated with abelout.
Abelout is called on inst2, which checks the connections on its input ports and substitutes
the name of the connected port in the final outputted code. The resulting code is
inst2p2 = in0p0 & in1p0;
Inst3 is evaluated next in the same fashion. The connection on inst3p0 is found to be
inst2out, so “inst2out” is put in the code in its place. The connection on isnt3p1 is found to
be in1p0, so “in1p0” is substituted into the code. The resulting logic equation is set as the
definition of inst3out, the node defined for the output pin of inst3.
Finally, out0 is evaluated. It only has one pin, out0p0 and it is connected to inst3out, so
“inst3out” is substituted into the prefab code and the equation is outputted.
The final step calls a method that appends “end BATcode” to the end of the file. This
string indicates the end of the code.
Resulting ABEL HDL Code:
Module BATcode
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
Title 'This example illustrates how BAT handles a very simple
circuit. .The title is optional and is not be included in BAT
output.' .
.
"inputs .
in0p0
pin;
.
in1p1
pin;
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 30
"outputs
out0p0
pin;
"nodes
inst2out node;
inst3out node;
equations
inst2out = in0p0 & in1p0;
inst3out = inst2out # in1p0;
out0p0 = inst3out;
end BATcode
Example 2:
Figure J.3 – B2 Logic Schematic – pins and nodes labeled
EDF:
(edif connectivity
(edifVersion 2 0 0)
(edifLevel 0)
(keywordMap (keywordLevel 0))
(library b2logic
(edifLevel 0)
(technology (numberDefinition
(scale 1 (E 1 -12) (unit CAPACITANCE))))
(cell NOR2C
(cellType generic)
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
THEORY OF OPERATIONS
PROJECT BAT
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 31
(view viewnamedefault
(viewtype netlist)
(interface
(port p0 (direction input))
(port p1 (direction input))
(port p2 (direction output))
)))
(cell NAND2C
(cellType generic)
(view viewnamedefault
(viewtype netlist)
(interface
(port p0 (direction input))
(port p1 (direction input))
(port p2 (direction output))
)))
(cell DFFPC
(cellType generic)
(view viewnamedefault
(viewtype netlist)
(interface
(port p0 (direction input))
(port p1 (direction input))
(port p2 (direction input))
(port p3 (direction input))
(port p4 (direction output))
(port p5 (direction output))
)))
(cell VDD
(cellType generic)
(view viewnamedefault
(viewtype netlist)
(interface
(port p0 (direction output))
)))
(cell toplevel (cellType generic)
(view view_1 (viewType netlist)
(interface
(port x (direction input))
(port Clk0 (direction input))
(port z (direction output))
)
(contents
(instance INST3
(viewRef viewnamedefault
(cellRef NOR2C)
))
(instance INST4
(viewRef viewnamedefault
(cellRef NOR2C)
))
(instance INST5
(viewRef viewnamedefault
(cellRef NAND2C)
))
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
THEORY OF OPERATIONS
PROJECT BAT
UNIVERSITY OF PORTLAND
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 32
(instance INST6
(viewRef viewnamedefault
(cellRef DFFPC)
))
(instance INST7
(viewRef viewnamedefault
(cellRef DFFPC)
))
(instance INST8
(viewRef viewnamedefault
(cellRef VDD)
))
(net Net0
(joined
(portRef x)
(portRef P0 (instanceRef INST5))
))
(net Net1
(joined
(portRef Clk0)
(portRef P1 (instanceRef INST7))
(portRef P1 (instanceRef INST6))
))
(net Net2
(joined
(portRef P5 (instanceRef INST6))
(portRef P0 (instanceRef INST3))
))
(net Net3
(joined
(portRef P4 (instanceRef INST7))
(portRef P1 (instanceRef INST3))
))
(net Net4
(joined
(portRef P2 (instanceRef INST3))
(portRef P2 (instanceRef INST6))
))
(net Net5
(joined
(portRef P4 (instanceRef INST6))
(portRef P0 (instanceRef INST4))
))
(net Net6
(joined
(portRef P5 (instanceRef INST7))
(portRef P1 (instanceRef INST4))
(portRef P1 (instanceRef INST5))
))
(net Net7
(joined
(portRef P2 (instanceRef INST4))
(portRef z)
))
(net Net8
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
THEORY OF OPERATIONS
PROJECT BAT
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 33
(joined
(portRef P2 (instanceRef INST5))
(portRef P2 (instanceRef INST7))
))
(net Net9
(joined
(portRef P0 (instanceRef INST8))
(portRef P0 (instanceRef INST6))
(portRef P3 (instanceRef INST6))
(portRef P3 (instanceRef INST7))
(portRef P0 (instanceRef INST7))
))
))))
(design root
(cellref toplevel
(libraryRef b2logic))))
The first interesting thing that the parser finds in this EDF is ‘port x’. The instance ‘x’ and
its port ‘xp0’ are created. “xp0 pin;” is automatically appended to the ‘inputs’ string.
Next ‘port Clk0’ is found, so the instance ‘clk0’ and its port ‘clk0p0’ are created and “clk0p0
pin;” is appended to the ‘inputs’ string.
‘port z’ indicates an external output, so the instance ‘z’ and its port ‘zp0’ are created and
“zp0 pin;” is appended to the ‘outputs’ string.
Now create the instances. ‘inst3’ is found and specified as type ‘nor2c’ so a nor2c
instance is created and named ‘inst3’. Its pins, ‘inst3p0’, inst3p1’ and ‘inst3p2’ are all
created and given the types ‘in’, ‘in’, ‘out’, respectively. ‘inst3p2’ defines an output pin, so
a node is also created by appending “inst3p2 node;” to the ‘nodes’ string.
‘inst4’ is found and specified as type ‘nor2c’. It’s creation will follow exactly as inst3,
except all the names will be ‘inst4xx’ rather than ‘inst3xx’.
‘inst5’ is found and specified as type ‘nand2c’. It’s creation will follow exactly as inst3,
except all the names will be ‘inst5xx’ rather than ‘inst3xx’.
‘inst6’ is found and specified as type ‘dffpc’. Thus, a new dffpc instance is created by the
name of ‘inst6’, with ports ‘inst6p0’, ‘inst6p1’, ‘inst6p2’, ‘inst6p3, ‘inst6p4’ and ‘inst6p5’.
‘inst6p4’ and ‘inst6p5’ are both outputs, so they are given the type ‘out’ and nodes are
created by appending “inst6p4 node istype ‘reg’;” and “inst6p5 node istype ‘reg’;” to the
‘nodes’ string. The nodes on dffpcs are initialized at type ‘reg’ to let ABEL know that they
are registered (clocked) signals. Ports ‘inst6p0’ through ‘inst6p3’ are all given the type ‘in’.
‘inst7’ is found and specified as type ‘dffpc’. It’s creation will follow exactly as inst6, except
all the names will be ‘inst7xx’ rather than ‘inst6xx’.
‘inst8’ is found and specified as type ‘vdd’. Instances of type ‘vdd’ are treated as external
inputs so no nodes are created; an instance named ‘inst8’ of type ‘vdd’ is created with port
‘inst8p0’. ‘inst8p0’ is given type ‘out’ and “inst8p0 pin;” is appended to the ‘inputs’ string.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
Netlist analysis
.
.
The first port referenced
Net0 is ‘x’ and is followed by p0 of inst5, so “xp0” is appended
. array ofin‘inst5p0’
to the connection
and “inst5p0” is appended to the connection array of
.
‘xp0’.
.
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 34
Net1: “clk0p0” is appended to the connection arrays of ‘inst7p1’ and ‘inst6p1’. Similarly,
“inst7p1” and “inst6p1” are appended to the connection array of ‘clk0p0’.
Net2: “inst6p5” is appended to the connection array of ‘inst3p0’ and “inst3p0” is appended
to the connection array of ‘inst6p5’.
Net3: “inst7p4” is appended to the connection array of ‘inst3p1’ and “inst3p1” is appended
to the connection array of ‘inst7p4’.
Net4: “inst3p2” is appended to the connection array of ‘inst6p2’ and “inst6p2” is appended
to the connection array of ‘inst3p2’.
Net5: “inst6p4” is appended to the connection array of ‘inst4p0’ and “inst4p0” is appended
to the connection array of ‘inst6p4’.
Net6: “inst7p5” is appended to the connection arrays of ‘inst4p1’ and ‘inst5p1’; “inst4p1”
and “inst5p1” are appended to the connection array of ‘inst7p5’.
Net7: “inst4p2” is appended to the connection array of ‘zp0’ and “zp0” is appended to the
connection array of ‘inst4p2’.
Net8: “inst5p2” is appended to the connection array of ‘inst7p2’ and “inst7p2” is appended
to the connection array of ‘inst5p2’.
Net9: “inst8p0” is appended to the connection arrays of ‘inst6p0’, ‘inst6p3’, ‘inst7p0’ and
‘inst7p3’. "inst6p0", "inst6p3", "inst7p0" and "inst7p3" are appended to the connection
array of ‘inst8p0’.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
THEORY OF OPERATIONS
PROJECT BAT
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 35
Figure J. 4 - Visual representation of object relationships and connections for Example 2
ABEL HDL Code output begins with calling methods that output the header, inputs,
outputs and nodes (see Example 1 above),
The actual equations are generated by calling the ‘abelout()’ method on each instance,
excluding the external inputs.
Inst7: abelout() polls ‘inst7p0’ through ‘inst7p3’ to determine the incoming connections
and pipes those values into the code. ‘inst7p0’ and ‘inst7p3’ are connected to ‘inst8p0’, so
“inst8p0” is put into the appropriate places in the ABEL code. ‘inst7p1’ is connected to
‘clk0p0’, so “clk0p0” is put in its place in the ABEL code. ‘inst7p2’ is connected to ‘inst5p2’,
so “inst5p2” is placed in the appropriate spot in the ABEL code. The values that are
substituted into the code appear on the right hand side of the outputted equations and the
names of the output ports (here “inst7p4” and “inst7p5”) appear on the left hand side of the
equations.
Inst6 is processed the same as inst7. ‘inst6p0’ and ‘inst6p3’ are connected to ‘inst8p0’;
‘inst6p1’ is connected to ‘clk0p0’; ‘inst6p2’ is connected to ‘inst3p2’
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
.
Inst5: ‘inst5p0’ is connected to ‘xp0’; ‘inst5p1’ is connected to ‘inst7p5’; “inst5p2” will
appear on the.left hand side of the equations, and “xp0” and “inst7p5” will appear on the
. of the equations
right hand side
.
Inst4: ‘inst4p0’. is connected to ‘inst6p0’; ‘inst4p1’ is connected to ‘inst7p5’; “inst4p2” will
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 36
appear on the left hand side of the equation, and “inst6p0” and “inst7p5” will appear on the
right hand side of the equations
Inst3: ‘inst3p0’ is connected to ‘inst6p5’; ‘inst3p1’ is connected to ‘inst7p4’; “inst3p2” will
appear on the left hand side of the equation, and “inst6p5” and “inst7p4” wil appear on the
right hand side of the equations
Z: ‘zp0’ is connected to ‘inst4p2’; “zp0” will appear on the left hand side of the equation
and “inst4p2” will appear on the right hand side of the equation
Finally, the last method will be called that appends “end BATcode” to the end of the file.
This string indicates the end of the code.
Corresponding ABEL HDL Code
MODULE BATcode
"inputs
xp0
clk0p0
inst8p0
pin;
pin;
pin;
"outputs
zp0
pin;
"nodes
inst4p2
inst6p4
inst7p5
inst7p4
inst5p2
inst6p5
inst3p2
node;
node istype
node istype
node istype
node;
node istype
node;
'reg';
'reg';
'reg';
'reg';
equations
"dff
inst6p4.clk = clk0p0;
inst6p5.clk = clk0p0;
inst6p4.ar = inst8p0;
inst6p4.ap = inst8p0;
inst6p5.ar = inst8p0;
inst6p5.ap = inst8p0;
"dff
inst7p4.clk = clk0p0;
inst7p5.clk = clk0p0;
inst7p4.ar = inst8p0;
inst7p4.ap = inst8p0;
inst7p5.ar = inst8p0;
inst7p5.ap = inst8p0;
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE
.
.
.
.
inst4p2 = .inst6p4 # inst7p5;
inst6p4 :=. inst3p2;
inst7p5 :=. !inst5p2;
inst7p4 :=. inst5p2;
inst5p2 = .xp0 & inst7p5;
inst6p5 := !inst3p2;
THEORY OF OPERATIONS
PROJECT BAT
REV. 1.0
PAGE 37
inst3p2 = inst6p5 # inst7p4;
zp0 = inst4p2;
end BATcode
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: I. TAGGE