MACPHY To A MicroBlaze System On A Virtex-II FPGA PDF

Interfacing an external Ethernet
MAC/PHY to a MicroBlaze system on

a Virtex-II FPGA
Masters thesis
performed for ITEE, University of Queensland, Brisbane,
Australia
by
Johan Bernsp
ang
Reg nr: LiTH-ISY-EX-3440-2004
31th May 2004
Interfacing an external Ethernet

MAC/PHY to a MicroBlaze system on
a Virtex-II FPGA
Masters thesis
performed in Computer Engineering,
Dept. of Electrical Engineering
at Link
opings universitet
by Johan Bernsp
ang
Reg nr: LiTH-ISY-EX-3440-2004
Supervisor: Doctor John Williams

ITEE, University of Queenland
Professor Neil Bergmann
ITEE, University of Queenland
Examiner: Professor Dake Liu
Linkopings Universitet
Linkoping, 31th May 2004
Avdelning, Institution
Division, Department
Datum
Date
Computer Engineering,
Dept. of Electrical Engineering
581 83 Link
oping
Spr
ak
Rapporttyp
Report category
Language
Svenska/Swedish
Engelska/English
Licentiatavhandling
Examensarbete
C-uppsats
D-uppsats
Ovrig
rapport
31th May 2004
ISBN
ISRN
LITH-ISY-EX-3440-2004
Serietitel och serienummer ISSN
Title of series, numbering
URL f
or elektronisk version
http://www.ep.liu.se/exjobb/isy/2004/3440/
Titel
Title
F
orfattare
Author
Utveckling av ett gr
anssnitt mellan ett externt ethernetchip och ett
Microblaze system p
a en Virtex-II FPGA
Interfacing an external Ethernet MAC/PHY to a MicroBlaze system
on a Virtex-II FPGA
Johan Bernsp
ang
Sammanfattning
Abstract
Due to the development towards more dense programmable devices

(FPGAs) it is today possible to fit a complete embedded system including microprocessor, bus architecture, memory, and custom peripherals
onto one single reprogrammable chip, it is called a System-on-Chip
(SoC). The custom peripherals can be of literally any nature from I/O
interfaces to Ethernet Media Access Controllers. The latter core, however, usually consumes a big part of a good sized FPGA. The purpose
of this thesis is to explore the possibilities of interfacing an FPGA
based Microblaze system to an off-chip Ethernet MAC/PHY. A solution which would consume a smaller part of the targeted FPGA, and
thus giving room for other on-chip peripherals or enable the use of a
smaller sized FPGA. To employ a smaller FPGA is desirable since it
would reduce power consumption and device price. This work includes
evaluation of different available Ethernet devices, decision of interface
technology, implementation of the interface, testing and verification.
Since the ISA interface still is a common interface to Ethernet MAC
devices a bus bridge is implemented linking the internal On-Chip Peripheral Bus (OPB) with the ISA bus. Due to delivery delays of the
selected Ethernet chip a small on-chip ISA peripheral was constructed
to provide a tool for the testing and verification of the bus bridge. The
main result of this work is an OPB to ISA bus bridge core. The bridge
was determined to work according to specification, and with this report
at hand the connection of the Ethernet chip to the system should be
quite straightforward.
Nyckelord
Keywords
OPB, ISA, Microblaze, FPGA, VHDL, Ethernet, ChipScope
Abstract
Due to the development towards more dense programmable devices (FPGAs) it is today possible
to fit a complete embedded system including microprocessor, bus architecture, memory, and
custom peripherals onto one single reprogrammable chip, it is called a System-on-Chip (SoC).
The custom peripherals can be of literally any nature from I/O interfaces to Ethernet Media
Access Controllers. The latter core, however, usually consumes a big part of a good sized FPGA.
The purpose of this thesis is to explore the possibilities of interfacing an FPGA based Microblaze
system to an off-chip Ethernet MAC/PHY. A solution which would consume a smaller part of the
targeted FPGA, and thus giving room for other on-chip peripherals or enable the use of a smaller
sized FPGA. To employ a smaller FPGA is desirable since it would reduce power consumption
and device price. This work includes evaluation of different available Ethernet devices, decision
of interface technology, implementation of the interface, testing and verification. Since the ISA
interface still is a common interface to Ethernet MAC devices a bus bridge is implemented linking
the internal On-Chip Peripheral Bus (OPB) with the ISA bus. Due to delivery delays of the
selected Ethernet chip a small on-chip ISA peripheral was constructed to provide a tool for the
testing and verification of the bus bridge. The main result of this work is an OPB to ISA bus
bridge core. The bridge was determined to work according to specification, and with this report
at hand the connection of the Ethernet chip to the system should be quite straightforward.
Keywords:
OPB, ISA, Microblaze, FPGA, VHDL, Ethernet, ChipScope
Contents
Abstract
1 Introduction
1.1 Background .
1.2 Objectives . .
1.3 Method . . .
1.4 Limitations .
1.4.1 Time .
1.5 Thesis outline
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
2
2
2
2 Technology & Background

2.1 Systems-on-Chip, SoC . . . . . . . . . . . . . . .
2.2 Field Programmable Gate Array, FPGA . . . . .
2.2.1 Virtex-II . . . . . . . . . . . . . . . . . . .
2.2.2 The Microblaze core . . . . . . . . . . . .
2.2.3 Embedded Development Toolkit, EDK . .
2.3 Ethernet MAC/PHY . . . . . . . . . . . . . . . .
2.3.1 Media Access Controller, MAC . . . . . .
2.3.2 Physical Layer Device, PHY . . . . . . . .
2.3.3 The OPB Ethernet MAC . . . . . . . . .
2.4 Bus architectures . . . . . . . . . . . . . . . . . .
2.4.1 The ISA bus specification . . . . . . . . .
2.4.2 Standard 16-bit I/O device ISA bus cycles
2.4.3 The OPB bus specification . . . . . . . .
2.4.4 The OPB cycle . . . . . . . . . . . . . . .
2.5 Designing OPB peripherals for Microblaze . . . .
2.5.1 IPIF . . . . . . . . . . . . . . . . . . . . .
2.6 Clock domain crossing . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
5
6
7
7
7
8
8
8
8
9
11
12
14
14
14
3 Implementation & Testing

3.1 Choosing Ethernet MAC/PHY .
3.2 OPB to ISA bridge . . . . . . . .
3.2.1 Specification . . . . . . .
3.2.2 Components . . . . . . .
3.2.3 Interrupts . . . . . . . . .
3.3 ISA General Purpose I/O, GPIO
3.4 Testing methodology . . . . . . .
3.4.1 Simulations . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
17
18
19
25
26
27
27
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.4.2
On-Chip verifications
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4 Results & Discussion

4.1 Device utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Microblaze utilization/waste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
31
32
5 Conclusions
5.1 Lessons learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Further work on the bus bridge . . . . . . . . . . . . . . . . . . . . . . . .
33
33
34
34
Bibliography
35
A List of Acronyms
37
B Acknowledgements
38
C Hardware and software resources
39
D Using ChipScope for debugging and functional verification

D.1 ChipScope for dummies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.1.1 Inserter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D.1.2 Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
40
40
44
E The VHDL code

E.1 OPB to ISA bus bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.2 ISA GPIO code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
46
76
F Device utilization
80
G Simulation waveforms
82
vii
List of Figures
2.1
2.2
2.3
2.4
2.5
Schematic of a CLB slice . . . . . . . . . . . . .

The Microblaze Architecture . . . . . . . . . .
Standard 16-bit I/O device ISA bus cycle . . .
Basic OPB transaction . . . . . . . . . . . . . .
Circuit for moving data across clock boundary
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
6
10
13
15
3.1
3.2
3.3
3.4
3.5
OPB to ISA bridge architecture . . . . . . . .

The OPB Finite state machine . . . . . . . .
The ISA Finite state machine . . . . . . . . .
The Timeout Watchdog Finite state machine
The ISA GPIO core . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
21
23
24
26
4.1
4.2
4.3
4.4
OPB
OPB
OPB
OPB
D.1
D.2
D.3
D.4
D.5
D.6
G.1
G.2
G.3
G.4
to
to
to
to
ISA
ISA
ISA
ISA
read operation . . . . . . .
write operation . . . . . . .
read operation with failure
write operation with failure
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
30
30
31
ChipScope
ChipScope
ChipScope
ChipScope
ChipScope
ChipScope
Inserter, design specification

Inserter, trigger parameters .
Inserter, capture parameters
Inserter, net connections . .
Analyzer trigger setup . . . .
Analyzer waveform capture .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
42
42
43
45
45
Simulation
Simulation
Simulation
Simulation
of
of
of
of
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
83
84
85
86
unsuccessful read cycle .

successful read cycle . .
unsuccessful write cycle
successful write cycle . .
.
.
.
.
viii
List of Tables
3.1
Bus bridge specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.1
Device utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
ix
List of Listings
E.1
E.2
E.3
E.4
E.5
E.6
E.7
E.8
Bus Wrapper . . . . . . . .
OPB Interface . . . . . . . .
ISA Interface . . . . . . . .
Timeout Watchdog . . . . .
ISA Clock Generator . . . .
OPB to ISA communication
Clock Domain Crossing . .
ISA GPIO . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
55
61
68
71
72
74
76
Chapter 1
Introduction
1.1
Background
One of the research areas of School of Information Technology and Electrical Engineering (ITEE)
at University of Queensland in Brisbane, Australia, is reconfigurable Systems-on-Chip (rSoC).
Particularly for implementation of real-time embedded systems where custom hardware peripherals can improve real-time response rates. The research is mainly based on a Field Programmable
Gate Array (FPGA) with a MicroBlaze softcore processor from Xilinx running a version of embedded Linux, uCLinux. The port of uCLinux to Microblaze is made by a member of the research
group, John Williams, who is also one of the supervisors of this project. The group has proposed
a future platform for real-time reconfigurable system on chips, Egret, which would be based on
a Microblaze softcore processor running uCLinux.[1]
One of the key capabilities of an embedded real-time system is to communicate efficiently
with the surrounding environment. An Ethernet core can easily be added to the system as an
on-chip peripheral on the utilized FPGA, however with the significant drawback that it covers a
comparatively large part of the chip. Thus, taking room from other potential peripherals or realtime tasks implemented in hardware, or forcing the use of a larger and more expensive FPGA.
This masters thesis is an attempt to interface a standard Ethernet Media Access Controller/Physical interface (MAC/PHY) chip with the FPGA in a general way, utilizing as little of the
FPGA chip as possible. The reason to achieve small solution would be to make room for other
time critical tasks to be implemented in hardware. A small solution would also enable the use
of a smaller FPGA device which would be cheaper and consume less power. Price and power
consumption are two negative aspects with employing FPGA chips instead of using the ASIC
technology.
The first task of this project was a thorough investigation of previous attempts to interface an
Ethernet MAC/PHY with a Microblaze system. No such solution was to be found though, in all
previous solutions on-chip Ethernet MACs were used together with off-chip physical interfaces.
The second task was to implement the interface between the Microblaze system and the Ethernet
MAC/PHY of choice and to review the involved technologies. Finally, a careful testing and
verification of the implementation need to be done ensure its functionality.
The thesis work is carried out due to the requirement of the master of engineering degree
at the university of Linkoping in Sweden. Examination is done by the professor in computer
engineering, Dake Liu, at the department of electrical engineering.
1
Introduction
1.2
Objectives
The main objective of this thesis is to find a suitable Ethernet MAC/PHY for the existing
system and create an interface between the chip and the Microblaze system. In order to reach
this objective a number of goals were identified:
Evaluation of different Ethernet MAC/PHY chips to find a suitable solution.
Review and evaluation of the utilized FPGA technology and the Microblaze system, the
development tools and the development of Microblaze peripherals. The review should cover
the bus architecture utilized by Microblaze systems and the design of custom peripherals.
Review of the interface technology between the chosen Ethernet chip and the Microblaze
system. Design challenges should be identified and evaluated.
Development of an interface between Ethernet chip and the system. Preferably this interface should be an easy to use IP core, which utilize as small part of the FPGA as possible.
The IP should be implemented in a general way, which would render other areas of use
besides the specific area described in this thesis.
1.3
Method
The first part of the work was to learn how to use the tools to create embedded systems on Xilinx
devices. Tutorials on EDK and ISE were used for this purpose. Second, a suitable Ethernet
MAC/PHY was chosen to identify what kind of interface that had to be constructed. Third,
the different technologies involved in the interface, such as the On-Chip Peripheral Bus (OPB),
the Industry Standard Architecture (ISA bus), the utilized FPGA family and the Microblaze
softcore processor were investigated to give an understanding about how the custom core was to
be implemented.
When the topics mentioned in the previous paragraph had been thoroughly studied in various
publications, an OPB to ISA bus bridge was designed and implemented. To verify the design
both simulation and on-chip verification were performed.
1.4
Limitations
Due to the schooling of the author this thesis is written in American English. Another aspect
of the limitations is the availability of software and hardware. For an indepth explanation of
the available resources for the implementation and testing of the OPB to ISA bus bridge, see
appendix C. The software tools proved to be satisfying for this kind of development.
1.4.1
Time
This thesis work has been performed during a period of 20 weeks in accordance with the requirements at the university of Linkoping.
1.5
Thesis outline
Chapter 2, Technology & Background, will give the reader sufficient background information
regarding the different technologies that will be utilized throughout the thesis.
Introduction
Chapter 3, Implementation & Testing, covers the different options of Ethernet chip as
well as the design and implementation of the bus bridge and a very simple on-chip ISA
peripheral. Furthermore, it describes the testing and verification methodologies.
Chapter 4, Results & Discussion, presents and discusses the outcomes from the work.
Chapter 5, Conclusions, sums up the report and gives some advice for future work.
The appendices contain a list of acronyms, acknowledgements, description of hardware and
software resources, a short guide and tutorial to ChipScope, the source code for the VHDL
implementations, details about device utilization, and simulation waveforms.
Chapter 2
Technology & Background

This chapter will cover the underlying theories for the technologies that are utilized throughout
this thesis. The technologies include SoC in general, the employed FPGA family, Virtex-II
from Xilinx, Ethernet, the OPB and ISA specifications, guidelines to design of custom OPB
peripherals, and how to provide a secure data path across clock domain boundaries. For a more
in-depth coverage, see the referred literature.
2.1
Systems-on-Chip, SoC
In recent years the embedded computer systems, utilized as vehicle control units, in wireless
communication systems, etc., have become increasingly complex. At the same time the feature
size of integrated circuits has decreased significantly making room for more transistors on one
piece of silicon than ever before.1 The trend towards more dense silicon technologies has led
to more sophisticated FPGA circuits that allow integration of numerous functions onto a single
silicon chip, thus it can be utilized for a wider range of applications. Instead of using different
chips for the different parts of the system, i.e. one chip for the processor core or micro controller,
one for IO-interface, one for memory etc. in a SoC all of these parts are integrated on the same
piece of silicon.
One recent development is towards reconfigurable System on Chip, even though the approach
was proposed in the 1960s. That is, the system is able to reprogram itself during runtime,
exchange one hardware function to another, or moving software processes to hardware ditto to
meet timing issues, depending on the demand of the system. When designing reconfigurable SoC
it is possible to use more hardware than available on the target chip, peripheral netlists are kept
in memory and loaded onto the device when necessary.[3]
2.2
Field Programmable Gate Array, FPGA
Before the appearance of programmable logic, hardware designers either built custom logic circuits at the board level using standard components, or at the gate level relying on expensive
ASIC technologies. Today the designers can use the FPGA technology to verify the functionality of a system during the design flow. An FPGA is a generic integrated circuit consisting of
configurable logic blocks (CLBs) and programmable interconnections. A design is implemented
by specifying a simple logic function for each cell, and closing the appropriate switches in the
1 At
the time of writing the smallest feature size in production is 90 nm.[2]
interconnection network. Modern FPGA circuits contain enough logic to implement SoCs and
other complex designs.[4]
The term Field Programmable implies that the function of the FPGA is defined by a user description rather than by the manufacturer of the circuit. The user employ a hardware description
language (HDL), such as VHDL or Verilog, to describe the desired system. Synthesis software
is then utilized to translate the description into a bit file that is used to program the FPGA.[4]
The bit file can be stored in either one-time programmable memory cells, non-volatile memory
(flash memory) or volatile memory (static and dynamic RAM). For reconfigurable system-on-chip
the latter is of particular interest. A SRAM-based FPGA can be programmed during system
initialization, and it can also be changed dynamically during system operation.[5]
FPGA circuits are well suited for prototyping and small production volumes. The use of
FPGAs also enables future hardware updates. That is, if bugs in the implementation are discovered a new bit file can be downloaded to the device in very short time without disturbing
the execution of the system too much. However, since an FPGA is not optimized for a specific
application it may consume more power or be less efficient implementation of the design than an
ASIC. Another drawback is that the price per chip is high.[4]
2.2.1
Virtex-II
Today, the FPGA market is dominated by three companies, Xilinx, Altera, and Actel[5]. Xilinx
has developed a number of FPGA families. The Virtex-II family is developed for high performance from designs based on customized modules and IP cores. The family consists of 11
members, ranging from 40K to 8M system gates.[6] The Virtex-II platform is the result of the
largest development attempt in the history of programmable logic, and it has many novel features which simplifies the design and implementation of complex systems. A Virtex-II FPGA
has, for instance, up to 16 low-skew clock domains2 , and on-chip controlled output impedances
to eliminate external termination resistors.[7]
LUT F
Register
MUX
LUT G
Register
MUX
Arithmetic
logic
Figure 2.1: A rough schematic of a CLB slice. Source: [6]

The Virtex-II FPGA consists of input/output blocks (IOBs), and internal logic blocks. The
interface between the external pins and the internal configurable logic is provided by the IOBs.
An IOB can be used in three different ways, as input block with either single- or double-datarate register (DDR), as output block with single-rate register or DDR, or with an optional
2 Depending
on the device size.
3-state buffer that can be driven directly or through a single or double register, or, finally,
as a bidirectional block with any combination of the above configurations. The internal logic
blocks has four major elements. Functional elements for combinatorial and synchronous logic
is provided by CLBs. Large 18 kbit storage elements are provided by dual-port RAM modules.
18x18-bit dedicated multipliers are provided by multiplier blocks. Finally, the digital clock
managers (DCM) provide a self-calibrating, fully digital delay compensated solutions for clock
multiplication and division, and coarse- and fine-grained clock phase shifting.[6]
Every CLB consists of four slices which is the main component of the CLB. The concept of
slices provides a good measure of device utilization during synthesis. Each slice is composed of two
4-input function generators, two storage elements, arithmetic and carry logic and multiplexers,
see figure 2.1. The function generators are mainly used as lookup tables (LUT), but can also
be used as a 16 bit distributed RAM or a 16 bit variable-tap shift register. A LUT is able to
implement any arbitrary 4-input boolean function, and its output drives both the slice output
and the input to the corresponding register in the slice. The multiplexers are included in the
Virtex-II slices to enable logical functions with up to 8 inputs, i.e. a combination of the two
LUTs. In a Virtex-II the storage elements can be configured either as edge-triggered D-flip-flops
or as level-sensitive latches.[6]
2.2.2
The Microblaze core
To enable the development of more powerful embedded solutions with the Xilinx FPGAs the
company has provided a soft core processor3 , Microblaze TM . The core is a high performance,
32-bit, RISC processor that runs at 100 MHz on a Virtex-II device. Furthermore it consists
of a three stage pipeline with separate instruction and data paths (Harvard-style). The core is
illustrated in figure 2.2 below.[8]
Instruction-side
bus interface
Data-side
bus interface
Add/Sub
ILMB
Program
Counter
DLMB
Shift/Logical
Multiply
Bus
IF
Bus
IF
Instruction
Decode
Instruction
Buffer
Register File
32 x 32 bit
IOPB
DOPB
Figure 2.2: The Microblaze core block diagram. Source: [9]

