interfacing an external ethernet mac/phy to a microblaze ...19744/fulltext01.pdf · interfacing an...

Interfacing an external EthernetMAC/PHY to a MicroBlaze system on

a Virtex-II FPGA

Master’s thesisperformed for ITEE, University of Queensland, Brisbane,

Australia

byJohan Bernspang

Reg nr: LiTH-ISY-EX-3440-2004

31th May 2004

Interfacing an external EthernetMAC/PHY to a MicroBlaze system on

a Virtex-II FPGA

Master’s thesis

performed in Computer Engineering,Dept. of Electrical Engineering

at Linkopings universitet

by Johan Bernspang

Reg nr: LiTH-ISY-EX-3440-2004

Supervisor: Doctor John WilliamsITEE, University of Queenland

Professor Neil BergmannITEE, University of Queenland

Examiner: Professor Dake LiuLinkopings Universitet

Linkoping, 31th May 2004

Avdelning, InstitutionDivision, Department

DatumDate

Sprak

Language

Svenska/Swedish

Engelska/English

RapporttypReport category

Licentiatavhandling

Examensarbete

C-uppsats

D-uppsats

Ovrig rapport

URL for elektronisk version

ISBN

ISRN

Serietitel och serienummerTitle of series, numbering

ISSN

Titel

Title

ForfattareAuthor

SammanfattningAbstract

NyckelordKeywords

Due to the development towards more dense programmable devices(FPGAs) it is today possible to fit a complete embedded system includ-ing microprocessor, bus architecture, memory, and custom peripheralsonto one single reprogrammable chip, it is called a System-on-Chip(SoC). The custom peripherals can be of literally any nature from I/Ointerfaces to Ethernet Media Access Controllers. The latter core, how-ever, usually consumes a big part of a good sized FPGA. The purposeof this thesis is to explore the possibilities of interfacing an FPGAbased Microblaze system to an off-chip Ethernet MAC/PHY. A solu-tion which would consume a smaller part of the targeted FPGA, andthus giving room for other on-chip peripherals or enable the use of asmaller sized FPGA. To employ a smaller FPGA is desirable since itwould reduce power consumption and device price. This work includesevaluation of different available Ethernet devices, decision of interfacetechnology, implementation of the interface, testing and verification.Since the ISA interface still is a common interface to Ethernet MACdevices a bus bridge is implemented linking the internal On-Chip Pe-ripheral Bus (OPB) with the ISA bus. Due to delivery delays of theselected Ethernet chip a small on-chip ISA peripheral was constructedto provide a tool for the testing and verification of the bus bridge. Themain result of this work is an OPB to ISA bus bridge core. The bridgewas determined to work according to specification, and with this reportat hand the connection of the Ethernet chip to the system should bequite straightforward.

Computer Engineering,Dept. of Electrical Engineering581 83 Linkoping

31th May 2004

—

LITH-ISY-EX-3440-2004

—

http://www.ep.liu.se/exjobb/isy/2004/3440/

Interfacing an external Ethernet MAC/PHY to a MicroBlaze systemon a Virtex-II FPGA

Utveckling av ett granssnitt mellan ett externt ethernetchip och ettMicroblaze system pa en Virtex-II FPGA

Johan Bernspang

××

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

Abstract

Due to the development towards more dense programmable devices (FPGAs) it is today possibleto fit a complete embedded system including microprocessor, bus architecture, memory, andcustom 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 MediaAccess 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 Microblazesystem to an off-chip Ethernet MAC/PHY. A solution which would consume a smaller part of thetargeted FPGA, and thus giving room for other on-chip peripherals or enable the use of a smallersized FPGA. To employ a smaller FPGA is desirable since it would reduce power consumptionand device price. This work includes evaluation of different available Ethernet devices, decisionof interface technology, implementation of the interface, testing and verification. Since the ISAinterface still is a common interface to Ethernet MAC devices a bus bridge is implemented linkingthe internal On-Chip Peripheral Bus (OPB) with the ISA bus. Due to delivery delays of theselected Ethernet chip a small on-chip ISA peripheral was constructed to provide a tool for thetesting and verification of the bus bridge. The main result of this work is an OPB to ISA busbridge core. The bridge was determined to work according to specification, and with this reportat hand the connection of the Ethernet chip to the system should be quite straightforward.

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

v

Contents

Abstract v

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4.1 Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Technology & Background 42.1 Systems-on-Chip, SoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Field Programmable Gate Array, FPGA . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Virtex-II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.2 The Microblaze core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.3 Embedded Development Toolkit, EDK . . . . . . . . . . . . . . . . . . . . 7

2.3 Ethernet MAC/PHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.1 Media Access Controller, MAC . . . . . . . . . . . . . . . . . . . . . . . . 72.3.2 Physical Layer Device, PHY . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.3 The OPB Ethernet MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Bus architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.1 The ISA bus specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.2 Standard 16-bit I/O device ISA bus cycles . . . . . . . . . . . . . . . . . . 92.4.3 The OPB bus specification . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.4 The OPB cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 Designing OPB peripherals for Microblaze . . . . . . . . . . . . . . . . . . . . . . 142.5.1 IPIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.6 Clock domain crossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Implementation & Testing 163.1 Choosing Ethernet MAC/PHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 OPB to ISA bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.1 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.3 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3 ISA General Purpose I/O, GPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.4 Testing methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4.1 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

vi

3.4.2 On-Chip verifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Results & Discussion 294.1 Device utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 Microblaze utilization/waste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Conclusions 335.1 Lessons learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2.1 Further work on the bus bridge . . . . . . . . . . . . . . . . . . . . . . . . 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 40D.1 ChipScope for dummies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

D.1.1 Inserter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40D.1.2 Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

E The VHDL code 46E.1 OPB to ISA bus bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46E.2 ISA GPIO code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

F Device utilization 80

G Simulation waveforms 82

vii

List of Figures

2.1 Schematic of a CLB slice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 The Microblaze Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Standard 16-bit I/O device ISA bus cycle . . . . . . . . . . . . . . . . . . . . . . 102.4 Basic OPB transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 Circuit for moving data across clock boundary . . . . . . . . . . . . . . . . . . . 15

3.1 OPB to ISA bridge architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 The OPB Finite state machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 The ISA Finite state machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.4 The Timeout Watchdog Finite state machine . . . . . . . . . . . . . . . . . . . . 243.5 The ISA GPIO core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1 OPB to ISA read operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 OPB to ISA write operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3 OPB to ISA read operation with failure . . . . . . . . . . . . . . . . . . . . . . . 304.4 OPB to ISA write operation with failure . . . . . . . . . . . . . . . . . . . . . . . 31

D.1 ChipScope Inserter, design specification . . . . . . . . . . . . . . . . . . . . . . . 41D.2 ChipScope Inserter, trigger parameters . . . . . . . . . . . . . . . . . . . . . . . . 42D.3 ChipScope Inserter, capture parameters . . . . . . . . . . . . . . . . . . . . . . . 42D.4 ChipScope Inserter, net connections . . . . . . . . . . . . . . . . . . . . . . . . . 43D.5 ChipScope Analyzer trigger setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 45D.6 ChipScope Analyzer waveform capture . . . . . . . . . . . . . . . . . . . . . . . . 45

G.1 Simulation of unsuccessful read cycle . . . . . . . . . . . . . . . . . . . . . . . . . 83G.2 Simulation of successful read cycle . . . . . . . . . . . . . . . . . . . . . . . . . . 84G.3 Simulation of unsuccessful write cycle . . . . . . . . . . . . . . . . . . . . . . . . 85G.4 Simulation of successful write cycle . . . . . . . . . . . . . . . . . . . . . . . . . . 86

viii

List of Tables

3.1 Bus bridge specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1 Device utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

ix

List of Listings

E.1 Bus Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46E.2 OPB Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55E.3 ISA Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61E.4 Timeout Watchdog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68E.5 ISA Clock Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71E.6 OPB to ISA communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72E.7 Clock Domain Crossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74E.8 ISA GPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

x

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 peripher-als can improve real-time response rates. The research is mainly based on a Field ProgrammableGate Array (FPGA) with a MicroBlaze softcore processor from Xilinx running a version of em-bedded Linux, uCLinux. The port of uCLinux to Microblaze is made by a member of the researchgroup, John Williams, who is also one of the supervisors of this project. The group has proposeda future platform for real-time reconfigurable system on chips, Egret, which would be based ona Microblaze softcore processor running uCLinux.[1]

One of the key capabilities of an embedded real-time system is to communicate efficientlywith the surrounding environment. An Ethernet core can easily be added to the system as anon-chip peripheral on the utilized FPGA, however with the significant drawback that it covers acomparatively large part of the chip. Thus, taking room from other potential peripherals or real-time tasks implemented in hardware, or forcing the use of a larger and more expensive FPGA.This master’s 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 theFPGA chip as possible. The reason to achieve small solution would be to make room for othertime critical tasks to be implemented in hardware. A small solution would also enable the useof a smaller FPGA device which would be cheaper and consume less power. Price and powerconsumption are two negative aspects with employing FPGA chips instead of using the ASICtechnology.

The first task of this project was a thorough investigation of previous attempts to interface anEthernet MAC/PHY with a Microblaze system. No such solution was to be found though, in allprevious 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 EthernetMAC/PHY of choice and to review the involved technologies. Finally, a careful testing andverification 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 degreeat the university of Linkoping in Sweden. Examination is done by the professor in computerengineering, Dake Liu, at the department of electrical engineering.

1

2 Introduction

1.2 Objectives

The main objective of this thesis is to find a suitable Ethernet MAC/PHY for the existingsystem and create an interface between the chip and the Microblaze system. In order to reachthis 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, thedevelopment tools and the development of Microblaze peripherals. The review should coverthe bus architecture utilized by Microblaze systems and the design of custom peripherals.

• Review of the interface technology between the chosen Ethernet chip and the Microblazesystem. Design challenges should be identified and evaluated.

• Development of an interface between Ethernet chip and the system. Preferably this inter-face 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 usebesides 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 Xilinxdevices. Tutorials on EDK and ISE were used for this purpose. Second, a suitable EthernetMAC/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 Microblazesoftcore processor were investigated to give an understanding about how the custom core was tobe implemented.

When the topics mentioned in the previous paragraph had been thoroughly studied in variouspublications, an OPB to ISA bus bridge was designed and implemented. To verify the designboth 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 aspectof the limitations is the availability of software and hardware. For an indepth explanation ofthe available resources for the implementation and testing of the OPB to ISA bus bridge, seeappendix 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 require-ments at the university of Linkoping.

1.5 Thesis outline

Chapter 2, Technology & Background, will give the reader sufficient background informationregarding the different technologies that will be utilized throughout the thesis.

Introduction 3

Chapter 3, Implementation & Testing, covers the different options of Ethernet chip aswell as the design and implementation of the bus bridge and a very simple on-chip ISAperipheral. 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 andsoftware resources, a short guide and tutorial to ChipScope, the source code for the VHDLimplementations, details about device utilization, and simulation waveforms.

Chapter 2

Technology & Background

This chapter will cover the underlying theories for the technologies that are utilized throughoutthis thesis. The technologies include SoC in general, the employed FPGA family, Virtex-IIfrom Xilinx, Ethernet, the OPB and ISA specifications, guidelines to design of custom OPBperipherals, and how to provide a secure data path across clock domain boundaries. For a morein-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 wirelesscommunication systems, etc., have become increasingly complex. At the same time the featuresize of integrated circuits has decreased significantly making room for more transistors on onepiece of silicon than ever before.1 The trend towards more dense silicon technologies has ledto more sophisticated FPGA circuits that allow integration of numerous functions onto a singlesilicon chip, thus it can be utilized for a wider range of applications. Instead of using differentchips 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 samepiece of silicon.

One recent development is towards reconfigurable System on Chip, even though the approachwas 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 tomeet timing issues, depending on the demand of the system. When designing reconfigurable SoCit is possible to use more hardware than available on the target chip, peripheral netlists are keptin 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 cir-cuits at the board level using standard components, or at the gate level relying on expensiveASIC technologies. Today the designers can use the FPGA technology to verify the function-ality of a system during the design flow. An FPGA is a generic integrated circuit consisting ofconfigurable logic blocks (CLBs) and programmable interconnections. A design is implementedby specifying a simple logic function for each cell, and closing the appropriate switches in the

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

4

Technology & Background 5

interconnection network. Modern FPGA circuits contain enough logic to implement SoCs andother complex designs.[4]

The term Field Programmable implies that the function of the FPGA is defined by a user de-scription rather than by the manufacturer of the circuit. The user employ a hardware descriptionlanguage (HDL), such as VHDL or Verilog, to describe the desired system. Synthesis softwareis 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-chipthe latter is of particular interest. A SRAM-based FPGA can be programmed during systeminitialization, and it can also be changed dynamically during system operation.[5]

FPGA circuits are well suited for prototyping and small production volumes. The use ofFPGAs also enables future hardware updates. That is, if bugs in the implementation are dis-covered a new bit file can be downloaded to the device in very short time without disturbingthe execution of the system too much. However, since an FPGA is not optimized for a specificapplication it may consume more power or be less efficient implementation of the design than anASIC. 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]. Xilinxhas developed a number of FPGA families. The Virtex-II family is developed for high per-formance from designs based on customized modules and IP cores. The family consists of 11members, ranging from 40K to 8M system gates.[6] The Virtex-II platform is the result of thelargest development attempt in the history of programmable logic, and it has many novel fea-tures which simplifies the design and implementation of complex systems. A Virtex-II FPGAhas, for instance, up to 16 low-skew clock domains2, and on-chip controlled output impedancesto eliminate external termination resistors.[7]

LUT F

LUT G Register

Register

Arithmetic logic

MUX

MUX

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. Theinterface 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-data-rate register (DDR), as output block with single-rate register or DDR, or with an optional

2Depending on the device size.

6 Technology & Background

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 logicblocks has four major elements. Functional elements for combinatorial and synchronous logicis 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 clockmanagers (DCM) provide a self-calibrating, fully digital delay compensated solutions for clockmultiplication 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 ofslices provides a good measure of device utilization during synthesis. Each slice is composed of two4-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 alsobe used as a 16 bit distributed RAM or a 16 bit variable-tap shift register. A LUT is able toimplement any arbitrary 4-input boolean function, and its output drives both the slice outputand the input to the corresponding register in the slice. The multiplexers are included in theVirtex-II slices to enable logical functions with up to 8 inputs, i.e. a combination of the twoLUTs. In a Virtex-II the storage elements can be configured either as edge-triggered D-flip-flopsor as level-sensitive latches.[6]

2.2.2 The Microblaze core

To enable the development of more powerful embedded solutions with the Xilinx FPGAs thecompany 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 consistsof a three stage pipeline with separate instruction and data paths (Harvard-style). The core isillustrated in figure 2.2 below.[8]

Bus IF

Bus IF

Instruction-side bus interface

Data-side bus interface

Program Counter

Instruction Buffer

ILMB

IOPB

Instruction Decode

Register File 32 x 32 bit

Add/Sub

Shift/Logical

Multiply

DLMB

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 forthe data path. Each of the interfaces is divided into an interface for the On-chip PeripheralBus (OPB), and an interface for the Local Memory Bus (LMB). The connection to the on- andoff-chip peripherals and memory is provided by the OPB, while a single-cycle access to on-chip

3A soft core processor has a configurable architecture. It is possible to add custom design peripherals and/orinstructions prior to synthesis.


dual-port block RAM is provided by the LMB. A Microblaze platform must include one datapath 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 mostsignificant bit (MSB) in a vector is positioned in bit zero. When designing custom cores, orusing pre-designed peripherals, care has to be taken when connecting vectors with differentendian conventions.[9]

2.2.3 Embedded Development Toolkit, EDK

To facilitate the development of embedded systems based on FPGAs from Xilinx the companyhas provided the Embedded Development Kit, EDK. EDK comprises the whole tool chain thatis needed to transform a specification into a running embedded system, as well as the Microblazecore 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. Inthe file each core of the system is configured and given an address space. The processor and busarchitecture 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 systemin 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 isinput to the library generator tool which is employed to configure the peripheral device driversand libraries.[10] The system netlist is input to a chain of tools that carries out mapping of thesystem, placement of the logic functions onto CLBs, routing of the interconnects, and finallygeneration 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 embed-ded system need some sort of network interface. The most widespread network protocol usedtoday is the IEEE 802.3 standard, a.k.a Ethernet. An Ethernet adapter consists of two parts: theMedia 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 mech-anism is based on a system called Carrier Sense Multiple Access with Collision Detection (CS-MA/CD). Carrier sense means that all devices need to listen for a period of quiet before at-tempting to send. Multiple access imply that when it has been quiet long enough all devices hasequal chance of sending. Finally, due to collision detection, if two devices start to send at thesame time the collision is detected and both quit the attempts.[12]

The Ethernet protocol sends data, and additional information, in packets. Prior to the packeta 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 packetis the header which includes destination address, source address and data type. Following theheader is 46 to 1500 bytes of data. If the data in a packet is less than 46 bytes it has to be paddedwith unused bytes. After the data section is finally an error detection section. On the mediumthe packets are transmitted serially to four bits in parallel over the shared channel to everyconnected 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 thenext transmission.[12, 13]

2.3.2 Physical Layer Device, PHY

Several different types of medium are available for Ethernet networks; coaxial- and twisted paircables and optical fibers. There are three common physical layers utilized to connect the EthernetMAC 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 MIIand RMII were introduced with 10/100 MBit/s Ethernet standard. MII and RMII offer someextent 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 notknow 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 aMII 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 withthe rest of the system. To achieve 10 Mbit/s Ethernet communication the system clock mustbe at least 6.5 MHz. Thus, by dividing the minimum clock frequency with the number of OPBdata transitions per second gives the number of employed OPB clock cycles per transition, seecalculation below.[13]

650000010000000/32

= 21

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. Firstof all, the core is not free of charge, in order to use it for more than a few hours at a time alicense fee has to be paid. Second, on a Virtex-II FPGA the core consumes at least 1555 sliceswhich 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, andthe newer OPB.

2.4.1 The ISA bus specification

Originally, in the IBM PC, the Industry Standard Architecture bus was only 8 bits wide, butwith the evolution towards the IBM PC/AT it was expanded to 16-bit data width with someadditional functionality. At a later stage the ISA bus was extended to 32 bits with the adventof Extended Industry Standard Architecture (EISA). Still today, the ISA bus is one of the mostcommon interfaces among Ethernet devices. There are a number of different ISA bus cycles, both8-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 communicatingwith a microprocessor.