The Microblaze core comprises two bus interfaces, one for the instruction path and one for
the data path. Each of the interfaces is divided into an interface for the On-chip Peripheral
Bus (OPB), and an interface for the Local Memory Bus (LMB). The connection to the on- and
off-chip peripherals and memory is provided by the OPB, while a single-cycle access to on-chip
3 A soft core processor has a configurable architecture. It is possible to add custom design peripherals and/or
instructions prior to synthesis.
dual-port block RAM is provided by the LMB. A Microblaze platform must include one data
path and one instruction path, therefor it will utilize two, three or four bus interfaces.[9]
The Microblaze architecture employ big-endian bit naming convention. That is, the most
significant bit (MSB) in a vector is positioned in bit zero. When designing custom cores, or
using pre-designed peripherals, care has to be taken when connecting vectors with different
endian conventions.[9]
2.2.3
Embedded Development Toolkit, EDK
To facilitate the development of embedded systems based on FPGAs from Xilinx the company
has provided the Embedded Development Kit, EDK. EDK comprises the whole tool chain that
is needed to transform a specification into a running embedded system, as well as the Microblaze
core itself and a large set of other peripherals. Among the supplied peripherals are UARTs,
memory controllers, OPB to PCI bus bridge, and a Ethernet MAC.[10]
The system architecture is specified in a Microprocessor Hardware Specification, MHS, file. In
the file each core of the system is configured and given an address space. The processor and bus
architecture is specified together with all the peripherals. Local and global ports are also defined.
The MHS file is the input to the platform generator tool, which constructs an embedded system
in the form of hardware netlists. In the corresponding Microprocessor Software Specification,
MSS, file the type of software driver for every core of the system is specified. The MSS file is
input to the library generator tool which is employed to configure the peripheral device drivers
and libraries.[10] The system netlist is input to a chain of tools that carries out mapping of the
system, placement of the logic functions onto CLBs, routing of the interconnects, and finally
generation of the bit file that is downloaded to the FPGA[11].
2.3
Ethernet MAC/PHY
In order to be able to communicate with a surrounding network, or with the internet, an embedded system need some sort of network interface. The most widespread network protocol used
today is the IEEE 802.3 standard, a.k.a Ethernet. An Ethernet adapter consists of two parts: the
Media Access Controller, MAC, which controls the transactions, and the Physical layer, PHY,
which is the physical connection to the surrounding network.[12]
2.3.1
Media Access Controller, MAC
The Media Access Controller determines whether the device has access or not. The MAC mechanism is based on a system called Carrier Sense Multiple Access with Collision Detection (CSMA/CD). Carrier sense means that all devices need to listen for a period of quiet before attempting to send. Multiple access imply that when it has been quiet long enough all devices has
equal chance of sending. Finally, due to collision detection, if two devices start to send at the
same time the collision is detected and both quit the attempts.[12]
The Ethernet protocol sends data, and additional information, in packets. Prior to the packet
a seven byte preamble field consisting of alternating ones and zeros is used for synchronization.
Following the preamble is a start of frame delimiter of one byte. The first 14 bytes of the packet
is the header which includes destination address, source address and data type. Following the
header is 46 to 1500 bytes of data. If the data in a packet is less than 46 bytes it has to be padded
with unused bytes. After the data section is finally an error detection section. On the medium
the packets are transmitted serially to four bits in parallel over the shared channel to every
connected device. The transmission method, i.e. the number of bits in parallel, is depending on
the physical layer. After each packet transmission all devices have equal chances of doing the
next transmission.[12, 13]
2.3.2
Physical Layer Device, PHY
Several different types of medium are available for Ethernet networks; coaxial- and twisted pair
cables and optical fibers. There are three common physical layers utilized to connect the Ethernet
MAC to the medium; Attachment Unit Interface (AUI), Medium Independent Interface (MII),
and Reduced MII (RMII). The AUI is an old interface for 10 MBit/s connection only, while MII
and RMII were introduced with 10/100 MBit/s Ethernet standard. MII and RMII offer some
extent of parallelism, MII transport data with four parallel bits and RMII with two parallel bits.
The RMII was developed to reduce the pin count, but instead it utilizes a higher clock frequency.
The physical layer of an Ethernet device conform to certain standards, the device itself does not
know which type of PHY it uses.[14]
2.3.3
The OPB Ethernet MAC
The Ethernet MAC core from Xilinx is designed for 10/100 Mbit/s communication through a
MII physical interface provided by the development board used for this project or another PHY.
On-chip the MAC is connected to the OPB, with 32 bit data width, for communication with
the rest of the system. To achieve 10 Mbit/s Ethernet communication the system clock must
be at least 6.5 MHz. Thus, by dividing the minimum clock frequency with the number of OPB
data transitions per second gives the number of employed OPB clock cycles per transition, see
calculation below.[13]
6500000
= 21
10000000/32
That is, for an average Ethernet MAC cycle 21 OPB clock cycles are used.
The MAC is equipped with a number of design parameters to provides flexibility for the
system designer. There are two major drawbacks with the Xilinx Ethernet MAC though. First
of all, the core is not free of charge, in order to use it for more than a few hours at a time a
license fee has to be paid. Second, on a Virtex-II FPGA the core consumes at least 1555 slices
which is quite a lot if device size or power consumption is an issue.[13]
2.4
Bus architectures
Two different bus architectures are involved in the design in this thesis: the older ISA bus, and
the newer OPB.
2.4.1
The ISA bus specification
Originally, in the IBM PC, the Industry Standard Architecture bus was only 8 bits wide, but
with the evolution towards the IBM PC/AT it was expanded to 16-bit data width with some
additional functionality. At a later stage the ISA bus was extended to 32 bits with the advent
of Extended Industry Standard Architecture (EISA). Still today, the ISA bus is one of the most
common interfaces among Ethernet devices. There are a number of different ISA bus cycles, both
8-bit and 16-bit data width, communicating with processors or direct memory access (DMA)
devices.[15] This section will only deal with the 16-bit version of the ISA bus communicating
with a microprocessor.
The ISA bus can be divided into three different parts; the address bus, the data path, and the
control- and timing signals. A hash sign (#) after a signal name indicates that the signal is active
low. Signals used during memory operation, such as DMA, are omitted since the implementation
in this thesis only work in I/O mode.
Address bus: The system address bus, SA, consists of the lower 20 bits of the microprocessor address. During address time, Ts, the address is latched onto the address bus
and is visible to all ISA peripherals. If address pipelining is utilized by the peripheral,
bit 17 to 23 of the microprocessor address bus can be presented prior to Ts. These bits
are called the latchable address bus, LA4 . Some processors and peripherals also make use
of the system bus high enable, SBHE#, to indicate that the upper half of the data bus,
SD(15:8), will be transferring a byte to an odd address.[15] The Ethernet chip targeted in
this implementation uses this signal completely different however, see section 3.2.2[16].
Data path: The system data bus, SD, is utilized to transfer data during the data time,
Tc, of a bus cycle. The data bus is bidirectional, i.e. it can be used for both read and
write operations. If a peripheral is 8-bit, only the lower path5 is used. For 16-bit transfers
the lower path is used to transfer data to even-addressed locations, and the upper path is
used to transfer data to odd-addressed locations.[15]
Control- and timing signals: Depending on the nature of the ISA cycle, hence if it is
an I/O read or an I/O write operation, the appropriate control signal, IOR# respectively
IOW#, is asserted during Tc.[15]
The ISA bus clock BCLK is derived from the system clock. Usually the ISA clock has a
frequency between 8 and 8.33 MHz. Some peripherals, however, allow frequencies up to 11
MHz6 or more.[15]
The buffered address latch enable, BALE, signal is asserted during the second half of Ts. It
indicates that the address bus is now valid and latched onto SA. When the microprocessor
is not the bus master, i.e. when DMA is utilized for instance, the BALE signal is constantly
asserted. For peripherals that are not fast enough to respond to a standard ISA bus cycle
the channel ready signal, CHRDY, can be utilized. The peripheral deasserts the signals
and, thus, adds clock cycles to the bus cycle until it asserts CHRDY again. To indicate
that the peripheral can support one wait-state I/O bus cycle it asserts the I/O size 16
signal, IO16#.[15]
During power-on the reset signal, RESDRV, is asserted in order to force the peripherals
into a known state. The RESDRV also prevents the peripherals from doing anything until
the power is stabilized or until the microprocessor is ready to receive data or interrupts
from a peripheral. Originally the ISA bus structure had four interrupt lines that were not
assigned to devices, IRQ9 to IRQ11 and IRQ157 .[15]
2.4.2
Standard 16-bit I/O device ISA bus cycles
There are a number of different ISA bus cycle types depending on the nature of the implementation. The data width may be either 8 or 16 bit, the peripheral may be either a memory device
4 This
bus is always zero during I/O operations.

lower path constitutes of bits 0 to 7 on the ISA data bus.
6 The Ethernet chip used in this thesis accepts clock frequencies between 8 and 11 MHz.[16]
7 These names are used in the implementation described in this thesis. The only limitation on the number of
interrupt lines, however, is purely in the system interrupt handler. See section 3.2.3.
5 The
10
or an I/O device. This section describes the standard 16-bit I/O device bus cycle which consists
of one address clock cycle and two data clock cycles. Each step corresponds to a reference point
in figure 2.3.[15]
Tc2
Ts
Tc1
Tc2
BCLK
Address bus, SA
iii
BALE
iv
IOR#, IOW#
vii
Read data, SD
ii
Write data, SD
v
CHRDY
vi
IO16#
Figure 2.3: This figure describes a standard access to a 16-bit I/O ISA device. The figure is a
modified version of figure 17-3 in [15].
i. When BALE is asserted halfway through Ts, the address is latched onto the SA bus. The
address remains on the SA bus for the remainder of the bus cycle, and until the next ISA
address is latched onto the bus.
ii. If the current cycle is a write, the output data is latched onto the SD bus simultaneously
with the address. The valid data is available on the data bus, SD, until halfway through
Ts in the next ISA bus cycle.
iii. The first data cycle, Tc1, starts with the falling edge of BALE.
iv. At midpoint of Tc1, the appropriate read- or write signal is asserted. The command line
remains asserted until the end of the last data cycle, Tc2, during a normal I/O bus cycle.
v. At the second data cycle, CHRDY is sampled. If the peripheral cannot complete the
transaction by the end of this clock cycle, it should deassert CHRDY. Additional data
time is given until CHRDY is asserted to indicate that the bus cycle can be completed.
11
vi. To determine if the I/O device is 8 or 16-bit wide the IO16# is sampled at the midpoint
of Tc2. If asserted the bus cycle will be terminated at the end of Tc2 without any data
steering. The bus cycle will not be terminated if CHRDY is not asserted.
vii. At the end of the last data cycle, the appropriate read- or write signal is deasserted. In
case of a read operation, data is read from the SD bus at the rising edge of BCLK that
terminates the bus cycle.
2.4.3
The OPB bus specification
IBM has developed a family of three different busses for interconnecting cores and custom logic
in system-on-chips, the CoreConnectTM bus architecture. The family consists of the Processor
Local Bus (PLB), On-Chip Peripheral Bus (OPB), and Device Control Register bus (DCR). The
PLB is utilized for interconnection between high-bandwidth devices, mainly in Virtex-II PRO
devices. For instance processor cores, external memory interfaces, and DMA controllers. The
DCR is intended to use for reading of status and configuration registers of lower performance.[17]
However, the current system employs only the OPB from the CoreConnect family, for communication between the processor core and on-chip memory the Microblaze uses Xilinx Local Memory
Bus[9].
The Microblaze utilize one or more instances of the OPB to communicate with on-chip peripherals. The architecture provides a common, easy-to-use, interface for various peripherals.
The bus allows an arbitrary number of bus masters to read from and write to an arbitrary number of slaves. The Xilinx implementation, however, supports up to 16 masters together with
an unlimited number of slaves (depending on hardware resources). When several OPB masters
share a bus, an OPB Arbiter8 is used to grant exclusive bus access. Thus, a master may have
to wait an arbitrary number of clock cycles until the bus is idle. In order to obtain several slave
operations per bus grant an OPB master may utilize a bus lock, also referred to as burst or
sequential access. Sequential access keeps arbitration overhead to a minimum.[18, 19]
Physically the address- and data path, and control signals of the bus are implemented as
a distributed multiplexer where the different slave data busses and other outputs are ORed
together9 . This approach make it possible to add peripherals to a system without changing the
existing peripherals.[18]
The OPB signals are grouped into five categories: arbitration signals, bus signals, data transfer control signals, byte enable support signals, and DMA peripheral support signals. The two
latter categories are optional, and are not discussed in this thesis. This section will describe the
relevant signals for an OPB slave.[18]
Arbitration signals: If a slave does not respond to an operation, or does not assert
the Sln toutSup10 (see data transfer control signals below) within 16 clock cycles after the
OPB select signal is asserted, the arbiter will assert the OPB timeout signal. It indicates
to the master of the operation that the slave does not respond, and the operation has to
be terminated.[18]
If a slave is unable to complete an operation the slave should assert the Sln retry signal.
The assertion will cause the requesting master to cancel the operation. Sln retry must
remain asserted until the slave is deselected.[18]
8 The
Xilinx OPB implementation that comes together with the EDK includes an arbiter.
every slave must drive all outputs to zero when inactive.
10 The Sln prefix indicates that the signal is directed from the slave to the bus. Mn is the prefix for a signal
going from a master to the bus.
9 Thus,
12

Bus signals: Each slave is given an address range during the system specification. To
access a slave, or a specific register in a peripheral, the bus master use the address bus,
OPB ABus. OPB ABus is 32 bits wide and carries its most significant bit in bit 0.[18]
The data input and output signals to and from all OPB peripherals are separated. I.e.
each peripheral contain one 32-bit in-data bus, OPB DBus, and one 32-bit out-data bus.
The data output from all masters and slaves, Mn DBus and Sln DBus, are ORed together
to form the data bus, OPB DBus. Both in- and out-data has its most significant bit in
position 0.[18]
Data transfer control signals: When a bus master is granted to use the bus by the
arbiter it asserts the OPB select signal together with the correct address. The select signal
will be driven high until the slave acknowledge the transaction, or asserts the OPB retry,
or until the OPB timeout is asserted by the arbiter. If the master that is in control of the
bus terminates the transaction by deasserting OPB select, all slaves must terminate the
process and reset their state machines.[18]
The direction of the transaction is indicated by OPB RNW, Read Not Write. It must
be valid any time the OPB select is asserted. If the signal is high it indicates that a
read operation is taking place, and if it is low it indicates that the current operation is a
write.[18]
The bus architecture provides the OPB seqAddr signal to indicate that the following bus
cycle will have the same direction as the current operation to the next sequential address.
Thus reducing the access latency. There will be no intervening bus transactions to other
addresses if the OPB seqAddr is correctly asserted by a master. If the signal is ignored by
the slave, the data transfer proceeds normally.[18]
To indicate that the slave is finished and, in case of a read operation, valid data is available
on Sln DBus, the slave asserts the transfer acknowledge signal, Sln xferAck. The signal
must not be asserted for more than one clock cycle per data transfer, nor in conjunction
with Sln retry. If Sln xferAck is asserted in the same cycle as OPB timeout, the bus master
should ignore the timeout signal and finish the transaction.[18]
If the slave encounter any kind of error it should assert the error acknowledge signal,
Sln errAck, to terminate the operation. The signal must be asserted together with Sln xfer
Ack.[18]
By default the OPB Arbiter asserts the OPB timeout after 16 clock cycles. To prevent
a bus timeout, slow slaves may assert the timeout suppress signal, Sln toutSup, at any
time before the 16th clock cycle. Sln toutSup must remain asserted until the operation is
completed.[18]
2.4.4
The OPB cycle
The length of a OPB bus cycle depends on the slave. With a fast peripheral the cycle can be as
short as two clock cycles, but usually the bus cycle is longer than that. This section describes
a basic bus operation regardless of the speed of the slave. Each step corresponds to a reference
point in figure 2.4.[18]
i. One clock cycle after a master is granted access to the bus by the arbiter it asserts
OPB select. At the same time the valid address and, in case of a write operation, the
valid data is written to OPB ABus and OPB DBus respectively.
13
n-1
OPB_CLK
OPB_ABus
iv
OPB_DBus
i
vi
OPB_select
ii
OPB_RNW
v
Sln_xferAck
Sln_errAck
iii
Sln_toutSup
Figure 2.4: This figure describes a basic OPB transaction. The figure is a modified version of
figure 6 in [20].
ii. At the same time as the select signal is asserted OPB RNW is set to the correct value,
high if it is a read operation or low if it is a write operation.
iii. If the slave does not finish the transaction within 16 clock cycles from the assertion of
OPB select, then it must assert the Sln toutSup signal. Otherwise will the slave not be
able to finish the transaction properly since the arbiter will assert OPB timeout.
iv. In case of a read transaction, the slave will write the data to the data bus during the last
clock cycle. At all other time Sln DBus is driven to zero.
v. When the slave is finished with the operation it asserts Sln xferAck for one clock cycle.
If the slave has been unsuccessful with the transaction it should assert Sln errAck as well
during the last clock cycle.
vi. When the master has registered the Sln xferAck it deasserts OPB select. At the same time
zeros are written to OPB ABus and OPB DBus. When OPB select is deasserted the slave
should deassert any outputs to the OPB, i.e. the outputs should be driven to zero.
14
2.5
Designing OPB peripherals for Microblaze
Due to the complexity of modern SoC devices, a standardization of the connection of different
cores has been an important development issue for Xilinx. The choice of incorporating the
OPB into EDK has made the interfacing of custom logic to a Microblaze system is a relatively
straightforward task.[20]
There are, however, some considerations to keep in mind when designing a custom OPB
peripheral. The core must be compatible with the OPB protocol described in section 2.4.4,
as well as the OPB interface. The design must also meet the requirements of the platform
generator in order to enable the automated system synthesis flow. Additionally there are some
general design guidelines proposed by Xilinx in order to improve timing:[20]
Signals going to and from the user core should be registered
Try to avoid using different clock domains by utilizing Clock Enables
Reset output signals from slaves synchronously using OPB xferAck
If the data width is smaller than 32 bits, expand the data path to 32 bits and tie unused
lines to zero, or apply appropriate steering logic
For compatibility with the platform generator two additional files are needed together with
the code; the .PAO and .MPD files. The first file specifies the Peripheral Analyze Order and
defines which HDL files that are needed for synthesis. The second file is the Microprocessor
Peripheral Description file. It defines the interface of the core, i.e. properties of input and
output ports, synthesis parameters, interrupts etc.[20]
2.5.1
IPIF
To facilitate a common bus interface for core designers Xilinx has developed the OPB IP interface,
IPIF. It is a simplified bus wrapper that takes care of the OPB timing protocol, address decoding,
and appropriate byte steering onto correct byte lanes when the core data width is smaller than the
OPB data width. The interface also includes the following optional features: interrupt handling,
read- and write FIFOs, DMA, and Scatter Gather.[21]
One major disadvantage of IPIF is that it targets CoreConnect bus architectures on Xilinx
platforms only. If a design is to be re-used with a different bus architecture, or on an FPGA of
different brand, the core has to be rewritten.[22]
2.6
Clock domain crossing
The On-chip Peripheral Bus is working synchronously with the system clock11 , while the ISA bus
is working with a clock frequency between 8 and 8.33 MHz. Design of a core that is working in
two different, asynchronous, clock domains need some mechanism for safe transfer of data across
the clock boundary.
One solution is proposed in [23]. When data is ready on the transmitting side a D-flip-flop is
clocked and, thus, asserting a flag signal common to both the transmitter and the receiver. As
long as the flag is high the transmitter must maintain the data on the bus. The receiver reads
the data into a register in the receiver clock domain and clocks a flip-flop that resets the transmit
flip-flop and pulls the flag low. When the flag is low the flip-flop on the receiver side is reset.
11 The
system clock is 66 MHz in this case
15
Parallel data
Transmitter
Receiver
Flag
High
CLK
Ready
Clear
High
CLK
Clear
Acknowledge
Figure 2.5: A safe circuit for moving data across asynchronous clock boundaries. Source: [23]
Chapter 3
Implementation & Testing

This chapter gives an account for the different issues related to the design, implementation and
testing of the OPB to ISA bus bridge. The first section describes the different Ethernet options
available and how the choice was made, the second section explain the bridge, and the third
section deals with the testing issues related to the implementation. Everything in this chapter,
text and figures, that do not have a reference is a contribution by the author.
3.1
Choosing Ethernet MAC/PHY
One of the IP cores that is provided with the EDK is the OPB Ethernet MAC core. In conjunction
with an off-chip physical layer it provides a working network interface. One drawback with the
core, however, is its size. When included in a Microblaze based embedded system it will use
almost one third of a Virtex-II device with one million gates. Since the FPGA might be utilized
for more applications, than merely a microprocessor connected to a local network or to the
internet, it is desirable to find a solution where the system is cooperating with an external
Ethernet MAC/PHY device. Another drawback is that the Xilinx Ethernet core is not free,
after three hours of use it has to be restarted unless a licence fee is paid.
In order to connect the Ethernet MAC/PHY to the Virtex-II FPGA and the Microblaze
system, the Ethernet device has to meet certain requirements:
The I/O signals between the FPGA and the Ethernet chip must be run at 3.3V.
For convenient testing and connection the chip need to be readily available on some sort
of development board1 .
The communication interface between the chip and the system need to be of a known type
which is either available in the Microblaze system or possible to implement.
The operating system should contain a device driver for the chip of choice, otherwise a
device driver need to be implemented.
It should be possible to change the Ethernet MAC/PHY to another device in the future.
At this stage there is no requirement on the communication speed of the Ethernet device, thus
either a 10 Mbit/s or faster chip can be utilized.
1A
development board is a printed circuit board containing all overhead circuitry needed to use the chip.
16
17
There were several candidates when choosing an Ethernet MAC/PHY chip to use in conjunction with a Microblaze based embedded system. The considered chips were:
Cirrus Logic CS8900A
Davicom DM9008
Realtek RTL8019AS
Standard Microsystems Corporation LAN91c96 and LAN91c111
All of the chips provided an ISA-bus interface, and the LAN91c111 had several other interfaces as
well. Also, the LAN91c111 offered 10/100 Mbit/s communication speed2 . No Ethernet MAC/PHY devices from Intel were considered since they employ the PCI bus architecture which is not
suitable to use with the target operating system, uCLinux, due to its complexity. The DM9008
and RTL8019AS offered only 5V I/O signals, hence unsuitable to use in conjunction with the
Virtex-II FPGA which only supports 3.3V I/O signals. Of the remaining three only CS8900A
was readily available on a development board. The option of designing a custom printed circuit
board (PCB) for the LAN91c111 was considered, but the idea was rejected due to limited time
and the level of PCB design experience. Thus, the CS8900A was chosen as the Ethernet MAC/PHY for this implementation. However, since the ISA-bus interface is widely spread among
the available Ethernet MAC/PHY chips, future implementations of a Microblaze system with
external MAC/PHY are not bound to use CS8900A. The only requirement which was not met
is thus the lack of interface between the Ethernet chip and the Microblaze system.
The operating system of choice for the system, uCLinux, contain a well tested driver for the
CS8900A chip. Thus, no such development needed to be undertaken.
3.2
OPB to ISA bridge
Prior to this work, no known IP core connecting the OPB with the ISA bus existed. Consequently
a core linking the two bus architectures needed to be developed.
The first attempt was to employ the IP interface (IPIF) provided by Xilinx. It was, however,
unsuccessful due to immature nature of IPIF. Instead a more straightforward bus interface was
created similar to the interfaces of the existing OPB peripherals where a simple bus wrapper is
created to interface the custom logic with the OPB.3
The OPB to ISA bus bridge was implemented as a custom OPB slave peripheral. The initial
step in the design flow was to identify the different parts of which the core should consist. These
parts were designed as independent entities to enable a smaller scale development. Thus, the
simulation and functional verification of every entity was carried out separately, see section 3.4.
A modular design methodology also enables future development of the core to be carried out
conveniently with redesign only of the part that need to be changed.
The design can, roughly, be divided into three different areas; the OPB interface, the ISA
interface, and the glue logic around and inbetween the bus interfaces. The different parts are:
Bus wrapper
OPB interface
2 In
order to utilize the 100 Mbit/s speed the interface clock need to run at least at 25 MHz if a MII PHY
interface is employed.
3 Only IPIF from EDK v3.2 was tried, recent releases of EDK include a revised version of IPIF which might
work correctly.
18

ISA interface
Timeout watchdog
ISA clock generator
OPB to ISA communication (clock domain crossing)
Figure 3.1 shows the overall layout of the core and its signals. Included in the glue logic is the bus
wrapper, the timeout watchdog and the clock domain crossing (CDC) mechanism. The pselect
module is shown in the figure, but is included as a part of the bus wrapper. The clock boundary
is defined by the dashed line.
OPB clock domain
OPB_select
ISA clock domain

Bus wrapper
pselect
OPB_select_i
OPB_ABus(0:31)
OPB_DBus(0:31)
OPB
interface
OPB_BE(0:4)
OPB_RNW
ISA
interface
Data to OPB
Ready 1
Ready 2
OPB to ISA
Acknowledge 2 communication Acknowledge 1
Flag 2
ISA_Finish
I2O_errAck
ISA_Failure
I2O_toutSup
I2O_retry
OPB_select_i
OPB_Rst
ISA_BCLK
ISA_BALE
ISA_IOR
Flag 1
I2O_xferAck
OPB_clk
ISA_SD(15:0)
ISA_SHBE
OPB_seqAddr
I2O_DBus(0:31)
ISA_SA(19:0)
ISA clock
generator
Timeout
watchdog
ISA_IOW
ISA_RESDRV
ISA_IO16
ISA_CHRDY
ISA clk
Interrupt9
IRQ9
Interrupt10
IRQ10
Interrupt11
IRQ11
Interrupt15
IRQ15
Figure 3.1: This block diagram illustrates the different parts of the bus bridge
3.2.1
Specification
Table 3.1 gives an account for the specification of the different parts of the core on different
issues.
The OPB interface and the ISA clock generator are working synchronous to the system clock
which is equal to the OPB clock, while the ISA interface and the timeout watchdog are working
19
synchronous to the ISA clock signal. The communication module is asynchronous and triggers
on the ready- and acknowledge signals from the bus interfaces. The signals to the CDC, however,
are synchronous to the respective clock domain.
The bus bridge is activated when the OPB select signal is asserted together with an address
on the OPB address bus which is in the defined address range of the core, the address range
is set in the MHS file during system design. When the bridge is inactive all output signals to
the OPB are driven to zero, see section 2.4.3. Since the bus bridge is an OPB slave it is never
triggered by an ISA peripheral. Thus, the ISA interface is only started when an address or data
is available from the OPB side. According to specification, section 2.4.1, the address and data
busses on the ISA side are latched. That is, at a certain time in the ISA bus cycle address, and
in case of a write operation, data are written to the respective bus. The content on the busses is
not changed until the next ISA bus cycle. The ISA control signals are registered, however, and
reset at the end of each bus cycle. In the glue logic the address- and data paths are registered
and driven to zero by the OPB interface when the bridge is inactive. The control signals, such
as ISA Finish and ISA Failure, are registered and synchronous to the clock signals as well, while
the flag signals from the CDC are registered but asynchronous to the clock signals.
issue
clock
handshake
data bus consistency

address bus cons.
control signal cons.
3.2.2
Table 3.1: Bus bridge specification

OPB
Glue
System clock
System and ISA clock
Triggered by
CDC started by
OPB select signal
ready signals,
and correct address
watchdog triggered
by internal select
Zero when inactive
Zero when inactive
Zero when inactive
Zero when inactive
Zero when inactive
Registered
ISA
ISA clock
Started with the
rising edge of the
flag indicating
available data
Latched data
Latched address
Registered
Components
Every module that performs a series of tasks with inputs from other parts of the core, or other
parts of the system was designed as a finite state machine. That is, the two bus interfaces and
the timeout watchdog. The finite state machine approach provided a straightforward method to
make the bus interfaces speak the particular bus specification since a FSM is clock dependent and
the bus architectures are synchronous. During synthesis the state machines are highly optimized
by the synthesis tool, which minimize the device utilization. The ISA clock generator and CDC
modules were not implemented as finite state machines but with a register approach.
In all three cases the finite state machines were of Moore type4 . That is, the outputs from
the state machines are dependent of the current state and independent of the input signals. It
was necessary to use the Moore approach since the output signals from the finite state machines
had to be synchronous to the clocks in order to strictly follow the bus specifications.
Bus wrapper
The OPB to ISA bridge bus wrapper provides the interface between the core and surrounding
system, and ties the different parts together to one visible entity. In figure 3.1 the wrapper
4 The alternative approach is the Mealy state machine. In such machine the outputs are affected by the inputs
and can be altered asynchronously.
20
is defined by the line surrounding the different modules. Apart from the modules designed
specifically for this core, and discussed below, the wrapper also consists the pselect module. It
is a highly optimized address decoder provided by Xilinx. It takes the OPB select signal and
the address bus as inputs and generates the internal OPB select when the address on the bus is
within the address range of the core that is specified in the MHS file.
A number5 of custom parameters are used by the wrapper to enable flexibility during system
design, see lines 36 to 40 in listing E.1.
C ISA CLK DIV is an integer forwarded to the ISA clock generator which specifies the
factor by which the system clock should be divided by to obtain the ISA clock signal. By
default this constant is set to 8 which is a suitable division factor for the system used
during the design and implementation of this core.
C USE CHRDY is a bit used by the ISA interface to decide whether it should wait for
the CHRDY signal to be asserted or not before the bus cycle is finished. By default this
constant is set to 1.
C NUM ISA CYC TOUT is an integer forwarded to the timeout watchdog telling it how
many ISA clock cycles to wait before ISA Failure should be asserted. By default this
constant is set to 16 clock cycles.
C ON CHIP SL ONLY is a single bit telling the bus wrapper whether the ISA peripherals
will be on-chip only, or both on- and off-chip. It is necessary for this parameter to be 1 if
only on-chip peripherals are connected to the ISA bus. If no peripherals are connected to
signals going off-chip, the signals will end up in an undefined, or high, state. By default
this constant is set to 1 and should thus be changed when the off-chip Ethernet MAC is
connected to the ISA bus interface.
C NUM ON CHIP SL is an integer telling the bus wrapper how many on-chip peripherals
are connected to the ISA bus. It is used to generate the correct number of CHRDY signal
inputs, see lines 237 to 274 in listing E.1. By default this constant is set to 1.
The signals to and from the ISA bus are connected to IOBs in the FPGA, see section 2.2.1.
Insignals to the core, however, cannot be shared by on-chip peripherals and IOBs. Consequently
on-chip counterparts of global insignals must be created when using on-chip ISA peripherals.
This feature might be removed in the future due to the questionable use of such peripherals.
On-chip peripherals are used for debugging and verification purposes, see sections 3.3 and 3.4.
OPB Interface
The OPB interface is connected to the OPB side of the bus wrapper. Its main responsibility is
to communicate with the on-chip peripheral bus according to the bus specification, see section
2.4.4. The OPB interface is also responsible for initiating the ISA bus cycle. The state machine
consists of six states; Idle, Send, Waiting, Receive, Finish, and Failure, as illustrated in figure
3.2. The code for the OPB interface is presented in listing E.2.
When the bus bridge is addressed by the processor, the OPB interface is woken from its Idle
state by the internal select signal on the next system clock cycle. The internal select signal,
OPB select i, is generated by the pselect module in the bus wrapper. During the Send state the
ISA bus cycle is started by asserting the OPB interface ready signal and keeping the address, and
data during a write operation, available and unaltered until the flag goes low. The flag, which
5 Five
in the current implementation, the number might grow due to future developments of the core.
21
reset
Idle
select = 0
select = 1
Send
ISA_Failure = 1
xfer_success = 1
ISA_Finish = 1
Waiting
RNW = 1
Finish
Ackn = 1
Receive
Failure
ISA_Failure = 1
Figure 3.2: The OPB Finite state machine

is controlled by the clock domain crossing mechanism, is deasserted when the ISA interface is
declaring its acknowledge signal, see section 2.6. The falling edge of the flag changes the internal
signal xfer success from zero to one, the transition of xfer success back to zero is done when the
FSM reaches its Waiting or Idle states, or upon a reset of the bus bridge, see lines 186 to 194 in
listing E.2. When xfer success is asserted the next FSM state is set to Waiting6 .
The OPB RNW signal indicates if the current transaction is a read or a write. In case of
a read transaction no waiting is carried out in the Waiting state, during the next clock cycle
the FSM is set to Receive and the waiting for data is done in that state instead. When data is
read from the ISA bus and the ISA to OPB flag is high, data is written to the I2O DBus. The
state machine steps into its Finish state when the OPB interface has asserted its Acknowledge
signal. If the ISA peripheral fails to assert CHRDY the bus cycle will be cancelled by the timeout
watchdog and the next state in the FSM is set to Failure. During a write transaction, however,
the OPB interface is waiting for the ISA interface to acknowledge the write in the Waiting state.
When the ISA interface has successfully written the data to the ISA peripheral the ISA Finish
signal is asserted, see the section about the ISA interface. ISA Finish causes the OPB FSM to
step into its Finish state from which the state machine goes back to Idle at the next clock cycle.
If the ISA interface does not assert ISA Finish, due to the ISA peripheral not asserting CHRDY,
the write operation will be cancelled by the timeout watchdog.
When idle the OPB interface is required to drive all of its outputs to the OPB bus to zero
6 The
reason for calling the state Waiting instead of Wait is that the word Wait is a reserved keyword in VHDL.
22
due to the signals from different peripherals are ORed together to form the bus lines. Since an
I/O ISA bus cycle is bound to employ at least three ISA clock cycles, equivalent to 24 system
clock cycles, the timeout suppress signal, I2O toutSup, should be asserted as soon as a bridge
transaction is started. I2O toutSup must remain asserted until the transaction is successfully
finished or cancelled. In this implementation the toutSup signal is asserted when the finite state
machine reaches its Send state, and stays asserted until the bridge transaction is finished or
cancelled. That is, the I2O toutSup signal is only deasserted when the OPB FSM is idle. When
a transaction is finished I2O xferAck is asserted during the last OPB clock cycle. In case of a
failure I2O errAck is asserted in conjunction with xferAck to indicate to the host system that
the transaction failed.
The On-chip Peripheral Bus employs big endian bit ordering, i.e. the most significant bit is
located in position 0 of the data field. The ISA bus, on the contrary, employs little endian bit
ordering where the least significant bit is located in position 0. Data going to the ISA bus is
located in bits 0 to 15 on the OPB DBus, and data coming from the ISA peripheral should be
written to bits 16 to 31 on the I2O DBus. Also, only the lower 8 bits of the OPB ABus is of any
importance for the ISA bus. The upper 24 bits are used to address the bus bridge itself. The bit
reordering, and bit steering, is carried out by the OPB interface, see lines 238 to 269 in listing
E.2.
If a bridge transaction is cancelled by the system, or if the core for any reason is reset, the
OPB state machine is set to Idle. Thus, all internal and external signals are reset to a known
state. Furthermore, if the ISA interface does not respond properly the state machine will always
reach the Failure state due to the timeout signal from the watchdog. Thus, the state machine is
free from deadlocks.
The design of the OPB interface was a fairly straightforward task because of the many
examples available with the EDK. To improve the timing the guidelines in section 2.5 were
followed as close as possible. That is, the inputs from, and outputs to, the OPB were registered,
the core is reset when the bridge transfer is acknowledged (OPB xferAck is asserted) and the 16
bit data path from the ISA interface is expanded with zeros to 32 bit width. Observe that some
signals are not explicitly registered, the outputs from the FSM for instance. During synthesis,
however, all signals are registered.
ISA Interface
Connected to the ISA side of the bus wrapper, the key responsibility of the ISA interface is
to communicate with on- and off-chip ISA peripherals. That is, the ISA interface should act
as a bus master on the ISA bus and carry out bus cycles according to the specification, see
section 2.4.1. The ISA interface state machine consists of four state; Idle, Address, Data1, and
Data2 in conjunction with the ISA bus cycle specification, see figure 3.3. Note that the ISA
bus cycle is only started by the Microblaze system, through the OPB interface, and never by a
ISA peripheral. A peripheral can, however, notify the system that data is available by giving
an interrupt if interrupts are supported by the device driver. The code for the ISA interface is
presented in listing E.3.
The state machine is started when the flag from the clock domain crossing module indicates
that valid address and data is available from the OPB interface. Once the state machine is
started it spends one clock cycle at each of the two first states Address and Data1. At the last
state, data2, the state machine is dependent on the CHRDY signal to be asserted in order to
finish the bus cycle.
Originally the ISA interface module was designed to always wait for the CHRDY signal to be
asserted in order to continue. It is not mandatory, however, that the ISA peripherals utilize the
23
reset
Idle
flag = 1
Address
Address ready
Data1
Data1 ready
Data2
CHRDY = 1
Figure 3.3: The ISA Finite state machine
signal. The CS8900A development board used for this project, for instance, does not indicate
that it has done a successful read or write by asserting CHRDY. The ISA interface simply
assumes that the peripheral is working properly, in a commercial system, however, the CHRDY
signal should be utilized to ensure that data is read and written correctly. To overcome the lack
of CHRDY signal from the ISA peripheral a parameter was introduced in the core that indicate
if the ISA interface should check the signal or not. The parameter is set in the MHS file during
system design. If the ISA peripheral is not using CHRDY, the internal counterpart is set high
during synthesis.
According to specification the BALE signal should do a low to high transition at the falling
clock edge in the address cycle, and fall again on the next rising edge of the ISA clock. To obtain
this feature the bale signal needed to be ANDed together by two signals; one that is set to high
at the falling edge of the ISA clock in the address cycle and low at all other falling edges of the
clock, and one that is high during the address cycle. See lines 123 to 160 and 289 to 290 in listing
E.3. The falling edge of the BALE signal marks the end of the address cycle and the transition
from the Address state to the Data1 state. On the falling ISA clock in the middle of Data1 the
appropriate read (IOR) or write(IOW) signal on the ISA bus should be declared. The signals
are active low and should go high again at the end of the last data cycle. IOR and IOW are
achieved in a similar fashion as the BALE signal, see lines 166 to 178 and 294 to 295 in listing
E.3.
The SBHE (system bus high enable) is an active low signal that indicates that a transfer on
24
the high bytes of data bus is about to take place. The CS8900A chip requires that a high to
low followed by a low to high transition is provided by the signal after any hardware or software
reset. As for the IO16 signal, it is not utilized by the CS8900A development board, and it is
omitted in this implementation. At this point it is assumed that only 16-bit ISA peripherals will
be connected to the bus bridge.
The ISA data bus is bi-directional, i.e. the same bus lines are used for both reads and writes.
To achieve bi-directionality the data bus is implemented as tri-state buffers as recommended in
[20].
The internal reset signal in the ISA interface is created by ORing the OPB Rst, the Failure
signal from the watchdog, and the inverse of the OPB select i. That is, the ISA interface is reset
and the state machine is set to Idle at any global reset, timeout failure, or if the core for any
reason is deselected by the system. Hence, the state machine will never be trapped or deadlocked.
At a reset the RESDRV signal is asserted resetting all ISA peripherals as well. Consequently
the ISA interface can never reach a deadlock situation where it is keeping the rest of the system
waiting.
Timeout watchdog
One of the most critical parts of the OPB to ISA bus bridge is the timeout watchdog. It ensures
that the core never consumes more than a specified amount of clock cycles. Needless to say, it
is vital that the timeout watchdog never fails since its most important task is to reset the bus
interfaces during an error in the ISA interface or in a peripheral.
OPB_select = 0
Idle
ISA_Finish = 1
flag = 1
Counting
Timeout = 1
Failure
Data1
Figure 3.4: The Timeout Watchdog Finite state machine

The watchdog is constructed with one counter and one finite state machine. The three states
of the machine are; Idle, Counting, and Failure, see figure 3.4. As shown in figure 3.1 the
watchdog has four inputs; ISA clock, OPB to ISA Flag, OPB select, and ISA Finish, and one
output; ISA Failure. It is working synchronous to the ISA clock and the state machine is started,
by changing state from Idle to Counting, when the flag is high. When the counter reaches its
25
limit an internal timeout signal is asserted which change the state from Counting to Failure.
During the Failure state the ISA Failure signal is asserted to the bus interfaces. If the ISA
interface asserts its ISA Finish signal the state machine is put to Idle again. Moreover, if the
bridge transaction is cancelled, i.e. if the internal select signal is going low, the state machine is
set to Idle and, consequently, the counter is reset and will never reach a deadlock situation. The
VHDL code for the timeout watchdog is presented in listing E.4.
The maximum length of an operation is parameterized, and hence defined by the system
designer at synthesis, to provide flexibility. In a real-time system there might be limits on the
maximum bus cycle length in order to secure the task schedule, i.e. a task might execute every
100 OPB clock cycles and thus limiting the maximum length to 12 ISA clock cycles.
ISA clock generator
Since the ISA clock, according to specification, is defined to run at a frequency between 8 and
8.33 MHz some sort of clock generator is needed to provide the signal. Ultimately, the ISA clock
should be independent from the system clock, but in this design it is generated by division of
the system clock, see listing E.5. The division factor is parameterized, i.e. when the system is
defined it is possible to use a correct factor depending on the system clock. If the system clock
is running at 66 MHz, for instance, the factor should be eight to obtain a 8.25 MHz clock signal.
The ISA clock generator is running constantly, regardless if the bus bridge is utilized or not, to
provide the ISA peripherals with a clock signal.
The 8 MHz frequency limit is only theoretical, some modern ISA peripherals is able to
run at higher speed. E.g. the CS8900A Ethernet MAC/PHY can run at 11 MHz. A higher
clock frequency is easily obtained during system design simply by changing the clock division
parameter. Running the ISA bus at a higher frequency might render less wasted processor cycles.
OPB to ISA communication
Another important module of the bus bridge is the safe mechanism for transport of address,
data, and signals across the clock domain boundary. Since the OPB interface work synchronous
to the system clock, and the ISA interface synchronous to the ISA clock, transfer of address and
data from one side to the other cannot be carried out in a standard fashion. Instead the method
discussed in section 2.6 had to be implemented.
The module itself is not very advanced, it merely consists of two instances of the clock
domain crossing mechanism, see listing E.6. Equally simple is the CDC itself containing only
two registers with asynchronous reset. The inputs are the ready signal from the transmitting side
and the acknowledge signal which the receiving side asserts when the data is safely transferred.
The output is the flag signal which is asserted when the transmitting side has signaled that it is
ready, see listing E.7. No data is actually transferred through the communication module, its task
is purely to provide the bus interfaces with the flag signals. When a flag is high, the transmitting
bus interface is prevented from altering the data until the receiving side has acknowledged the
transfer.
3.2.3
Interrupts
In the ISA specification there are four interrupt channels that are not used by other peripherals in
the original IBM PC. These are called IRQ9, IRQ10, IRQ11, and IRQ15. In this implementation
nothing is done to the interrupt lines in the core, the interrupts are forwarded to the Microblaze
system as Interrupt9, Interrupt10, Interrupt11, and Interrupt15. In this fashion no local interrupt
handler needed to be implemented. Instead the interrupts from the ISA bus is handled by the
26
system interrupt controller. The core is not limited to four interrupt lines, only the limit of a
maximum of 32 interrupt lines to the system interrupt controller need to be remembered by the
system designer.
When an interrupt has been generated by an ISA peripheral it is first handled by the system
interrupt controller which is connected to the OPB. Depending on the nature of the peripheral
the interrupt controller takes the appropriate measure. In the case with the CS8900A Ethernet
MAC/PHY the interrupt controller should notify the device driver in uCLinux. The device driver
is programmed to read the interrupt status queue, located on the CS8900A, until it is empty.
Thus, the system is only interrupted once if several interrupts are generated by the same device.
The bus bridge is not affected if an ISA interrupt is received from another peripheral in the
middle of a bridge operation. The interrupt should then be queued in the interrupt controller.
It is, however, up to the system designer to make sure that the controller behaves that way.
3.3
ISA General Purpose I/O, GPIO
Due to the delivery delay of the CS8900A development board a different instrument for testing
and verification of the core was required. To achieve a simple but useful peripheral with short
development time, and high chance of success, an emulator of the OPB GPIO7 was designed.
A GPIO can be used for many different purposes, but in this case it is employed to read from
programmable buttons, or the DIP switches, and write to the two 7-segment LED displays on
the Virtex-II development board.
In addition to the standard ISA bus signals the ISA GPIO also has a 24 bit GPIO tri-state
port which communicate with the switches and LEDs on the development board. As a parameter
during system design it takes a 12 bit base address. Thus it is possible to create multiple instances
of the ISA GPIO connected to the same bus bridge.
resdrv
addr_ok
address(19:0)
bale
clk
Adress decoder
CHRDY reg.
chrdy
gpio_i(23)
data_o(15:0)
ior
gpio_ce
Idle
addr_ok = 1
Data
Data in
gpio_o
data_i(15:0)
iow
Data out
Data out register

gpio
gpio_i
gpio_t
Figure 3.5: A block diagram describing the ISA GPIO.
7A
core shipped with the EDK.
27
The GPIO core consists of one very basic finite state machine, one address decoder, two data
transfer registers, and one register generating the CHRDY signal, see figure 3.5. As illustrated
in the figure, the state machine does only contain two states; Idle and Data. When the address
decoder determines that the 12 lower bits on the ISA address bus is equal to the peripheral
base address it asserts the addr ok signal, see lines 102 to 113 in listing E.8. The high addr ok
signal makes the finite state machine change state from Idle to Data. The state machine stays
in the Data state for one clock cycle in which the gpio ce signal goes high. When the gpio ce is
high, the address decoder is reset and the data registers are enabled, i.e. data is read or written
depending on the read and write signals. In the code there are two different versions of the
CHRDY generation, as illustrated on lines 123 to 137 in listing E.8. Both takes switch number
one on the development board as an input, and generates the CHRDY signal depending on how
the switch is set. The difference between the two implementations is that the one using an
FDRE 18 register only generates the high OPB errAck signal when the CHRDY is not asserted,
whereas the one using the FDR 1 register generates a high OPB errAck for every illegal address
on the ISA address bus. The FDRE 1 implementation might, however, result in system errors
in uCLinux.
Since the ISA GPIO is designed to replace the OPB ditto, the bit order of the GPIO signal
is not changed from big endian to little endian. Instead the bit steering is taken care of by the
read and write data registers. That is, during one transition from the OPB to the GPIO, or vice
versa, the data is changed from big endian to little endian and back to big endian again.
3.4
Testing methodology
To verify that the design was working properly two different methods of testing was applied.
During the design phase testing by simulations were carried out on the different modules of the
core independently, and finally on the entire core. To verify the functionality after synthesis,
on-chip verification was utilized. Both of these methods were powerful tools that together proved
the functionality of the core.
3.4.1
Simulations
Every part of the design was constructed as independent VHDL entities using Xilinx ISE 6.2.
This methodology enabled continuous testing and simulation with ModelSim. That is, it was
possible to verify that the bus interfaces were working according to the specifications, that the
clock generator created a correct clock signal, that the clock domain crossing mechanism worked
according to theory, and that the timeout watchdog asserted the failure signal after the correct
number of clock cycles. It also shortened the coding-debugging-coding cycle significantly since
the synthesis of a small core is much faster than the synthesis of a large one consisting of many
parts.
ModelSim can be employed for simulation in many different steps using the same testbench.
A testbench is a core that is connected to the simulated one and provides the meaningful inputs
and also monitors the outputs. The first step is behavioral simulation where the inputs from the
testbench are run through the logic of the core and generates waveforms on the output. When
satisfactory results were obtained from the behavioral simulation the most advanced simulation
method was utilized. The post-place-and-route-simulation which synthesize the core all the way
through the synthesis chain prior to simulation. This renders simulation results that not only
8 FDRE 1 is a register with synchronous reset and clock enable triggering on the falling clock edge, while FDR 1
is lacking the clock enable function.
28
verifies the logical behavior, but also verifies that the timing in the core is correct. It also takes
into account the signal path latencies. That is, that signal dependencies are not ruined due to
other signals running late.
When all modules in the system were independently verified to work properly by post-placeand-route-simulation the whole core was assembled into the wrapper. A new testbench was
constructed that handled all the inputs and outputs of the entire core, and the core was simulated and verified to work with post-place-and-route-simulation. Waveforms from four different
simulations are presented in appendix G. The first two are read operations and the last two
are write operations. The difference of the two simulations of each kind is that in the first one
CHRDY is set to zero, whereas in the second one it is asserted. That is, the first simulation,
CHRDY = 0, simulates an unsuccessful transaction, and the second simulation, CHRDY = 1,
simulates a successful transaction. A comparison of the simulation waveforms to the ISA bus
cycle specification in section 2.4.1 shows that the simulated system is working correctly.
3.4.2
On-Chip verifications
Another very powerful verification tool provided by Xilinx is ChipScope PRO, see appendix D
for a short tutorial on how to use it. When using ChipScope one extra core is added to the
system after system synthesis and before the other steps in the chain towards a bit file, see
section 2.2.3. The core listens to, and monitors, chosen signals for a number of samples and
sends the data through the JTAG connection to the software on a PC. The software gives the
user the opportunity to chose which signal events to trigger on.
It is next to impossible to verify the functionality of the OPB to ISA bus bridge without
any peripheral connected to the ISA bus. Therefore the ISA GPIO peripheral in section 3.3 was
employed. During the testing with the GPIO the need for on-chip versions of the ISA in-signals
was discovered, hence such signals were implemented in the bus wrapper. Tests were done with a
single and multiple instances of the GPIO connected to the ISA bus. No functionality problems
were discovered, though when testing with the uCLinux system it was found that some altering
with the internal system addresses in the operating system had to be done to reach success. Also,
it was noticed that it might be useful to implement some sort of initialization chain in the bus
bridge, see section 5.2.
Another bug that was found and fixed during on-chip verification was that the toutSup signal
sometimes was asserted at the same time as the OPB arbiter cancelled the operation. This
happened due to that the toutSup signal previously was asserted when the OPB FSM reached
the Waiting state. The bug was fixed by asserting the toutSup signal in the Send state instead.
To render reads and writes from the Microblaze processor to the ISA GPIO the XMD software
was used. XMD is used to connect to, and communicate with, the debug serial port of the system.
With the program it is possible to read or write from different addresses, and registers, in the
system address space. The testing of the core with the ISA GPIO and ChipScope confirmed that
the bus bridge worked correctly according to the bus specifications. Experiments also showed
that the timeout watchdog cancels the bridge operation if the ISA peripheral does not react in
time. More details are found in chapter 4
Chapter 4
Results & Discussion

The major outcome of this project is an IP core containing a OPB to ISA bus bridge. It can,
however, be altered to a general purpose interface between the OPB and any off-chip peripheral
working at a different clock frequency. The modular nature of the core enables quick redesign
to suit different interfacing purposes. The ISA interface, for instance, can be altered to interface
different chips, or the clock generator can be remodelled to generate an independent clock signal
at any frequency.
When the bus bridge together with the ISA GPIO worked according to specification and
showed no evidences of any bugs or misbehavior, then the bridge and the GPIO was finally
utilized in conjunction with the uCLinux operating system. uCLinux is the operating system of
the embedded system at ITEE which the bus bridge is primary designed for. No problems were
encountered using the cores together with the operating system either. A GPIO test program,
constructed in uCLinux for other purposes, executing a series of reads and writes to the GPIO
was executed without any errors being observed. Thus, the OPB to ISA bus bridge was judged
to work without any major bugs. On the other hand, since the bus bridge has not been tested
with the CS8900A Ethernet MAC/PHY yet, it cannot be taken for granted that all possible bugs
are found and fixed.
Figure 4.1: A read operation monitored by ChipScope. The scale above the waveforms show the
system clock cycles.
In figures 4.1 and 4.2, one read and one write operation are showed as monitored by Chip29
30
Scope. A comparison with figure 2.3 shows that the bus bridge is working according to the ISA
specification in both cases.
As seen in figure 4.1, the ISA bus cycle is started two system clock cycles after the assertion
of the toutSup signal. Initially the bale and the IOR signals are asserted according to the
specification. On the rising edge of the ISA clock, indicating the end of the second data cycle
the data available on ISA data in is read by the ISA interface, and one system clock cycle later
the data is written to the OPB data bus. It is worth investigating why it takes one extra system
clock cycle before the bridge cycle is finished by the declaration of the xferAck signal.
Figure 4.2: A write operation monitored by ChipScope

During the write operation, illustrated in figure 4.2, five system clock cycles were wasted
waiting for the ISA bus cycle to start. It is worth noting however, that a few system clock cycles
are saved in the end of each write operation since the ISA interface signals that the transaction
is finished as soon as the CHRDY signal is asserted in the second ISA data cycle.
Figure 4.3: A failing read operation monitored by ChipScope

In the case where CHRDY is used, but not asserted by the peripheral, the bus bridge will
cancel the transaction when the watchdog signals ISA Failure. Figures 4.3 and 4.4 shows that
the bus bridge will consume more system clock cycles while waiting. The figures also show
that at the end of the failed bus transaction the errAck signal is asserted together with the the
31
xferAck signal. Several experiments where CHRDY was low showed that the timeout watchdog
was working properly. Note also that even though the CHRDY signal is not asserted during a
write operation data is still written to the ISA data bus, and could be read by the peripheral.
Figure 4.4: A failing write operation monitored by ChipScope

This implementation of the OPB to ISA bus bridge only works according to the standard
16 bit I/O device ISA bus cycle specification. The ISA specification include a few other bus
cycles as well, for instance the 8 bit I/O device bus cycle and the 16 bit memory device bus
cycle. The 8 bit I/O device cycle was omitted due to the lack of interesting 8 bit ISA peripherals
today, especially Ethernet MAC/PHYs, and due to the lack of direct memory access (DMA)
functionality in the target system the memory device bus cycles were omitted as well. It should
not be impossible, however, to extend the bus bridge to support DMA in the future.
4.1
Device utilization
One of the objectives of the project was to create a Ethernet solution which minimized the usage
of the FPGA. Hence, a comparison of the FPGA usage for different solutions would be of interest.
The place-and-route tool outputs a summary of the device utilization. The outputs from some
different systems are present in appendix F, and summarized table 4.1 below.
A Microblaze system without any kind of Ethernet connection, EMAC or OPB to ISA bus
bridge, utilize 1884 of the 5120 slices and 146 of the 324 IOBs on a Virtex-II FPGA with one
million system gates. Note that this is not the smallest possible Microblaze system, but it is the
system used in this project. The same Microblaze system with an added on-chip Ethernet core
use 3552 slices and 165 IOBs. That is, the OPB Ethernet MAC core from Xilinx is almost as
big as the Microblaze system. If the on-chip Ethernet core is replaced by the OPB to ISA bus
bridge instead, only 1976 slices are occupied together with a maximum of 192 IOBs. The bus
bridge need 46 IOBs if all 20 ISA address lines need to be connected to the peripheral. When
using the CS8900A chip, however, only the 4 lowest address lines are needed. I.e. the number of
employed IOBs can be reduced to 30, or 176 for the whole system.
The advantage of using the OPB to ISA bridge with an external Ethernet MAC/PHY chip
is clearly the lower device utilization which gives room for other tasks or functions to be implemented in hardware or enables usage of a smaller device with less power consumption and unit
price. Another advantage is that the OPB to ISA core is free to use without limitation, whereas
the MAC is not. The downside with using an external Ethernet MAC/PHY together with the
32
Table 4.1: Device utilization

Unit
Slices
IOBs
Virtex-II
5120
324
Microblaze system
1884
146
EMAC
1668
19
Bus bridge
92
46 (maximum)
OPB to ISA bridge is the low clock frequency of the ISA interface that wastes clock cycles on
the Microblaze system, see next section.
4.2
Microblaze utilization/waste
The system clock on a Virtex-II FPGA has a maximum frequency of 100 MHz, in the current
Microblaze system it is set to 66 MHz. An ISA bus cycle uses three ISA clock cycles if the
peripheral does not require more. Since the ISA clock in this implementation is synchronous
with the system clock and eight times slower it will take anywhere between one and seven
system clock cycles from the start of the bridge transaction to the start of the ISA bus cycle.
During the whole bridge operation the OPB and the Microblaze will be will be locked. For every
Ethernet read or write there will be quite a few wasted clock cycles for the system, something
that might ruin the real-time scheduling for the system.
As seen in section 2.3.3, a 32 bit transaction for the OPB Ethernet MAC need approximately
21 system clock cycles to finish. Figures 4.1 and 4.2 above show that an average OPB to ISA
bridge transaction needs roughly 30 system clock cycles for a read operation and around 25 cycles
for a write operation1 . That is, it does only seem like the bus bridge is about 25 - 50 percent
slower than the OPB Ethernet MAC, it is worth mentioning however that during the 25 - 30
clock cycles of the bus bridge only 16 bits are read or written while 32 bits are read or written
during one OPB Ethernet MAC operation. In section 5.2.1 a remedy for this phenomenon is
proposed.
1 The reason that a write operation is faster than a read operation is that it does not have to wait for the data
from the ISA peripheral.
Chapter 5
Conclusions
The main objective with this thesis was to find a suitable Ethernet MAC/PHY for an existing
FPGA based embedded system and to create an interface between the chip and the existing
Microblaze system. The OPB to ISA bus bridge was designed and implemented, and to verify
its functionality a small on-chip ISA peripheral was constructed. Unfortunately the CS8900A
development board did not arrive in time to the university in Brisbane to be used in this work.
Apart from the thorough description of the implementation of the bus bridge, this thesis also
gives a summary of different Ethernet MAC/PHY chips suitable for use as an off-chip networking
solution to embedded systems on Virtex-II FPGAs from Xilinx, as well as reviews of involved
bus architectures, and a tutorial on the on-chip logic analyzer tool ChipScope.
The trials with the on-chip ISA peripheral showed that the bus bridge works as expected
and is suitable to use as an interface between Microblaze systems and off-chip ISA peripherals.
The size of the core is very small compared to existing on-chip Ethernet solutions which makes
it ideal to utilize the bus bridge when FPGA size is an issue. Since the core bridges the OPB
with the ISA bus it is not limited to use only with Ethernet peripherals, but is also suitable to
use for other off-chip ISA peripherals that might be connected to a Microblaze system. Such
peripherals could be a VGA adapter or a sound card. If speed is an issue the bus bridge might be
considered to waste too much CPU time in its current implementation. It is, however, possible
to design systems which utilize multiple Microblaze processors. That is, one processor could be
dedicated to handle communication tasks. One suggestion is to redesign one of the Microblazes
in the multiprocessor case to work with 16 bit data path instead of 32 bit which should reduce
its size significantly.
Even though the ISA clock is around 8 MHz per definition some ISA peripherals, the CS8900A
for instance, support higher frequencies. In those cases the ISA clock should be sped up to meet
the maximum frequency for the device to save processor time for other tasks.
5.1
Lessons learned
One of the main challenges during this thesis work, and the design of the OPB to ISA bus bridge
was to determine which parts of the bridge should work on which side of the clock boundary, and
how the communication between the two sides would be secure and convenient. Several lessons
both regarding design of an FPGA core and regarding VHDL coding in general were learned
during the design phase of this project.
The project also gave a good training of the software tools from Xilinx. Especially the
ChipScope tools needed some time to get used to.
33
34
Conclusions
5.2
Future work
The primary task for any successor of this work should be to verify the functionality with the
CS8900A MAC/PHY. It is only when such a verification is carried out the bus bridge can be
said to work properly. Another interesting experiment would be to use the bus bridge for other
types of off-chip ISA peripherals.
5.2.1
Further work on the bus bridge
The current version of the design is not very efficient. There are a number of changes that can
be made to save system clock cycles.
The worst case scenario is that the system has to wait for seven clock cycles before the ISA
cycle starts as shown in section 4.2. Thus, a process which start the ISA clock when the
bus bridge is utilized, or in another way make the gap smaller, should be investigated.
The ISA bus has 16 bit data width while OPB has 32 bit. It should be possible to read or
write 32 bits at a time from the ISA peripheral by dividing the data into two parts. Hence,
the bus bridge would be almost twice as fast and up to thirty system clock cycles could be
saved.
The ability to start a bridge cycle which release the OPB when the bridge cycle is initialized
and notifies the Microblaze when there is valid data available, or if the ISA peripheral did
not respond properly, should be investigated.
A completely different approach to the work made in this thesis would be to implement
a basic on-chip Ethernet MAC which meet the demands from a uCLinux system run on
Microblaze to determine which approach is more beneficial. There might also be other
MAC cores available from other developers. It is, however, desirable by the research group
at ITEE to have an off-chip solution.
Two minor details were omitted during the implementation phase, and should be implemented in a near future. First; some sort of initialization procedures for the core, i.e. a
process making sure that nothing extraordinary happens on power-up etc. Second; a reset
function for the OPB to ISA communication module and the CDCs.
Bibliography
[1] Neil W Bergmann, John Williams, and Peter Waldeck. Egret: A flexible platform for
real-time reconfigurable systems on chip. 2003.
[2] Intel Press Release. <http://www.intel.com/ca/pressroom/2002/0813.htm>. Accessed
on WWW on October 22, 2003.
[3] Michael Barr. A reconfigurable computing primer. Multimedia Systems Design, pages
4447, September 1998.
[4] Ray Andraka. FPGA basics, <www.andraka.com/whatisan.htm>. Accessed on January
27, 2004.
[5] Neil W Bergmann and John Williams. Avionics upgrade management using reconfigurable
logic. 2003.
[6] Xilinx Inc. Virtex-II Platform FPGAs: Complete Data Sheet, October 2003.
[7] Xilinx Inc. Virtex-II Platform FPGA User Guide, August 2003.
[8] Xilinx Inc. Microblaze soft processor, <http://www.xilinx.com/>. Accessed on January
29, 2004.
[9] Xilinx Inc. Microblaze processor reference guide, September 2003.
[10] Xilinx Inc. Embedded System Tools Guide, Embedded Development Kit, October 2003.
[11] Xilinx Inc. Development System Reference Guide, 2003.
[12] Cisco Inc. Internetworking technology handbook,
<http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito\_doc/index.htm>.
Accessed on February 5, 2004.
[13] Xilinx Inc. OPB Ethernet Media Access Controller, v1.00m, July 2003.
[14] Jayant Kadambi, Ian Crayford, and Mohan Kalkunte. Gigabit Ethernet - Migrating to
High-Bandwidth LANs. Prentice Hall, 1998.
[15] Tom Shanley and Don Anderson. ISA System Architecture. Addison-Wesley, 1995.
[16] Cirrus Logic Inc. CS8900A Product Data Sheet, 2001.
[17] IBM. The CoreConnectTM Bus Architecture (White Paper), 1999.
<http://www.chips.ibm.com/products/coreconnect/>.
35
36
Bibliography
[18] IBM. On-Chip Peripheral Bus, Architecture Specifications, April 2001.

[19] Xilinx Inc. On-Chip Peripheral Bus v2.0, product overview, September 2003.
[20] Xilinx Inc. Designing Custom OPB Slave Peripherals for Microblaze, February 2002.
[21] Xilinx Inc. OPB IPIF, v2.00.h, product overview, November 2003.
[22] Tien-Lung Lee and Neil W Bergmann. An interface methodology for retargettable FPGA
peripherals. 2003.
[23] Peter Alfke. Moving data across asynchronous clock boundaries, October 2001.
<http://www.xilinx.com/>.
[24] Xilinx Inc. ChipScope Pro Software and Cores User Manual, May 2003.
Appendix A
List of Acronyms
ASIC Application Specific Integrated Circuit
CLB Configurable Logic Block
DMA Direct Memory Access
EDK Embedded Development Toolkit. Software package from Xilinx for development of Microblaze systems.
EISA Extended Industry Standard Architecture. The extended 32-bit version of the ISA bus.
FPGA Field Programmable Gate Array
IOB Input/Output Block
IPIF IP Interface. An interface created by Xilinx with the intention to create a standard
approach to connect custom cores with the OPB.
ISA Industry Standard Architecture
ISE Integrated Software Environment
ITEE Information Technology and Electrical Engineering
LMB Local Memory Bus
LUT Lookup table
MAC/PHY Media Access Controller/Physical interface. A chip or core with the whole Ethernet logic integrated into one unit both controlling the transfered media and the physical
connection.
OPB On-Chip Peripheral Bus. A 32-bit bus architecture employed to connect the Microblaze
processor with on-chip peripherals.
SoC System-on-Chip. A complete embedded system fitted onto one chip.
UART Universal Asynchronous Receiver/Transmitter
VHDL VLSI Hardware Description Language. The programming language that is utilized to
describe the functionality of hardware.
XMD Xilinx Microprocessor Debugger
37
Appendix B
Acknowledgements
The interfacing of an external Ethernet MAC/PHY to a Microblaze based embedded system
has been performed as a master thesis project in Computer Engineering at the department of
Electrical Engineering at Linkopings Universitet. The work was carried out at the school of IT
& Electrical Engineering at University of Queensland in Brisbane, Australia, where the results
hopefully will be beneficial. I wish to thank the following persons:
Professor Neil Bergmann at ITEE for giving me the opportunity to come to Australia for
six months and carry out this work. Also, for providing me with the computer resources
and other hardware that I needed.
Doctor John Williams at ITEE for very valuable support and heaps of good advices. Hopefully Ill be able to return some of it in the future.
Professor Dake Liu at Linkopings Universitet for giving me valuable comments on the
report.
My opponent Anna Rosen for valuable feedback on the thesis as well as proof reading.
38
Appendix C
Hardware and software resources

The hardware used in this work is divided into two different categories. For design and implementation a Dell PC was employed. The PC was equipped with a 2.5 GHz CPU, 1 Gb primary
memory, 20 Gb secondary memory, and high speed Ethernet connection to the primary source
of information, the internet. To verify that the implementation worked properly it was tested on
the target device. The FPGA is a Virtex-II from Xilinx with one million gates. The device was
mounted on a development board from Insight which is also equipped with two 7-segment LED
displays, eight DIP switches, four programmable buttons, JTAG port, two serial ports, USB
port, Ethernet PHY interface, general purpose connections to the FPGA, SRAM and DRAM,
and Flash RAM.
Four different software packages were utilized during the development. For the independent
development of the core modules ISE 6.1.03 from Xilinx was employed. ISE facilitates the development of IP cores in the hardware description language of choice, VHDL or Verilog. Easily
accessable from ISE is ModelSim from MentorGraphics. It enables quick simulation of implemented designs. To create systems of mixed cores targeted for Xilinx FPGAs the EDK 6.1 is an
ideal tool. It takes certain files as inputs, such as the MHS and the MSS files, and generates the
systems in a number of steps. The EDK comes with a graphical user interface, XPS, which was
avoided due to its immaturity in the release of EDK used during the first half of the project. For
on-chip verification and monitoring ChipScope PRO 6.1 was used. It is a very powerful tool, see
appendix D, which is ideal to utilize for FPGA development.
39
Appendix D
Using ChipScope for debugging

and functional verification
A very convenient way to verify a system based on an FPGA, rather than using a traditional
logic analyzer, is to use the ChipScope Pro software provided by Xilinx. Instead of connecting a
logic analyzer to the I/O pins of the FPGA, an additional core is inserted into the design. The
core consists of an Integrated Logic Analyzer that monitors user specified signals directly on-chip
and communicates with the ChipScope software through the JTAG Boundary Scan port.[24]
ChipScope PRO consists of three different tools: the core generator, the core inserter and
the analyzer. The core generator provides netlists and instantiation templates for a number of
cores including: integrated controller (ICON), integrated logic analyzer (ILA), and integrated
bus analyzer for OPB (IBA/OPB). The inserter is a tool utilized after the synthesis that inserts
necessary cores in the design before the merging of the core netlists into one system file. Finally,
the analyzer is the software that displays the monitored signals on the computer screen. The
analyzer is also used to set up the triggers and specify the number of samples.[24]
The communication link between the ILA cores and the host computer is provided by the
integrated controller core, ICON, and the JTAG download cable. One ICON core can handle
communication with a maximum of 15 separate analyzer cores (ILA, IBA etc.)
D.1
ChipScope for dummies
This tutorial aim to show how to employ ChipScope for verification of a custom core designed
for a Microblaze system. Only the inserter, and analyzer, tools are utilized though. For more
information about the software, see the ChipScope Pro users manual [24].
D.1.1
Inserter
When the design and implementation of the custom core is done, synthesize the system by
running:
make netlist - This command creates netlists for the different parts of the system, but does
not glue it together.
Start the inserter software. The first task is to specify the input design netlist, see figure D.1
below. Browse to the system.ngc, or equivalent, in the implementation directory of the system.
The output netlist and directory should be filled in automatically. Before clicking on next-button,
40
Using ChipScope for debugging and functional verification
41
make sure that the correct device family is specified. If an Inserter project is available it can
be opened instead of specifying the input netlist. Projects, however, are not considered in this
tutorial, but little consideration is needed understand the concept.
Figure D.1: Specify the input design netlist to which a ChipScope core should be added.
After clicking the next button the trigger parameters field will be visible, see figure D.2.
Select the number of desired trigger ports, on the first trial chose a small number. For every
trigger port a group of options appear in the field. The first option is the width of the port.
A valid width is in the range from 1 to 256, and the ports can trigger on individual bits or
busses of arbitrary width. The number of match units specify how many different combinations
that a port can trigger on, by keeping the number low (1 match unit) conserves resources, while
allowing more match units enable flexibility in the trigger conditions on the cost of logic. The
type of the match unit is set to the right in the field. For a full list of the match unit types see
[24], but a rule of thumb is to use basic with edges for bit triggers and range with edges for bus
triggers.
When clicking the next button the screen in figure D.3 becomes visible. Make sure that all
trigger ports are used as data, i.e. every check box is checked. Otherwise the signals will not be
captured by the analyzer nor displayed on the computer screen. It is also possible to define how
many samples that should be made on each trigged event, and on which clock edge the samples
should be taken. At the bottom of the screen the needed number of BlockRAMs is displayed.
Finally the connections to the trigger ports are specified on the next screen, see figure D.4.
Press the Modify Connections button and a dialog containing the different clock and trigger
signals appear to the right and the valid signals to trigger on appears the left. Highlight a trigger
of choice and a corresponding signal and press the Make Connections button1 . When ready,
close the dialog by pressing Ok. If any signal is not connected it will appear in red in figure D.4,
the core cannot be inserted in the design before all trigger signals are connected. It is possible
1 Tip of the day: It is possible to connect many signals and trigger inputs at the same time by using shift when
highlighting.
42
Figure D.2: Specify the trigger parameters and match unit settings.
Figure D.3: Specify the capture settings.
43
Figure D.4: Specify the signals to trigger on.

to go back to the trigger parameter screen and change the number of trigger inputs if needed,
and then go back to the net connections screen again and define the connections.
When everything is ready, press the Insert button. The ChipScope core will now be inserted
in the system netlist. When the Inserter indicates that the insertion is finished continue with
the building of the system by running the following command,
ngdbuild -sd implementation/ -p xc2v1000fg456-6 -nt timestamp -bm
implementation/system.bmm -uc data/system.ucf system.ngo
The command builds the system together to one unit. When the building is done the following
files has to be moved from the root directory of the system to the implementation directory:
- ddr v1 00 b virtex2 async fifo.ngo
- system ngdbuild.nav
- netlist.lst
- system.bld
- system.ngd
The task is usually carried out by the synthesis flow, but has to be done manually when inserting
a ChipScope core. Next step is to do the mapping of the system, it is done by writing the following
to the command line:
map -o implementation/system map.ncd implementation/system.ngd
implementation/system.pcf
Following the mapping is the place-and-route tool and the bit generation before the insertion of
the XMD stub and the download to the FPGA:
par -w -ol 2 implementation/system map.ncd implementation/system.ncd
implementation/system.pcf
44

bitgen -w -f etc/bitgen.ut implementation/system
bitinit system.mhs -pe microblaze 0 microblaze 0/code/xmdstub.elf
-bt implementation/system.bit -o implementation/download.bit
impact -batch etc/download.cmd
Instead of the last command it is possible to use the graphical interface of the iMPACT software.
It is more convenient, though, to use the command line. The download.cmd file should look
something like this:
setMode -bscan
setCable -p lpt1
addDevice -p 1 -file etc/xc18v04_vq44.bsd
assignfile -p 1 -file etc/xc18v04_vq44.bsd
addDevice -p 2 -file implementation/download.bit
program -p 2
quit
D.1.2
Analyzer
When the system is created and downloaded to the FPGA it is time to start the ChipScope
Analyzer. The user interface is somewhat more complex than the Inserter, but fear not, it is
very convenient once you learn how to use it. To connect the analyzer to the system on the
FPGA, click on the icon to the far left in the toolbar, see figure D.5. If everything is done
correctly all signals should appear in the waveform window and the window to the left of the
waveforms. To be able to keep the signals apart it is adviced to import a saved Inserter project
file. Most of the time it will give the signals their correct names, but sometimes the user has to
do some signal renaming manually as well. In the analyzer it is also possible to group signals
into busses by highlighting the signals and select Add to Bus - New Bus from the left-click menu.
The upper right window is used to set the triggers, i.e. select the signals to trigger on and how
to trigger. For instance, replace the X with a T if any transition on a signal should be triggered.
Keep in mind that the Analyzer is using little endian bit ordering. That is, if triggering on a
certain OPB address, the bus has to be reversed and some extra care has to be taken regarding
the address. In figure D.5 trigger port 5 is set to trigger on address XXX6 FFFF, but due to the
bit ordering it is really triggering on address FFFF 6XXX2 . The X indicate a dont-care.
In the Analyzer it is possible to define trigger condition equations. That is, logical equations
combining different trigger events. See [24] for more information, or play around with it for a
few minutes to understand what it is all about. The last setup to consider before trying the core
is to define what type of capture that should be made. It is possible to define how many samples
to capture, how many capture windows to use, and where in those windows the trigger should
appear.
When everything is setup it is possible to start the capturing of signal waveforms by pressing
the play button, the third icon in the toolbar. Use XMD connected to the debug UART to
generate some meaningful events in the system. The first event in figure D.6 is generated by
writing FC01 to address FFFF60F0, and the second event is generated by reading from the same
address.
In this example the OPB to ISA bus bridge and the ISA GPIO peripheral are employed to
read from the DIP switches an write to the 7-segment LEDs on the development board.
2 Note
that XXX4 FFFF is equal to FFFF 2XXX.
45
Figure D.5: Specify the trigger conditions.
Figure D.6: The captured waveforms, triggering on the value FFFF6 XXX on the address bus,
using two windows.
Appendix E
The VHDL code

This appendix contains the VHDL code from the implementations in the project. The first
section shows the the complete source code for the bus bridge, and the second section account
for the ISA GPIO. Note however that only the source code is presented here, the other files
needed to use the cores together with the EDK are distributed with the rest of the core by the
author.
E.1
OPB to ISA bus bridge

Listing E.1: Bus Wrapper
10
15
20
F i l e :
o p b i s a . vhd
Version : v1 . 0 0 a
D e s c r i p t i o n :
This module wraps up t h e OPB t o ISA b r i d g e , and p r o v i d e s an i n t e r
f a c e f o r t h e MHS f i l e . I t c o n t a i n s a g e n e r a t o r f o r t h e ISA c l o c k ,
i n t e r f a c e s f o r t h e two bus a r c h i t e c t u r e s , and a communication l i n k
b e t w e en t h e two c l o c k domains . There i s a l s o a t i m e o u t watchdog
t h a t t e r m i n a t e s t h e t r a n s a c t i o n i f t h e ISA s i d e i s not r e s p o n d i n g
p r o p e r l y .
( c ) 2 0 0 4 Johan Bernspang , johan<at>bernspang <dot>s e
H i s t o r y :
2003.12 Created by Johan Bernspang
li b r a r y IEEE ;
use IEEE . STD LOGIC 1164 .ALL;
l i b r a r y Common v1 00 a ;
use Common v1 00 a . a l l ;
use Common v1 00 a . p s e l e c t ;
46
The VHDL code
47
25
30
entity o p b i s a i s
generic (
C BASEADDR
C HIGHADDR
C USER ID CODE
C OPB AWIDTH
C OPB DWIDTH
C FAMILY
Custom p a r a m e t e r s
C ISA CLK DIV
C USE CHRDY
C NUM ISA CYC TOUT
C ON CHIP SL ONLY
C NUM ON CHIP SL
35
40
:
:
:
:
:
:
s t d l o g i c v e c t o r ( 0 to 3 1 )
s t d l o g i c v e c t o r ( 0 to 3 1 )
integer
integer
integer
string
:=
:=
:=
:=
:=
:=
XFFFFFFFF ;
X 00000000 ;
3;
32;
32;
virtex2 ;
:
:
:
:
:
integer
std logic
integer
std logic
integer
:= 8 ;
:= 1 ;
:= 16;
:= 1 ;
:= 1
);
45
50
55
60
65
70
port (
OPB bus s i g n a l s
OPB clk
: in
OPB Rst
: in
OPB ABus
: in
OPB DBus
: in
OPB RNW
: in
OPB BE
: in
OPB seqAddr : in
OPB select : in
I 2 O xf er A c k : out
I2O errAck : out
I2O toutSup : out
: out
I2O Retry
I2O DBus
: out
std
std
std
std
std
std
std
std
std
std
std
std
std
ISA bus s i g n a l s
ISA SD IN and ISA IS
ISA SA
: out s t d
ISA SD I
: in s t d
ISA SD O
: out s t d
ISA SD T
: out s t d
: in s t d
ISA SD IN
ISA SD OUT : out s t d
: out s t d
ISA Bale
ISA SBHE
: out s t d
: out s t d
ISA iow
ISA ior
: out s t d
ISA bclk
: out s t d
CHRDY
: in s t d
RESDRV
: out s t d
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
;
;
v e c t o r ( 0 to C OPB AWIDTH 1 ) ;
v e c t o r ( 0 to C OPB DWIDTH 1 ) ;
;
v e c t o r ( 0 to C OPB AWIDTH/ 8 1 ) ;
;
;
;
;
;
;
v e c t o r ( 0 to C OPB DWIDTH 1 ) ;
OUT a r e used by onc h i p ISA p e r i p h e r a l s .

l o g i c v e c t o r ( 1 9 downto 0 ) ;
logic ;
logic ;
logic ;
logic ;
logic ;
logic ;
logic ;
48
75
80
85
90
95
The VHDL code

IO16
Chrdy oc
io16 oc
: in
: in
: in
s t d l o g i c ; not used
s t d l o g i c v e c t o r ( 0 to C NUM ON CHIP SL 1 ) ;
s t d l o g i c ; not used
Four IRQ c h a n n e l s implemented f o r ISA i n t e r r u p t s . These a r e

c o n n e c t e d d i r e c t l y t o t h e system i n t e r r u p t h a n d l e r .
IRQ9
: in s t d l o g i c ;
IRQ10
IRQ11
IRQ15
Interrupt9
: out s t d l o g i c ;
I n t e r r u p t 1 0 : out s t d l o g i c ;
I n t e r r u p t 1 1 : out s t d l o g i c ;
I n t e r r u p t 1 5 : out s t d l o g i c ) ;
end o p b i s a ;
architecture IMP of o p b i s a i s
The d i f f e r e n t components o f t h e b r i d g e a r e s p e c i f i e d h e r e
component i s a c l k g e n i s
generic (
C CLK DIV
: integer );
port (
OPB clk
OPB Rst
ISA clk
: out s t d l o g i c ) ;
end component i s a c l k g e n ;
100
105
110
115
120
component o p b i n t e r f a c e i s
generic (
C AW
: integer ;
C DW
: integer );
port (
OPB ABus
: in s t d l o g i c
OPB DBus
OPB clk
OPB Rst
OPB RNW
OPB BE
O P B s e l e c t i : in s t d l o g i c
I2 O x fe r A c k : out s t d l o g i c
I2O errAck : out s t d l o g i c
I2O toutSup : out s t d l o g i c
: out s t d l o g i c
I2O Retry
I2O DBus
ISA Address : out s t d l o g i c
ISA Data out : out s t d l o g i c
I S A D a t a i n : in s t d l o g i c
ISA RNW
Ready
v e c t o r ( 0 to C AW 1 ) ;
v e c t o r ( 0 to C DW 1 ) ;
;
;
;
v e c t o r ( 0 to C AW/ 8 1 ) ;
;
;
;
;
;
vector
vector
vector
vector
;
;
( 0 to C AW
( 1 9 downto
( 1 5 downto
( 1 5 downto
1);
0);
0);
0);
The VHDL code
125
130
135
140
145
150
155
160
165
Acknowledge :
Flag 1
:
Flag 2
:
ISA finish
:
ISA Failure :
end component o p b
49
out s t d l o g i c
in s t d l o g i c
in s t d l o g i c
in s t d l o g i c
in s t d l o g i c
interface ;
component i s a i n t e r f a c e i s
generic (
C USE CHRDY : s t d l o g i c ) ;
port (
ISA SA
ISA SD I
ISA SD O
ISA SD T
ISA Bale
ISA SBHE
ISA iow
ISA ior
ISA bclk
CHRDY
RESDRV
IO16
OPB Rst
OPB RNW i
Isa clk
ISA Address : in s t d l o g i c
ISA Data out : in s t d l o g i c
I S A D a t a i n : out s t d l o g i c
Flag
Ready
Acknowledge : out s t d l o g i c
O P B s e l e c t i : in s t d l o g i c
Finish
F a i l u r e : in s t d l o g i c ) ;
end component i s a i n t e r f a c e ;
;
;
;
;
);
vector
vector
vector
vector
component opb isa comm i s
downto
downto
downto
downto
0);
0);
0);
0);
;
;
;
;
;
;
;
;
;
;
;
v e c t o r ( 1 9 downto 0 ) ;
;
;
;
;
;
component timeout watchdog i s