The ISA bus can be divided into three different parts; the address bus, the data path, and thecontrol- and timing signals. A hash sign (#) after a signal name indicates that the signal is activelow. Signals used during memory operation, such as DMA, are omitted since the implementationin this thesis only work in I/O mode.

• Address bus: The system address bus, SA, consists of the lower 20 bits of the micro-processor address. During address time, Ts, the address is latched onto the address busand 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 bitsare called the latchable address bus, LA4. Some processors and peripherals also make useof 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 inthis 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 andwrite operations. If a peripheral is 8-bit, only the lower path5 is used. For 16-bit transfersthe lower path is used to transfer data to even-addressed locations, and the upper path isused to transfer data to odd-addressed locations.[15]

• Control- and timing signals: Depending on the nature of the ISA cycle, hence if it isan I/O read or an I/O write operation, the appropriate control signal, IOR# respectivelyIOW#, is asserted during Tc.[15]

The ISA bus clock BCLK is derived from the system clock. Usually the ISA clock has afrequency between 8 and 8.33 MHz. Some peripherals, however, allow frequencies up to 11MHz6 or more.[15]

The buffered address latch enable, BALE, signal is asserted during the second half of Ts. Itindicates that the address bus is now valid and latched onto SA. When the microprocessoris not the bus master, i.e. when DMA is utilized for instance, the BALE signal is constantlyasserted. For peripherals that are not fast enough to respond to a standard ISA bus cyclethe channel ready signal, CHRDY, can be utilized. The peripheral deasserts the signalsand, thus, adds clock cycles to the bus cycle until it asserts CHRDY again. To indicatethat the peripheral can support one wait-state I/O bus cycle it asserts the I/O size 16signal, IO16#.[15]

During power-on the reset signal, RESDRV, is asserted in order to force the peripheralsinto a known state. The RESDRV also prevents the peripherals from doing anything untilthe power is stabilized or until the microprocessor is ready to receive data or interruptsfrom a peripheral. Originally the ISA bus structure had four interrupt lines that were notassigned 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 implemen-tation. The data width may be either 8 or 16 bit, the peripheral may be either a memory device

4This bus is always zero during I/O operations.5The lower path constitutes of bits 0 to 7 on the ISA data bus.6The Ethernet chip used in this thesis accepts clock frequencies between 8 and 11 MHz.[16]7These 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.


or an I/O device. This section describes the standard 16-bit I/O device bus cycle which consistsof one address clock cycle and two data clock cycles. Each step corresponds to a reference pointin figure 2.3.[15]

BCLK

Tc2 Ts Tc1 Tc2

Address bus, SA

BALE

IOR#, IOW#

i iii

ii

iv

Read data, SD

Write data, SD

vii

CHRDY

IO16#

v

vi

Figure 2.3: This figure describes a standard access to a 16-bit I/O ISA device. The figure is amodified version of figure 17-3 in [15].

i. When BALE is asserted halfway through Ts, the address is latched onto the SA bus. Theaddress remains on the SA bus for the remainder of the bus cycle, and until the next ISAaddress is latched onto the bus.

ii. If the current cycle is a write, the output data is latched onto the SD bus simultaneouslywith the address. The valid data is available on the data bus, SD, until halfway throughTs 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 lineremains 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 thetransaction by the end of this clock cycle, it should deassert CHRDY. Additional datatime is given until CHRDY is asserted to indicate that the bus cycle can be completed.


vi. To determine if the I/O device is 8 or 16-bit wide the IO16# is sampled at the midpointof Tc2. If asserted the bus cycle will be terminated at the end of Tc2 without any datasteering. 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. Incase of a read operation, data is read from the SD bus at the rising edge of BCLK thatterminates the bus cycle.

2.4.3 The OPB bus specification

IBM has developed a family of three different busses for interconnecting cores and custom logicin system-on-chips, the CoreConnectTMbus architecture. The family consists of the ProcessorLocal Bus (PLB), On-Chip Peripheral Bus (OPB), and Device Control Register bus (DCR). ThePLB is utilized for interconnection between high-bandwidth devices, mainly in Virtex-II PROdevices. For instance processor cores, external memory interfaces, and DMA controllers. TheDCR 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 communi-cation between the processor core and on-chip memory the Microblaze uses Xilinx Local MemoryBus[9].

The Microblaze utilize one or more instances of the OPB to communicate with on-chip pe-ripherals. 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 num-ber of slaves. The Xilinx implementation, however, supports up to 16 masters together withan unlimited number of slaves (depending on hardware resources). When several OPB mastersshare a bus, an OPB Arbiter8 is used to grant exclusive bus access. Thus, a master may haveto wait an arbitrary number of clock cycles until the bus is idle. In order to obtain several slaveoperations per bus grant an OPB master may utilize a bus lock, also referred to as burst orsequential 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 asa distributed multiplexer where the different slave data busses and other outputs are ORedtogether9. This approach make it possible to add peripherals to a system without changing theexisting peripherals.[18]

The OPB signals are grouped into five categories: arbitration signals, bus signals, data trans-fer control signals, byte enable support signals, and DMA peripheral support signals. The twolatter categories are optional, and are not discussed in this thesis. This section will describe therelevant signals for an OPB slave.[18]

• Arbitration signals: If a slave does not respond to an operation, or does not assertthe Sln toutSup10 (see data transfer control signals below) within 16 clock cycles after theOPB select signal is asserted, the arbiter will assert the OPB timeout signal. It indicatesto the master of the operation that the slave does not respond, and the operation has tobe 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 mustremain asserted until the slave is deselected.[18]

8The Xilinx OPB implementation that comes together with the EDK includes an arbiter.9Thus, every slave must drive all outputs to zero when inactive.

10The Sln prefix indicates that the signal is directed from the slave to the bus. Mn is the prefix for a signalgoing from a master to the bus.


• Bus signals: Each slave is given an address range during the system specification. Toaccess 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 togetherto form the data bus, OPB DBus. Both in- and out-data has its most significant bit inposition 0.[18]

• Data transfer control signals: When a bus master is granted to use the bus by thearbiter it asserts the OPB select signal together with the correct address. The select signalwill 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 thebus terminates the transaction by deasserting OPB select, all slaves must terminate theprocess and reset their state machines.[18]

The direction of the transaction is indicated by OPB RNW, Read Not Write. It mustbe valid any time the OPB select is asserted. If the signal is high it indicates that aread operation is taking place, and if it is low it indicates that the current operation is awrite.[18]

The bus architecture provides the OPB seqAddr signal to indicate that the following buscycle 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 otheraddresses if the OPB seqAddr is correctly asserted by a master. If the signal is ignored bythe slave, the data transfer proceeds normally.[18]

To indicate that the slave is finished and, in case of a read operation, valid data is availableon Sln DBus, the slave asserts the transfer acknowledge signal, Sln xferAck. The signalmust not be asserted for more than one clock cycle per data transfer, nor in conjunctionwith Sln retry. If Sln xferAck is asserted in the same cycle as OPB timeout, the bus mastershould 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 xferAck.[18]

By default the OPB Arbiter asserts the OPB timeout after 16 clock cycles. To preventa bus timeout, slow slaves may assert the timeout suppress signal, Sln toutSup, at anytime before the 16th clock cycle. Sln toutSup must remain asserted until the operation iscompleted.[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 asshort as two clock cycles, but usually the bus cycle is longer than that. This section describesa basic bus operation regardless of the speed of the slave. Each step corresponds to a referencepoint in figure 2.4.[18]

i. One clock cycle after a master is granted access to the bus by the arbiter it assertsOPB select. At the same time the valid address and, in case of a write operation, thevalid data is written to OPB ABus and OPB DBus respectively.


OPB_CLK

OPB_ABus

OPB_DBus

OPB_select

iii

OPB_RNW

Sln_xferAck

Sln_errAck

Sln_toutSup

iv

v

i

1 2 … n - 1 n

ii

vi

Figure 2.4: This figure describes a basic OPB transaction. The figure is a modified version offigure 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 ofOPB select, then it must assert the Sln toutSup signal. Otherwise will the slave not beable 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 lastclock 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 wellduring the last clock cycle.

vi. When the master has registered the Sln xferAck it deasserts OPB select. At the same timezeros are written to OPB ABus and OPB DBus. When OPB select is deasserted the slaveshould deassert any outputs to the OPB, i.e. the outputs should be driven to zero.


2.5 Designing OPB peripherals for Microblaze

Due to the complexity of modern SoC devices, a standardization of the connection of differentcores has been an important development issue for Xilinx. The choice of incorporating theOPB into EDK has made the interfacing of custom logic to a Microblaze system is a relativelystraightforward task.[20]

There are, however, some considerations to keep in mind when designing a custom OPBperipheral. 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 platformgenerator in order to enable the automated system synthesis flow. Additionally there are somegeneral 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 unusedlines to zero, or apply appropriate steering logic

For compatibility with the platform generator two additional files are needed together withthe code; the .PAO and .MPD files. The first file specifies the Peripheral Analyze Order anddefines which HDL files that are needed for synthesis. The second file is the MicroprocessorPeripheral Description file. It defines the interface of the core, i.e. properties of input andoutput 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 theOPB 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 Xilinxplatforms only. If a design is to be re-used with a different bus architecture, or on an FPGA ofdifferent 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 busis working with a clock frequency between 8 and 8.33 MHz. Design of a core that is working intwo different, asynchronous, clock domains need some mechanism for safe transfer of data acrossthe clock boundary.

One solution is proposed in [23]. When data is ready on the transmitting side a D-flip-flop isclocked and, thus, asserting a flag signal common to both the transmitter and the receiver. Aslong as the flag is high the transmitter must maintain the data on the bus. The receiver readsthe data into a register in the receiver clock domain and clocks a flip-flop that resets the transmitflip-flop and pulls the flag low. When the flag is low the flip-flop on the receiver side is reset.

11The system clock is 66 MHz in this case


Parallel data

D Q

CLK

Q D

CLK

High High

Clear Clear

Flag

Ready Acknowledge

Transmitter Receiver

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 andtesting of the OPB to ISA bus bridge. The first section describes the different Ethernet optionsavailable and how the choice was made, the second section explain the bridge, and the thirdsection 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 conjunctionwith an off-chip physical layer it provides a working network interface. One drawback with thecore, however, is its size. When included in a Microblaze based embedded system it will usealmost one third of a Virtex-II device with one million gates. Since the FPGA might be utilizedfor more applications, than merely a microprocessor connected to a local network or to theinternet, it is desirable to find a solution where the system is cooperating with an externalEthernet 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 Microblazesystem, 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 sortof development board1.

• The communication interface between the chip and the system need to be of a known typewhich 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 adevice 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, thuseither 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

Implementation & Testing 17

There were several candidates when choosing an Ethernet MAC/PHY chip to use in conjunc-tion 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 aswell. 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 notsuitable to use with the target operating system, uCLinux, due to its complexity. The DM9008and RTL8019AS offered only 5V I/O signals, hence unsuitable to use in conjunction with theVirtex-II FPGA which only supports 3.3V I/O signals. Of the remaining three only CS8900Awas readily available on a development board. The option of designing a custom printed circuitboard (PCB) for the LAN91c111 was considered, but the idea was rejected due to limited timeand 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 amongthe available Ethernet MAC/PHY chips, future implementations of a Microblaze system withexternal MAC/PHY are not bound to use CS8900A. The only requirement which was not metis 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 theCS8900A 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. Consequentlya 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 wascreated similar to the interfaces of the existing OPB peripherals where a simple bus wrapper iscreated to interface the custom logic with the OPB.3

The OPB to ISA bus bridge was implemented as a custom OPB slave peripheral. The initialstep in the design flow was to identify the different parts of which the core should consist. Theseparts were designed as independent entities to enable a smaller scale development. Thus, thesimulation 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 outconveniently 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 ISAinterface, and the glue logic around and inbetween the bus interfaces. The different parts are:

• Bus wrapper

• OPB interface2In 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.3Only IPIF from EDK v3.2 was tried, recent releases of EDK include a revised version of IPIF which might

work correctly.

18 Implementation & Testing

• 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 buswrapper, the timeout watchdog and the clock domain crossing (CDC) mechanism. The pselectmodule is shown in the figure, but is included as a part of the bus wrapper. The clock boundaryis defined by the dashed line.

OPB interface

OPB_ABus(0:31)

OPB_DBus(0:31)

OPB_BE(0:4)

OPB_clk

OPB_Rst

OPB_RNW

OPB_select

OPB_seqAddr

I2O_DBus(0:31)

I2O_xferAck

I2O_errAck

I2O_toutSup

I2O_retry

OPB_select_i

ISA clock generator

ISA interface

ISA_SA(19:0)

ISA_SD(15:0)

ISA_BALE

ISA_IOR

ISA_IOW

ISA_BCLK

ISA_CHRDY

ISA_IO16

ISA_RESDRV

IRQ9

IRQ10

IRQ11

IRQ15

ISA_SHBE

OPB to ISA communication

Ready 2

Acknowledge 1

Timeout watchdog

ISA clk

Flag 1

Flag 2

ISA_Finish

ISA_Failure

OPB_select_i

pselect

Ready 1

Acknowledge 2

Bus wrapper

IRQ9

IRQ10

IRQ11

IRQ15

Interrupt9

Interrupt10

Interrupt11

Data to OPB

Interrupt15

ISA clock domain OPB clock domain

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 differentissues.

The OPB interface and the ISA clock generator are working synchronous to the system clockwhich is equal to the OPB clock, while the ISA interface and the timeout watchdog are working


synchronous to the ISA clock signal. The communication module is asynchronous and triggerson 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 addresson the OPB address bus which is in the defined address range of the core, the address rangeis set in the MHS file during system design. When the bridge is inactive all output signals tothe OPB are driven to zero, see section 2.4.3. Since the bus bridge is an OPB slave it is nevertriggered by an ISA peripheral. Thus, the ISA interface is only started when an address or datais available from the OPB side. According to specification, section 2.4.1, the address and databusses on the ISA side are latched. That is, at a certain time in the ISA bus cycle address, andin case of a write operation, data are written to the respective bus. The content on the busses isnot changed until the next ISA bus cycle. The ISA control signals are registered, however, andreset at the end of each bus cycle. In the glue logic the address- and data paths are registeredand driven to zero by the OPB interface when the bridge is inactive. The control signals, suchas ISA Finish and ISA Failure, are registered and synchronous to the clock signals as well, whilethe flag signals from the CDC are registered but asynchronous to the clock signals.

Table 3.1: Bus bridge specificationissue OPB Glue ISAclock System clock System and ISA clock ISA clockhandshake Triggered by CDC started by Started with the

OPB select signal ready signals, rising edge of theand correct address watchdog triggered flag indicating

by internal select available datadata bus consistency Zero when inactive Zero when inactive Latched dataaddress bus cons. Zero when inactive Zero when inactive Latched addresscontrol signal cons. Zero when inactive Registered Registered

3.2.2 Components

Every module that performs a series of tasks with inputs from other parts of the core, or otherparts of the system was designed as a finite state machine. That is, the two bus interfaces andthe timeout watchdog. The finite state machine approach provided a straightforward method tomake the bus interfaces speak the particular bus specification since a FSM is clock dependent andthe bus architectures are synchronous. During synthesis the state machines are highly optimizedby the synthesis tool, which minimize the device utilization. The ISA clock generator and CDCmodules 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 fromthe state machines are dependent of the current state and independent of the input signals. Itwas necessary to use the Moore approach since the output signals from the finite state machineshad 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 surroundingsystem, and ties the different parts together to one visible entity. In figure 3.1 the wrapper

4The alternative approach is the Mealy state machine. In such machine the outputs are affected by the inputsand can be altered asynchronously.


is defined by the line surrounding the different modules. Apart from the modules designedspecifically for this core, and discussed below, the wrapper also consists the pselect module. Itis a highly optimized address decoder provided by Xilinx. It takes the OPB select signal andthe address bus as inputs and generates the internal OPB select when the address on the bus iswithin 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 systemdesign, see lines 36 to 40 in listing E.1.

• C ISA CLK DIV is an integer forwarded to the ISA clock generator which specifies thefactor by which the system clock should be divided by to obtain the ISA clock signal. Bydefault this constant is set to 8 which is a suitable division factor for the system usedduring the design and implementation of this core.

• C USE CHRDY is a bit used by the ISA interface to decide whether it should wait forthe CHRDY signal to be asserted or not before the bus cycle is finished. By default thisconstant is set to 1.

• C NUM ISA CYC TOUT is an integer forwarded to the timeout watchdog telling it howmany ISA clock cycles to wait before ISA Failure should be asserted. By default thisconstant is set to 16 clock cycles.

• C ON CHIP SL ONLY is a single bit telling the bus wrapper whether the ISA peripheralswill be on-chip only, or both on- and off-chip. It is necessary for this parameter to be 1 ifonly on-chip peripherals are connected to the ISA bus. If no peripherals are connected tosignals going off-chip, the signals will end up in an undefined, or high, state. By defaultthis constant is set to 1 and should thus be changed when the off-chip Ethernet MAC isconnected to the ISA bus interface.

• C NUM ON CHIP SL is an integer telling the bus wrapper how many on-chip peripheralsare connected to the ISA bus. It is used to generate the correct number of CHRDY signalinputs, 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. Consequentlyon-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 isto communicate with the on-chip peripheral bus according to the bus specification, see section2.4.4. The OPB interface is also responsible for initiating the ISA bus cycle. The state machineconsists of six states; Idle, Send, Waiting, Receive, Finish, and Failure, as illustrated in figure3.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 Idlestate 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 theISA bus cycle is started by asserting the OPB interface ready signal and keeping the address, anddata during a write operation, available and unaltered until the flag goes low. The flag, which

5Five in the current implementation, the number might grow due to future developments of the core.


Idle

Send

Waiting

Receive

Failure

Finish

select = 1

xfer_success = 1

RNW = 1

ISA_Failure = 1

Ackn = 1

select = 0

ISA_Failure = 1

ISA_Finish = 1

reset

Figure 3.2: The OPB Finite state machine

is controlled by the clock domain crossing mechanism, is deasserted when the ISA interface isdeclaring its acknowledge signal, see section 2.6. The falling edge of the flag changes the internalsignal xfer success from zero to one, the transition of xfer success back to zero is done when theFSM reaches its Waiting or Idle states, or upon a reset of the bus bridge, see lines 186 to 194 inlisting 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 ofa read transaction no waiting is carried out in the Waiting state, during the next clock cyclethe FSM is set to Receive and the waiting for data is done in that state instead. When data isread from the ISA bus and the ISA to OPB flag is high, data is written to the I2O DBus. Thestate machine steps into its Finish state when the OPB interface has asserted its Acknowledgesignal. If the ISA peripheral fails to assert CHRDY the bus cycle will be cancelled by the timeoutwatchdog 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 Finishsignal is asserted, see the section about the ISA interface. ISA Finish causes the OPB FSM tostep 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

6The reason for calling the state Waiting instead of Wait is that the word Wait is a reserved keyword in VHDL.


due to the signals from different peripherals are ORed together to form the bus lines. Since anI/O ISA bus cycle is bound to employ at least three ISA clock cycles, equivalent to 24 systemclock cycles, the timeout suppress signal, I2O toutSup, should be asserted as soon as a bridgetransaction is started. I2O toutSup must remain asserted until the transaction is successfullyfinished or cancelled. In this implementation the toutSup signal is asserted when the finite statemachine reaches its Send state, and stays asserted until the bridge transaction is finished orcancelled. That is, the I2O toutSup signal is only deasserted when the OPB FSM is idle. Whena transaction is finished I2O xferAck is asserted during the last OPB clock cycle. In case of afailure I2O errAck is asserted in conjunction with xferAck to indicate to the host system thatthe transaction failed.

The On-chip Peripheral Bus employs big endian bit ordering, i.e. the most significant bit islocated in position 0 of the data field. The ISA bus, on the contrary, employs little endian bitordering where the least significant bit is located in position 0. Data going to the ISA bus islocated in bits 0 to 15 on the OPB DBus, and data coming from the ISA peripheral should bewritten to bits 16 to 31 on the I2O DBus. Also, only the lower 8 bits of the OPB ABus is of anyimportance for the ISA bus. The upper 24 bits are used to address the bus bridge itself. The bitreordering, and bit steering, is carried out by the OPB interface, see lines 238 to 269 in listingE.2.

If a bridge transaction is cancelled by the system, or if the core for any reason is reset, theOPB state machine is set to Idle. Thus, all internal and external signals are reset to a knownstate. Furthermore, if the ISA interface does not respond properly the state machine will alwaysreach the Failure state due to the timeout signal from the watchdog. Thus, the state machine isfree from deadlocks.

The design of the OPB interface was a fairly straightforward task because of the manyexamples available with the EDK. To improve the timing the guidelines in section 2.5 werefollowed 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 16bit data path from the ISA interface is expanded with zeros to 32 bit width. Observe that somesignals 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 isto communicate with on- and off-chip ISA peripherals. That is, the ISA interface should actas a bus master on the ISA bus and carry out bus cycles according to the specification, seesection 2.4.1. The ISA interface state machine consists of four state; Idle, Address, Data1, andData2 in conjunction with the ISA bus cycle specification, see figure 3.3. Note that the ISAbus cycle is only started by the Microblaze system, through the OPB interface, and never by aISA peripheral. A peripheral can, however, notify the system that data is available by givingan interrupt if interrupts are supported by the device driver. The code for the ISA interface ispresented in listing E.3.

The state machine is started when the flag from the clock domain crossing module indicatesthat valid address and data is available from the OPB interface. Once the state machine isstarted it spends one clock cycle at each of the two first states Address and Data1. At the laststate, data2, the state machine is dependent on the CHRDY signal to be asserted in order tofinish the bus cycle.

Originally the ISA interface module was designed to always wait for the CHRDY signal to beasserted in order to continue. It is not mandatory, however, that the ISA peripherals utilize the


Idle

Address

Data1

flag = 1

Data2

CHRDY = 1

Address ready

Data1 ready

reset

Figure 3.3: The ISA Finite state machine

signal. The CS8900A development board used for this project, for instance, does not indicatethat it has done a successful read or write by asserting CHRDY. The ISA interface simplyassumes that the peripheral is working properly, in a commercial system, however, the CHRDYsignal should be utilized to ensure that data is read and written correctly. To overcome the lackof CHRDY signal from the ISA peripheral a parameter was introduced in the core that indicateif the ISA interface should check the signal or not. The parameter is set in the MHS file duringsystem design. If the ISA peripheral is not using CHRDY, the internal counterpart is set highduring synthesis.

According to specification the BALE signal should do a low to high transition at the fallingclock edge in the address cycle, and fall again on the next rising edge of the ISA clock. To obtainthis feature the bale signal needed to be ANDed together by two signals; one that is set to highat the falling edge of the ISA clock in the address cycle and low at all other falling edges of theclock, and one that is high during the address cycle. See lines 123 to 160 and 289 to 290 in listingE.3. The falling edge of the BALE signal marks the end of the address cycle and the transitionfrom the Address state to the Data1 state. On the falling ISA clock in the middle of Data1 theappropriate read (IOR) or write(IOW) signal on the ISA bus should be declared. The signalsare active low and should go high again at the end of the last data cycle. IOR and IOW areachieved in a similar fashion as the BALE signal, see lines 166 to 178 and 294 to 295 in listingE.3.

The SBHE (system bus high enable) is an active low signal that indicates that a transfer on


the high bytes of data bus is about to take place. The CS8900A chip requires that a high tolow followed by a low to high transition is provided by the signal after any hardware or softwarereset. As for the IO16 signal, it is not utilized by the CS8900A development board, and it isomitted in this implementation. At this point it is assumed that only 16-bit ISA peripherals willbe 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 Failuresignal from the watchdog, and the inverse of the OPB select i. That is, the ISA interface is resetand the state machine is set to Idle at any global reset, timeout failure, or if the core for anyreason 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. Consequentlythe ISA interface can never reach a deadlock situation where it is keeping the rest of the systemwaiting.

Timeout watchdog

One of the most critical parts of the OPB to ISA bus bridge is the timeout watchdog. It ensuresthat the core never consumes more than a specified amount of clock cycles. Needless to say, itis vital that the timeout watchdog never fails since its most important task is to reset the businterfaces during an error in the ISA interface or in a peripheral.

Idle

Counting

Data1

flag = 1

Failure

Timeout = 1

ISA_Finish = 1

OPB_select = 0

Figure 3.4: The Timeout Watchdog Finite state machine

The watchdog is constructed with one counter and one finite state machine. The three statesof the machine are; Idle, Counting, and Failure, see figure 3.4. As shown in figure 3.1 thewatchdog has four inputs; ISA clock, OPB to ISA Flag, OPB select, and ISA Finish, and oneoutput; 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


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 ISAinterface asserts its ISA Finish signal the state machine is put to Idle again. Moreover, if thebridge transaction is cancelled, i.e. if the internal select signal is going low, the state machine isset to Idle and, consequently, the counter is reset and will never reach a deadlock situation. TheVHDL code for the timeout watchdog is presented in listing E.4.

The maximum length of an operation is parameterized, and hence defined by the systemdesigner at synthesis, to provide flexibility. In a real-time system there might be limits on themaximum bus cycle length in order to secure the task schedule, i.e. a task might execute every100 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 and8.33 MHz some sort of clock generator is needed to provide the signal. Ultimately, the ISA clockshould be independent from the system clock, but in this design it is generated by division ofthe system clock, see listing E.5. The division factor is parameterized, i.e. when the system isdefined it is possible to use a correct factor depending on the system clock. If the system clockis 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, toprovide the ISA peripherals with a clock signal.

The 8 MHz frequency limit is only theoretical, some modern ISA peripherals is able torun at higher speed. E.g. the CS8900A Ethernet MAC/PHY can run at 11 MHz. A higherclock frequency is easily obtained during system design simply by changing the clock divisionparameter. 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 synchronousto the system clock, and the ISA interface synchronous to the ISA clock, transfer of address anddata from one side to the other cannot be carried out in a standard fashion. Instead the methoddiscussed in section 2.6 had to be implemented.

The module itself is not very advanced, it merely consists of two instances of the clockdomain crossing mechanism, see listing E.6. Equally simple is the CDC itself containing onlytwo registers with asynchronous reset. The inputs are the ready signal from the transmitting sideand 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 isready, see listing E.7. No data is actually transferred through the communication module, its taskis purely to provide the bus interfaces with the flag signals. When a flag is high, the transmittingbus interface is prevented from altering the data until the receiving side has acknowledged thetransfer.

3.2.3 Interrupts

In the ISA specification there are four interrupt channels that are not used by other peripherals inthe original IBM PC. These are called IRQ9, IRQ10, IRQ11, and IRQ15. In this implementationnothing is done to the interrupt lines in the core, the interrupts are forwarded to the Microblazesystem as Interrupt9, Interrupt10, Interrupt11, and Interrupt15. In this fashion no local interrupthandler needed to be implemented. Instead the interrupts from the ISA bus is handled by the


system interrupt controller. The core is not limited to four interrupt lines, only the limit of amaximum of 32 interrupt lines to the system interrupt controller need to be remembered by thesystem designer.

When an interrupt has been generated by an ISA peripheral it is first handled by the systeminterrupt controller which is connected to the OPB. Depending on the nature of the peripheralthe interrupt controller takes the appropriate measure. In the case with the CS8900A EthernetMAC/PHY the interrupt controller should notify the device driver in uCLinux. The device driveris 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 themiddle 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 testingand verification of the core was required. To achieve a simple but useful peripheral with shortdevelopment 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 fromprogrammable buttons, or the DIP switches, and write to the two 7-segment LED displays onthe Virtex-II development board.

In addition to the standard ISA bus signals the ISA GPIO also has a 24 bit GPIO tri-stateport which communicate with the switches and LEDs on the development board. As a parameterduring system design it takes a 12 bit base address. Thus it is possible to create multiple instancesof the ISA GPIO connected to the same bus bridge.

Idle

Data

addr_ok = 1

Adress decoder address(19:0)

bale

addr_ok

gpio_ce

Data out

Data in ior

iow

data_o(15:0)

data_i(15:0)

Data out register

gpio_t

gpio_i

gpio_o

clk

CHRDY reg.

gpio_i(23)

chrdy

gpio

resdrv

Figure 3.5: A block diagram describing the ISA GPIO.

7A core shipped with the EDK.


The GPIO core consists of one very basic finite state machine, one address decoder, two datatransfer registers, and one register generating the CHRDY signal, see figure 3.5. As illustratedin the figure, the state machine does only contain two states; Idle and Data. When the addressdecoder determines that the 12 lower bits on the ISA address bus is equal to the peripheralbase address it asserts the addr ok signal, see lines 102 to 113 in listing E.8. The high addr oksignal makes the finite state machine change state from Idle to Data. The state machine staysin the Data state for one clock cycle in which the gpio ce signal goes high. When the gpio ce ishigh, the address decoder is reset and the data registers are enabled, i.e. data is read or writtendepending on the read and write signals. In the code there are two different versions of theCHRDY generation, as illustrated on lines 123 to 137 in listing E.8. Both takes switch numberone on the development board as an input, and generates the CHRDY signal depending on howthe switch is set. The difference between the two implementations is that the one using anFDRE 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 addresson the ISA address bus. The FDRE 1 implementation might, however, result in system errorsin uCLinux.

Since the ISA GPIO is designed to replace the OPB ditto, the bit order of the GPIO signalis not changed from big endian to little endian. Instead the bit steering is taken care of by theread and write data registers. That is, during one transition from the OPB to the GPIO, or viceversa, 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 thecore 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 provedthe 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 waspossible to verify that the bus interfaces were working according to the specifications, that theclock generator created a correct clock signal, that the clock domain crossing mechanism workedaccording to theory, and that the timeout watchdog asserted the failure signal after the correctnumber of clock cycles. It also shortened the coding-debugging-coding cycle significantly sincethe synthesis of a small core is much faster than the synthesis of a large one consisting of manyparts.

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 inputsand also monitors the outputs. The first step is behavioral simulation where the inputs from thetestbench are run through the logic of the core and generates waveforms on the output. Whensatisfactory results were obtained from the behavioral simulation the most advanced simulationmethod was utilized. The post-place-and-route-simulation which synthesize the core all the waythrough the synthesis chain prior to simulation. This renders simulation results that not only

8FDRE 1 is a register with synchronous reset and clock enable triggering on the falling clock edge, while FDR 1is lacking the clock enable function.


verifies the logical behavior, but also verifies that the timing in the core is correct. It also takesinto account the signal path latencies. That is, that signal dependencies are not ruined due toother signals running late.

When all modules in the system were independently verified to work properly by post-place-and-route-simulation the whole core was assembled into the wrapper. A new testbench wasconstructed that handled all the inputs and outputs of the entire core, and the core was simu-lated and verified to work with post-place-and-route-simulation. Waveforms from four differentsimulations are presented in appendix G. The first two are read operations and the last twoare write operations. The difference of the two simulations of each kind is that in the first oneCHRDY 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 buscycle 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 Dfor a short tutorial on how to use it. When using ChipScope one extra core is added to thesystem after system synthesis and before the other steps in the chain towards a bit file, seesection 2.2.3. The core listens to, and monitors, chosen signals for a number of samples andsends the data through the JTAG connection to the software on a PC. The software gives theuser 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 withoutany peripheral connected to the ISA bus. Therefore the ISA GPIO peripheral in section 3.3 wasemployed. During the testing with the GPIO the need for on-chip versions of the ISA in-signalswas discovered, hence such signals were implemented in the bus wrapper. Tests were done with asingle and multiple instances of the GPIO connected to the ISA bus. No functionality problemswere discovered, though when testing with the uCLinux system it was found that some alteringwith 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 busbridge, see section 5.2.

Another bug that was found and fixed during on-chip verification was that the toutSup signalsometimes was asserted at the same time as the OPB arbiter cancelled the operation. Thishappened due to that the toutSup signal previously was asserted when the OPB FSM reachedthe 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 softwarewas 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 thesystem address space. The testing of the core with the ISA GPIO and ChipScope confirmed thatthe bus bridge worked correctly according to the bus specifications. Experiments also showedthat the timeout watchdog cancels the bridge operation if the ISA peripheral does not react intime. 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 peripheralworking at a different clock frequency. The modular nature of the core enables quick redesignto suit different interfacing purposes. The ISA interface, for instance, can be altered to interfacedifferent chips, or the clock generator can be remodelled to generate an independent clock signalat any frequency.

When the bus bridge together with the ISA GPIO worked according to specification andshowed no evidences of any bugs or misbehavior, then the bridge and the GPIO was finallyutilized in conjunction with the uCLinux operating system. uCLinux is the operating system ofthe embedded system at ITEE which the bus bridge is primary designed for. No problems wereencountered 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 GPIOwas executed without any errors being observed. Thus, the OPB to ISA bus bridge was judgedto work without any major bugs. On the other hand, since the bus bridge has not been testedwith the CS8900A Ethernet MAC/PHY yet, it cannot be taken for granted that all possible bugsare found and fixed.

Figure 4.1: A read operation monitored by ChipScope. The scale above the waveforms show thesystem clock cycles.

In figures 4.1 and 4.2, one read and one write operation are showed as monitored by Chip-

29

30 Results & Discussion

Scope. A comparison with figure 2.3 shows that the bus bridge is working according to the ISAspecification in both cases.

As seen in figure 4.1, the ISA bus cycle is started two system clock cycles after the assertionof the toutSup signal. Initially the bale and the IOR signals are asserted according to thespecification. On the rising edge of the ISA clock, indicating the end of the second data cyclethe data available on ISA data in is read by the ISA interface, and one system clock cycle laterthe data is written to the OPB data bus. It is worth investigating why it takes one extra systemclock 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 wastedwaiting for the ISA bus cycle to start. It is worth noting however, that a few system clock cyclesare saved in the end of each write operation since the ISA interface signals that the transactionis 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 willcancel the transaction when the watchdog signals ISA Failure. Figures 4.3 and 4.4 shows thatthe bus bridge will consume more system clock cycles while waiting. The figures also showthat at the end of the failed bus transaction the errAck signal is asserted together with the the

Results & Discussion 31

xferAck signal. Several experiments where CHRDY was low showed that the timeout watchdogwas working properly. Note also that even though the CHRDY signal is not asserted during awrite 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 standard16 bit I/O device ISA bus cycle specification. The ISA specification include a few other buscycles as well, for instance the 8 bit I/O device bus cycle and the 16 bit memory device buscycle. The 8 bit I/O device cycle was omitted due to the lack of interesting 8 bit ISA peripheralstoday, 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 shouldnot 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 usageof 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 somedifferent 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 busbridge, utilize 1884 of the 5120 slices and 146 of the 324 IOBs on a Virtex-II FPGA with onemillion system gates. Note that this is not the smallest possible Microblaze system, but it is thesystem used in this project. The same Microblaze system with an added on-chip Ethernet coreuse 3552 slices and 165 IOBs. That is, the OPB Ethernet MAC core from Xilinx is almost asbig as the Microblaze system. If the on-chip Ethernet core is replaced by the OPB to ISA busbridge instead, only 1976 slices are occupied together with a maximum of 192 IOBs. The busbridge need 46 IOBs if all 20 ISA address lines need to be connected to the peripheral. Whenusing the CS8900A chip, however, only the 4 lowest address lines are needed. I.e. the number ofemployed 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 chipis clearly the lower device utilization which gives room for other tasks or functions to be imple-mented in hardware or enables usage of a smaller device with less power consumption and unitprice. Another advantage is that the OPB to ISA core is free to use without limitation, whereasthe MAC is not. The downside with using an external Ethernet MAC/PHY together with the

32 Results & Discussion

Table 4.1: Device utilizationUnit Slices IOBsVirtex-II 5120 324Microblaze system 1884 146EMAC 1668 19Bus bridge 92 46 (maximum)

OPB to ISA bridge is the low clock frequency of the ISA interface that wastes clock cycles onthe 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 currentMicroblaze system it is set to 66 MHz. An ISA bus cycle uses three ISA clock cycles if theperipheral does not require more. Since the ISA clock in this implementation is synchronouswith the system clock and eight times slower it will take anywhere between one and sevensystem 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 everyEthernet read or write there will be quite a few wasted clock cycles for the system, somethingthat 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 approximately21 system clock cycles to finish. Figures 4.1 and 4.2 above show that an average OPB to ISAbridge transaction needs roughly 30 system clock cycles for a read operation and around 25 cyclesfor a write operation1. That is, it does only seem like the bus bridge is about 25 - 50 percentslower than the OPB Ethernet MAC, it is worth mentioning however that during the 25 - 30clock cycles of the bus bridge only 16 bits are read or written while 32 bits are read or writtenduring one OPB Ethernet MAC operation. In section 5.2.1 a remedy for this phenomenon isproposed.

1The reason that a write operation is faster than a read operation is that it does not have to wait for the datafrom the ISA peripheral.

Chapter 5

Conclusions

The main objective with this thesis was to find a suitable Ethernet MAC/PHY for an existingFPGA based embedded system and to create an interface between the chip and the existingMicroblaze system. The OPB to ISA bus bridge was designed and implemented, and to verifyits functionality a small on-chip ISA peripheral was constructed. Unfortunately the CS8900Adevelopment 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 alsogives a summary of different Ethernet MAC/PHY chips suitable for use as an off-chip networkingsolution to embedded systems on Virtex-II FPGAs from Xilinx, as well as reviews of involvedbus 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 expectedand 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 makesit ideal to utilize the bus bridge when FPGA size is an issue. Since the core bridges the OPBwith the ISA bus it is not limited to use only with Ethernet peripherals, but is also suitable touse for other off-chip ISA peripherals that might be connected to a Microblaze system. Suchperipherals could be a VGA adapter or a sound card. If speed is an issue the bus bridge might beconsidered to waste too much CPU time in its current implementation. It is, however, possibleto design systems which utilize multiple Microblaze processors. That is, one processor could bededicated to handle communication tasks. One suggestion is to redesign one of the Microblazesin the multiprocessor case to work with 16 bit data path instead of 32 bit which should reduceits size significantly.

Even though the ISA clock is around 8 MHz per definition some ISA peripherals, the CS8900Afor instance, support higher frequencies. In those cases the ISA clock should be sped up to meetthe 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 bridgewas to determine which parts of the bridge should work on which side of the clock boundary, andhow the communication between the two sides would be secure and convenient. Several lessonsboth regarding design of an FPGA core and regarding VHDL coding in general were learnedduring the design phase of this project.

The project also gave a good training of the software tools from Xilinx. Especially theChipScope 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 theCS8900A MAC/PHY. It is only when such a verification is carried out the bus bridge can besaid to work properly. Another interesting experiment would be to use the bus bridge for othertypes 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 canbe made to save system clock cycles.

• The worst case scenario is that the system has to wait for seven clock cycles before the ISAcycle starts as shown in section 4.2. Thus, a process which start the ISA clock when thebus 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 orwrite 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 besaved.

• The ability to start a bridge cycle which release the OPB when the bridge cycle is initializedand notifies the Microblaze when there is valid data available, or if the ISA peripheral didnot respond properly, should be investigated.

• A completely different approach to the work made in this thesis would be to implementa basic on-chip Ethernet MAC which meet the demands from a uCLinux system run onMicroblaze to determine which approach is more beneficial. There might also be otherMAC cores available from other developers. It is, however, desirable by the research groupat ITEE to have an off-chip solution.

• Two minor details were omitted during the implementation phase, and should be imple-mented in a near future. First; some sort of initialization procedures for the core, i.e. aprocess making sure that nothing extraordinary happens on power-up etc. Second; a resetfunction for the OPB to ISA communication module and the CDCs.

Bibliography

[1] Neil W Bergmann, John Williams, and Peter Waldeck. Egret: A flexible platform forreal-time reconfigurable systems on chip. 2003.

[2] Intel Press Release. <http://www.intel.com/ca/pressroom/2002/0813.htm>. Accessedon WWW on October 22, 2003.

[3] Michael Barr. A reconfigurable computing primer. Multimedia Systems Design, pages44–47, September 1998.

[4] Ray Andraka. FPGA basics, <www.andraka.com/whatisan.htm>. Accessed on January27, 2004.

[5] Neil W Bergmann and John Williams. Avionics upgrade management using reconfigurablelogic. 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 January29, 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 toHigh-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 CoreConnectTMBus 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 FPGAperipherals. 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 Mi-croblaze 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 standardapproach 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 Eth-ernet logic integrated into one unit both controlling the transfered media and the physicalconnection.

OPB On-Chip Peripheral Bus. A 32-bit bus architecture employed to connect the Microblazeprocessor 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 todescribe 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 systemhas been performed as a master thesis project in Computer Engineering at the department ofElectrical 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 resultshopefully will be beneficial. I wish to thank the following persons:

Professor Neil Bergmann at ITEE for giving me the opportunity to come to Australia forsix months and carry out this work. Also, for providing me with the computer resourcesand other hardware that I needed.

Doctor John Williams at ITEE for very valuable support and heaps of good advices. Hope-fully I’ll be able to return some of it in the future.

Professor Dake Liu at Linkopings Universitet for giving me valuable comments on thereport.

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 imple-mentation a Dell PC was employed. The PC was equipped with a 2.5 GHz CPU, 1 Gb primarymemory, 20 Gb secondary memory, and high speed Ethernet connection to the primary sourceof information, the internet. To verify that the implementation worked properly it was tested onthe target device. The FPGA is a Virtex-II from Xilinx with one million gates. The device wasmounted on a development board from Insight which is also equipped with two 7-segment LEDdisplays, eight DIP switches, four programmable buttons, JTAG port, two serial ports, USBport, 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 independentdevelopment of the core modules ISE 6.1.03 from Xilinx was employed. ISE facilitates the de-velopment of IP cores in the hardware description language of choice, VHDL or Verilog. Easilyaccessable from ISE is ModelSim from MentorGraphics. It enables quick simulation of imple-mented designs. To create systems of mixed cores targeted for Xilinx FPGAs the EDK 6.1 is anideal tool. It takes certain files as inputs, such as the MHS and the MSS files, and generates thesystems in a number of steps. The EDK comes with a graphical user interface, XPS, which wasavoided due to its immaturity in the release of EDK used during the first half of the project. Foron-chip verification and monitoring ChipScope PRO 6.1 was used. It is a very powerful tool, seeappendix D, which is ideal to utilize for FPGA development.

39

Appendix D

Using ChipScope for debuggingand functional verification

A very convenient way to verify a system based on an FPGA, rather than using a traditionallogic analyzer, is to use the ChipScope Pro software provided by Xilinx. Instead of connecting alogic analyzer to the I/O pins of the FPGA, an additional core is inserted into the design. Thecore consists of an Integrated Logic Analyzer that monitors user specified signals directly on-chipand 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 andthe analyzer. The core generator provides netlists and instantiation templates for a number ofcores including: integrated controller (ICON), integrated logic analyzer (ILA), and integratedbus analyzer for OPB (IBA/OPB). The inserter is a tool utilized after the synthesis that insertsnecessary 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. Theanalyzer 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 theintegrated controller core, ICON, and the JTAG download cable. One ICON core can handlecommunication 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 designedfor a Microblaze system. Only the inserter, and analyzer, tools are utilized though. For moreinformation 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 byrunning:

make netlist - This command creates netlists for the different parts of the system, but doesnot glue it together.

Start the inserter software. The first task is to specify the input design netlist, see figure D.1below. 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 canbe opened instead of specifying the input netlist. Projects, however, are not considered in thistutorial, 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 everytrigger 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 orbusses of arbitrary width. The number of match units specify how many different combinationsthat a port can trigger on, by keeping the number low (1 match unit) conserves resources, whileallowing more match units enable flexibility in the trigger conditions on the cost of logic. Thetype 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 bustriggers.

When clicking the ’next’ button the screen in figure D.3 becomes visible. Make sure that alltrigger ports are used as data, i.e. every check box is checked. Otherwise the signals will not becaptured by the analyzer nor displayed on the computer screen. It is also possible to define howmany samples that should be made on each trigged event, and on which clock edge the samplesshould 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 triggersignals appear to the right and the valid signals to trigger on appears the left. Highlight a triggerof 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

1Tip of the day: It is possible to connect many signals and trigger inputs at the same time by using shift whenhighlighting.

42 Using ChipScope for debugging and functional verification

Figure D.2: Specify the trigger parameters and match unit settings.

Figure D.3: Specify the capture settings.


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 insertedin the system netlist. When the Inserter indicates that the insertion is finished continue withthe building of the system by running the following command,

ngdbuild -sd implementation/ -p xc2v1000fg456-6 -nt timestamp -bmimplementation/system.bmm -uc data/system.ucf system.ngo

The command builds the system together to one unit. When the building is done the followingfiles 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 insertinga ChipScope core. Next step is to do the mapping of the system, it is done by writing the followingto the command line:

map -o implementation/system map.ncd implementation/system.ngdimplementation/system.pcf

Following the mapping is the place-and-route tool and the bit generation before the insertion ofthe XMD stub and the download to the FPGA:

par -w -ol 2 implementation/system map.ncd implementation/system.ncdimplementation/system.pcf

44 Using ChipScope for debugging and functional verification

bitgen -w -f etc/bitgen.ut implementation/systembitinit system.mhs -pe microblaze 0 microblaze 0/code/xmdstub.elf

-bt implementation/system.bit -o implementation/download.bitimpact -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 looksomething like this:

setMode -bscansetCable -p lpt1addDevice -p 1 -file etc/xc18v04_vq44.bsdassignfile -p 1 -file etc/xc18v04_vq44.bsdaddDevice -p 2 -file implementation/download.bitprogram -p 2quit

D.1.2 Analyzer

When the system is created and downloaded to the FPGA it is time to start the ChipScopeAnalyzer. The user interface is somewhat more complex than the Inserter, but fear not, it isvery convenient once you learn how to use it. To connect the analyzer to the system on theFPGA, click on the icon to the far left in the toolbar, see figure D.5. If everything is donecorrectly all signals should appear in the waveform window and the window to the left of thewaveforms. To be able to keep the signals apart it is adviced to import a saved Inserter projectfile. Most of the time it will give the signals their correct names, but sometimes the user has todo some signal renaming manually as well. In the analyzer it is also possible to group signalsinto 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 howto 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 acertain OPB address, the bus has to be reversed and some extra care has to be taken regardingthe address. In figure D.5 trigger port 5 is set to trigger on address XXX6 FFFF, but due to thebit ordering it is really triggering on address FFFF 6XXX2. The X indicate a don’t-care.

In the Analyzer it is possible to define trigger condition equations. That is, logical equationscombining different trigger events. See [24] for more information, or play around with it for afew minutes to understand what it is all about. The last setup to consider before trying the coreis to define what type of capture that should be made. It is possible to define how many samplesto capture, how many capture windows to use, and where in those windows the trigger shouldappear.

When everything is setup it is possible to start the capturing of signal waveforms by pressingthe ’play’ button, the third icon in the toolbar. Use XMD connected to the debug UART togenerate some meaningful events in the system. The first event in figure D.6 is generated bywriting FC01 to address FFFF60F0, and the second event is generated by reading from the sameaddress.

In this example the OPB to ISA bus bridge and the ISA GPIO peripheral are employed toread from the DIP switches an write to the 7-segment LEDs on the development board.

2Note that XXX4 FFFF is equal to FFFF 2XXX.


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 firstsection shows the the complete source code for the bus bridge, and the second section accountfor the ISA GPIO. Note however that only the source code is presented here, the other filesneeded to use the cores together with the EDK are distributed with the rest of the core by theauthor.

E.1 OPB to ISA bus bridge

Listing E.1: Bus Wrapper−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−F i l e : op b i s a . vhd−−Version : v1 .00 a−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

5 −−Descr ip t i on :−−This module wraps up the OPB to ISA br idge , and prov ide s an in t e r−−−f a ce f o r the MHS f i l e . I t con ta ins a genera tor f o r the ISA c lock ,−−i n t e r f a c e s f o r the two bus a r c h i t e c t u r e s , and a communication l i n k−−between the two c l o c k domains . There i s a l s o a t imeout watchdog

10 −−t h a t t e rmina tes the t r an sac t i on i f the ISA s i d e i s not responding−−prope r l y .−−−−( c ) 2004 Johan Bernspang , johan<at>bernspang<dot>se−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

15 −−His tory :−−2003.12 −− Created by Johan Bernspang−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

l ibrary IEEE ;20 use IEEE . STD LOGIC 1164 .ALL;

l ibrary 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

entity opb i sa i sgeneric (

C BASEADDR : s t d l o g i c v e c t o r ( 0 to 31 ) := X”FFFFFFFF” ;C HIGHADDR : s t d l o g i c v e c t o r ( 0 to 31 ) := X”00000000” ;

30 C USER ID CODE : i n t e g e r := 3 ;C OPB AWIDTH : i n t e g e r := 32 ;C OPB DWIDTH : i n t e g e r := 32 ;C FAMILY : s t r i n g := ” v i r t e x2 ” ;

35 −−Custom parametersC ISA CLK DIV : i n t e g e r := 8 ;C USE CHRDY : s t d l o g i c := ’ 1 ’ ;C NUM ISA CYC TOUT : i n t e g e r := 16 ;C ON CHIP SL ONLY : s t d l o g i c := ’ 1 ’ ;

40 C NUM ON CHIP SL : i n t e g e r := 1) ;

port (−−OPB bus s i g n a l s

45 OPB clk : in s t d l o g i c ;OPB Rst : in s t d l o g i c ;OPB ABus : in s t d l o g i c v e c t o r ( 0 to C OPB AWIDTH − 1) ;OPB DBus : in s t d l o g i c v e c t o r ( 0 to C OPB DWIDTH − 1) ;OPBRNW : in s t d l o g i c ;

50 OPB BE : in s t d l o g i c v e c t o r ( 0 to C OPB AWIDTH/8 − 1) ;OPB seqAddr : in s t d l o g i c ;OPB select : in s t d l o g i c ;I2O xferAck : out s t d l o g i c ;I2O errAck : out s t d l o g i c ;

55 I2O toutSup : out s t d l o g i c ;I2O Retry : out s t d l o g i c ;I2O DBus : out s t d l o g i c v e c t o r ( 0 to C OPB DWIDTH − 1) ;

−−ISA bus s i g n a l s60 −−ISA SD IN and ISA IS OUT are used by on−ch ip ISA pe r i p h e r a l s .

ISA SA : out s t d l o g i c v e c t o r (19 downto 0 ) ;ISA SD I : in s t d l o g i c v e c t o r (15 downto 0 ) ;ISA SD O : out s t d l o g i c v e c t o r (15 downto 0 ) ;ISA SD T : out s t d l o g i c v e c t o r (15 downto 0 ) ;

65 ISA SD IN : in s t d l o g i c v e c t o r (15 downto 0 ) ;ISA SD OUT : out s t d l o g i c v e c t o r (15 downto 0 ) ;ISA Bale : out s t d l o g i c ;ISA SBHE : out s t d l o g i c ;ISA iow : out s t d l o g i c ;

70 ISA ior : out s t d l o g i c ;ISA bclk : out s t d l o g i c ;CHRDY : in s t d l o g i c ;RESDRV : out s t d l o g i c ;

48 The VHDL code

IO16 : in s t d l o g i c ; −−not used75 Chrdy oc : in s t d l o g i c v e c t o r ( 0 to C NUM ON CHIP SL − 1) ;

i o 16 oc : in s t d l o g i c ; −−not used

−−Four IRQ channe ls implemented f o r ISA i n t e r r u p t s . These are−−connected d i r e c t l y to the system in t e r r u p t hand ler .

80 IRQ9 : in s t d l o g i c ;IRQ10 : in s t d l o g i c ;IRQ11 : in s t d l o g i c ;IRQ15 : in s t d l o g i c ;In t e r rupt9 : out s t d l o g i c ;

85 In t e r rupt10 : out s t d l o g i c ;In t e r rupt11 : out s t d l o g i c ;In t e r rupt15 : out s t d l o g i c ) ;

end opb i sa ;

90 architecture IMP of opb i sa i s−−The d i f f e r e n t components o f the b r i d g e are s p e c i f i e d herecomponent i s a c l k g e n i s

generic (C CLK DIV : i n t e g e r ) ;

95 port (OPB clk : in s t d l o g i c ;OPB Rst : in s t d l o g i c ;ISA clk : out s t d l o g i c ) ;

end component i s a c l k g e n ;100

component opb i n t e r f a c e i sgeneric (

C AW : i n t e g e r ;C DW : i n t e g e r ) ;

105 port (OPB ABus : in s t d l o g i c v e c t o r ( 0 to C AW − 1) ;OPB DBus : in s t d l o g i c v e c t o r ( 0 to C DW − 1) ;OPB clk : in s t d l o g i c ;OPB Rst : in s t d l o g i c ;

110 OPBRNW : in s t d l o g i c ;OPB BE : in s t d l o g i c v e c t o r ( 0 to C AW/8 − 1) ;OPB se l ec t i : in s t d l o g i c ;I2O xferAck : out s t d l o g i c ;I2O errAck : out s t d l o g i c ;

115 I2O toutSup : out s t d l o g i c ;I2O Retry : out s t d l o g i c ;I2O DBus : out s t d l o g i c v e c t o r ( 0 to C AW − 1) ;ISA Address : out s t d l o g i c v e c t o r (19 downto 0 ) ;ISA Data out : out s t d l o g i c v e c t o r (15 downto 0 ) ;

120 ISA Data in : in s t d l o g i c v e c t o r (15 downto 0 ) ;ISA RNW : out s t d l o g i c ;Ready : out s t d l o g i c ;

The VHDL code 49

Acknowledge : out s t d l o g i c ;Flag 1 : in s t d l o g i c ;

125 Flag 2 : in s t d l o g i c ;I SA f i n i s h : in s t d l o g i c ;ISA Fai lure : in s t d l o g i c ) ;

end component opb i n t e r f a c e ;

130 component i s a i n t e r f a c e i sgeneric (

C USE CHRDY : s t d l o g i c ) ;port (

ISA SA : out s t d l o g i c v e c t o r (19 downto 0 ) ;135 ISA SD I : in s t d l o g i c v e c t o r (15 downto 0 ) ;

ISA SD O : out s t d l o g i c v e c t o r (15 downto 0 ) ;ISA SD T : out s t d l o g i c v e c t o r (15 downto 0 ) ;ISA Bale : out s t d l o g i c ;ISA SBHE : out s t d l o g i c ;

140 ISA iow : out s t d l o g i c ;ISA ior : out s t d l o g i c ;ISA bclk : out s t d l o g i c ;CHRDY : in s t d l o g i c ;RESDRV : out s t d l o g i c ;

145 IO16 : in s t d l o g i c ;OPB Rst : in s t d l o g i c ;OPB RNW i : in s t d l o g i c ;I s a c l k : in s t d l o g i c ;ISA Address : in s t d l o g i c v e c t o r (19 downto 0 ) ;

150 ISA Data out : in s t d l o g i c v e c t o r (15 downto 0 ) ;ISA Data in : out s t d l o g i c v e c t o r (15 downto 0 ) ;Flag : in s t d l o g i c ;Ready : out s t d l o g i c ;Acknowledge : out s t d l o g i c ;

155 OPB se l ec t i : in s t d l o g i c ;F in i sh : out s t d l o g i c ;Fa 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 ;

160 component timeout watchdog i sgeneric (

C NUM ISA CYCLES TOUT : i n t e g e r ) ;port (

ISA Clk : in s t d l o g i c ;165 OPB select : in s t d l o g i c ;

Flag : in s t d l o g i c ;ISA Finish : in s t d l o g i c ;ISA Fai lure : out s t d l o g i c ) ;

end component timeout watchdog ;170

component opb isa comm i s

50 The VHDL code

port (OPB Rst : in s t d l o g i c ;f l a g 1 : out s t d l o g i c ;

175 f l a g 2 : out s t d l o g i c ;OPB ready : in s t d l o g i c ;ISA ready : in s t d l o g i c ;OPB ackn : in s t d l o g i c ;ISA ackn : in s t d l o g i c ) ;

180 end component opb isa comm ;

component p s e l e c t i sgeneric (

C AB : i n t e g e r ;185 C AW : i n t e g e r ;

C BAR : s t d l o g i c v e c t o r ) ;port (

A : in s t d l o g i c v e c t o r ( 0 to C AW−1);AValid : in s t d l o g i c ;

190 PS : out s t d l o g i c ) ;end component p s e l e c t ;

−−I n t e rna l s i g n a l ssignal i s a c l k i : s t d l o g i c ;

195 signal OPB rdy i : s t d l o g i c ;signal OPB ackn i : s t d l o g i c ;signal ISA rdy i : s t d l o g i c ;signal ISA ackn i : s t d l o g i c ;signal f l a g 1 i : s t d l o g i c ;

200 signal f l a g 2 i : s t d l o g i c ;signal f i n i s h i : s t d l o g i c ;signal f a i l u r e i : s t d l o g i c ;

signal add r e s s i : s t d l o g i c v e c t o r (19 downto 0 ) ;205 signal da t a ou t i : s t d l o g i c v e c t o r (15 downto 0 ) ;

signal d a t a i n i : s t d l o g i c v e c t o r (15 downto 0 ) ;signal opb rnw i : s t d l o g i c ;

signal ISA SD I INT : s t d l o g i c v e c t o r (15 downto 0 ) ;210 signal ISA SD O INT : s t d l o g i c v e c t o r (15 downto 0 ) ;

signal CHRDY INT : s t d l o g i c ;signal io16 INT : s t d l o g i c ;

signal o p b s e l e c t i : s t d l o g i c ;215

function Addr Bits ( x , y : s t d l o g i c v e c t o r ( 0 to C OPB AWIDTH−1))return i n t e g e r i svariable addr xor : s t d l o g i c v e c t o r ( 0 to C OPB AWIDTH−1);

begin220 addr xor := x xor y ;

The VHDL code 51

for i in 0 to C OPB AWIDTH−1 loopi f addr xor ( i )= ’1 ’ then return i ;end i f ;

end loop ;225 return (C OPB AWIDTH) ;

end function Addr Bits ;

constant C AB : i n t e g e r := Addr Bits (C HIGHADDR,C BASEADDR) ;

230 begin−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−Generate the appropr ia t e ISA SD connect ions depending on i f the−−ISA pe r i p h e r a l s are on− or o f f−ch ip .−−The ORing o f the chrdy oc i s v e r y ug l y at the moment . My

235 −−apo 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 ;

240 io16 INT <= io16 oc ;CHRDY OC GEN 0 : i f C NUM ON CHIP SL = 1 generate

ch rdy in t <= chrdy oc ( 0 ) ;end generate CHRDY OC GEN 0;CHRDY OC GEN 1 : i f C NUM ON CHIP SL = 2 generate

245 ch rdy in t <= chrdy oc ( 0 ) or chrdy oc ( 1 ) ;end generate CHRDY OC GEN 1;CHRDY OC GEN 2 : i f C NUM ON CHIP SL = 3 generate

ch rdy in t <= chrdy oc ( 0 ) or chrdy oc ( 1 ) or chrdy oc ( 2 ) ;end generate CHRDY OC GEN 2;

250 CHRDY OC GEN 3 : i f C NUM ON CHIP SL = 4 generatech rdy in t <= chrdy oc ( 0 ) or chrdy oc ( 1 ) or chrdy oc (2 )

or chrdy oc ( 3 ) ;end generate CHRDY OC GEN 3;

end generate ISA ON CHIP GEN ;255

ISA OFF CHIP GEN : i f C ON CHIP SL ONLY = ’0 ’ generateISA 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 ;CHRDY OC GEN 0 : i f C NUM ON CHIP SL = 1 generate

260 ch rdy in t <= CHRDY or chrdy oc ( 0 ) ;end generate CHRDY OC GEN 0;CHRDY OC GEN 1 : i f C NUM ON CHIP SL = 2 generate

ch rdy in t <= CHRDY or chrdy oc ( 0 ) or chrdy oc ( 1 ) ;end generate CHRDY OC GEN 1;

265 CHRDY OC GEN 2 : i f C NUM ON CHIP SL = 3 generatech rdy in t <= CHRDY or chrdy oc ( 0 ) or chrdy oc (1 )

or chrdy oc ( 2 ) ;end generate CHRDY OC GEN 2;CHRDY OC GEN 3 : i f C NUM ON CHIP SL = 4 generate

52 The VHDL code

270 ch rdy in t <= CHRDY or chrdy oc ( 0 ) or chrdy oc (1 )or chrdy oc ( 2 ) or chrdy oc ( 3 ) ;

end generate CHRDY OC GEN 3;io16 INT <= io16 or i o 16 oc ;

end generate ISA OFF CHIP GEN ;275

In t e r rupt9 <= IRQ9 ;In te r rupt10 <= IRQ10 ;In te r rupt11 <= IRQ11 ;In te r rupt15 <= IRQ15 ;

280

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−p s e l e c t i s prov ided by X i l i n x as a standard component f o r per i−−−phera l s e l e c t i o n .−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

285 OPB Select I : p s e l e c tgeneric map (

C AB => C AB,C AW => C OPB AWIDTH,C BAR => C BASEADDR )

290 port map (A => opb ABus , −− [ in ]AValid => opb Se lec t , −− [ in ]PS => o p b s e l e c t i ) ; −− [ out ]

295 ISA CLK GEN I : i s a c l k g e ngeneric map (

C CLK DIV => C ISA CLK DIV)port map (

OPB clk => OPB clk , −− [ in ]300 OPB Rst => OPB Rst , −− [ in ]

ISA clk => i s a c l k i ) ; −− [ out ]

OPB INTERFACE I : opb i n t e r f a c egeneric map (

305 C AW => C OPB AWIDTH,C DW => C OPB DWIDTH)

port map (OPB ABus => OPB ABus , −− [ in ]OPB DBus => OPB DBus , −− [ in ]

310 OPB clk => OPB clk , −− [ in ]OPB Rst => OPB Rst , −− [ in ]OPBRNW => OPB RNW, −− [ in ]OPB BE => OPB BE, −− [ in ]OPB se l ec t i => opb s e l e c t i , −− [ in ]

315 I2O xferAck => I2O xferAck , −− [ out ]I2O errAck => I2O errAck , −− [ out ]I2O toutSup => I2O toutSup , −− [ out ]I2O Retry => I2O Retry , −− [ out ]

The VHDL code 53

I2O DBus => I2O DBus , −− [ out ]320 ISA Address => addr e s s i , −− [ out ]

ISA Data out => data out i , −− [ out ]ISA Data in => da t a i n i , −− [ in ]ISA RNW => opb rnw i , −− [ out ]Ready => OPB rdy i , −− [ out ]

325 Acknowledge => OPB ackn i , −− [ out ]Flag 1 => f l a g 1 i , −− [ in ]Flag 2 => f l a g 2 i , −− [ in ]ISA Finish => f i n i s h i , −− [ in ]ISA Fai lure => f a i l u r e i ) ; −− [ in ]

330

ISA INTERFACE I : i s a i n t e r f a c egeneric map (

C USE CHRDY => C USE CHRDY)port map (

335 ISA SA => ISA SA , −− [ out ]ISA SD I => ISA SD I INT , −− [ in ]ISA SD O => ISA SD O INT , −− [ out ]ISA SD T => ISA SD T , −− [ out ]ISA Bale => ISA Bale , −− [ out ]

340 ISA SBHE => ISA SBHE , −− [ out ]ISA iow => ISA iow , −− [ out ]ISA ior => ISA ior , −− [ out ]ISA bclk => ISA bclk , −− [ out ]CHRDY => CHRDY INT, −− [ in ]

345 RESDRV => RESDRV, −− [ out ]IO16 => IO16 , −− [ in ]OPB Rst => OPB Rst , −− [ in ]OPB RNW i => opb rnw i , −− [ in ]i s a c l k => i s a c l k i , −− [ in ]

350 ISA Address => addr e s s i , −− [ in ]ISA Data out => data out i , −− [ in ]ISA Data in => da t a i n i , −− [ out ]f l a g => f l a g 1 i , −− [ in ]Ready => ISA rdy i , −− [ out ]

355 Acknowledge => ISA ackn i , −− [ out ]OPB se l ec t i => opb s e l e c t i , −− [ in ]Fin i sh => f i n i s h i , −− [ out ]Fa i l u r e => f a i l u r e i ) ; −− [ in ]

360 WATCHDOG I : timeout watchdoggeneric map (

C NUM ISA CYCLES TOUT => C NUM ISA CYC TOUT)port map (

ISA Clk => i s a c l k i , −− [ in ]365 OPB select => opb s e l e c t i , −− [ in ]

Flag => f l a g 1 i , −− [ in ]ISA Finish => f i n i s h i , −− [ in ]

54 The VHDL code

ISA Fai lure => f a i l u r e i ) ; −− [ out ]

370 OPB ISA COMMUNICATION I : opb isa commport map (

OPB Rst => OPB Rst , −− [ in ]Flag 1 => f l a g 1 i , −− [ out ]Flag 2 => f l a g 2 i , −− [ out ]

375 OPB ready => OPB rdy i , −− [ in ]ISA ready => ISA rdy i , −− [ in ]OPB ackn => OPB ackn i , −− [ in ]ISA ackn => ISA ackn i ) ; −− [ in ]

end IMP;

The VHDL code 55

Listing E.2: OPB Interface

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−F i l e : o p b i n t e r f a c e . vhd−−Version : v1 .00 a−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

5 −−Descr ip t i on :−−This module c on s i s t s o f the OPB i n t e r f a c e . I t i s working synchron−−−ous to the OPB c l o c k and does a l l the communication wi th the OPB−−bus excep t f o r the address decoding / p e r i p h e r a l s e l e c t which i s−−ca r r i ed out by p s e l e c t in the opb i s a module .

10 −−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 through the c l o c k−−domain c ro s s i n g module , wi th the ISA i n t e r f a c e .−−−−( c ) 2004 Johan Bernspang , johan<at>bernspang<dot>se−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

15 −−His tory :−−2003.12 −− Created by Johan Bernspang−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−l ibrary IEEE ;use IEEE . STD LOGIC 1164 .ALL;

20

entity opb i n t e r f a c e i sgeneric (

C AW : i n t e g e r := 32 ;C DW : i n t e g e r := 32 ) ;

25 port (−−S i gna l s to and from the OPBOPB ABus : in s t d l o g i c v e c t o r ( 0 to C AW − 1) ;OPB DBus : in s t d l o g i c v e c t o r ( 0 to C DW − 1) ;OPB Clk : in s t d l o g i c ;

30 OPB Rst : in s t d l o g i c ;OPBRNW : in s t d l o g i c ;OPB BE : in s t d l o g i c v e c t o r ( 0 to C AW/8 − 1) ;OPB se l ec t i : in s t d l o g i c ;I2O xferAck : out s t d l o g i c ;

35 I2O errAck : out s t d l o g i c ;I2O toutSup : out s t d l o g i c ;I2O Retry : out s t d l o g i c ;I2O DBus : out s t d l o g i c v e c t o r ( 0 to C DW − 1) ;−−S i gna l s to and from ISA

40 ISA Address : out s t d l o g i c v e c t o r (19 downto 0 ) ;ISA Data out : out s t d l o g i c v e c t o r (15 downto 0 ) ;ISA Data in : in s t d l o g i c v e c t o r (15 downto 0 ) ;ISA RNW : out s t d l o g i c ;ISA Finish : in s t d l o g i c ;

45 ISA Fai lure : in s t d l o g i c ;−−S i gna l s to and from CDCReady : out s t d l o g i c ;Acknowledge : out s t d l o g i c ;

56 The VHDL code

Flag 1 : in s t d l o g i c ; −− f l a g f o r data going to ISA50 Flag 2 : in s t d l o g i c ) ; −− f l a g f o r data going to OPB

end opb i n t e r f a c e ;

architecture IMP of opb i n t e r f a c e i s

55 component FDRE i sport (

Q : out s t d l o g i c ;C : in s t d l o g i c ;CE : in s t d l o g i c ;

60 D : in s t d l o g i c ;R : in s t d l o g i c ) ;

end component FDRE;

component FDR i s65 port (

Q : out s t d l o g i c ;C : in s t d l o g i c ;D : in s t d l o g i c ;R : in s t d l o g i c ) ;

70 end component FDR;

signal x f e r s u c c e s s : s t d l o g i c ;signal opb rnw i : s t d l o g i c ;signal o p b s e l e c t i n : s t d l o g i c ;

75 signal addr ce : s t d l o g i c ;signal r e ady i : s t d l o g i c ;signal acknowledge i : s t d l o g i c ;

type Bridge State Machine i s ( Id l e , Send , Waiting , Receive ,80 Finish , Fa i l u r e ) ;

signal opb s t a t e cu r r en t : Br idge State Machine ;signal opb s ta t e nex t : Br idge State Machine ;

begin85 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

−−3 proce s s e s f o r the FSM−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−SEQ FSM PROCESS : process ( OPB Rst , OPB Clk , o p b s e l e c t i n ) i sbegin

90 i f OPB Rst = ’1 ’ or o p b s e l e c t i n = ’1 ’ thenopb s t a t e cu r r en t <= Id l e ;

e l s i f r i s i n g e d g e (OPB Clk ) thenopb s t a t e cu r r en t <= opb s ta t e nex t ;

end i f ;95 end process ;

COMB FSM PROCESS : process ( opb s ta t e cu r r en t , OPB se lect i ,

The VHDL code 57

x f e r s u c c e s s , opb rnw i , ISA Finish ,ISA Fai lure , acknowledge i ) i s

100 begincase opb s t a t e cu r r en t i s

when I d l e =>i f OPB se l ec t i = ’1 ’ then

opb s ta t e nex t <= Send ;105 else

opb s ta t e nex t <= opb s t a t e cu r r en t ;end i f ;

when Send =>i f x f e r s u c c e s s = ’1 ’ then

110 opb s ta t e nex t <= Waiting ;e l s i f ISA Fai lure = ’1 ’ then

opb s ta t e nex t <= Fa i lu r e ;e l s i f

opb s ta t e nex t <= opb s t a t e cu r r en t ;115 end i f ;

when Waiting =>i f opb rnw i = ’1 ’ then

opb s ta t e nex t <= Receive ;e l s i f ISA Finish = ’1 ’ then

120 opb s ta t e nex t <= Fin i sh ;e l s i f ISA Fai lure = ’1 ’ then

opb s ta t e nex t <= Fa i lu r e ;else

opb s ta t e nex t <= opb s t a t e cu r r en t ;125 end i f ;

when Receive =>i f acknowledge i = ’1 ’ then

opb s ta t e nex t <= Fin i sh ;e l s i f ISA Fai lure = ’1 ’ then

130 opb s ta t e nex t <= Fa i lu r e ;else

opb s ta t e nex t <= opb s t a t e cu r r en t ;end i f ;

when Fin i sh =>135 opb s ta t e nex t <= Id l e ;

when Fa i l u r e =>i f OPB se l ec t i = ’0 ’ then

opb s ta t e nex t <= Id l e ;else

140 opb s ta t e nex t <= opb s t a t e cu r r en t ;end i f ;

end case ;end process COMB FSM PROCESS;

145 OUTP FSM PROC : process ( opb s t a t e cu r r en t ) i sbegin

58 The VHDL code

case opb s t a t e cu r r en t i swhen I d l e =>

I2O errAck <= ’0 ’;150 I2O ret ry <= ’0 ’;

I2O xferAck <= ’0 ’ ;I2O toutSup <= ’0 ’ ;

when Send =>I2O errAck <= ’0 ’;

155 I2O ret ry <= ’0 ’;I2O xferAck <= ’0 ’ ;I2O toutSup <= ’1 ’ ;

when Waiting =>I2O errAck <= ’0 ’;


when Receive =>I2O errAck <= ’0 ’;


when Fin i sh =>I2O errAck <= ’0 ’;


when Fa i l u r e =>I2O errAck <= ’1 ’; −−or maybe I2O re t ry ?


end case ;end process OUTP FSM PROC;

180

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−I f ISA a s s e r t s Acknowledge the t r an s f e r o f address and data has−−been s u c c e s s f u l . FSM goes to Waiting s t a t e . I f o p b s e l e c t i i s−−dea s s e r t ed something unexpected has happened .

185 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−SUCCESSFUL PROC : process ( OPB Rst , f l a g 1 , opb s t a t e cu r r en t ) i sbegin

i f OPB Rst = ’1 ’ or opb s t a t e cu r r en t = i d l e oropb s t a t e cu r r en t = wait ing then

190 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;195

The VHDL code 59

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−The OPB s i d e acknowledge during a read opera t ion i s de layed by−−one c l o c k c y c l e . Might not be necessary though .−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

200 FLAGACKNOWLEDGE : process (OPB Rst , OPB Clk ) i sbegin

i f OPB Rst = ’1 ’ thenAcknowledge <= ’0 ’ ;

e l s i f r i s i n g e d g e (OPB Clk ) then205 i f f l a g 2 = ’1 ’ then

acknowledge i <= ’1 ’ ;Acknowledge <= acknowledge i ;

elseacknowledge i <= ’0 ’ ;

210 Acknowledge <= ’0 ’ ;end i f ;

end i f ;end process FLAGACKNOWLEDGE;

215 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−Reg i s t e r s−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−RDY DFF : process ( OPB Rst , OPB Clk ) i sbegin

220 i f OPB Rst = ’1 ’ thenr e ady i <= ’0 ’ ;

e l s i f r i s i n g e d g e (OPB Clk ) theni f opb s t a t e cu r r en t = Send then

r e ady i <= ’1 ’ ;225 else

r e ady i <= ’0 ’ ;end i f ;

end i f ;end process RDY DFF;

230

RNW DFF : process ( OPB Rst , OPB Clk ) i sbegin

i f OPB Rst = ’1 ’ thenopb rnw i <= ’0 ’ ;

235 e l s i f r i s i n g e d g e (OPB Clk ) thenopb rnw i <= OPBRNW;

end i f ;end process RNW DFF;

240 ABUS DEC FF GENERATE: for i in 0 to 19 generateABUS FF I : FDREport map (

Q => ISA Address (19 − i ) , −− [ out ]C => OPB Clk , −− [ in ]

60 The VHDL code

245 CE => addr ce , −− [ in ]D => OPB ABus(12 + i ) , −− [ in ]R => o p b s e l e c t i n −− [ in ]

) ;end generate ABUS DEC FF GENERATE;

250

OPB DBUS FF GENERATE: for i in 0 to 15 generateDATA FF I : FDREport map (

Q => ISA Data out (15 − i ) , −− [ out ]255 C => OPB Clk , −− [ in ]

CE => not f l a g 1 , −− [ in ]D => OPB DBus( i ) , −− [ in ]R => o p b s e l e c t i n −− [ in ]

) ;260 end generate OPB DBUS FF GENERATE;

I2ODBUS FF GENERATE : for i in 0 to 15 generateDATA IN REG I : FDREport map (

265 Q => I2O Dbus (16 + i ) , −− [ out ]C => OPB Clk , −− [ in ]CE => f l a g 2 , −− [ in ]D => ISA Data in (15 − i ) , −− [ in ]R => o p b s e l e c t i n −− [ in ]

270 ) ;end generate I2ODBUS FF GENERATE;

−−Assorted s i g n a l sI2O DBus ( 0 to 15) <= (others = > ’0 ’ ) ;

275 Ready <= ready 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 <= opb rnw i ;addr ce <= o p b s e l e c t i and not r e ady i ;

end IMP;

The VHDL code 61

Listing E.3: ISA Interface

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−F i l e : i s a i n t e r f a c e . vhd−−Version : v1 .00 a−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

5 −−Descr ip t i on :−−This module c on s i s t s o f the ISA i n t e r f a c e . I t i s dr i ven by the ISA−−c l o c k genera tor . I t a c t s as an ISA bus master , and i s a b l e to work−−with an a r b i t r a r y number o f s l a v e s . The communication p ro t o co l−−assumes t ha t the s l a v e s have 16 b i t data width .

10 −−I t communicates wi th the OPB i n t e r f a c e through the CDC, and a l s o−−with the Timeout Watchdog .−−NB! Some s l a v e s might not l i k e the ISA SBHE implementat ion .−−−−( c ) 2004 Johan Bernspang , johan<at>bernspang<dot>se

15 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−His tory :−−2003.12 −− Created by Johan Bernspang−−−−2004.05 −− OPB se lec t i added to i n t e r n a l r e s e t s i g n a l .

20 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−l ibrary IEEE ;use IEEE . STD LOGIC 1164 .ALL;

entity i s a i n t e r f a c e i s25 generic (

C USE CHRDY : s t d l o g i c ) ;port (

ISA SA : out s t d l o g i c v e c t o r (19 downto 0 ) ;ISA SD I : in s t d l o g i c v e c t o r (15 downto 0 ) ;

30 ISA SD O : out s t d l o g i c v e c t o r (15 downto 0 ) ;ISA SD T : out s t d l o g i c v e c t o r (15 downto 0 ) ;ISA Bale : out s t d l o g i c ;ISA SBHE : out s t d l o g i c ;ISA iow : out s t d l o g i c ;

35 ISA ior : out s t d l o g i c ;ISA bclk : out s t d l o g i c ;CHRDY : in s t d l o g i c ;RESDRV : out s t d l o g i c ;IO16 : in s t d l o g i c ;

40 OPB Rst : in s t d l o g i c ;OPB RNW i : in s t d l o g i c ;ISA Clk : in s t d l o g i c ;ISA Address : in s t d l o g i c v e c t o r (19 downto 0 ) ;ISA Data out : in s t d l o g i c v e c t o r (15 downto 0 ) ;

45 ISA Data in : out s t d l o g i c v e c t o r (15 downto 0 ) ;Flag : in s t d l o g i c ;Ready : out s t d l o g i c ;Acknowledge : out s t d l o g i c ;

62 The VHDL code

OPB se l ec t i : in s t d l o g i c ;50 Fin i sh : out s t d l o g i c ;

Fa i l u r e : in s t d l o g i c ) ;end i s a i n t e r f a c e ;

architecture IMP of i s a i n t e r f a c e i s55

component FDRE i sport (

Q : out s t d l o g i c ;C : in s t d l o g i c ;

60 CE : in s t d l o g i c ;D : in s t d l o g i c ;R : in s t d l o g i c) ;

end component FDRE;65

signal ba l e c e : s t d l o g i c ;signal ba l e c e h : s t d l o g i c ;signal i s a b a l e i : s t d l o g i c ;signal i o r i ow c e : s t d l o g i c ;

70 signal i o r i ow c e h : s t d l o g i c ;signal da t a 2 s t a t e : s t d l o g i c ;signal i s a s d t i : s t d l o g i c v e c t o r (15 downto 0 ) ;signal r e ady i : s t d l o g i c ;signal acknowledge i : s t d l o g i c ;

75 signal f i n i s h i : s t d l o g i c ;signal r e s e t : s t d l o g i c ;signal data out ce : s t d l o g i c ;signal ch rdy i : s t d l o g i c ;

80 type Bridge State Machine i s ( Id l e , Address , Data 1 , Data 2 ) ;signal i s a s t a t e c u r r e n t : Br idge State Machine ;signal i s a s t a t e n e x t : Br idge State Machine ;

begin85 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

−−3 proce s s e s f o r the FSM−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−SEQ FSM PROC : process ( r e s e t , ISA Clk ) i sbegin

90 i f r e s e t = ’1 ’ theni s a s t a t e c u r r e n t <= Id l e ;RESDRV <= ’1 ’ ;ISA SBHE <= ’0 ’ ; −−shou ld be low during 8− b i t t r a n s f e r s

e l s i f r i s i n g e d g e ( ISA Clk ) then95 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

COMB FSM PROC : process ( i s a s t a t e c u r r e n t , f l a g , ch rdy i ) i sbegin

case i s a s t a t e c u r r e n t i swhen I d l e =>

105 i f f l a g = ’1 ’ theni s a s t a t e n e x t <= Address ;

elsei 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 ;110 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 =>

115 i f ch rdy i = ’0 ’ theni 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 ;

elsei s a s t a t e n e x t <= Id l e ;

end i f ;120 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 sbegin

125 case i s a s t a t e c u r r e n t i swhen I d l e =>

ba l e c e <= ’0 ’ ;i o r i ow c e <= ’0 ’ ;d a t a 2 s t a t e <= ’0 ’ ;

130 when Address =>ba l e c e <= ’1 ’ ;i o r i ow c e <= ’0 ’ ;d a t a 2 s t a t e <= ’0 ’ ;

when Data 1 =>135 ba l e c e <= ’0 ’ ;

i o r i ow c e <= ’1 ’ ;d a t a 2 s t a t e <= ’0 ’ ;

when Data 2 =>ba l e c e <= ’0 ’ ;

140 i o r i ow c e <= ’1 ’ ;d a t a 2 s t a t e <= ’1 ’ ;

end case ;end process OUTP FSM PROC;

145 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−b a l e c e h in conjunc t ion wi th b a l e c e from the FSM are ANDed to

64 The VHDL code

−−form the 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

150 begini f r e s e t = ’1 ’ then

ba 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 then155 ba l e c e h <= ’1 ’ ;

elseba l e c e h <= ’0 ’ ;

end i f ;end i f ;

160 end process BALE CE H I ;

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−i o r i ow c e h in conjunc t ion wi th i o r i ow c e enab l e s the output−−o f the co r r e c t Read/Write s i g n a l .

165 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−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 sbegin

i f r e s e t = ’1 ’ theni o r i ow c e h <= ’0 ’ ;

170 e l s i f f a l l i n g e d g e ( ISA Clk ) theni 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 theni o r i ow c e h <= ’1 ’ ;

else175 i o r i ow c e h <= ’0 ’ ;

end i f ;end i f ;

end process IOR IOW CE H I ;

180 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−The Acknowledge s i g n a l cou ld a l s o go h igh on f a l l i n g edge o f−−ISA BALE s ince t ha t s i g n a l depend on the f l a g . Might be a b e t t e r−−s o l u t i o n .−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

185 FLAGACKNOWLEDGE : process ( r e s e t , ISA Clk ) i sbegin

i f r e s e t = ’1 ’ thenacknowledge i <= ’0 ’ ;

e l s i f r i s i n g e d g e ( ISA Clk ) then190 i f f l a g = ’1 ’ then

acknowledge i <= ’1 ’ ;else

acknowledge i <= ’0 ’ ;end i f ;

195 end i f ;

The VHDL code 65

end process FLAGACKNOWLEDGE;

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−I f CHRDY i s a s s e r t e d at midpoint o f second data c y c l e the bus

200 −−c y c l e w i l l f i n i s h wi th the next r i s i n g edge o f the ISA c l o c k .−−Otherwise i t w i l l wai t f o r CHRDY to go h igh or u n t i l the watch−−−dog s i g n a l s Fa i l u re .−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−BUS CYCLE FINISHED : process ( r e s e t , ISA Clk ) i s

205 begini f r e s e t = ’1 ’ then

f i n i s h i <= ’0 ’ ;e l s i f f a l l i n g e d g e ( ISA Clk ) then

i f da t a 2 s t a t e = ’1 ’ and ch rdy i = ’1 ’ then210 f i n i s h i <= ’1 ’ ;

elsef i n i s h i <= ’0 ’ ;

end i f ;end i f ;

215 end process BUS CYCLE FINISHED;

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−On the r i s i n g edge o f ISA BALE the ISA address output and the−−data t r i s t a t e r e g i s t e r i s s e t .

220 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−ADDR DATA TRISTATE PROCESS : process ( r e s e t , i s a b a l e i ) i sbegin

i f r e s e t = ’1 ’ thenISA SA <= (others = > ’0 ’ ) ;

225 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 ’ thenISA SA <= ISA Address ;ISA SD T i <= (others = > ’1 ’ ) ;

230 elseISA SA <= ISA Address ;ISA SD T i <= (others = > ’0 ’ ) ;

end i f ;end i f ;

235 end process ADDR DATA TRISTATE PROCESS;

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−During a wr i t e opera t ion the ISA data bus i s wr i t t en to on the−−r i s i n g edge o f ISA BALE.

240 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−OUTPUTS FF GENERATE : for i in 15 downto 0 generateDATA OUT REG I : FDREport map (

Q => ISA SD O( i ) , −− [ out ]

66 The VHDL code

245 C => i s a b a l e i , −− [ in ]CE => data out ce , −− [ in ]D => ISA Data out ( i ) , −− [ in ]R => r e s e t −− [ in ]

) ;250 end generate OUTPUTS FF GENERATE;

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−During a read opera t ion the ISA data bus i s read on the l a s t−−r i s i n g edge o f the bus c y c l e .

255 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−DATA IN RDY PROCESS : process ( r e s e t , ISA Clk ) i sbegin

i f r e s e t = ’1 ’ thenr e ady i <= ’0 ’ ;

260 ISA Data in <= (others = > ’0 ’ ) ;e l s i f r i s i n g e d g e ( ISA Clk ) then

i f OPB RNW i = ’1 ’ and f i n i s h i = ’1 ’ thenISA Data in <= ISA SD I ;r e ady i <= ’1 ’ ;

265 elseISA Data in <= (others = > ’0 ’ ) ;r e ady i <= ’0 ’ ;

end i f ;end i f ;

270 end process DATA IN RDY PROCESS;

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−The C USE CHRDY parameter i s used during system s p e c i f i c a t i o n to−− t e l l t he ISA i n t e r f a c e whether to wai t f o r CHRDY or not .

275 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−CHRDY 1 GEN : i f C USE CHRDY = ’1 ’ generate

ch rdy i <= CHRDY;end generate CHRDY 1 GEN;

280 CHRDY 0 GEN : i f C USE CHRDY = ’0 ’ generatech rdy i <= ’1 ’ ;

end generate CHRDY 0 GEN;

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−285 −−Assorted s i g n a l s

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−Ready <= ready i ;Acknowledge <= acknowledge i and ba l e c e h ;i s a b a l e i <= ba l e c e h and ba l e c e ;

290 ISA Bale <= i s a b a l e i ;ISA bclk <= ISA Clk ;ISA SD T <= i s a s d t i ;r e s e t <= OPB Rst or Fa i l u r e or not OPB se l ec t i ;

The VHDL code 67

i s a i o r <= not ( i o r i ow c e and i o r i ow c e h and OPB RNW i ) ;295 i s a i ow <= not ( i o r i ow c e and i o r i ow c e h and not OPB RNW i ) ;

F in i sh <= f i n i s h i and ( not OPB RNW i or r e ady i ) ;da ta out ce <= f l a g and not OPB RNW i ;

end IMP;

68 The VHDL code

Listing E.4: Timeout Watchdog

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−F i l e : tou t watchdog . vhd−−Version : v1 .00 a−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

5 −−Descr ip t i on :−−This module p rov ide s a watchdog t ha t w i l l cance l a t r an sac t i on i f−−the s l a v e f a i l s to answer . The watchdog i s s t a r t e d by the f l a g−−t h a t i n d i c a t e s t ha t a bus opera t ion has s t a r t ed , and runs u n t i l−−the ISA i n t e r f a c e i n d i c a t e s complet ion or u n t i l the counter

10 −−reaches the l im i t . The C NUM ISA CYCLES TOUT parameter i n d i c a t e s−−how long time the watchdog shou ld wai t u n t i l ISA Fai lure i s−−a s s e r t e d .−−The watchdog i s r e s e t when the 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 .−−

15 −−( c ) 2004 Johan Bernspang , johan<at>bernspang<dot>se−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−His tory :−−2004.01.28 −− Created by Johan Bernspang−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

20 l ibrary IEEE ;use IEEE . STD LOGIC 1164 .ALL;

entity timeout watchdog i sgeneric (

25 C NUM ISA CYCLES TOUT : i n t e g e r ) ;port (

ISA Clk : in s t d l o g i c ;OPB select : in s t d l o g i c ;Flag : in s t d l o g i c ;

30 ISA Finish : in s t d l o g i c ;ISA Fai lure : out s t d l o g i c ) ;

end timeout watchdog ;

architecture IMP of timeout watchdog i s35 signal t imeout : s t d l o g i c ;

signal count : s t d l o g i c ;

type Watchdog State Machine i s ( Id l e , Counting , Fa i l u r e ) ;signal watchdog s ta t e cur r ent : Watchdog State Machine ;

40 signal watchdog state next : Watchdog State Machine ;begin−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−3 proce s s e s f o r the FSM−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

45 SEQ FSM PROC : process ( OPB select , ISA Clk ) i sbegin

i f OPB select = ’0 ’ thenwatchdog s ta t e cur r ent <= Id l e ;

The VHDL code 69

e l s i f r i s i n g e d g e ( ISA clk ) then50 watchdog s ta t e cur r ent <= watchdog state next ;

end i f ;end process SEQ FSM PROC;

COMB FSM PROC : process ( watchdog s tate cur rent , Flag , timeout ,55 ISA Finish ) i s

begincase watchdog s ta t e cur r ent i s

when I d l e =>i f Flag = ’1 ’ then

60 watchdog state next <= Counting ;else

watchdog state next <= watchdog s ta t e cur r ent ;end i f ;

when Counting =>65 i f t imeout = ’1 ’ then

watchdog state next <= Fa i lu r e ;e l s i f ISA Finish = ’1 ’ then

watchdog state next <= Id l e ;else

70 watchdog state next <= watchdog s ta t e cur r ent ;end i f ;

when Fa i l u r e =>watchdog state next <= Id l e ;

end case ;75 end process COMB FSM PROC;

OUTP FSM PROC : process ( watchdog s ta t e cur r ent ) i sbegin

case watchdog s ta t e cur r ent i s80 when I d l e =>

ISA Fai lure <= ’0 ’ ;count <= ’0 ’ ;

when Counting =>ISA Fai lure <= ’0 ’ ;

85 count <= ’1 ’ ;when Fa i l u r e =>

ISA Fai lure <= ’1 ’ ;count <= ’0 ’ ;

end case ;90 end process OUTP FSM PROC;

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−The counter−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

95 COUNTER PROC : process ( ISA Clk , count ) i svariable counter : i n t e g e r range 0 to (C NUM ISA CYCLES TOUT − 1) ;begin

70 The VHDL code

i f count = ’0 ’ thencounter := 0 ;

100 t imeout <= ’0 ’ ;e l s i f r i s i n g e d g e ( ISA Clk ) then

i f counter < (C NUM ISA CYCLES TOUT − 1) thencounter := counter + 1 ;timeout <= ’0 ’ ;

105 elsecounter := 0 ;timeout <= ’1 ’ ;

end i f ;end i f ;

110 end process COUNTER PROC;end IMP;

The VHDL code 71

Listing E.5: ISA Clock Generator

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−F i l e : i s a c l k g e n . vhd−−Version : v1 .00 a−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

5 −−Descr ip t i on :−−This module genera t e s the ISA c l o c k . I t t a k e s the OPB c l o c k and a−−d i v i s i o n parameter as input and c r ea t e s a lower f requency c l o c k−−s i g n a l .−−NB! The ISA c l o c k f requency can be h i gher than 8 MHz. I t depends

10 −−on the s l a v e s .−−−−( c ) 2004 Johan Bernspang , johan<at>bernspang<dot>se−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−His tory :

15 −−2003.12 −− Created by Johan Bernspang−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−l ibrary IEEE ;use IEEE . STD LOGIC 1164 .ALL;

20 entity i s a c l k g e n i sgeneric (

C CLK DIV : i n t e g e r ) ;port (

OPB clk : in s t d l o g i c ;25 OPB Rst : in s t d l o g i c ;

ISA clk : out s t d l o g i c ) ;end i s a c l k g e n ;

architecture IMP of i s a c l k g e n i s30 signal i s a c l k i : s t d l o g i c ;

beginClock : process ( OPB Rst , OPB clk )variable c l k c oun t e r : i n t e g e r range 0 to (C CLK DIV/2 − 1) ;begin

35 i f OPB Rst = ’1 ’ theni s a c l k i <= ’0 ’ ;c l k c oun t e r := 0 ;

e l s i f r i s i n g e d g e (OPB clk ) theni f c l k c oun t e r < (C CLK DIV/2 − 1) then

40 c l k c oun t e r := c l k coun t e r + 1 ;else

i s a c l k i <= not i s a c l k i ;c l k c oun t e r := 0 ;

end i f ;45 end i f ;

ISA clk <= i s a c l k i ;end process Clock ;

end IMP;

72 The VHDL code

Listing E.6: OPB to ISA communication

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−F i l e : opb isa comm . vhd−−Version : v1 .00 a−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

5 −−Descr ip t i on :−−This module p rov ide s the secure communication between the OPB−−c l o c k domain and the ISA c l o c k domain .−−From OPB the address , data , and the OPBRNW s i g n a l i s t rans f e r ed ,−−from the ISA s i d e on ly the data i s t r an s f e r e d from a bus read .

10 −−When the re i s v a l i d data to read from the o ther s i d e the proper−− f l a g i s a s s e r t e d . The f l a g i s h igh between the a s s e r t i on o f the−−t r an sm i t t e r s ready s i g n a l and the r e c e i v e r s acknowledge s i g n a l .−−−−( c ) 2004 Johan aBernspang , johan<at>bernspang<dot>se

15 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−His tory :−−2003.12 −− Created by Johan Bernspang−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−l ibrary IEEE ;

20 use IEEE . STD LOGIC 1164 .ALL;

entity opb isa comm i sport (

OPB Rst : in s t d l o g i c ;25 f l a g 1 : out s t d l o g i c ;

f l a g 2 : out s t d l o g i c ;OPB ready : in s t d l o g i c ;ISA ready : in s t d l o g i c ;OPB ackn : in s t d l o g i c ;

30 ISA ackn : in s t d l o g i c ) ;end opb isa comm ;

architecture IMP of opb isa comm i scomponent cdc i s

35 port (r e s e t : in s t d l o g i c ;ready : in s t d l o g i c ;ackn : in s t d l o g i c ;f l a g : out s t d l o g i c ) ;

40 end component cdc ;

beginOPB2ISA CDC I : cdc

port map (45 r e s e t => OPB Rst ,

ready => OPB ready ,ackn => ISA ackn ,f l a g => f l a g 1 ) ;

The VHDL code 73

50 ISA2OPB CDC I : cdcport map (

r e s e t => OPB Rst ,ready => ISA ready ,ackn => OPB ackn ,

55 f l a g => f l a g 2 ) ;end IMP;

74 The VHDL code

Listing E.7: Clock Domain Crossing

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−F i l e : cdc . vhd−−Version : v1 .00 a−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

5 −−Descr ip t i on :−−This i s the mechanism tha t t r a n s f e r s the data s a f e t l y across the−−c l o c k domain boundary .−−A re s e t f unc t i on shou ld be implemented c l e a r i n g the f l i p −f l o p s and−−d ea s s e r t i n g the f l a g during a t r an sac t i on c an c e l l a t i o n .

10 −−−−( c ) 2004 Johan Bernspang , johan<at>bernspang<dot>se−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−His tory :−−2003.12 −− Created by Johan Bernspang

15 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−l ibrary IEEE ;use IEEE . s t d l o g i c 1 1 6 4 . a l l ;

entity cdc i s20 port (

r e s e t : in s t d l o g i c ;ready : in s t d l o g i c ;ackn : in s t d l o g i c ;f l a g : out s t d l o g i c ) ;

25 end cdc ;

architecture IMP of cdc i scomponent FDC i s

port (30 Q : out s t d l o g i c ;

C : in s t d l o g i c ;CLR : in s t d l o g i c ;D : in s t d l o g i c ) ;

end component ;35

signal q transmit : s t d l o g i c ;signal q r e c e i v e : s t d l o g i c ;signal no t f l a g : s t d l o g i c ;

40 begin−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−Two D−f l i p −f l o p s wi th asynchronous r e s e t−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−TRANSMIT DFF: FDC

45 port map (Q => q transmit ,C => ready ,CLR => q r e c e i v e ,

The VHDL code 75

D = > ’1 ’) ;50

RECEIVE DFF : FDCport map (

Q => q r e c e i v e ,C => ackn ,

55 CLR => no t f l a g ,D = > ’1 ’) ;

f l a g <= q transmit ;n o t f l a g <= not q transmit ;

60 end architecture IMP;

76 The VHDL code

E.2 ISA GPIO code

Listing E.8: ISA GPIO

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−F i l e : i s a g p i o . vhd−−Version : v1 .00 a−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

5 −−Descr ip t i on :−−This f i l e d e s c r i b e s a very ba s i c ISA pe r i p h e r a l . I t i s a GPIO tha t−−i s des i gned to wr i t e to the LED d i s p l a y and read the DIP sw i t che s−−on the Virtex−I I development board .−−

10 −−( c ) 2004 Johan Bernspang , johan<at>bernspang<dot>se−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−His tory :−−2004.01.20 −− Created by Johan Bernspang−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

15 l ibrary IEEE ;use IEEE . STD LOGIC 1164 .ALL;use IEEE .STD LOGIC ARITH.ALL;use IEEE .STD LOGIC UNSIGNED.ALL;

20 entity i s a g p i o i sgeneric (

C ISA BASE ADDR : s t d l o g i c v e c t o r (11 downto 0 ) ) ;port (

c l k : in s t d l o g i c ;25 ba le : in s t d l o g i c ;

i o r : in s t d l o g i c ;iow : in s t d l o g i c ;r e sdrv : in s t d l o g i c ;i o16 : out s t d l o g i c ;

30 chrdy : out s t d l o g i c ;i s a add r e s s : in s t d l o g i c v e c t o r (19 downto 0 ) ;data o : out s t d l o g i c v e c t o r (15 downto 0 ) ;d a t a i : in s t d l o g i c v e c t o r (15 downto 0 ) ;gp io o : out s t d l o g i c v e c t o r ( 0 to 2 3 ) ;

35 g p i o i : in s t d l o g i c v e c t o r ( 0 to 2 3 ) ;gp i o t : out s t d l o g i c v e c t o r ( 0 to 2 3 ) ) ;

end i s a g p i o ;

architecture Behaviora l of i s a g p i o i s40

component FDR 1 i sport (

Q : out s t d l o g i c ;C : in s t d l o g i c ;

45 D : in s t d l o g i c ;

The VHDL code 77

R : in s t d l o g i c ) ;end component FDR 1 ;

signal data out r eg : s t d l o g i c v e c t o r ( 0 to 1 5 ) ;50 signal da t a i n r e g : s t d l o g i c v e c t o r ( 0 to 7 ) ;

signal gp i o c e : s t d l o g i c ;signal g p i o t i : s t d l o g i c v e c t o r ( 0 to 2 3 ) ;signal addr ok : s t d l o g i c ;signal ch rdy r s t : s t d l o g i c ;

55 signal chrdy ce : s t d l o g i c ;

type STATE TYPE i s ( Id l e , data ) ;signal Current State , Next State : STATE TYPE;

60 begin−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−3 proce s s e s f o r the FSM−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−SYNC PROC: process ( c lk , r e sdrv )

65 begini f r e sdrv = ’1 ’ then

Current State <= Id l e ;e l s i f r i s i n g e d g e ( c l k ) then

Current State <= Next State ;70 end i f ;

end process ;

COMBPROC: process ( Current State , addr ok )begin

75 case Current State i swhen I d l e =>

i f addr ok = ’1 ’ thenNext s ta te <= data ;

else80 Next State <= Current State ;

end i f ;when data =>

Next State <= Id l e ;end case ;

85 end process ;

OUTP PROC: process ( Current State ) i sbegin

case Current State i s90 when I d l e =>

i o16 <= ’0 ’ ;gp i o c e <= ’0 ’ ;

when data =>i o16 <= ’0 ’ ;

78 The VHDL code

95 gp i o c e <= ’1 ’ ;end case ;

end process ;

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−100 −−Address decoding

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−ADDR DEC PROC : process ( bale , gp i o c e ) i sbegin

i f gp i o c e = ’1 ’ then105 addr ok <= ’0 ’ ;

e l s i f f a l l i n g e d g e ( ba l e ) theni f i s a add r e s s ( 15 downto 4) = C ISA BASE ADDR then

addr ok <= ’1 ’ ;else

110 addr ok <= ’0 ’ ;end i f ;

end i f ;end process ADDR DEC PROC;

115 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−CHRDY s i g n a l i s a s s e r t e d i f DIP swi t ch 1 i s ’ 1 ’ , t h i s i s f o r−−debug purposes .−−The FDR so l u t i o n w i l l render a errAck f o r every OPB wr i t e or−−read opera t ion to an i l l e g a l address , wh i l e the FDRE so l u t i o n

120 −−only genera t e s a errAck when CHRDY i s not a s s e r t e d . The f i r s t−−ve r s i on might genera te system er ro r s on a uCLinux system .−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

−− chrdy ce <= addr ok or gp i o c e ;−− GPIO CHRDY FF : FDRE 1

125 −− por t map (−− Q => CHRDY,−− C => c l k ,−− CE => chrdy ce ,−− D => g p i o i (23) ,

130 −− R => re sdrv ) ;ch rdy r s t <= not ( addr ok or gp i o c e ) ;GPIO CHRDY FF : FDR 1

port map (Q => CHRDY,

135 C => c lk ,D => g p i o i ( 23 ) ,R => ch rdy r s t ) ;

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−140 −−During a wr i t e operat ion , data i s wr i t t en to da t a ou t r e g

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−DATA OUT PROCESS : process ( c l k ) i sbegin

The VHDL code 79

i f r i s i n g e d g e ( c l k ) then145 i f iow = ’0 ’ and ( gp i o c e = ’1 ’ or addr ok = ’1 ’ ) then

for i in 0 to 15 loopi f g p i o t i ( i ) = ’ 0 ’ then

data out r eg ( i ) <= da ta i (15 − i ) ;else

150 data out r eg ( i ) <= data out r eg ( i ) ;end i f ;

end loop ;end i f ;

end i f ;155 end process DATA OUT PROCESS;

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−During a read operat ion , data i s t r an s f e r e d from the upper gp io−−b i t s to the upper data o b i t s . The low by t e in data o i s a lways

160 −−zero .−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−DATA IN PROCESS : process ( c l k ) i sbegin

i f f a l l i n g e d g e ( c l k ) then165 i f i o r = ’0 ’ and gp i o c e = ’1 ’ then

for i in 0 to 7 loopdata o (8 + i ) <= gp i o i (23 − i ) ;

end loop ;data o ( 7 downto 0) <= (others = > ’0 ’ ) ;

170 elsedata o <= (others = > ’0 ’ ) ;

end i f ;end i f ;

end process DATA IN PROCESS;175

gp io o ( 0 to 1 5 ) <= data out r eg ;gp io o ( 1 6 to 23) <= (others = > ’0 ’ ) ;g p i o t <= g p i o t i ;−−the g p i o t i s hardcoded in t h i s case

180 g p i o t i ( 0 to 15) <= (others = > ’0 ’ ) ;g p i o t i ( 16 to 23) <= (others = > ’1 ’ ) ;

end Behaviora l ;

Appendix F

Device utilization

This appendix contain the device utilization information gathered from the place-and-route re-port for different implementations of the system. The information is used to determine thehardware utilization of different Ethernet solutions.System with on-chip Ethernet MAC core:

Device utilization summary:

Number of External IOBs 165 out of 324 50%Number of LOCed External IOBs 165 out of 165 100%

Number of MULT18X18s 3 out of 40 7%Number of RAMB16s 34 out of 40 85%Number of SLICEs 3552 out of 5120 69%

Number of BUFGMUXs 8 out of 16 50%Number of DCMs 3 out of 8 37%

System without on-chip Ethernet MAC core:





80

Device utilization 81

System with OPB to ISA bridge and OPB GPIO:





System with OPB to ISA bridge and ISA GPIO:





Appendix G

Simulation waveforms

The waveforms in this appendix are taken from the post-place-and-route simulation results inModelSim.

The first two simulation waveforms show the results from read operations where the CHRDYsignal is set to zero in the first case. The two latter waveforms show the results from similarsimulations of write operations. A comparison with the ISA specification in section 2.4.1 showsthat the simulated core behaves according to the ISA specification.

82

Simulation waveforms 83

0000

...00

1111

1111

1111

1111

0110

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000 00

0000

0000

0000

0000

0000

0000

0000

00

0000

0000

0000

0000

0000

1111

0110

0000

0000

0000

0000

0000

0000

0000

0000

0000

...00

1011

0001

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

1111

1111

1111

1111

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

020

0 ns

400

ns60

0 ns

800

ns

opb_

clk

opb_

rst

opb_

abus

0000

...00

1111

1111

1111

1111

0110

0000

0000

0000

opb_

dbus

0000

0000

0000

0000

0000

0000

0000

0000

opb_

rnw

opb_

be00

00

opb_

seqa

ddr

opb_

sele

ct

i2o_

xfer

ack

i2o_

erra

ck

i2o_

tout

sup

i2o_

retr

y

i2o_

dbus

0000

0000

0000

0000

0000

0000

0000

0000

isa_

sa00

0000

0000

0000

0000

0011

1101

1000

0000

0000

0000

0000

0000

0000

0000

00

isa_

sd_i

0000

...00

1011

0001

0000

0000

0000

0000

0000

0000

isa_

sd_o

0000

0000

0000

0000

isa_

sd_t

0000

0000

0000

0000

1111

1111

1111

1111

0000

0000

0000

0000

isa_

sd_i

n00

0000

0000

0000

00

isa_

sd_o

ut00

0000

0000

0000

00

isa_

bale

isa_

sbhe

isa_

iow

isa_

ior

isa_

bclk

irq9

irq10

irq11

irq15

chrd

y

resd

rv

io16

inte

rrup

t9

inte

rrup

t10

inte

rrup

t11

Figure G.1: Simulation of read cycle, CHRDY = 0

84 Simulation waveforms

0000

...00

1111

1111

1111

1111

0110

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000 00

0000

0000

0000

0000

0000

0000

0000

0010

1100

0100

...0

0000

...00

0000

0000

0000

0000

0000

1111

0110

0000

0000

0000

0000

...00

1011

0001

0000

0000

0000

...00

0000

0000

0000

0000

0000

0000

0000

0000

1111

1111

1111

1111

0000

0000

0000

0000

0000

0000

0000

0000

020

0 ns

400

ns60

0 ns

opb_

clk

opb_

rst

opb_

abus

0000

...00

1111

1111

1111

1111

0110

0000

0000

0000

opb_

dbus

0000

0000

0000

0000

0000

0000

0000

0000

opb_

rnw

opb_

be00

00

opb_

seqa

ddr

opb_

sele

ct

i2o_

xfer

ack

i2o_

erra

ck

i2o_

tout

sup

i2o_

retr

y

i2o_

dbus

0000

0000

0000

0000

0000

0000

0000

0000

1011

0001

00...

000

00...

00

isa_

sa00

0000

0000

0000

0000

0011

1101

1000

0000

0000

00

isa_

sd_i

0000

...00

1011

0001

0000

0000

0000

...00

isa_

sd_o

0000

0000

0000

0000

isa_

sd_t

0000

0000

0000

0000

1111

1111

1111

1111

isa_

sd_i

n00

0000

0000

0000

00

isa_

sd_o

ut00

0000

0000

0000

00

isa_

bale

isa_

sbhe

isa_

iow

isa_

ior

isa_

bclk

irq9

irq10

irq11

irq15

chrd

y

resd

rv

io16

inte

rrup

t9

inte

rrup

t10

inte

rrup

t11

Figure G.2: Simulation of read cycle, CHRDY = 1

Simulation waveforms 85

0000

...00

1111

1111

1111

1111

0110

0000

0000

0000

0000

...00

1111

1100

0000

0001

0000

0000

0000

0000

0000 00

0000

0000

0000

0000

0000

0000

0000

00

0000

0000

0000

0000

0000

1111

0110

0000

0000

0000

0000

...00

0000

0000

0000

0000

0000

0000

0000

0000

1111

1100

0000

0001

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

1111

1100

0000

0001

020

0 ns

400

ns60

0 ns

opb_

clk

opb_

rst

opb_

abus

0000

...00

1111

1111

1111

1111

0110

0000

0000

0000

opb_

dbus

0000

...00

1111

1100

0000

0001

0000

0000

0000

0000

opb_

rnw

opb_

be00

00

opb_

seqa

ddr

opb_

sele

ct

i2o_

xfer

ack

i2o_

erra

ck

i2o_

tout

sup

i2o_

retr

y

i2o_

dbus

0000

0000

0000

0000

0000

0000

0000

0000

isa_

sa00

0000

0000

0000

0000

0011

1101

1000

0000

0000

0000

00...

00

isa_

sd_i

0000

0000

0000

0000

isa_

sd_o

0000

0000

0000

0000

1111

1100

0000

0001

isa_

sd_t

0000

0000

0000

0000

isa_

sd_i

n00

0000

0000

0000

00

isa_

sd_o

ut00

0000

0000

0000

0011

1111

0000

0000

01

isa_

bale

isa_

sbhe

isa_

iow

isa_

ior

isa_

bclk

irq9

irq10

irq11

irq15

chrd

y

resd

rv

io16

inte

rrup

t9

inte

rrup

t10

inte

rrup

t11

Figure G.3: Simulation of write cycle, CHRDY = 0

86 Simulation waveforms

0000

...00

1111

1111

1111

1111

0110

0000

0000

0000

0000

...00

1111

1100

0000

0001

0000

0000

0000

0000

0000 00

0000

0000

0000

0000

0000

0000

0000

00

0000

0000

0000

0000

0000

1111

0110

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

1111

1100

0000

0001

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

0000

1111

1100

0000

0001

020

0 ns

400

ns60

0 ns

opb_

clk

opb_

rst

opb_

abus

0000

...00

1111

1111

1111

1111

0110

0000

0000

0000

opb_

dbus

0000

...00

1111

1100

0000

0001

0000

0000

0000

0000

opb_

rnw

opb_

be00

00

opb_

seqa

ddr

opb_

sele

ct

i2o_

xfer

ack

i2o_

erra

ck

i2o_

tout

sup

i2o_

retr

y

i2o_

dbus

0000

0000

0000

0000

0000

0000

0000

0000

isa_

sa00

0000

0000

0000

0000

0011

1101

1000

0000

0000

00

isa_

sd_i

0000

0000

0000

0000

isa_

sd_o

0000

0000

0000

0000

1111

1100

0000

0001

isa_

sd_t

0000

0000

0000

0000

isa_

sd_i

n00

0000

0000

0000

00

isa_

sd_o

ut00

0000

0000

0000

0011

1111

0000

0000

01

isa_

bale

isa_

sbhe

isa_

iow

isa_

ior

isa_

bclk

irq9

irq10

irq11

irq15

chrd

y

resd

rv

io16

inte

rrup

t9

inte

rrup

t10

inte

rrup

t11

Figure G.4: Simulation of write cycle, CHRDY = 1

Copyright

Svenska

Detta dokument halls tillgangligt pa Internet - eller dess framtida ersattare - under en langre tidfran publiceringsdatum under forutsattning att inga extra-ordinara omstandigheter uppstar.

Tillgang till dokumentet innebar tillstand for var och en att lasa, ladda ner, skriva ut enstakakopior for enskilt bruk och att anvanda det oforandrat for ickekommersiell forskning och for un-dervisning. Overforing av upphovsratten vid en senare tidpunkt kan inte upphava detta tillstand.All annan anvandning av dokumentet kraver upphovsmannens medgivande. For att garanteraaktheten, sakerheten och tillgangligheten finns det losningar av teknisk och administrativ art.

Upphovsmannens ideella ratt innefattar ratt att bli namnd som upphovsman i den omfattningsom god sed kraver vid anvandning av dokumentet pa ovan beskrivna satt samt skydd mot attdokumentet andras eller presenteras i sadan form eller i sadant sammanhang som ar krankandefor 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 - fora 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 non-commercial research and educational purpose. Subsequent transfers of copyright cannot revokethis permission. All other uses of the document are conditional on the consent of the copyrightowner. 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/herwork is accessed as described above and to be protected against infringement.

For additional information about the Linkoping University Electronic Press and its proceduresfor publication and for assurance of document integrity, please refer to its WWW home page:http://www.ep.liu.se/

c© Johan BernspangLinkoping, 31th May 2004

interfacing an external ethernet mac/phy to a microblaze ...19744/fulltext01.pdf · interfacing an...

Documents