generic (
C NUM ISA CYCLES TOUT : i n t e g e r ) ;
port (
ISA Clk
OPB select : in s t d l o g i c ;
Flag
ISA Finish
I S A F a i l u r e : out s t d l o g i c ) ;
end component timeout wa tchdog ;
170
(19
(15
(15
(15
50
175
180
185
190
195
200
205
210
The VHDL code
port (
OPB Rst
:
flag 1
:
flag 2
:
OPB ready
:
ISA ready
:
OPB ackn
:
ISA ackn
:
end component opb
in s t d l o g i c
out s t d l o g i c
out s t d l o g i c
in s t d l o g i c
in s t d l o g i c
in s t d l o g i c
in s t d l o g i c
isa comm ;
;
;
;
;
;
;
);
component p s e l e c t i s
generic (
C AB
: integer ;
C AW
: integer ;
C BAR
: std logic vector );
port (
A
: in s t d l o g i c v e c t o r ( 0 to C AW1);
AValid
PS
end component p s e l e c t ;
I n t e r n a l s i g n a l s
signal i s a c l k i
s i g n a l OPB rdy i
s i g n a l OPB ackn i
signal ISA rdy i
signal ISA ackn i
signal f l a g 1 i
signal f l a g 2 i
signal f i n i s h i
signal f a i l u r e i
:
:
:
:
:
:
:
:
:
std
std
std
std
std
std
std
std
std
logic
logic
logic
logic
logic
logic
logic
logic
logic
signal
signal
signal
signal
address i
data out i
data in i
opb rnw i
:
:
:
:
std
std
std
std
logic
logic
logic
logic
signal
signal
signal
signal
ISA SD I INT
ISA SD O INT
CHRDY INT
io16 INT
:
:
:
:
std
std
std
std
logic
logic
logic
logic
signal o p b s e l e c t i
;
;
;
;
;
;
;
;
;
;
;
;
: std logic ;
215
220
function A d d r B i t s ( x , y : s t d l o g i c v e c t o r ( 0 to C OPB AWIDTH1))

return i n t e g e r i s
variable a d d r x o r
: s t d l o g i c v e c t o r ( 0 to C OPB AWIDTH1);
begin
a d d r x o r : = x xor y ;
The VHDL code
225
f or i in 0 to C OPB AWIDTH1 loop

i f a d d r x o r ( i ) = 1 then return i ;
end i f ;
end loop ;
return (C OPB AWIDTH ) ;
end function A d d r B i t s ;
constant C AB
230
235
240
245
250
51
: i n t e g e r : = A d d r B i t s (C HIGHADDR,C BASEADDR ) ;
begin
Generate t h e a p p r o p r i a t e ISA SD c o n n e c t i o n s d e p e n d i n g on i f t h e
ISA p e r i p h e r a l s a r e on or o f f c h i p .
The ORing o f t h e c h r d y o c i s v e r y u g l y a t t h e moment . My
a p o l o g i e s . . .
ISA ON CHIP GEN : i f C ON CHIP SL ONLY = 1 generate

ISA SD I INT <= ISA SD IN ;
ISA SD OUT <= ISA SD O INT ;
io16 INT <= i o 1 6 o c ;
CHRDY OC GEN 0 : i f C NUM ON CHIP SL = 1 generate
c h r d y i n t <= c h r d y o c ( 0 ) ;
end generate CHRDY OC GEN 0 ;
c h r d y i n t <= c h r d y o c ( 0 ) or c h r d y o c ( 1 ) ;
c h r d y i n t <= c h r d y o c ( 0 ) or c h r d y o c ( 1 ) or c h r d y o c ( 2 ) ;
c h r d y i n t <= c h r d y o c ( 0 ) or c h r d y o c ( 1 ) or c h r d y o c ( 2 )
or c h r d y o c ( 3 ) ;
end generate ISA ON CHIP GEN ;
255
260
265
ISA OFF CHIP GEN : i f C ON CHIP SL ONLY = 0 generate

ISA SD I INT <= ISA SD IN or ISA SD I ;
w i l l t h i s work ?
ISA SD O <= ISA SD O INT ;
c h r d y i n t <= CHRDY or c h r d y o c ( 0 ) ;
c h r d y i n t <= CHRDY or c h r d y o c ( 0 ) or c h r d y o c ( 1 ) ;
c h r d y i n t <= CHRDY or c h r d y o c ( 0 ) or c h r d y o c ( 1 )
or c h r d y o c ( 2 ) ;
52
270
The VHDL code

c h r d y i n t <= CHRDY or c h r d y o c ( 0 ) or c h r d y o c ( 1 )
or c h r d y o c ( 2 ) or c h r d y o c ( 3 ) ;
io16 INT <= i o 1 6 or i o 1 6 o c ;
end generate ISA OFF CHIP GEN ;
275
Interrupt9
Interrupt10
Interrupt11
Interrupt15
<=
<=
<=
<=
IRQ9 ;
IRQ10 ;
IRQ11 ;
IRQ15 ;
280
285
290
295
300
305
310
315
p s e l e c t i s p r o v i d e d by X i l i n x as a s t a n d a r d component f o r p e r i
p h e r a l s e l e c t i o n .
OPB Select I : p s e l e c t
generic map (
C AB
=> C AB ,
C AW
=> C OPB AWIDTH,
C BAR
=> C BASEADDR )
port map (
A
=> opb ABus ,
[ i n ]
AValid
=> o p b S e l e c t ,
[ i n ]
PS
=> o p b s e l e c t i ) ;
[ o u t ]
ISA CLK GEN I : i s a c l k g e n
generic map (
C CLK DIV
=> C ISA CLK DIV )
port map (
OPB clk
=> OPB clk ,
OPB Rst
=> OPB Rst ,
=> i s a c l k i ) ;
ISA clk
[ i n ]
[ i n ]
[ o u t ]
OPB INTERFACE I :
generic map (
C AW
C DW
port map (
OPB ABus
OPB DBus
OPB clk
OPB Rst
OPB RNW
OPB BE
OPB select i
I2O xferAck
I2O errAck
I2O toutSup
I2O Retry
opb interface
=> C OPB AWIDTH,
=> C OPB DWIDTH)
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
OPB ABus ,
OPB DBus ,
OPB clk ,
OPB Rst ,
OPB RNW,
OPB BE,
opb select i ,
I2O xferAck ,
I2O errAck ,
I2O toutSup ,
I2O Retry ,
[ in ]
[ in ]
[ in ]
[ in ]
[ in ]
[ in ]
[ in ]
[ out ]
[ out ]
[ out ]
[ out ]
The VHDL code
320
325
I2O DBus
ISA Address
ISA Data out
ISA Data in
ISA RNW
Ready
Acknowledge
Flag 1
Flag 2
ISA Finish
ISA Failure
53
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
I2O DBus ,
address i ,
data out i ,
data in i ,
opb rnw i ,
OPB rdy i ,
OPB ackn i ,
flag 1 i ,
flag 2 i ,
finish i ,
failure i );
[ out ]
[ out ]
[ out ]
[ in ]
[ out ]
[ out ]
[ out ]
[ in ]
[ in ]
[ in ]
[ in ]
[ out ]
[ in ]
[ out ]
[ out ]
[ out ]
[ out ]
[ out ]
[ out ]
[ out ]
[ in ]
[ out ]
[ in ]
[ in ]
[ in ]
[ in ]
[ in ]
[ in ]
[ out ]
[ in ]
[ out ]
[ out ]
[ in ]
[ out ]
[ in ]
330
335
340
345
350
355
360
365
ISA INTERFACE I :
generic map (
C USE CHRDY
port map (
ISA SA
ISA SD I
ISA SD O
ISA SD T
ISA Bale
ISA SBHE
ISA iow
ISA ior
ISA bclk
CHRDY
RESDRV
IO16
OPB Rst
OPB RNW i
isa clk
ISA Address
ISA Data out
ISA Data in
flag
Ready
Acknowledge
OPB select i
Finish
Failure
isa interface
=> C USE CHRDY)
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
ISA SA ,
ISA SD I INT ,
ISA SD O INT ,
ISA SD T ,
ISA Bale ,
ISA SBHE ,
ISA iow ,
ISA ior ,
ISA bclk ,
CHRDY INT,
RESDRV,
IO16 ,
OPB Rst ,
opb rnw i ,
isa clk i ,
address i ,
data out i ,
data in i ,
flag 1 i ,
ISA rdy i ,
ISA ackn i ,
opb select i ,
finish i ,
failure i );
WATCHDOG I : ti meout watchdog

generic map (
C NUM ISA CYCLES TOUT => C NUM ISA CYC TOUT)
port map (
=> i s a c l k i ,
ISA Clk
OPB select
=> o p b s e l e c t i ,
Flag
=> f l a g 1 i ,
ISA Finish
=> f i n i s h i ,
[ in ]
[ in ]
[ in ]
[ in ]
54
The VHDL code

ISA Failure
370
375
=>
failure i );
OPB ISA COMMUNICATION I : opb isa comm

port map (
OPB Rst
=> OPB Rst ,
Flag 1
=> f l a g 1 i ,
Flag 2
=> f l a g 2 i ,
OPB ready
=> OPB rdy i ,
ISA ready
=> I S A r d y i ,
OPB ackn
=> OPB ackn i ,
ISA ackn
=> I S A a c k n i ) ;
end IMP ;
[ o u t ]
[ in ]
[ out ]
[ out ]
[ in ]
[ in ]
[ in ]
[ in ]
The VHDL code
55
Listing E.2: OPB Interface
10
15
F i l e :
o p b i n t e r f a c e . vhd
This module c o n s i s t s o f t h e OPB i n t e r f a c e . I t i s w o r k i n g synchron
ous t o t h e OPB c l o c k and d o e s a l l t h e communication w i t h t h e OPB
bus e x c e p t f o r t h e a d d r e s s d e c o d i n g / p e r i p h e r a l s e l e c t which i s
c a r r i e d o u t by p s e l e c t i n t h e o p b i s a module .
I t a l s o communicates d i r e c t l y , or i n d i r e c t l y t h r o u g h t h e c l o c k
domain c r o s s i n g module , w i t h t h e ISA i n t e r f a c e .
H i s t o r y :
l i b r a r y IEEE ;
20
25
30
35
40
45
entity o p b i n t e r f a c e i s
generic (
C AW
: integer := 32;
C DW
: integer := 32);
port (
S i g n a l s t o and from t h e OPB
OPB ABus
: in s t d l o g i c v e c t o r
OPB DBus
OPB Clk
OPB Rst
OPB RNW
OPB BE
OPB select i
I 2 O xf er A c k
I2O errAck
I2O toutSup
I2O Retry
I2O DBus
: out s t d l o g i c v e c t o r
S i g n a l s t o and from ISA
: out s t d l o g i c v e c t o r
ISA Address
ISA Data out : out s t d l o g i c v e c t o r
ISA Data in
ISA RNW
ISA Finish
ISA Failure
S i g n a l s t o and from CDC
Ready
Acknowledge
( 0 to C AW 1 ) ;
( 0 to C DW 1 ) ;
( 0 to C AW/ 8 1 ) ;
( 0 to C DW 1 ) ;
( 1 9 downto 0 ) ;
( 1 5 downto 0 ) ;
( 1 5 downto 0 ) ;
56
50
The VHDL code
Flag 1
: in
Flag 2
: in
end o p b i n t e r f a c e ;
std logic ;
std logic );
f l a g f o r d a t a g o i n g t o ISA
f l a g f o r d a t a g o i n g t o OPB
architecture IMP of o p b i n t e r f a c e i s
55
60
65
70
75
80
85
90
95
component FDRE i s
port (
Q
C
CE : in s t d l o g i c
D
R
end component FDRE;
component FDR
port (
Q
: out
C
: in
D
: in
R
: in
end component
signal
signal
signal
signal
signal
signal
;
;
;
;
);
is
std
std
std
std
FDR;
logic
logic
logic
logic
xfer success
opb rnw i
opb select i n
addr ce
ready i
acknowledge i
;
;
;
);
:
:
:
:
:
:
std
std
std
std
std
std
logic
logic
logic
logic
logic
logic
;
;
;
;
;
;
type B r i d g e S t a t e M a c h i n e i s ( I d l e , Send , Waiting , Receive ,

Finish , Failure ) ;
signal o p b s t a t e c u r r e n t
: Bridge State Machine ;
signal o pb s ta t e ne x t
begin
3 p r o c e s s e s f o r t h e FSM
SEQ FSM PROCESS : process ( OPB Rst , OPB Clk , o p b s e l e c t i n ) i s

begin
i f OPB Rst = 1 or o p b s e l e c t i n = 1 then
o p b s t a t e c u r r e n t <= I d l e ;
e l s i f r i s i n g e d g e ( OPB Clk ) then
o p b s t a t e c u r r e n t <= o p b s t a t e n e x t ;
end i f ;
end process ;
COMB FSM PROCESS : process ( o p b s t a t e c u r r e n t , O P B s e l e c t i ,
The VHDL code
57
x f e r s u c c e s s , opb rnw i , ISA Finish ,
ISA Failure , acknowledge i ) is
100
105
110
115
120
125
130
135
140
145
begin
case o p b s t a t e c u r r e n t i s
when I d l e =>
i f O P B s e l e c t i = 1 then
o p b s t a t e n e x t <= Send ;
else
o p b s t a t e n e x t <= o p b s t a t e
end i f ;
when Send =>
i f x f e r s u c c e s s = 1 then
o p b s t a t e n e x t <= Waiting ;
e l s i f I S A F a i l u r e = 1 then
o p b s t a t e n e x t <= F a i l u r e ;
elsif
end i f ;
when Waiting =>
i f o p b r n w i = 1 then
o p b s t a t e n e x t <= R e c e i v e ;
e l s i f I S A F i n i s h = 1 then
o p b s t a t e n e x t <= F i n i s h ;
else
end i f ;
when R e c e i v e =>
i f a c k n o w l e d g e i = 1 then
o p b s t a t e n e x t <= F i n i s h ;
else
end i f ;
when F i n i s h =>
o p b s t a t e n e x t <= I d l e ;
when F a i l u r e =>
i f O P B s e l e c t i = 0 then
o p b s t a t e n e x t <= I d l e ;
else
end i f ;
end case ;
end process COMB FSM PROCESS;
current ;
current ;
current ;
current ;
current ;
OUTP FSM PROC : process ( o p b s t a t e c u r r e n t ) i s

begin
58
150
155
160
165
170
175
The VHDL code

case o p b s t a t e c u r r e n t i s
when I d l e =>
I2O errAck <= 0 ;
I2O retry
<= 0 ;
I 2O x f e rA c k < = 0 ;
I2O toutSup < = 0 ;
when Send =>
I2O errAck <= 0 ;
I2O retry
<= 0 ;
I 2O x f e rA c k < = 0 ;
I2O toutSup < = 1 ;
when Waiting =>
I2O errAck <= 0 ;
I2O retry
<= 0 ;
I 2O x f e rA c k < = 0 ;
I2O toutSup < = 1 ;
when R e c e i v e =>
I2O errAck <= 0 ;
I2O retry
<= 0 ;
I 2O x f e rA c k < = 0 ;
I2O toutSup < = 1 ;
when F i n i s h =>
I2O errAck <= 0 ;
I2O retry
<= 0 ;
I 2O x f e rA c k < = 1 ;
I2O toutSup < = 1 ;
I2O errAck <= 1 ; or maybe I 2 O r e t r y ?
I2O retry
<= 0 ;
I 2O x f e rA c k < = 1 ;
I2O toutSup < = 1 ;
end case ;
end process OUTP FSM PROC;
180
185
190
195
I f ISA a s s e r t s Acknowledge t h e t r a n s f e r o f a d d r e s s and d a t a has

been s u c c e s s f u l . FSM g o e s t o Waiting s t a t e . I f o p b s e l e c t i i s
d e a s s e r t e d s o m e t h i n g u n e x p e c t e d has happened .
SUCCESSFUL PROC : process ( OPB Rst , f l a g 1 , o p b s t a t e c u r r e n t ) i s

begin
i f OPB Rst = 1 or o p b s t a t e c u r r e n t = i d l e or
o p b s t a t e c u r r e n t = w a i t i n g then
x f e r s u c c e s s <= 0 ;
e l s i f f a l l i n g e d g e ( f l a g 1 ) then
x f e r s u c c e s s <= 1 ;
end i f ;
end process SUCCESSFUL PROC ;
The VHDL code
200
205
210
215
220
225
The OPB s i d e a c k n o w l e d g e d u r i n g a read o p e r a t i o n i s d e l a y e d by

one c l o c k c y c l e . Might not be n e c e s s a r y t h o u g h .
FLAG ACKNOWLEDGE : process ( OPB Rst , OPB Clk ) i s

begin
i f OPB Rst = 1 then
Acknowledge < = 0 ;
i f f l a g 2 = 1 then
acknowledge i <= 1 ;
Acknowledge <= a c k n o w l e d g e i ;
else
Acknowledge < = 0 ;
end i f ;
end i f ;
end process FLAG ACKNOWLEDGE;
R e g i s t e r s
RDY DFF : process ( OPB Rst , OPB Clk ) i s

begin
r e a d y i <= 0 ;
i f o p b s t a t e c u r r e n t = Send then
r e a d y i <= 1 ;
else
r e a d y i <= 0 ;
end i f ;
end i f ;
end process RDY DFF;
230
235
240
59
RNW DFF : process ( OPB Rst , OPB Clk ) i s

begin
opb rnw i <= 0 ;
o p b r n w i <= OPB RNW;
end i f ;
end process RNW DFF;
ABUS DEC FF GENERATE : f or i in 0 to 1 9 generate
ABUS FF I : FDRE
port map (
Q
=> ISA Address (19 i ) ,
[ o u t ]
C
=> OPB Clk ,
[ i n ]
60
245
The VHDL code

CE
D
R
=> a d d r c e ,
=> OPB ABus( 1 2 + i ) ,
=> o p b s e l e c t i n
[ i n ]
[ i n ]
[ i n ]
);
end generate ABUS DEC FF GENERATE ;
250
255
260
265
270
275
OPB DBUS FF GENERATE : f o r i in 0 to 1 5 generate

DATA FF I : FDRE
port map (
Q
=> ISA Data out (15 i ) , [ o u t ]
C
=> OPB Clk ,
[ i n ]
CE => not f l a g 1 ,
[ i n ]
D
=> OPB DBus( i ) ,
[ i n ]
R
[ i n ]
);
end generate OPB DBUS FF GENERATE ;
I2ODBUS FF GENERATE : f o r i in 0 to 1 5 generate
DATA IN REG I : FDRE
port map (
Q
=> I2O Dbus ( 1 6 + i ) ,
[ o u t ]
C
=> OPB Clk ,
[ i n ]
CE => f l a g 2 ,
[ i n ]
D
=> I S A D a t a i n (15 i ) ,
[ i n ]
R
[ i n ]
);
end generate I2ODBUS FF GENERATE ;
A s s o r t e d s i g n a l s
I2O DBus ( 0 to 15) <= ( others = > 0 ) ;
Ready <= r e a d y i ;
o p b s e l e c t i n <= not o p b s e l e c t i ;
ISA RNW <= o p b r n w i ;
a d d r c e <= o p b s e l e c t i and not r e a d y i ;
end IMP ;
The VHDL code
61
Listing E.3: ISA Interface
10
15
20
25
30
35
40
45
F i l e :
i s a i n t e r f a c e . vhd
This module c o n s i s t s o f t h e ISA i n t e r f a c e . I t i s d r i v e n by t h e ISA
c l o c k g e n e r a t o r . I t a c t s as an ISA bus master , and i s a b l e t o work
w i t h an a r b i t r a r y number o f s l a v e s . The communication p r o t o c o l
assumes t h a t t h e s l a v e s have 1 6 b i t d a t a w i d t h .
I t communicates w i t h t h e OPB i n t e r f a c e t h r o u g h t h e CDC, and a l s o
w i t h t h e Timeout Watchdog .
NB! Some s l a v e s might not l i k e t h e ISA SBHE i m p l e m e n t a t i o n .
H i s t o r y :
2004.05 O P B s e l e c t i added t o i n t e r n a l r e s e t s i g n a l .
entity i s a i n t e r f a c e i s
generic (
C USE CHRDY
: std
port (
ISA SA
: out
: in
ISA SD I
ISA SD O
: out
ISA SD T
: out
ISA Bale
: out
ISA SBHE
: out
ISA iow
: out
ISA ior
: out
ISA bclk
: out
CHRDY
: in
RESDRV
: out
IO16
: in
: in
OPB Rst
OPB RNW i
: in
ISA Clk
: in
: in
ISA Address
ISA Data out : in
: out
ISA Data in
Flag
: in
Ready
: out
Acknowledge
: out
logic );
std
std
std
std
std
std
std
std
std
std
std
std
std
std
std
std
std
std
std
std
std
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
vector
vector
vector
vector
(19
(15
(15
(15
downto
downto
downto
downto
0);
0);
0);
0);
;
;
;
;
;
;
;
;
;
;
;
;
;
;
62
50
The VHDL code
OPB select i
Finish
Failure
end i s a i n t e r f a c e
: in s t d l o g i c ) ;
;
architecture IMP of i s a i n t e r f a c e i s
55
60
component FDRE i s
port (
Q
C
CE : in s t d l o g i c
D
R
);
end component FDRE;
;
;
;
;
65
70
75
80
85
90
95
signal
signal
signal
signal
signal
signal
signal
signal
signal
signal
signal
signal
signal
bale ce
bale ce h
isa bale i
ior iow ce
ior iow ce h
data 2 state
isa sd t i
ready i
acknowledge i
finish i
reset
data out ce
chrdy i
:
:
:
:
:
:
:
:
:
:
:
:
:
std
std
std
std
std
std
std
std
std
std
std
std
std
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
;
;
;
;
;
;
;
;
;
;
;
;
type B r i d g e S t a t e M a c h i n e i s ( I d l e , Address , Data 1 , Data 2 ) ;

signal i s a s t a t e c u r r e n t
signal i s a s t a t e n e x t
begin
SEQ FSM PROC : process ( r e s e t , ISA Clk ) i s

begin
i f r e s e t = 1 then
i s a s t a t e c u r r e n t <= I d l e ;
RESDRV < = 1 ;
s h o u l d be low d u r i n g 8 b i t t r a n s f e r s
ISA SBHE < = 0 ;
e l s i f r i s i n g e d g e ( ISA Clk ) then
i s a s t a t e c u r r e n t <= i s a s t a t e n e x t ;
RESDRV < = 0 ;
ISA SBHE < = 1 ;
The VHDL code
63
end i f ;
end process SEQ FSM PROC ;
100
105
110
115
120
125
130
135
140
145
COMB FSM PROC : process ( i s a s t a t e c u r r e n t , f l a g , c h r d y i ) i s

begin
case i s a s t a t e c u r r e n t i s
when I d l e =>
i f f l a g = 1 then
i s a s t a t e n e x t <= Address ;
else
i s a s t a t e n e x t <= i s a s t a t e c u r r e n t ;
end i f ;
when Address =>
i s a s t a t e n e x t <= Data 1 ;
when Data 1 =>
i s a s t a t e n e x t <= Data 2 ;
when Data 2 =>
i f c h r d y i = 0 then
i s a s t a t e n e x t <= i s a s t a t e c u r r e n t ;
else
i s a s t a t e n e x t <= I d l e ;
end i f ;
end case ;
end process COMB FSM PROC;
OUTP FSM PROC : process ( i s a s t a t e c u r r e n t ) i s
begin
case i s a s t a t e c u r r e n t i s
when I d l e =>
b a l e c e <= 0 ;
i o r i o w c e <= 0 ;
d a t a 2 s t a t e <= 0 ;
when Address =>
b a l e c e <= 1 ;
i o r i o w c e <= 0 ;
d a t a 2 s t a t e <= 0 ;
when Data 1 =>
b a l e c e <= 0 ;
i o r i o w c e <= 1 ;
d a t a 2 s t a t e <= 0 ;
when Data 2 =>
b a l e c e <= 0 ;
i o r i o w c e <= 1 ;
d a t a 2 s t a t e <= 1 ;
end case ;
b a l e c e h i n c o n j u n c t i o n w i t h b a l e c e from t h e FSM a r e ANDed t o
64
150
155
160
165
170
175
180
185
190
195
The VHDL code

form t h e ISA BALE s i g n a l .
BALE CE H I : process ( r e s e t , ISA Clk , i s a s t a t e c u r r e n t ) i s

begin
b a l e c e h <= 0 ;
e l s i f f a l l i n g e d g e ( ISA Clk ) then
i f i s a s t a t e c u r r e n t = Address then
b a l e c e h <= 1 ;
else
b a l e c e h <= 0 ;
end i f ;
end i f ;
end process BALE CE H I ;
i o r i o w c e h i n c o n j u n c t i o n w i t h i o r i o w c e e n a b l e s t h e o u t p u t
o f t h e c o r r e c t Read/ Write s i g n a l .
IOR IOW CE H I : process ( r e s e t , ISA Clk , i s a s t a t e c u r r e n t ) i s

begin
i o r i o w c e h <= 0 ;
i f i s a s t a t e c u r r e n t = Data 1 or
i s a s t a t e c u r r e n t = Data 2 then
i o r i o w c e h <= 1 ;
else
i o r i o w c e h <= 0 ;
end i f ;
end i f ;
end process IOR IOW CE H I ;
The Acknowledge s i g n a l c o u l d a l s o go h i g h on f a l l i n g e d g e o f
ISA BALE s i n c e t h a t s i g n a l depend on t h e f l a g . Might be a b e t t e r
s o l u t i o n .
FLAG ACKNOWLEDGE : process ( r e s e t , ISA Clk ) i s

begin
i f f l a g = 1 then
else
end i f ;
end i f ;
The VHDL code
65
end process FLAG ACKNOWLEDGE;
200
205
210
215
220
225
230
235
240
I f CHRDY i s a s s e r t e d a t m i d p o i n t o f second d a t a c y c l e t h e bus

c y c l e w i l l f i n i s h w i t h t h e n e x t r i s i n g e d g e o f t h e ISA c l o c k .
O t h e r w i s e i t w i l l w a i t f o r CHRDY t o go h i g h or u n t i l t h e watch
dog s i g n a l s F a i l u r e .
BUS CYCLE FINISHED : process ( r e s e t , ISA Clk ) i s

begin
f i n i s h i <= 0 ;
i f d a t a 2 s t a t e = 1 and c h r d y i = 1 then
f i n i s h i <= 1 ;
else
f i n i s h i <= 0 ;
end i f ;
end i f ;
end process BUS CYCLE FINISHED ;
On t h e r i s i n g e d g e o f ISA BALE t h e ISA a d d r e s s o u t p u t and t h e

d a t a t r i s t a t e r e g i s t e r i s s e t .
ADDR DATA TRISTATE PROCESS : process ( r e s e t , i s a b a l e i ) i s

begin
ISA SA <= ( others = > 0 ) ;
ISA SD T i <= ( others = > 0 ) ;
e l s i f r i s i n g e d g e ( i s a b a l e i ) then
i f OPB RNW i = 1 then
ISA SA <= ISA Address ;
else
ISA SA <= ISA Address ;
end i f ;
end i f ;
end process ADDR DATA TRISTATE PROCESS ;
During a w r i t e o p e r a t i o n t h e ISA d a t a bus i s w r i t t e n t o on t h e

r i s i n g e d g e o f ISA BALE .
OUTPUTS FF GENERATE : f or i in 1 5 downto 0 generate

DATA OUT REG I : FDRE
port map (
Q
=> ISA SD O ( i ) ,
[ o u t ]
66
245
250
255
260
265
270
275
280
285
290
The VHDL code

C
CE
D
R
=>
=>
=>
=>
isa bale i ,
data out ce ,
ISA Data out ( i ) ,
reset
[ in ]
[ in ]
[ in ]
[ in ]
);
end generate OUTPUTS FF GENERATE;
During a read o p e r a t i o n t h e ISA d a t a bus i s read on t h e l a s t

r i s i n g e d g e o f t h e bus c y c l e .
DATA IN RDY PROCESS : process ( r e s e t , ISA Clk ) i s

begin
r e a d y i <= 0 ;
I S A D a t a i n <= ( others = > 0 ) ;
i f OPB RNW i = 1 and f i n i s h i = 1 then
I S A D a t a i n <= ISA SD I ;
r e a d y i <= 1 ;
else
I S A D a t a i n <= ( others = > 0 ) ;
r e a d y i <= 0 ;
end i f ;
end i f ;
end process DATA IN RDY PROCESS ;
The C USE CHRDY parameter i s used d u r i n g system s p e c i f i c a t i o n t o

t e l l t h e ISA i n t e r f a c e w h e t h e r t o w a i t f o r CHRDY or not .
CHRDY 1 GEN : i f C USE CHRDY = 1 generate

c h r d y i <= CHRDY;
end generate CHRDY 1 GEN ;
CHRDY 0 GEN : i f C USE CHRDY = 0 generate
c h r d y i <= 1 ;
end generate CHRDY 0 GEN ;
A s s o r t e d s i g n a l s
Ready <= r e a d y i ;
Acknowledge <= a c k n o w l e d g e i and b a l e c e h ;
i s a b a l e i <= b a l e c e h and b a l e c e ;
ISA Bale <= i s a b a l e i ;
I S A b c l k <= ISA Clk ;
ISA SD T <= i s a s d t i ;
r e s e t <= OPB Rst or F a i l u r e or not O P B s e l e c t i ;
The VHDL code
295
i s a i o r <= not ( i o r i o w c e and i o r i o w c e h and OPB RNW i ) ;

i s a i o w <= not ( i o r i o w c e and i o r i o w c e h and not OPB RNW i ) ;
F i n i s h <= f i n i s h i and ( not OPB RNW i or r e a d y i ) ;
d a t a o u t c e <= f l a g and not OPB RNW i ;
end IMP ;
67
68
The VHDL code

Listing E.4: Timeout Watchdog
10
15
20
25
30
35
40
45
F i l e :
t o u t w a t c h d o g . vhd
This module p r o v i d e s a watchdog t h a t w i l l c a n c e l a t r a n s a c t i o n i f
t h e s l a v e f a i l s t o answer . The watchdog i s s t a r t e d by t h e f l a g
t h a t i n d i c a t e s t h a t a bus o p e r a t i o n has s t a r t e d , and runs u n t i l
t h e ISA i n t e r f a c e i n d i c a t e s c o m p l e t i o n or u n t i l t h e c o u n t e r
r e a c h e s t h e l i m i t . The C NUM ISA CYCLES TOUT parameter i n d i c a t e s
how l o n g time t h e watchdog s h o u l d w a i t u n t i l I S A F a i l u r e i s
a s s e r t e d .
The watchdog i s r e s e t when t h e p e r i p h e r a l s e l e c t s i g n a l i s low .
H i s t o r y :
2004.01.28 Created by Johan Bernspang
entity timeout watchdo g i s
generic (
C NUM ISA CYCLES TOUT
port (
ISA Clk
OPB select
Flag
ISA Finish
ISA Failure
end timeout watchdog ;
: integer );
:
:
:
:
:
in s t d l o g i c ;
out s t d l o g i c ) ;
architecture IMP of tim eout watchdog i s

signal timeout
: std logic ;
s i g n a l count
: std logic ;
type Watchdog State Machine i s ( I d l e , Counting , F a i l u r e ) ;
signal watchdog state current
: Watchdog State Machine ;
: Watchdog State Machine ;
signal watchdog state next
begin
SEQ FSM PROC : process ( OPB select , ISA Clk ) i s

begin
i f OPB select = 0 then
w a t c h d o g s t a t e c u r r e n t <= I d l e ;
The VHDL code
50
55
60
65
70
75
80
85
90
95
69
e l s i f r i s i n g e d g e ( I S A c l k ) then
w a t c h d o g s t a t e c u r r e n t <= w a t c h d o g s t a t e n e x t ;
end i f ;
end process SEQ FSM PROC ;
COMB FSM PROC : process ( w a t c h d o g s t a t e c u r r e n t , Flag , timeout ,
ISA Finish ) is
begin
case w a t c h d o g s t a t e c u r r e n t i s
when I d l e =>
i f Flag = 1 then
w a t c h d o g s t a t e n e x t <= Counting ;
else
w a t c h d o g s t a t e n e x t <= w a t c h d o g s t a t e c u r r e n t ;
end i f ;
when Counting =>
i f t i m e o u t = 1 then
w a t c h d o g s t a t e n e x t <= F a i l u r e ;
e l s i f I S A F i n i s h = 1 then
w a t c h d o g s t a t e n e x t <= I d l e ;
else
w a t c h d o g s t a t e n e x t <= w a t c h d o g s t a t e c u r r e n t ;
end i f ;
w a t c h d o g s t a t e n e x t <= I d l e ;
end case ;
end process COMB FSM PROC;
OUTP FSM PROC : process ( w a t c h d o g s t a t e c u r r e n t ) i s
begin
case w a t c h d o g s t a t e c u r r e n t i s
when I d l e =>
ISA Failure <= 0 ;
count < = 0 ;
when Counting =>
ISA Failure <= 0 ;
count < = 1 ;
ISA Failure <= 1 ;
count < = 0 ;
end case ;
The c o u n t e r
COUNTER PROC : process ( ISA Clk , count ) i s

variable c o u n t e r
: i n t e g e r range 0 to ( C NUM ISA CYCLES TOUT 1 ) ;
begin
70
100
105
110
i f count = 0 then
counter : = 0 ;
timeout <= 0 ;
i f c o u n t e r < (C NUM ISA CYCLES TOUT 1 ) then
counter := counter + 1;
timeout <= 0 ;
else
counter : = 0 ;
timeout <= 1 ;
end i f ;
end i f ;
end process COUNTER PROC;
end IMP ;
The VHDL code
The VHDL code
71
Listing E.5: ISA Clock Generator
10
15
20
25
30
35
40
45
F i l e :
i s a c l k g e n . vhd
This module g e n e r a t e s t h e ISA c l o c k . I t t a k e s t h e OPB c l o c k and a
d i v i s i o n parameter as i n p u t and c r e a t e s a l o w e r f r e q u e n c y c l o c k
s i g n a l .
NB! The ISA c l o c k f r e q u e n c y can be h i g h e r than 8 MHz . I t depends
on t h e s l a v e s .
H i s t o r y :
entity i s a c l k g e n i s
generic (
C CLK DIV
: integer );
port (
OPB clk
OPB Rst
ISA clk
end i s a c l k g e n ;
architecture IMP of i s a c l k g e n i s
signal i s a c l k i
: std logic ;
begin
Clock : process ( OPB Rst , OPB clk )
variable c l k c o u n t e r
: i n t e g e r range 0 to ( C CLK DIV / 2 1 ) ;
begin
i s a c l k i <= 0 ;
clk counter := 0;
e l s i f r i s i n g e d g e ( OPB clk ) then
i f c l k c o u n t e r < (C CLK DIV / 2 1 ) then
clk counter := clk counter + 1;
else
i s a c l k i <= not i s a c l k i ;
clk counter := 0;
end i f ;
end i f ;
I S A c l k <= i s a c l k i ;
end process Clock ;
end IMP ;
72
The VHDL code

Listing E.6: OPB to ISA communication
10
15
20
25
30
35
40
45
F i l e :
opb isa comm . vhd
This module p r o v i d e s t h e s e c u r e communication betw e en t h e OPB
c l o c k domain and t h e ISA c l o c k domain .
From OPB t h e a d d r e s s , data , and t h e OPB RNW s i g n a l i s t r a n s f e r e d ,
from t h e ISA s i d e o n l y t h e d a t a i s t r a n s f e r e d from a bus read .
When t h e r e i s v a l i d d a t a t o re ad from t h e o t h e r s i d e t h e p r o p e r
f l a g i s a s s e r t e d . The f l a g i s h i g h betw ee n t h e a s s e r t i o n o f t h e
t r a n s m i t t e r s r e a d y s i g n a l and t h e r e c e i v e r s a c k n o w l e d g e s i g n a l .
( c ) 2 0 0 4 Johan
aBernspang , johan<at>bernspang <dot>s e
H i s t o r y :
li b r a r y IEEE ;
entity opb isa comm
port (
OPB Rst
: in
flag 1
: out
flag 2
: out
OPB ready : in
ISA ready : in
OPB ackn : in
ISA ackn : in
end opb isa comm ;
is
architecture IMP of
component cdc i s
port (
reset
: in
ready
: in
ackn
: in
flag
: out
end component cdc ;
opb isa comm i s
std
std
std
std
std
std
std
std
std
std
std
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
;
;
;
;
;
;
);
;
;
;
);
begin
OPB2ISA CDC I : cdc
port map (
reset
=> OPB Rst ,
ready
=> OPB ready ,
ackn
=> ISA ackn ,
flag
=> f l a g 1 ) ;
The VHDL code
50
55
ISA2OPB CDC I : cdc

port map (
reset
=> OPB Rst ,
ready
=> ISA ready ,
ackn
=> OPB ackn ,
flag
=> f l a g 2 ) ;
end IMP ;
73
74
The VHDL code

Listing E.7: Clock Domain Crossing
10
15
20
25
30
F i l e :
cdc . vhd
This i s t h e mechanism t h a t t r a n s f e r s t h e d a t a s a f e t l y a c r o s s t h e
c l o c k domain boundary .
A r e s e t f u n c t i o n s h o u l d be implemented c l e a r i n g t h e f l i p f l o p s and
d e a s s e r t i n g t h e f l a g d u r i n g a t r a n s a c t i o n c a n c e l l a t i o n .
H i s t o r y :
li b r a r y IEEE ;
use IEEE . s t d l o g i c 1 1 6 4 . a l l ;
entity cdc i s
port (
reset
ready
ackn
flag
end cdc ;
:
:
:
:
in
in
in
out
std
std
std
std
logic
logic
logic
logic
architecture IMP of cdc i s

component FDC i s
port (
Q
C
CLR
D
end component ;
;
;
;
);
;
;
;
);
35
signal q transmit : s t d l o g i c ;
signal q r e c e i v e
: std logic ;
signal n o t f l a g
: std logic ;
40
45
begin
Two Df l i p f l o p s w i t h a s y n c hr o n o u s r e s e t
TRANSMIT DFF : FDC

port map (
Q
=> q t r a n s m i t ,
C
=> ready ,
CLR => q r e c e i v e ,
The VHDL code

D
= > 1 );
50
55
60
RECEIVE DFF : FDC

port map (
Q
=> q r e c e i v e ,
C
=> ackn ,
CLR => n o t f l a g ,
D
= > 1 );
f l a g <= q t r a n s m i t ;
n o t f l a g <= not q t r a n s m i t ;
end architecture IMP ;
75
76
E.2
The VHDL code
ISA GPIO code

Listing E.8: ISA GPIO
10
15
20
25
30
35
F i l e :
i s a g p i o . vhd
This f i l e d e s c r i b e s a v e r y b a s i c ISA p e r i p h e r a l . I t i s a GPIO t h a t
i s d e s i g n e d t o w r i t e t o t h e LED d i s p l a y and read t h e DIP s w i t c h e s
on t h e V i r t e x I I d e v e l o p m e n t board .
H i s t o r y :
2004.01.20 Created by Johan Bernspang
use IEEE . STD LOGIC ARITH .ALL;
use IEEE . STD LOGIC UNSIGNED .ALL;
entity i s a g p i o i s
generic (
C ISA BASE ADDR
port (
clk
bale
ior
iow
resdrv
io16
chrdy
isa address
data o
data i
gpio o
gpio i
gpio t
end i s a g p i o ;
: s t d l o g i c v e c t o r ( 1 1 downto 0 ) ) ;
:
:
:
:
:
:
:
:
:
:
:
:
:
in
in
in
in
in
out
out
in
out
in
out
in
out
std
std
std
std
std
std
std
std
std
std
std
std
std
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
logic
architecture B e h a v i o r a l of i s a g p i o i s
40
45
component
port (
Q
:
C
:
D
:
FDR 1 i s
out s t d l o g i c ;
;
;
;
;
;
;
;
vector
vector
vector
vector
vector
vector
( 1 9 downto 0 ) ;
( 1 5 downto 0 ) ;
( 1 5 downto 0 ) ;
( 0 to 2 3 ) ;
( 0 to 2 3 ) ;
( 0 to 2 3 ) ) ;
The VHDL code
77
R
: in s t d l o g i c ) ;
end component FDR 1 ;
50
55
signal
signal
signal
signal
signal
signal
signal
data out reg

data in reg
gpio ce
gpio t i
a d d r ok
chrdy rst
chrdy ce
:
:
:
:
:
:
:
std
std
std
std
std
std
std
logic
logic
logic
logic
logic
logic
logic
v e c t o r ( 0 to 1 5 ) ;
v e c t o r ( 0 to 7 ) ;
;
v e c t o r ( 0 to 2 3 ) ;
;
;
;
type STATE TYPE i s ( I d l e , data ) ;

s i g n a l C u r r e n t S t a t e , N e x t S t a t e : STATE TYPE ;
60
65
70
75
80
85
90
begin
SYNC PROC : process ( c l k , r e s d r v )

begin
i f r e s d r v = 1 then
C u r r e n t S t a t e <= I d l e ;
e l s i f r i s i n g e d g e ( c l k ) then
C u r r e n t S t a t e <= N e x t S t a t e ;
end i f ;
end process ;
COMB PROC: process ( C u r r e n t S t a t e , a d d r ok )
begin
case C u r r e n t S t a t e i s
when I d l e =>
i f a d d r o k = 1 then
N e x t s t a t e <= data ;
else
N e x t S t a t e <= C u r r e n t S t a t e ;
end i f ;
when data =>
N e x t S t a t e <= I d l e ;
end case ;
end process ;
OUTP PROC : process ( C u r r e n t S t a t e ) i s
begin
case C u r r e n t S t a t e i s
when I d l e =>
io16 <= 0 ;
g p i o c e <= 0 ;
when data =>
io16 <= 0 ;
78
95
100
105
110
115
120
125
130
135
140
The VHDL code

g p i o c e <= 1 ;
end case ;
end process ;
Address d e c o d i n g
ADDR DEC PROC : process ( b a l e , g p i o c e ) i s

begin
i f g p i o c e = 1 then
addr ok <= 0 ;
e l s i f f a l l i n g e d g e ( b a l e ) then
i f i s a a d d r e s s ( 1 5 downto 4 ) = C ISA BASE ADDR then
addr ok <= 1 ;
else
addr ok <= 0 ;
end i f ;
end i f ;
end process ADDR DEC PROC;
CHRDY s i g n a l i s a s s e r t e d i f DIP s w i t c h 1 i s 1 , t h i s i s f o r
debug p u r p o s e s .
The FDR s o l u t i o n w i l l r e n d e r a errAck f o r e v e r y OPB w r i t e or
rea d o p e r a t i o n t o an i l l e g a l a d d r e s s , w h i l e t h e FDRE s o l u t i o n
o n l y g e n e r a t e s a errAck when CHRDY i s not a s s e r t e d . The f i r s t
v e r s i o n might g e n e r a t e system e r r o r s on a uCLinux system .
c h r d y c e <= a d d r o k or g p i o c e ;
GPIO CHRDY FF : FDRE 1
p o r t map (
Q
=> CHRDY,
C
=> c l k ,
CE => c h r d y c e ,
D
=> g p i o i ( 2 3 ) ,
R
=> r e s d r v ) ;
c h r d y r s t <= not ( a d d r o k or g p i o c e ) ;
GPIO CHRDY FF : FDR 1
port map (
Q
=> CHRDY,
C
=> c l k ,
D
=> g p i o i ( 2 3 ) ,
R
=> c h r d y r s t ) ;
During a w r i t e o p e r a t i o n , d a t a i s w r i t t e n t o d a t a o u t r e g
DATA OUT PROCESS : process ( c l k ) i s

begin
The VHDL code
145
150
155
160
165
170
i f r i s i n g e d g e ( c l k ) then
i f iow = 0 and ( g p i o c e = 1 or a d d r o k = 1 ) then
fo r i in 0 to 1 5 loop
i f g p i o t i ( i ) = 0 then
d a t a o u t r e g ( i ) <= d a t a i (15 i ) ;
else
d a t a o u t r e g ( i ) <= d a t a o u t r e g ( i ) ;
end i f ;
end loop ;
end i f ;
end i f ;
end process DATA OUT PROCESS;
During a rea d o p e r a t i o n , d a t a i s t r a n s f e r e d from t h e upper g p i o

b i t s t o t h e upper d a t a o b i t s . The low b y t e i n d a t a o i s a l w a y s
z e r o .
DATA IN PROCESS : process ( c l k ) i s

begin
i f f a l l i n g e d g e ( c l k ) then
i f i o r = 0 and g p i o c e = 1 then
for i in 0 to 7 loop
d a t a o ( 8 + i ) <= g p i o i (23 i ) ;
end loop ;
d a t a o ( 7 downto 0) <= ( others = > 0 ) ;
else
d a t a o <= ( others = > 0 ) ;
end i f ;
end i f ;
end process DATA IN PROCESS ;
175
180
79
g p i o o ( 0 to 1 5 ) <= d a t a o u t r e g ;
g p i o o ( 1 6 to 23) <= ( others = > 0 ) ;
g p i o t <= g p i o t i ;
t h e g p i o t i s hardc oded i n t h i s c a s e
g p i o t i ( 0 to 15) <= ( others = > 0 ) ;
g p i o t i ( 1 6 to 23) <= ( others = > 1 ) ;
end B e h a v i o r a l ;
Appendix F
Device utilization
This appendix contain the device utilization information gathered from the place-and-route report for different implementations of the system. The information is used to determine the
hardware utilization of different Ethernet solutions.
System with on-chip Ethernet MAC core:
Device utilization summary:
Number of External IOBs
Number of LOCed External IOBs
Number of MULT18X18s
Number of RAMB16s
Number of SLICEs
165 out of 324

165 out of 165
50%
100%
3 out of 40
34 out of 40
3552 out of 5120
7%
85%
69%
8 out of 16
3 out of 8
50%
37%
146 out of 324

146 out of 146
45%
100%
3 out of 40
30 out of 40
1884 out of 5120
7%
75%
36%
8 out of 16
3 out of 8
50%
37%
Number of BUFGMUXs
Number of DCMs
System without on-chip Ethernet MAC core:
Number of RAMB16s
Number of SLICEs
Number of BUFGMUXs
Number of DCMs
80
Device utilization
81
System with OPB to ISA bridge and OPB GPIO:

Number of RAMB16s
Number of SLICEs
Number of BUFGMUXs
Number of DCMs
192 out of 324

192 out of 192
59%
100%
3 out of 40
30 out of 40
1976 out of 5120
7%
75%
38%
8 out of 16
3 out of 8
50%
37%
System with OPB to ISA bridge and ISA GPIO:

Number of RAMB16s
Number of SLICEs
Number of BUFGMUXs
Number of DCMs
192 out of 324

192 out of 192
59%
100%
3 out of 40
30 out of 40
1940 out of 5120
7%
75%
37%
8 out of 16
3 out of 8
50%
37%
Appendix G
Simulation waveforms
The waveforms in this appendix are taken from the post-place-and-route simulation results in
ModelSim.
The first two simulation waveforms show the results from read operations where the CHRDY
signal is set to zero in the first case. The two latter waveforms show the results from similar
simulations of write operations. A comparison with the ISA specification in section 2.4.1 shows
that the simulated core behaves according to the ISA specification.
82
00000000000000000000000000000000
00000000000000000000
isa_sd_t
Figure G.1: Simulation of read cycle, CHRDY = 0
interrupt11
interrupt10
interrupt9
io16
resdrv
chrdy
irq15
irq11
irq10
irq9
isa_bclk
isa_ior
isa_iow
isa_sbhe
isa_bale
isa_sd_out
0000000000000000
isa_sd_in 0000000000000000
0000000000000000
0000000000000000
isa_sd_o
isa_sd_i 0000...00 1011000100000000
isa_sa
i2o_dbus
i2o_retry
i2o_toutsup
i2o_errack
i2o_xferack
opb_select
opb_seqaddr
opb_be 0000
opb_rnw
opb_dbus 00000000000000000000000000000000
200 ns
opb_abus 0000...00 11111111111111110110000000000000
opb_rst
opb_clk
1111111111111111
11110110000000000000
400 ns
600 ns
0000000000000000
800 ns
00000000000000000000
0000000000000000
83
00000000000000000000000000000000
0000000000000000
isa_sd_t
Figure G.2: Simulation of read cycle, CHRDY = 1
interrupt11
interrupt10
interrupt9
io16
resdrv
chrdy
irq15
irq11
irq10
irq9
isa_bclk
isa_ior
isa_iow
isa_sbhe
isa_bale
isa_sd_out
0000000000000000
isa_sd_in 0000000000000000
0000000000000000
isa_sd_o
1011000100000000
00000000000000000000
isa_sd_i 0000...00
isa_sa
i2o_dbus
i2o_retry
i2o_toutsup
i2o_errack
i2o_xferack
opb_select
opb_seqaddr
opb_be 0000
opb_rnw
200 ns
11111111111111110110000000000000
opb_dbus 00000000000000000000000000000000
opb_abus 0000...00
opb_rst
opb_clk
1111111111111111
11110110000000000000
400 ns
600 ns
0000...00
1011000100...0 0000...00
84
opb_select
00000000000000000000
isa_sd_t
Figure G.3: Simulation of write cycle, CHRDY = 0
interrupt11
interrupt10
interrupt9
io16
resdrv
chrdy
irq15
irq11
irq10
irq9
isa_bclk
isa_ior
isa_iow
isa_sbhe
isa_bale
isa_sd_out
0000000000000000
isa_sd_in 0000000000000000
0000000000000000
0000000000000000
isa_sd_o
isa_sd_i 0000000000000000
isa_sa
i2o_dbus
i2o_retry
i2o_toutsup
i2o_errack
i2o_xferack
00000000000000000000000000000000
opb_be 0000
opb_seqaddr
200 ns
11111100000000010000000000000000
opb_dbus 0000...00
opb_rnw
11111111111111110110000000000000
opb_abus 0000...00
opb_rst
opb_clk
1111110000000001
1111110000000001
11110110000000000000
400 ns
600 ns
0000...00
85
11111100000000010000000000000000
opb_dbus 0000...00
00000000000000000000000000000000
00000000000000000000
isa_sd_t
Figure G.4: Simulation of write cycle, CHRDY = 1
interrupt11
interrupt10
interrupt9
io16
resdrv
chrdy
irq15
irq11
irq10
irq9
isa_bclk
isa_ior
isa_iow
isa_sbhe
isa_bale
isa_sd_out
0000000000000000
isa_sd_in 0000000000000000
0000000000000000
0000000000000000
isa_sd_o
isa_sd_i 0000000000000000
isa_sa
i2o_dbus
i2o_retry
i2o_toutsup
i2o_errack
i2o_xferack
opb_select
opb_seqaddr
opb_be 0000
opb_rnw
11111111111111110110000000000000
opb_abus 0000...00
opb_rst
opb_clk
200 ns
1111110000000001
1111110000000001
11110110000000000000
400 ns
600 ns
86
Copyright
Svenska
Detta dokument h
alls tillgangligt p
a Internet - eller dess framtida ersattare - under en langre tid
fr
an publiceringsdatum under forutsattning att inga extra-ordinara omstandigheter uppst
ar.
Tillg
ang till dokumentet innebar tillst
and for var och en att lasa, ladda ner, skriva ut enstaka
kopior for enskilt bruk och att anvanda det oforandrat for ickekommersiell forskning och for un
dervisning. Overf
oring av upphovsratten vid en senare tidpunkt kan inte upphava detta tillst
and.
All annan anvandning av dokumentet kraver upphovsmannens medgivande. For att garantera
aktheten, sakerheten och tillgangligheten finns det losningar av teknisk och administrativ art.
Upphovsmannens ideella ratt innefattar ratt att bli namnd som upphovsman i den omfattning
som god sed kraver vid anvandning av dokumentet p
a ovan beskrivna satt samt skydd mot att
dokumentet andras eller presenteras i s
adan form eller i s
adant sammanhang som ar krankande
for upphovsmannens litterara eller konstnarliga anseende eller egenart.
For ytterligare information om Linkoping University Electronic Press se forlagets hemsida:
http://www.ep.liu.se/
English
The publishers will keep this document online on the Internet - or its possible replacement - for
a considerable time from the date of publication barring exceptional circumstances.
The online availability of the document implies a permanent permission for anyone to read,
to download, to print out single copies for your own use and to use it unchanged for any noncommercial research and educational purpose. Subsequent transfers of copyright cannot revoke
this permission. All other uses of the document are conditional on the consent of the copyright
owner. The publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be mentioned when his/her
work is accessed as described above and to be protected against infringement.
For additional information about the Linkoping University Electronic Press and its procedures
for publication and for assurance of document integrity, please refer to its WWW home page:
http://www.ep.liu.se/
c Johan Bernsp
ang
Linkoping, 31th May 2004

MACPHY To A MicroBlaze System On A Virtex-II FPGA PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

MACPHY To A MicroBlaze System On A Virtex-II FPGA PDF

Caricato da

Copyright:

Formati disponibili

Interfacing an external Ethernet

MAC/PHY to a MicroBlaze system on

Interfacing an external Ethernet

Supervisor: Doctor John Williams

31th May 2004

Title of series, numbering

Due to the development towards more dense programmable devices

OPB, ISA, Microblaze, FPGA, VHDL, Ethernet, ChipScope

OPB, ISA, Microblaze, FPGA, VHDL, Ethernet, ChipScope

2 Technology & Background

3 Implementation & Testing

4 Results & Discussion

C Hardware and software resources

D Using ChipScope for debugging and functional verification

E The VHDL code

Schematic of a CLB slice . . . . . . . . . . . . .

OPB to ISA bridge architecture . . . . . . . .

Inserter, design specification

unsuccessful read cycle .

Bus bridge specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Technology & Background

Field Programmable Gate Array, FPGA

the time of writing the smallest feature size in production is 90 nm.[2]

Technology & Background

Figure 2.1: A rough schematic of a CLB slice. Source: [6]

on the device size.

Technology & Background

The Microblaze core

Figure 2.2: The Microblaze core block diagram. Source: [9]

Technology & Background

Embedded Development Toolkit, EDK

Media Access Controller, MAC

Technology & Background

Physical Layer Device, PHY

The OPB Ethernet MAC

The ISA bus specification

Technology & Background

Standard 16-bit I/O device ISA bus cycles

bus is always zero during I/O operations.

Technology & Background

Technology & Background

The OPB bus specification

Technology & Background

The OPB cycle

Technology & Background

Technology & Background

Designing OPB peripherals for Microblaze

Clock domain crossing

system clock is 66 MHz in this case

Technology & Background

Implementation & Testing

Choosing Ethernet MAC/PHY

Implementation & Testing

OPB to ISA bridge

Implementation & Testing

ISA clock domain

Implementation & Testing

data bus consistency

Table 3.1: Bus bridge specification

Implementation & Testing

Implementation & Testing

Figure 3.2: The OPB Finite state machine

Implementation & Testing