IBM PowerPC 405GP (266Mhz), PowerPC 405GP (133Mhz), PowerPC 405GP (200Mhz) PowerPC 405 Processor Block Reference Guide Embedded Development Kit EDK 6.1 (Xilinx)

Download

PowerPC 405 ProcessorBlock Reference Guide

Embedded Development Kit

EDK 6.1 October 6, 2003

PowerPC 405 Processor Block Reference Guide www.xilinx.com EDK 6.1 October 6, 2003

1-800-255-7778

"Xilinx" and the Xilinx logo shown above are registered trademarks of Xilinx, Inc. Any rights not expressly granted herein are reserved. CoolRunner, RocketChips, Rocket IP, Spartan, StateBENCH, StateCAD, Virtex, XACT, XC2064, XC3090, XC4005, and XC5210 are

registered trademarks of Xilinx, Inc.

The shadow X shown above is a trademark of Xilinx, Inc. ACEController, ACEFlash, A.K.A. Speed, Alliance Series, AllianceCORE, Bencher,ChipScope, ConﬁgurableLogic Cell, CORE Generator,

CoreLINX, Dual Block, EZTag, Fast CLK, Fast CONNECT, Fast FLASH, FastMap, Fast Zero Power, Foundation, Gigabit Speeds...and Beyond!, HardWire, HDL Bencher, IRL, J Drive, JBits, LCA, LogiBLOX, Logic Cell, LogiCORE, LogicProfessor, MicroBlaze, MicroVia, MultiLINX, NanoBlaze, PicoBlaze,PLUSASM,PowerGuide, PowerMaze, QPro,Real-PCI, RocketI/O, SelectI/O, SelectRAM, SelectRAM+, Silicon Xpresso, Smartguide, Smart-IP, SmartSearch, SMARTswitch, System ACE, Testbench In A Minute, TrueMap, UIM, VectorMaze, VersaBlock, VersaRing, Virtex-II Pro, Virtex-II EasyPath, Wave Table, WebFITTER, WebPACK, WebPOWERED, XABEL, XACTFloorplanner, XACT-Performance,XACTstep Advanced, XACTstep Foundry, XAM, XAPP, X-BLOX +, XC designated products, XChecker, XDM, XEPLD, Xilinx Foundation Series, Xilinx XDTV, Xinfo, XSI, XtremeDSP and ZERO+ are trademarks of Xilinx, Inc.

The Programmable Logic Company is a service mark of Xilinx, Inc. All other trademarks are the property of their respective owners. Xilinx, Inc. does not assume any liability arising out of the application or use of any product described or shown herein; nor does it convey

any license under its patents, copyrights, or maskwork rights or any rights of others. Xilinx, Inc. reserves the right to make changes, at any time, in order to improve reliability, function or design and to supply the best product possible. Xilinx, Inc. will not assume responsibility for the use of any circuitry described herein other than circuitry entirely embodied in its products. Xilinx provides any design, code, or information shown or described herein "as is." By providing the design, code, or information as one possible implementation of a feature, application, or standard, Xilinx makes no representation that such implementation is free from any claims of infringement. You are responsible for obtaining any rights you may require for your implementation. Xilinx expressly disclaims any warranty whatsoever with respect to the adequacy of any such implementation, including but not limited to any warranties or representations that the implementation is freefromclaimsof infringement,as well as any implied warrantiesof merchantability or ﬁtness for a particular purpose. Xilinx, Inc. devices and products are protected under U.S. Patents.Other U.S. and foreign patents pending. Xilinx, Inc. does not represent that devices shown or products described herein are free from patent infringement or from any other third party right. Xilinx, Inc. assumes no obligation to correct any errors contained herein or to advise any user of this text of any correction if such be made. Xilinx, Inc. will not assume any liability for the accuracy or correctness of any engineering or software support or assistance provided to a user.

Xilinx products are not intended for use in life support appliances, devices, or systems. Use of a Xilinx product in such applications without the written consent of the appropriate Xilinx ofﬁcer is prohibited.

The contents of this manual are owned and copyrighted by Xilinx. Copyright 1994-2002 Xilinx, Inc. All Rights Reserved. Except as stated herein, none of the material may be copied, reproduced, distributed, republished,downloaded, displayed, posted, or transmitted in any form or byany means including, but not limitedto,electronic, mechanical, photocopying,recording, or otherwise, without the prior written consent of Xilinx. Any unauthorized use of any material contained in this manual may violate copyright laws, trademark laws, the laws of privacy and publicity, and communications regulations and statutes.

EDK 6.1 October 6, 2003 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778

PowerPC 405 Processor Block Reference Guide EDK 6.1 October 6, 2003

The following table shows the revision history for this document.

Version Revision

09/16/02 1.0 Initial Embedded Develpment Kit (EDK) release. 09/02/03 1.1 Updated for EDK 6.1 release

PowerPC 405 Processor Block Reference Guide www.xilinx.com EDK 6.1 October 6, 2003

1-800-255-7778

Table of Contents

About This Guide

Document Organization......................................................................................................... 9

Document Conventions.......................................................................................................... 9

General Conventions .............................................................................................................. 9

Registers...................................................................................................................................... 10

Terms ............................................................................................................................................ 11

Additional Reading................................................................................................................ 14

Chapter 1: Introduction to the PowerPC®405 Processor

PowerPC Architecture........................................................................................................... 15

PowerPC Embedded-Environment Architecture............................................................. 16

PPC405x3 Software Features .............................................................................................. 18

Privilege Modes..................................................................................................................... 20

Address Translation Modes.................................................................................................20

Addressing Modes ................................................................................................................21

Data Types..............................................................................................................................21

Register Set Summary........................................................................................................... 21

PPC405x3 Hardware Organization.................................................................................. 23

Central-Processing Unit........................................................................................................ 24

Exception Handling Logic.................................................................................................... 25

Memory Management Unit ................................................................................................. 25

Instruction and Data Caches................................................................................................ 26

Timer Resources .................................................................................................................... 26

Debug...................................................................................................................................... 27

PPC405x3 Interfaces.............................................................................................................. 27

PPC405x3 Performance.......................................................................................................... 28

Chapter 2: Input/Output Interfaces

Signal Naming Conventions.............................................................................................. 32

Clock and Power Management Interface..................................................................... 33

CPM Interface I/O Signal Summary.................................................................................. 33

CPM Interface I/O Signal Descriptions............................................................................. 34

CPU Control Interface........................................................................................................... 37

CPU Control Interface I/O Signal Summary.................................................................... 37

CPU Control Interface I/O Signal Descriptions ............................................................... 37

Reset Interface .......................................................................................................................... 39

Reset Requirements............................................................................................................... 39

Reset Interface I/O Signal Summary.................................................................................. 40

Reset Interface I/O Signal Descriptions............................................................................. 40

Instruction-Side Processor Local Bus Interface......................................................... 43

Instruction-Side PLB Operation.......................................................................................... 43

Instruction-Side PLB I/O Signal Table............................................................................... 46

Instruction-Side PLB Interface I/O Signal Descriptions.................................................. 47

PowerPC 405 Processor Block Reference Guide www.xilinx.com 5

EDK 6.1 October 6, 2003 1-800-255-7778

Instruction-Side PLB Interface Timing Diagrams............................................................. 55

Data-Side Processor Local Bus Interface ...................................................................... 66

Data-Side PLB Operation..................................................................................................... 66

Data-Side PLB Interface I/O Signal Table......................................................................... 69

Data-Side PLB Interface I/O Signal Descriptions............................................................. 70

Data-Side PLB Interface Timing Diagrams........................................................................ 82

Device-Control Register Interface................................................................................... 96

DCR Interface I/O Signal Summary................................................................................... 99

DCR Interface I/O Signal Descriptions............................................................................ 100

DCR Interface Timing Diagrams....................................................................................... 102

External Interrupt Controller Interface....................................................................... 107

EIC Interface I/O Signal Summary .................................................................................. 107

EIC Interface I/O Signal Descriptions.............................................................................. 108

Virtex-II Pro PPC405 JTAG Debug Port...................................................................... 109

JTAG Interface I/O Signal Table.......................................................................................109

JTAG Interface I/O Signal Descriptions .......................................................................... 109

Virtex-II Pro JTAG Instruction Register........................................................................... 110

Connecting PPC405 JTAG logic directly to Programmable I/O.................................. 112

Connecting PPC405 JTAG logic in Series with the dedicated Virtex-II Pro JTAG logic115

VHDL and Verilog Instantiation Templates ................................................................... 117

Debug Interface...................................................................................................................... 125

Debug Interface I/O Signal Summary ............................................................................. 125

Debug Interface I/O Signal Descriptions ........................................................................ 125

Trace Interface ........................................................................................................................ 128

Trace Interface Signal Summary ....................................................................................... 128

Trace Interface I/O Signal Descriptions .......................................................................... 129

Additional FPGA Specific Signals................................................................................ 132

Additional FPGA I/O Signal Descriptions...................................................................... 132

Chapter 3: PowerPC® 405 OCM Controller

Introduction............................................................................................................................. 135

Functional Features .............................................................................................................. 135

Common Features ............................................................................................................... 135

Data-Side OCM (DSOCM)................................................................................................. 136

Instruction-Side OCM (ISOCM)........................................................................................ 136

OCM Controller Operation .............................................................................................. 136

Operational Summary ........................................................................................................ 137

DSOCM Ports....................................................................................................................... 138

DSOCM Attributes.............................................................................................................. 139

ISOCM Ports......................................................................................................................... 140

ISOCM Attributes................................................................................................................ 141

Timing Specification........................................................................................................... 142

Single-Cycle Mode .............................................................................................................. 142

Multi-Cycle Mode ............................................................................................................... 143

Programmer’s Model........................................................................................................... 144

DCR Registers...................................................................................................................... 144

References................................................................................................................................. 146

Application Notes................................................................................................................. 146

Interfacing to Block RAM................................................................................................... 146

Size vs. Performance........................................................................................................... 146

6 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Application Example .......................................................................................................... 147

Appendix A: RISCWatch and RISCTrace Interfaces

RISCWatch Interface........................................................................................................... 155

RISCTrace Interface............................................................................................................. 157

Appendix B: Signal Summary

Interface Signals.................................................................................................................... 159

Appendix C: Processor Block Timing Model

Timing Parameters................................................................................................................ 166

Timing Parameter Tables and Diagram...................................................................... 167

Index...................................................................................................................................................... 173

PowerPC 405 Processor Block Reference Guide www.xilinx.com 7

EDK 6.1 October 6, 2003 1-800-255-7778

8 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

About This Guide

This guide serves as a technical reference describing the hardware interface to the PowerPC™ PPC405x3 processor block. It contains information on input/output signals, timing relationships between signals, and the mechanisms software can use to control the interface operation. The document is intended for use by FPGA and system hardware designers and by system programmers who need to understand how certain operations affect hardware external to the processor.

Document Organization

• Chapter 1, Introduction to the PowerPC®405 Processor, provides an overview of the

PowerPC embedded-environment architecture and the features supported by the PPC405x3.

• Chapter 2, Input/Output Interfaces, describes the interface signals into and out of the

PPC405x3 processor block. Where appropriate, timing diagrams are provided to assist in understanding the functional relationship between multiple signals.

• Chapter 3, PowerPC® 405 OCM Controller, describes the features, interface signals,

timing speciﬁcations, and programming model for the PPC405x3 on-chip memory (OCM) controller. The OCM controller serves as a dedicated interface between the block RAMs in the FPGA and OCM signals available on the embedded PPC405x3 core.

• Appendix A, RISCWatch and RISCTrace Interfaces, describes the interface

requirements between the PPC405x3 processor block and the RISCWatch and RISCTrace tools.

• Appendix B, Signal Summary, lists all PPC405x3 interface signals in alphabetical

order.

• Appendix C, Processor Block Timing Model, explains all of the timing parameters

associated with the IBM PPC405 Processor Block.

Preface

Document Conventions

General Conventions

Table 2-1 lists the general notational conventions used throughout this document.

PowerPC 405 Processor Block Reference Guide www.xilinx.com 9

EDK 6.1 October 6, 2003 1-800-255-7778

Preface: About This Guide

Table 2-1: General Notational Conventions

Convention Deﬁnition

mnemonic Instruction mnemonics are shown in lower-case bold.

variable Variable items are shown in italic. ActiveLow An overbar indicates an active-low signal. n A decimal number 0xn A hexadecimal number 0bn A binary number

Registers

OBJECT

A single bit in any object (a register, an instruction, an address,oraﬁeld) is shown as a subscripted number or name

OBJECT

b:b

A range of bits in any object (a register, an instruction, an address, or a ﬁeld)

OBJECT

b,b, . . .

A list of bits in any object (a register, an instruction, an

address, or a ﬁeld) REGISTER[FIELD] Fields within any register are shown in square brackets REGISTER[FIELD, FIELD

] A list of ﬁelds in any register

. . .

Table 2-2 lists the PPC405x3 registers used in this document and their descriptive names.

Table 2-2: PPC405x3 Registers

CCR0 Core-conﬁguration register 0 DBCRn Debug-control register n DBSR Debug-status register ESR Exception-syndrome register MSR Machine-state register PIT Programmable-interval timer TBL Time-base lower TBU Time-base upper TCR Timer-control register TSR Timer-status register

10 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Terms

active

assert

atomic access

big endian

Book-E

cache block cache line

cache set clear

As applied to signals, this term indicates a signal is in a state that causes an action to occur in the receiving device, or indicates an action occurred in the sending device. An active- high signal drives a logic 1 when active. An active-low signal drives a logic 0 when active.

As applied to signals, this term indicates a signal is driven to its active state.

A memory access that attempts to read from and write to the same address uninterrupted by other accesses to that address. The term refers to the fact that such transactions are indivisible.

A memory byte ordering where the address of an item corresponds to the most-signiﬁcant byte.

An version of the PowerPC architecture designed speciﬁcally for embedded applications.

Synonym for cache line. A portion of a cache array that contains a copy of contiguous

system-memory addresses. Cache lines are 32-bytes long and aligned on a 32-byte address.

Synonym for congruence class. To write a bit value of 0.

clock

congruence class cycle

dead cycle

deassert

dirty

doubleword effective address exception

Unless otherwise speciﬁed, this term refers to the PPC405x3 processor clock.

A collection of cache lines with the same index. The time between two successive rising edges of the associated

clock. A cycle in which no useful activity occurs on the associated

interface. As applied to signals, this term indicates a signal is driven to its

inactive state. An indication that cache information is more recent than the

copy in memory. Eight bytes, or 64 bits. The untranslated memory address as seen by a program. An abnormal event or condition that requires the processor’s

attention. They can be caused by instruction execution or an external device. The processor records the occurrence of an exception and they often cause an interrupt to occur.

PowerPC 405 Processor Block Reference Guide www.xilinx.com 11

EDK 6.1 October 6, 2003 1-800-255-7778

Preface: About This Guide

ﬁll buffer

ﬂush

GB halfword hit

inactive

interrupt

invalidate

A buffer that receives and sends data and instructions between the processor and PLB. It is used when cache misses occur and when access to non-cacheable memory occurs.

A cache operation that involves writing back a modiﬁed entry to memory, followed by an invalidation of the entry.

Gigabyte, or one-billion bytes. Two bytes, or 16 bits. An indication that requested information exists in the accessed

cache array, the associated ﬁll buffer, or on the corresponding OCM interface.

As applied to signals, this term indicates a signal is in a state that does not cause an action to occur, nor does it indicate an action occurred. An active-high signal drives a logic 0 when inactive. An active-low signal drives a logic 1 when inactive.

Theprocessof stopping the currentlyexecutingprogramso that an exception can be handled.

A cache or TLB operation that causes an entry to be marked as invalid. An invalid entry can be subsequently replaced.

Kilobyte, or one-thousand bytes.

line buffer

line ﬁll

line transfer

little endian

logical address MB memory miss

OEA

Abufferlocated in the cache array that can temporarily hold the contents of an entire cache line. It is loaded with the contents of a cache line when a cache hit occurs.

A transfer of the contents of the instruction or data line buffer into the appropriate cache.

A transfer of an aligned, sequentially addressed 4-word or 8word quantity (instructions or data) across the PLB interface. The transfer can be fromthe PLB slave (read)ortothePLB slave (write).

A memory byte ordering where the address of an item corresponds to the least-signiﬁcant byte.

Synonym for effective address. Megabyte, or one-million bytes. Collectively, cache memory and system memory. An indication that requested information does not exist in the

accessed cache array, the associated ﬁll buffer, or on the corresponding OCM interface.

The PowerPC operating-environment architecture, which deﬁnes the memory-management model, supervisor-level registers and instructions, synchronization requirements, the exception model, and the time-base resources as seen by supervisor programs.

12 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Terms

on chip

pending

physical address

PLB privileged mode

problem state process

real address scalar

In system-on-chip implementations, this indicates on the same FPGA chip as the processor core, but external to the processor core.

As applied to interrupts, this indicates that an exception occurred, but the interrupt is disabled. The interrupt occurs when it is later enabled.

The address used to access physically-implemented memory. This address can be translated from the effective address. When address translation is not used, this address is equal to the effective address.

Processor local bus. The operating mode typically used by system software.

Privileged operations are allowed and software can access all registers and memory.

Synonym for user mode. A program (or portion of a program) and any data required for

the program to run. Synonym for physical address. Individual data objects and instructions. Scalars are of arbitrary

size.

set sleep

sticky

string supervisor state system memory

tag

UISA

user mode

To write a bit value of 1. A state in which the PPC405x3 processor clock is prevented

from toggling. The execution state of the PPC405x3 does not change when in the sleep state.

A bit that can be set by software, but cleared only by the processor. Alternatively, a bit that can be cleared by software, but set only by the processor.

A sequence of consecutive bytes. Synonym for privileged mode. Physical memory installed in a computer system external to the

processor core, such RAM, ROM, and ﬂash. As applied to caches, a set of address bits used to uniquely

identify a speciﬁc cache line within a congruence class. As applied to TLBs, a set of address bits used to uniquely identify a speciﬁc entry within the TLB.

The PowerPC user instruction-set architecture, which deﬁnes the base user-level instruction set, registers, data types, the memory model, the programming model, and the exception model as seen by user programs.

The operating mode typically used by application software. Privileged operations are not allowed in user mode, and software can access a restricted set of registers and memory.

PowerPC 405 Processor Block Reference Guide www.xilinx.com 13

EDK 6.1 October 6, 2003 1-800-255-7778

Preface: About This Guide

VEA

virtual address

wake up

word

Additional Reading

The following documents contain additional information of potential interest to readers of this manual:

• XILINX PowerPC Processor Reference Guide

• XILINX Virtex-II Pro Platform FPGA Handbook

The PowerPC virtual-environment architecture, which deﬁnes a multi-access memory model, the cache model, cache-control instructions, and the time-base resources as seen by user programs.

An intermediate address used to translate an effective address into a physical address. It consists of a process ID and the effective address. It is only used when address translation is enabled.

The transition of the PPC405x3 out of the sleep state. The PPC405x3 processor clock begins toggling and the execution state of the PPC405x3 advances from that of the sleep state.

Four bytes, or 32 bits.

14 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Introduction to the

Chapter 1

PowerPC

The PPC405x3 is a 32-bit implementation of the PowerPC™ embedded-environment architecture that is derived from the PowerPC architecture. Speciﬁcally, the PPC405x3 is an

embedded PowerPC 405D5 processor core (PPC405D5). The term processor block is used throughout this document to refer to the combination of PPC405D5 core, on-chip memory logic (OCM), and the gasket logic and interface.

The PowerPC architecture provides a software model that ensures compatibility between implementations of the PowerPC family of microprocessors. The PowerPC architecture deﬁnes parameters that guarantee compatible processor implementations at the application-program level, allowing broad ﬂexibility in the development of derivative PowerPC implementations that meet speciﬁc market requirements.

This chapter provides an overview of the PowerPC architecture and an introduction to the features of the PPC405x3 core.

PowerPC Architecture

The PowerPC architecture is a 64-bit architecturewith a 32-bit subset. The various features of the PowerPC architecture are deﬁned at three levels. This layering provides ﬂexibility by allowing degrees of software compatibility across a wide range of implementations. For example, an implementation such as an embedded controller can support the user instruction set, but not the memory management, exception, and cache models where it might be impractical to do so.

405 Processor

The three levels of the PowerPC architecture are deﬁned in Table 1-1.

PowerPC 405 Processor Block Reference Guide www.xilinx.com 15

EDK 6.1 October 6, 2003 1-800-255-7778

Table 1-1: Three Levels of PowerPC Architecture

Chapter 1: Introduction to the PowerPC®405 Processor

User Instruction-Set Architecture

(UISA)

• Deﬁnes the architecture level to which user-level (sometimes referred to as problem state) software should conform

• Deﬁnes the base user-level instruction set, user-level registers, data types, ﬂoatingpoint memory conventions, exception model as seen by user programs, memory model, and the programming model

Note:All PowerPC implementations adhere to the UISA.

The PowerPC architecture requires that all PowerPC implementations adhere to the UISA, offering compatibility among all PowerPC application programs. However, different versions of the VEA and OEA are permitted.

Virtual Environment Architecture

(VEA)

• Deﬁnes additional user-level functionality that falls outside typical user-level software requirements

• Describes the memory model for an environment in which multiple devices can access memory

• Deﬁnes aspects of the cache model and cache-control instructions

• Deﬁnes the time-base resources from a user-level perspective

Note:Implementations that conform to the VEA level are guaranteed to conform to the UISA level.

Operating Environment

Architecture (OEA)

• Deﬁnes supervisor-level resources typically required by an operating system

• Deﬁnes the memorymanagement model, supervisorlevel registers, synchronization requirements, and the exception model

• Deﬁnes the time-base resources from a supervisor-level perspective

Note:Implementations that conform to the OEA level are guaranteed to conform to the UISA and VEA levels.

Embedded applications written for the PPC405x3 are compatible with other PowerPC implementations. Privileged software generally is not compatible. The migration of privileged software from the PowerPC architecture to the PPC405x3 is in many cases straightforward because of the simpliﬁcations made by the PowerPC embeddedenvironment architecture. Refer to PowerPC Processor Reference Guide for more information on programming the PPC405x3.

PowerPC Embedded-Environment Architecture

The PPC405x3 is an implementation of the PowerPC embedded-environment architecture. This architecture is optimized for embedded controllers and is a forerunner to the PowerPC Book-E architecture. The PowerPC embedded-environment architecture provides an alternative deﬁnition for certain features speciﬁed by the PowerPC VEA and OEA. Implementations that adhere to the PowerPC embedded-environment architecture also adhere to the PowerPC UISA. PowerPC embedded-environment processors are 32-bit only implementations and thus do not include the special 64-bit extensions to the PowerPC UISA. Also, ﬂoating-point support can be provided either in hardware or software by PowerPC embedded-environment processors.

The following are features of the PowerPC embedded-environment architecture:

• Memory management optimized for embedded software environments.

• Cache-management instructions for optimizing performance and memory control in complex applications that are graphically and numerically intensive.

• Storage attributes for controlling memory-system behavior.

• Special-purpose registers for controlling the use of debug resources, timer resources,

16 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

PowerPC Architecture

Virtual Environment

interrupts, real-mode storage attributes, memory-management facilities, and other architected processor resources.

• A device-control-register address space for managing on-chip peripherals such as memory controllers.

• A dual-level interrupt structure and interrupt-control instructions.

• Multiple timer resources.

• Debug resources that enable hardware-debug and software-debug functions such as instruction breakpoints, data breakpoints, and program single-stepping.

The virtual environment deﬁnes architectural features that enable application programs to create or modify code, to manage storage coherency, and to optimize memory-access performance. It deﬁnes the cache and memory models, the timekeeping resources from a user perspective, and resources that are accessible in user mode but are primarily used by system-library routines.The following summarizes the virtual-environment features of the PowerPC embedded-environment architecture:

• Storage model:

- Storage-control instructions as deﬁned in the PowerPC virtual-environment

architecture. These instructions are used to manage instruction caches and data caches, and for synchronizing and ordering instruction execution.

- Storage attributes for controlling memory-system behavior. These are: write-

through, cacheability, memory coherence (optional), guarded, and endian.

- Operand-placement requirements and their effect on performance.

• The time-base function as deﬁned by the PowerPC virtual-environment architecture, for user-mode read access to the 64-bit time base.

Operating Environment

The operating environment describes features of the architecture that enable operating systems to allocate and manage storage, to handle errors encountered by application programs, to support I/O devices, and to provide operating-system services. It speciﬁes the resources and mechanisms that require privileged access, including the memoryprotection and address-translation mechanisms, the exception-handling model, and privileged timer resources. Table 1-2 summarizes the operating-environment features of the PowerPC embedded-environment architecture.

PowerPC 405 Processor Block Reference Guide www.xilinx.com 17

EDK 6.1 October 6, 2003 1-800-255-7778

Chapter 1: Introduction to the PowerPC®405 Processor

Table 1-2: OEA Features of the PowerPC Embedded-Environment Architecture

Operating

Environment

Storage model

Exception model

Debug model

Time-keeping model

Synchronization requirements

Resetandinitialization requirements

Features

• Privileged special-purpose registers (SPRs) and instructions for accessing those registers

• Device control registers (DCRs) and instructions for accessing those registers

• Privileged cache-management instructions

• Storage-attribute controls

• Address translation and memory protection

• Privileged TLB-management instructions

• Dual-level interrupt structure supporting various exception types

• Speciﬁcation of interrupt priorities and masking

• Privileged SPRs for controlling and handling exceptions

• Interrupt-control instructions

• Speciﬁcation of how partially executed instructions are handled when an interrupt occurs

• Privileged SPRs for controlling debug modes and debug events

• Speciﬁcation for seven types of debug events

• Speciﬁcation for allowing a debug event to cause a reset

• The ability of the debug mechanism to freeze the timer resources

• 64-bit time base

• 32-bit decrementer (the programmable-interval timer)

• Three timer-event interrupts:

- Programmable-interval timer (PIT)

- Fixed-interval timer (FIT)

- Watchdog timer (WDT)

• Privileged SPRs for controlling the timer resources

• The ability to freeze the timer resources using the debug mechanism

• Requirements for special registers and the TLB

• Requirements for instruction fetch and for data access

• Speciﬁcations for context synchronization and execution synchronization

• Speciﬁcation for two internal mechanisms that can cause a reset:

- Debug-control register (DBCR)

- Timer-control register (TCR)

• Contents of processor resources after a reset

• The software-initialization requirements, including an initialization code example

PPC405x3 Software Features

The PPC405x3 processor core is an implementation of the PowerPC embeddedenvironmentarchitecture. The processorprovidesﬁxed-point embedded applications with high performance at low power consumption. It is compatible with the PowerPC UISA.

18 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

PPC405x3 Software Features

Much of the PPC405x3 VEA and OEA support is also available in implementations of the PowerPC Book-E architecture. Key software features of the PPC405x3 include:

• A ﬁxed-point execution unit fully compliant with the PowerPC UISA:

- 32-bit architecture, containing thirty-two 32-bit general purpose registers (GPRs).

• PowerPC embedded-environment architecture extensions providing additional support for embedded-systems applications:

- True little-endian operation

- Flexible memory management

- Multiply-accumulate instructions for computationally intensive applications

- Enhanced debug capabilities

- 64-bit time base

- 3 timers: programmable interval timer (PIT), ﬁxed interval timer (FIT), and

• Performance-enhancing features, including:

- Static branch prediction

- Five-stage pipeline with single-cycle execution of most instructions, including

- Multiply-accumulate instructions

- Hardware multiply/divide for faster integer arithmetic (4-cycle multiply,35-cycle

- Enhanced string and multiple-word handling

- Support for unaligned loads and unaligned stores to cache arrays, main memory,

- Minimized interrupt latency

• Integrated instruction-cache:

- 16 KB, 2-way set associative

- Eight words (32 bytes) per cache line

- Fetch line buffer

- Instruction-fetch hits are supplied from the fetch line buffer

- Programmable prefetch of next-sequential line into the fetch line buffer

- Programmable prefetch of non-cacheable instructions: full line (eight words) or

- Non-blocking during fetch line ﬁlls

• Integrated data-cache:

- 16 KB, 2-way set associative

- Eight words (32 bytes) per cache line

- Read and write line buffers

- Load and store hits are supplied from/to the line buffers

- Write-back and write-through support

- Programmable load and store cache line allocation

- Operand forwarding during cache line ﬁlls

- Non-blocking during cache line ﬁlls and ﬂushes

• Support for on-chip memory (OCM) that can provide memory-access performance identical to a cache hit

watchdog timer (all are synchronous with the time base)

loads and stores

divide)

and on-chip memory (OCM)

half line (four words)

PowerPC 405 Processor Block Reference Guide www.xilinx.com 19

EDK 6.1 October 6, 2003 1-800-255-7778

• Flexible memory management:

- Translation of the 4 GB logical-address space into the physical-address space

- Independent control over instruction translation and protection, and data

translation and protection

- Page-level access control using the translation mechanism

- Software control over the page-replacement strategy

- Write-through, cacheability, user-deﬁned 0, guarded, and endian (WIU0GE)

storage-attribute control for each virtual-memory region

- WIU0GE storage-attribute control for thirty-two 128 MB regions in real mode

- Additional protection control using zones

• Enhanced debug support with logical operators:

- Four instruction-address compares

- Two data-address compares

- Two data-value compares

- JTAG instruction for writing into the instruction cache

- Forward and backward instruction tracing

• Advanced power management support

Chapter 1: Introduction to the PowerPC®405 Processor

The following sections describe the software resources available in the PPC405x3. Refer to the PowerPC Processor Reference Guide for more information on using these resources.

Privilege Modes

Softwarerunningonthe PPC405x3 can do so in one of two privilege modes: privileged and user.

Privileged Mode

Privileged mode allows programs to access all registers and execute all instructions supported by the processor. Normally, the operating system and low-level device drivers operate in this mode.

User Mode

User mode restricts access to some registers and instructions. Normally, application programs operate in this mode.

Address Translation Modes

The PPC405x3 also supports two modes of address translation: real and virtual.

Real Mode

In real mode, programs address physical memory directly.

Virtual Mode

In virtual mode, programs address virtual memory and virtual-memory addresses are translated by the processor into physical-memory addresses. This allows programs to access much larger address spaces than might be implemented in the system.

20 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

PPC405x3 Software Features

Addressing Modes

Whether the PPC405x3 is running in real mode or virtual mode, data addressing is supported by the load and store instructions using one of the following addressing modes:

• Register-indirect with immediate index—A base address is stored in a register, and a displacement from the base address is speciﬁed as an immediate value in the instruction.

• Register-indirect with index—A base address is stored in a register, and a displacement from the base address is stored in a second register.

• Register indirect—The data address is stored in a register.

Instructionsthat use the two indexed forms of addressing also allow for automatic updates to the base-address register. With these instruction forms, the new data address is calculated, used in the load or store data access, and stored in the base-address register.

Withsequential instruction execution, the next-instruction address is calculated by adding four bytes to the current-instruction address. In the case of branch instructions, the nextinstruction address is determined using one of four branch-addressing modes:

• Branch to relative—The next-instruction address is at a location relative to the current-instruction address.

• Branch to absolute—The next-instruction address is at an absolute location in memory.

• Branch to link register—The next-instruction address is stored in the link register.

• Branch to count register—The next-instruction address is stored in the count register.

Data Types

PPC405x3 instructions support byte, halfword, and word operands. Multiple-word operands are supported by the load/store multiple instructions and byte strings are supported by the load/store string instructions. Integer data are either signed or unsigned, and signed data is represented using two’s-complement format.

The address of a multi-byte operand is determined using the lowest memory address occupied by that operand. For example, if the four bytes in a word operand occupy addresses 4, 5, 6, and 7, the word address is 4. The PPC405x3 supports both big-endian (an operand’s most signiﬁcant byte is at the lowest memory address) and little-endian (an operand’s least signiﬁcant byte is at the lowest memory address) addressing.

Register Set Summary

Figure 1-1 shows the registers contained in the PPC405x3. Descriptions of the registers are

in the following sections.

PowerPC 405 Processor Block Reference Guide www.xilinx.com 21

EDK 6.1 October 6, 2003 1-800-255-7778

Chapter 1: Introduction to the PowerPC®405 Processor

User Registers

General-Purpose Registers

r0 r1

. . .

r31

Condition Register

Fixed-Point Exception Register

XER

Link Register

Count Register

CTR

User-SPR General-Purpose

Registers

USPRG0

SPR General-Purpose

Registers

Time-Base Registers

(read only)

SPRG4 SPRG5 SPRG6 SPRG7

(read only)

TBU

TBL

Privileged Registers

Machine-State Register

MSR

Core-Configuration Register

CCR0

SPR General-Purpose

Registers

SPRG0 SPRG1 SPRG2 SPRG3 SPRG4 SPRG5 SPRG6 SPRG7

Exception-Handling Registers

EVPR

ESR DEAR SRR0 SRR1 SRR2 SRR3

Memory-Management

Registers

PID

ZPR

Storage-Attribute Control

Registers

DCCR

DCWR

ICCR

SGR SLER SU0R

Debug Registers

DBSR DBCR0 DBCR1

DAC1 DAC2 DVC1 DVC2

IAC1 IAC2 IAC3 IAC4

ICDBR

Timer Registers

TCR

TSR

PIT

Processor-Version Register

PVR

Time-Base Registers

TBU

TBL

UG018_36_102401

Figure 1-1: PPC405x3 Registers

General-Purpose Registers

The processor contains thirty-two 32-bit general-purpose registers (GPRs), identiﬁed as r0 through r31. The contents of the GPRs are read from memory using load instructions and written to memory using store instructions. Computational instructions often read

22 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

PPC405x3 Hardware Organization

operands from the GPRs and write their results in GPRs. Other instructions move data between the GPRs and other registers. GPRs can be accessed by all software.

Special-Purpose Registers

The processor contains a number of 32-bit special-purpose registers (SPRs). SPRs provide access to additional processor resources, such as the count register,the link register, debug resources, timers, interrupt registers, and others. Most SPRs are accessed only by privileged software, but a few, such as the count register and link register, are accessed by all software.

Machine-State Register

The 32-bit machine-state register (MSR) contains ﬁelds that control the operating state of the processor. This register can be accessed only by privileged software.

Condition Register

The 32-bit condition register (CR) contains eight 4-bit ﬁelds, CR0–CR7. The values in the CR ﬁelds can be used to control conditional branching. Arithmetic instructions can set CR0 and compare instructions can set any CR ﬁeld. Additional instructions are provided to perform logical operations and tests on CR ﬁelds and bits within the ﬁelds. The CR can be accessed by all software.

Device Control Registers

The 32-bit device control registers (not shown) are used to conﬁgure, control, and report status for various external devices that are not part of the PPC405x3 processor. The OCM controllers are examples of devices that contain DCRs. Although the DCRs are not part of the PPC405x3 implementation, they are accessed using the mtdcr and mfdcr instructions. The DCRs can be accessed only by privileged software.

PPC405x3 Hardware Organization

As shown in Figure 1-2, the PPC405x3 processor contains the following elements:

• A 5-stage pipeline consisting of fetch, decode, execute, write-back, and load writeback stages

• A virtual-memory-management unit that supports multiple page sizes and a variety of storage-protection attributes and access-control options

• Separate instruction-cache and data-cache units

• Debug support, including a JTAG interface

• Three programmable timers

The following sections provide an overview of each element. Refer to the PowerPC

Processor Reference Guide for more information on how software interacts with these

elements.

PowerPC 405 Processor Block Reference Guide www.xilinx.com 23

EDK 6.1 October 6, 2003 1-800-255-7778

Chapter 1: Introduction to the PowerPC®405 Processor

PLB Master

Read Interface

I-Cache

Array

Instruction-Cache

I-Cache

Controller

Unit

Cache Units

Data-Cache

Unit

D-Cache

Array

D-Cache

Controller

Instruction

OCM

Instruction

Shadow-TLB

(4-Entry)

Unified TLB

(64-Entry)

Data

Shadow-TLB

(8-Entry)

Fetch

and

Decode

Logic

32x32

GPR

CPUMMU

3-Element

Fetch Queue

Execute Unit

ALU MAC

Timers

and

Debug

Logic

PLB Master

Read Interface

Central-Processing Unit

PLB Master

Write Interface

Data

OCM

External-Interrupt

Controller Interface

JTAG

Instruction

Figure 1-2: PPC405x3 Organization

The PPC405x3 central-processing unit (CPU) implements a 5-stage instruction pipeline consisting of fetch, decode, execute, write-back, and load write-back stages.

The fetch and decode logic sends a steady ﬂow of instructions to the execute unit. All instructions are decoded before they are forwarded to the execute unit. Instructions are queued in the fetch queue if execution stalls. The fetch queue consists of three elements: two prefetch buffers and a decode buffer. If the prefetch buffers are empty instructions ﬂow directly to the decode buffer.

Up to two branches are processedsimultaneously by the fetch and decode logic. If a branch cannot be resolved prior to execution, the fetch and decode logic predicts how that branch is resolved, causing the processor to speculatively fetch instructions from the predicted path. Branches with negative-address displacements are predicted as taken, as are branches that do not test the condition register or count register.The default prediction can be overridden by software at assembly or compile time.

The PPC405x3 has a single-issue execute unit containing the general-purpose register ﬁle (GPR), arithmetic-logic unit (ALU), and the multiply-accumulate unit (MAC). The GPRs consist of thirty-two 32-bit registers that are accessed by the execute unit using three read ports and two write ports. During the decode stage, data is read out of the GPRs for use by the execute unit. During the write-back stage, results are written to the GPR. The use of ﬁve

Trace

UG018_35_102401

24 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

PPC405x3 Hardware Organization

read/write ports on the GPRs allows the processor to execute load/store operations in parallel with ALU and MAC operations.

The execute unit supports all 32-bit PowerPC UISA integer instructions in hardware, and is compliant with the PowerPC embedded-environment architecture speciﬁcation. Floating-point operations are not supported.

The MAC unit supports implementation-speciﬁc multiply-accumulate instructions and multiply-halfword instructions. MAC instructions operate on either signed or unsigned 16-bit operands, and they store their results in a 32-bit GPR. These instructions can produce results using either modulo arithmetic or saturating arithmetic. All MAC instructions have a single cycle throughput.

Exception Handling Logic

Exceptions are divided into two classes: critical and noncritical. The PPC405x3 CPU services exceptions caused by error conditions, the internal timers, debug events, and the external interrupt controller (EIC) interface. Across the two classes, a total of 19 possible exceptions are supported, including the two provided by the EIC interface.

Each exception class has its own pair of save/restore registers. SRR0 and SRR1 are used for noncritical interrupts, and SRR2 and SRR3 are used for critical interrupts. The exceptionreturn address and the machine state are written to these registers when an exception occurs, and they are automatically restored when an interrupt handler exits using the return-from-interrupt (rﬁ) or return-from critical-interrupt (rfci) instruction. Use of separate save/restore registers allows the PPC405x3 to handle critical interrupts independently of noncritical interrupts.

Memory Management Unit

The PPC405x3 supports 4 GB of ﬂat (non-segmented) address space. The memorymanagement unit (MMU) provides address translation, protection functions, and storageattribute control for this address space. The MMU supports demand-paged virtual memory using multiple page sizes of 1 KB, 4 KB, 16 KB, 64 KB, 256 KB, 1 MB, 4 MB and 16 MB. Multiple page sizes can improve memory efﬁciency and minimize the number of TLB misses. When supported by system software, the MMU provides the following functions:

• Translation of the 4 GB logical-address space into a physical-address space.

• Independent enabling of instruction translation and protection from that of data translation and protection.

• Page-level access control using the translation mechanism.

• Software control over the page-replacement strategy.

• Additional protection control using zones.

• Storage attributes for cache policy and speculative memory-access control.

The translation look-aside buffer (TLB) is used to control memory translation and protection. Each one of its 64 entries speciﬁes a page translation. It is fully associative, and can simultaneously hold translations for any combination of page sizes. To prevent TLB contention between data and instruction accesses, a 4-entry instruction and an 8-entry data shadow-TLB are maintained by the processor transparently to software.

Software manages the initialization and replacement of TLB entries. The PPC405x3 includes instructions for managing TLB entries by software running in privileged mode. This capability gives signiﬁcant control to system software over the implementation of a page replacement strategy. For example, software can reduce the potential for TLB

PowerPC 405 Processor Block Reference Guide www.xilinx.com 25

EDK 6.1 October 6, 2003 1-800-255-7778

thrashing or delays associated with TLB-entry replacement by reserving a subset of TLB entries for globally accessible pages or critical pages.

Storage attributes are provided to control access of memory regions. When memory translation is enabled, storage attributes are maintained on a page basis and read from the TLB when a memory access occurs. When memory translation is disabled, storage attributes are maintained in storage-attribute control registers. A zone-protection register (ZPR) is provided to allow system software to override the TLB access controls without requiring the manipulation of individual TLB entries. For example, the ZPR can provide a simple method for denying read access to certain application programs.

Instruction and Data Caches

The PPC405x3 accesses memory through the instruction-cache unit (ICU) and data-cache unit (DCU). Each cache unit includes a PLB-master interface, cache arrays, and a cache controller. Hits into the instruction cache and data cache appear to the CPU as single-cycle memory accesses. Cache misses are handled as requests over the PLB bus to another PLB device, such as an external-memory controller.

The PPC405x3 implements separate instruction-cache and data-cache arrays. Each is 16 KB in size, is two-way set-associative, and operates using 8 word (32 byte) cache lines. The caches are non-blocking, allowing the PPC405x3 to overlap instruction execution with reads over the PLB (when cache misses occur).

Chapter 1: Introduction to the PowerPC®405 Processor

The cache controllers replace cache lines according to a least-recently used (LRU) replacement policy. When a cache line ﬁll occurs, the most-recently accessed line in the cache set is retained and the other line is replaced. The cache controller updates the LRU during a cache line ﬁll.

The ICU supplies up to two instructions every cycle to the fetch and decode unit. The ICU can also forward instructions to the fetch and decode unit during a cache line ﬁll, minimizing execution stalls caused by instruction-cache misses. When the ICU is accessed, four instructions are read from the appropriate cache line and placed temporarily in a line buffer. Subsequent ICU accesses check this line buffer for the requested instruction prior to accessing the cache array. This allows the ICU cache array to be accessed as little as once every four instructions, signiﬁcantly reducing ICU power consumption.

The DCU can independently process load/store operations and cache-control instructions. The DCU can also dynamically reprioritize PLB requests to reduce the length of an execution stall. For example, if the DCU is busy with a low-priority request and a subsequent storage operation requested by the CPU is stalled, the DCU automatically increases the priority of the current (low-priority) request. The current request is thus ﬁnished sooner, allowing the DCU to process the stalled request sooner. The DCU can forwarddatatothe execute unit during a cache line ﬁll, further minimizing execution stalls caused by data-cache misses.

Additional features allow programmers to tailor data-cache performance to a speciﬁc application. The DCU can function in write-back or write-through mode, as determined by the storage-control attributes. Loads and stores that do not allocate cache lines can also be speciﬁed. Inhibiting certain cache line ﬁlls can reduce potential pipeline stalls and unwanted external-bus trafﬁc.

Timer Resources

The PPC405x3 contains a 64-bit time base and three timers. The time base is incremented synchronously using the CPU clock or an external clock source. The three timers are

26 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

PPC405x3 Hardware Organization

incremented synchronously with the time base. The three timers supported by the PPC405x3 are:

• Programmable Interval Timer

• Fixed Interval Timer

• Watchdog Timer

Programmable Interval Timer

The programmable interval timer (PIT) is a 32-bit register that is decremented at the time-base increment frequency. The PIT register is loaded with a delay value. When the PIT count reaches 0, a PIT interrupt occurs. Optionally, the PIT can be programmed to automatically reload the last delay value and begin decrementing again.

Fixed Interval Timer

The ﬁxed interval timer (FIT) causes an interrupt when a selected bit in the time-base register changes from 0 to 1. Programmers can select one of four predeﬁned bits in the time-base for triggering a FIT interrupt.

Watchdog Timer

The watchdog timer causes a hardware reset when a selected bit in the time-base register changes from 0 to 1. Programmers can select one of four predeﬁned bits in the time-base for triggering a reset, and the type of reset can be deﬁned by the programmer.

Debug

The PPC405x3 debug resources include special debug modes that support the various types of debugging used during hardware and software development. These are:

• Internal-debug mode for use by ROM monitors and software debuggers

• External-debug mode for use by JTAG debuggers

• Debug-wait mode, which allows the servicing of interrupts while the processor appears to be stopped

• Real-time trace mode, which supports event triggering for real-time tracing

Debug events are supported that allow developers to manage the debug process. Debug modes and debug events are controlled using debug registers in the processor. The debug registers are accessed either through software running on the processor or through the JTAG port.

The debug modes, events, controls, and interfaces provide a powerful combination of debug resources for hardware and software development tools.

PPC405x3 Interfaces

The PPC405x3 provides the following set of interfaces that support the attachment of cores and user logic:

• Processor local bus interface

• Device control register interface

• Clock and power management interface

• JTAG port interface

• On-chip interrupt controller interface

• On-chip memory controller interface

PowerPC 405 Processor Block Reference Guide www.xilinx.com 27

EDK 6.1 October 6, 2003 1-800-255-7778

Processor Local Bus

The processor local bus (PLB) interface provides a 32-bit address and three 64-bit data buses attached to the instruction-cache and data-cache units. Twoof the 64-bit buses are attached to the data-cache unit, one supporting read operations and the other supporting write operations. The third 64-bit bus is attached to the instruction-cache unit to support instruction fetching.

Device Control Register

The device control register (DCR) bus interface supports the attachment of on-chip registers for device control. Software can access these registers using the mfdcr and mtdcr instructions.

Clock and Power Management

The clock and power-management interface supports several methods of clock distribution and power management.

JTAG Port

The JTAG port interface supports the attachment of external debug tools. Using the JTAG test-access port, a debug tool can single-step the processor and examine internal-processor state to facilitate software debugging.

Chapter 1: Introduction to the PowerPC®405 Processor

On-Chip Interrupt Controller

The on-chip interrupt controller interface is an external interrupt controller that combines asynchronous interrupt inputs from on-chip and off-chip sources and presents them to the core using a pair of interrupt signals (critical and noncritical). Asynchronous interrupt sources can include external signals, the JTAG and debug units, and any other on-chip peripherals.

On-Chip Memory Controller

An on-chip memory (OCM) interface supports the attachment of additional memory to the instruction and data caches that can be accessed at performance levels matching the cache arrays.

PPC405x3 Performance

The PPC405x3 executes instructions at sustained speeds approaching one cycle per instruction. Table 1-3 lists the typical execution speed (in processor cycles) of the instruction classes supported by the PPC405x3.

Instructions that access memory (loads and stores) consider only the “ﬁrst order” effects of cache misses. The performance penalty associated with a cache miss involves a number of second-order effects. This includes PLB contention between the instruction and data caches and the time associated with performing cache-line ﬁlls and ﬂushes. Unless stated otherwise, the number of cycles described applies to systems having zero-wait-state memory access.

28 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

PPC405x3 Performance

Table 1-3: PPC405x3 Cycles per Instruction

Instruction Class Execution Cycles

Arithmetic 1 Trap 2 Logical 1 Shift and Rotate 1 Multiply (32-bit, 48-bit, 64-bit results, respectively) 1, 2, 4 Multiply Accumulate 1 Divide 35 Load 1 Load Multiple and Load String (cache hit) 1 per data transfer Store 1 Store Multiple and Store String (cache hit or miss) 1 per data transfer Move to/from device-control register 3 Move to/from special-purpose register 1 Branch known taken 1 or 2 Branch known not taken 1 Predicted taken branch 1 or 2 Predicted not-taken branch 1 Mispredicted branch 2 or 3

PowerPC 405 Processor Block Reference Guide www.xilinx.com 29

EDK 6.1 October 6, 2003 1-800-255-7778

Chapter 1: Introduction to the PowerPC®405 Processor

30 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Input/Output Interfaces

The processor block (PPC405x3, OCM controllers, and gasket logic) provides input/output (I/O) signals that are grouped functionally into the following interfaces:

• Clock and Power Management Interface, page 33

• CPU Control Interface, page 37

• Reset Interface, page 39

• Instruction-Side Processor Local Bus Interface, page 43

• Data-Side Processor Local Bus Interface, page 66

• Device-Control Register Interface, page 96

• External Interrupt Controller Interface, page 107

• Virtex-II Pro PPC405 JTAG Debug Port, page 109

• Debug Interface, page 125

• Trace Interface, page 128

Chapter 2

Each section within this chapter provides the following information:

• An overview summarizing the purpose of the interface.

• An I/O symbol providing a quick view of the signal names and the direction of information ﬂow with respect to the processor block.

• A signal table that summarizes the function of each signal. The I/O column in these tables speciﬁes the direction of information ﬂow with respect to the processor block.

• Detailed descriptions for each signal.

Detailed timing diagrams (where appropriate) that more clearly describe the operation of the interface. The diagrams typically illustrate best-case performance when the core is attached to the FPGA processor local bus (PLB) core, or to custom bus interface unit (BIU) designs.

The instruction-side and data-side OCM controller interfaces are described separately in

Chapter 3, PowerPC Appendix B, Signal Summary, alphabetically lists the signals described in this chapter.

The l/O designation and a description summary are included for each signal.

405 OCM Controller.

PowerPC 405 Processor Block Reference Guide www.xilinx.com 31

EDK 6.1 October 6, 2003 1-800-255-7778

Signal Naming Conventions

The following convention is used for signal names throughout this document:

PREFIX1PREFIX2SIGNAME1[SIGNAME1][NEG][(m:n)]

The components of a signal name are as follows:

• PREFIX1 is an uppercase preﬁx identifying the source of the signal. This preﬁx speciﬁes either a unit (for example, CPU) or a type of interface (for example, DCR). If PREFIX1 speciﬁes the processor block, the signal is considered an output signal. Otherwise, it is an input signal.

• PREFIX2 is an uppercase preﬁx identifying the destination of the signal. This preﬁx speciﬁes either a unit (for example, CPU) or a type of interface (for example, DCR). If PREFIX2 speciﬁes the processor block, the signal is considered an input signal. Otherwise, it is an output signal.

• SIGNAME1 is an uppercase name identifying the primary function of the signal.

• [NEG] is an optional notation that indicates a signal is active low.If this notation is not use, the signal is active high.

• [m:n] is an optional notation that indicates a bussed signal. “m” designates the mostsigniﬁcant bit of the bus and “n” designates the least-signiﬁcant bit of the bus.

Chapter 2: Input/Output Interfaces

Table 2-1 deﬁnes the preﬁxes used in the signal names. The last column in the table

identiﬁes whether the functional unit resides inside the processor block or outside the processor block.

Table 2-1: Signal Name Preﬁx Deﬁnitions

Preﬁx1 or Preﬁx2 Deﬁnition Location

CPM Clock and power management Outside C405

DBG Debug unit Inside DCR Device control register Outside DSOCM Data-side on-chip memory (DSOCM) Outside EIC External interrupt controller Outside ISOCM Instruction-side on-chip memory (ISOCM) Outside JTG JTAG Inside PLB Processor local bus Inside RST Reset Inside TIE TIE (signal tied statically to GND or VDD) Outside

Processor block

Inside

(1)

TRC Trace Inside XXX Unspeciﬁed FPGA unit Outside

Notes:

1. OCM controllers are located in the Processor Block.

32 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Clock and Power Management Interface

The clock and power management (CPM) interface enables power-sensitive applications to control the processor clock using external logic. The OCM controllers are clocked separately from the processor. Two types of processor clock control are possible:

• Global local enables control a clock zone within the processor. These signals are used to disable the clock splitters within a zone so that the clock signal is prevented from propagating to the latches within the zone. The PPC405x3 is divided into three clock zones: core, timer, and JTAG. Control over a zone is exercised as follows:

- The core clock zone contains most of the logic comprising the PPC405x3. It does

not contain logic that belongs to the timer or JTAG zones, or other logic within the processor block. The core zone is controlled by the CPMC405CPUCLKEN signal.

- The timer clock zone contains the PPC405x3 timer logic. It does not contain logic

that belongs to the core or JTAG zones, or other logic within the processor block. This zone is separated from the core zone so that timer events can be used to “wake up” the core logic if a power management application has put it to sleep. The timer zone is controlled by the CPMC405TIMERCLKEN signal.

- The JTAG clock zone contains the PPC405x3 JTAG logic. It does not contain logic

that belongs to the core or timer zones, or other logic within the processor block. The JTAG zone is controlled by the CPMC405JTAGCLKEN signal. Although an enable is provided for this zone, the JTAG standard does not allow local gating of the JTAG clock. This enables basic JTAG functions to be maintained when the rest of the chip (including the CPM FPGA macro) is not running.

• Global gating controls the toggling of the PPC405x3 clock, CPMC405CLOCK. Instead of using the global-local enables to prevent the clock signal from propagating through a zone, CPM logic can stop the PPC405x3 clock input from toggling. If this method of power management is employed, the clock signal should be held active (logic 1). The CPMC405CLOCK is used by the core and timer zones, but not the JTAG zone.

CPM logic should be designed to wake the PPC405x3 from sleep mode when any of the following occurs:

- A timer interrupt or timer reset is asserted by the PPC405x3.

- A chip-reset or system-reset request is asserted (this request comes from a source

other than the PPC405x3).

- An external interrupt or critical interrupt input is asserted and the corresponding

interrupt is enabled by the appropriate machine-state register (MSR) bit.

- The DBGC405DEBUGHALT chip-input signal (if provided) is asserted. Assertion

of this signal indicates that an external debug tool wants to control the PPC405x3 processor. See page 126 for more information.

CPM Interface I/O Signal Summary

Figure 2-1 shows the block symbol for the CPM interface. The signals are summarized in Table 2-2.

PowerPC 405 Processor Block Reference Guide www.xilinx.com 33

EDK 6.1 October 6, 2003 1-800-255-7778

Chapter 2: Input/Output Interfaces

CPMC405CLOCK

CPMC405CPUCLKEN

CPMC405TIMERCLKEN

CPMC405JTAGCLKEN

CPMC405CORECLKINACTIVE

CPMC405TIMERTICK

PPC405

C405CPMMSREE C405CPMMSRCE C405CPMTIMERIRQ C405CPMTIMERRESETREQ C405CPMCORESLEEPREQ

UG018_01_102001

Figure 2-1: CPM Interface Block Symbol

Table 2-2: CPM Interface I/O Signals

Signal

CPMC405CLOCK I Required PPC405x3 clock input (for all non-JTAG logic, including

CPMC405CPUCLKEN I 1 Enables the core clock zone. CPMC405TIMERCLKEN I 1 Enables the timer clock zone. CPMC405JTAGCLKEN I 1 Enables the JTAG clock zone. CPMC405CORECLKINACTIVE I 0 Indicates the CPM logic disabled the clocks to the core. CPMC405TIMERTICK I 1 Increments or decrements the PPC405x3 timers every time

I/O

Type

If Unused Function

timers).

it is active with the CPMC405CLOCK. C405CPMMSREE O No Connect Indicates the value of MSR[EE]. C405CPMMSRCE O No Connect Indicates the value of MSR[CE]. C405CPMTIMERIRQ O No Connect Indicates a timer-interrupt request occurred. C405CPMTIMERRESETREQ O No Connect Indicates a watchdog-timer reset request occurred. C405CPMCORESLEEPREQ O No Connect Indicates the core is requesting to be put into sleep mode.

CPM Interface I/O Signal Descriptions

The following sections describe the operation of the CPM interface I/O signals.

CPMC405CLOCK (input)

This signal is the source clock for all PPC405x3 logic (including timers). It is not the source clock for the JTAG logic. External logic can implement a power management mode that stops toggling of this signal. If such a method is employed, the clock signal should be held active (logic 1).

CPMC405CPUCLKEN (input)

Enables the core clock zone when asserted and disables the zone when deasserted. If logic is not implemented to control this signal, it must be held active (tied to 1).

CPMC405TIMERCLKEN (input)

Enables the timer clock zone when asserted and disables the zone when deasserted. If logic is not implemented to control this signal, it must be held active (tied to 1).

34 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Clock and Power Management Interface

CPMC405JTAGCLKEN (input)

Enables the JTAG clock zone when asserted and disables the zone when deasserted. CPM logic should not control this signal. The JTAG standard requires that it be held active (tied to 1).

CPMC405CORECLKINACTIVE (input)

This signal is a status indicator that is latched by an internal PPC405x3 register (JDSR). An external debug tool (such as RISCWatch) can read this register and determine that the PPC405x3 is in sleep mode. This signal should be asserted by the CPM when it places the PPC405x3 in sleep mode using either of the following methods:

• Deasserting CPMC405CPUCLKEN to disable the core clock zone.

• Stopping CPMC405CLOCK from toggling by holding it active (logic 1).

CPMC405TIMERTICK (input)

This signal is used to control the update frequency of the PPC405x3 time base and PIT (the FIT and WDT are timer events triggered by the time base). The time base is incremented and the PIT is decremented every cycle that CPMC405TIMERTICK and CPMC405CLOCK are both active. CPMC405TIMERTICK should be synchronous with CPMC405CLOCK for the timers to operate predictably. The timers are updated at the PPC405x3 clock frequency if CPMC405TIMERTICK is held active.

C405CPMMSREE (output)

This signal indicates the state of the MSR[EE] (external-interrupt enable) bit. When asserted, external interrupts are enabled (MSR[EE]=1). When deasserted, external interrupts are disabled (MSR[EE]=0). The CPM can use this signal to wake the processor from sleep mode when an external noncritical interrupt occurs.

When the processor wakes up, it deasserts the C405CPMMSREE, C405CPMMSRCE, and C405CPMTIMERIRQ signals one processor clock cycle before it deasserts the C405CPMCORESLEEPREQ signal. For this reason, the CPM should latch the C405CPMMSREE, C405CPMMSRCE, and C405CPMTIMERIRQ signals before using them to control the processor clocks.

C405CPMMSRCE (output)

This signal indicates the state of the MSR[CE] (critical-interrupt enable) bit. When asserted, critical interrupts are enabled (MSR[CE]=1). When deasserted, critical interrupts are disabled (MSR[CE]=0). The CPM can use this signal to wake the processor from sleep mode when an external critical interrupt occurs.

C405CPMTIMERIRQ (output)

When asserted, this signal indicates a timer exception occurred within the PPC405x3 and an interrupt request is pending to handle the exception. When deasserted, no timerinterrupt request is pending. This signal is the logical OR of interrupt requests from the programmable-interval timer (PIT), the ﬁxed-interval timer (FIT), and the watchdog timer

PowerPC 405 Processor Block Reference Guide www.xilinx.com 35

EDK 6.1 October 6, 2003 1-800-255-7778

(WDT). The CPM can use this signal to wake the processor from sleep mode when an internal timer exception occurs.

C405CPMTIMERRESETREQ (output)

When asserted, this signal indicates a watchdog time-out occurred and a reset request is pending. When deasserted, no reset request is pending. This signal is the logical OR of the core, chip, and system reset modes that are programmed using the watchdog timer mechanism. The CPM can use this signal to wake the processor from sleep mode when a watchdog time-out occurs.

C405CPMCORESLEEPREQ (output)

When asserted, this signal indicates the PPC405x3 has requested to be put into sleep mode. When deasserted, no request exists. This signal is asserted after software enables the wait state by setting the MSR[WE] (wait-state enable) bit to 1. The processor completes execution of all prior instructions and memory accesses before asserting this signal. The CPM can use this signal to place the processor in sleep mode at the request of software.

Chapter 2: Input/Output Interfaces

When the processor gets out of sleep mode at a later time, it deasserts the C405CPMMSREE, C405CPMMSRCE, and C405CPMTIMERIRQ signals one processor clock cycle before it deasserts the C405CPMCORESLEEPREQ signal. For this reason, the CPM should latch the C405CPMMSREE, C405CPMMSRCE, and C405CPMTIMERIRQ signals before using them to control the processor clocks.

36 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

CPU Control Interface

The CPU control interface is used primarily to provide CPU setup information to the PPC405x3. It is also used to report the detection of a machine check condition within the PPC405x3.

CPU Control Interface I/O Signal Summary

Figure 2-2 shows the block symbol for the CPU control interface. The signals are

summarized in Table 2-3.

TIEC405MMUEN

TIEC405DETERMINISTICMULT

TIEC405DISOPERANDFWD

PPC405

C405XXXMACHINECHECK

UG018_02_102001

Figure 2-2: CPU Control Interface Block Symbol

Table 2-3: CPU Control Interface I/O Signals

Signal

TIEC405MMUEN I Required Enables the memory-management unit (MMU) TIEC405DETERMINISTICMULT I Required Speciﬁes whether all multiply operations complete in a

TIEC405DISOPERANDFWD I Required Disables operand forwarding for load instructions C405XXXMACHINECHECK O No Connect Indicates a machine-check error has been detected by the

I/O

Type

If Unused Function

ﬁxed number of cycles or have an early-out capability

PPC405x3

CPU Control Interface I/O Signal Descriptions

The following sections describe the operation of the CPU control-interface I/O signals.

TIEC405MMUEN (input)

When held active (tied to logic 1), this signal enables the PPC405x3 memory-management unit (MMU). When held inactive (tied to logic 0), this signal disables the MMU. The MMU is used for virtual to address translation and for memory protection. Its operation is described in the PowerPC Processor Reference Guide. Disabling the MMU can improve the performance (clock frequency) of the PPC405x3.

TIEC405DETERMINISTICMULT (input)

When held active (tied to logic 1), this signal disables the hardware multiplier early-out capability. All multiply instructions have a 4-cycle reissue rate and a 5-cycle latency rate. When held inactive (tied to logic 0), this signal enables the hardware multiplier early-out capability. If early out is enabled, multiply instructions are executed in the number of cycles speciﬁed in Table 2-4. The performance of multiply instructions is described in the

PowerPC Processor Reference Guide.

PowerPC 405 Processor Block Reference Guide www.xilinx.com 37

EDK 6.1 October 6, 2003 1-800-255-7778

Chapter 2: Input/Output Interfaces

Table 2-4: Multiply and MAC Instruction Timing

Operations

MAC and Negative MAC 1 2 Halfword × Halfword (32-bit result) 1 2 Halfword × Word (48-bit result) 2 3 Word ×Word (64-bit result) 4 5

Notes:

For the purposes of this table, words are treated as halfwordsif the upper 16 bits of the operand contain asign extension of the lower 16 bits.For example, if the upper 16 bits ofa word operand are zero, the operand is considered a halfword when calculating execution time.

Issue-Rate

Cycles

TIEC405DISOPERANDFWD (input)

When held active (tied to logic 1), this signal disables operand forwarding. When held inactive (tied to logic 0), this signal enables operand forwarding. The processor uses operand forwarding to send load-instruction data from the data cache to the execution units as soon as it is available. Operand forwarding often saves a clock cycle when instructions following the load require the loaded data. Disabling operand forwarding can improve the performance (clock frequency) of the PPC405x3.

C405XXXMACHINECHECK (output)

When asserted, this signal indicates the PPC405x3 detected an instruction machine-check error. When deasserted, no error exists. This signal is asserted when the processor attempts to execute an instruction that was transferred to the PPC405x3 with the PLBC405ICUERR signal asserted. This signal remains asserted until software clears the instruction machinecheck bit in the exception-syndrome register (ESR[MCI]).

Latency

Cycles

38 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Reset Interface

A reset causes the processor block to perform a hardware initialization. It always occurs when the processor block is powered-up and can occur at any time during normal operation. If it occurs during normal operation, instruction execution is immediately halted and all processor state is lost.

The processor block recognizes three types of reset:

•Aprocessor reset affects the processor block only, including PPC405x3 execution units, cache units, and the on-chip memory controller (OCM). External devices (on-chip and off-chip) are not affected. This type of reset is also referred to as a core reset.

•Achip reset affects the processor block and all other devices or peripherals located on the same chip as the processor.

•Asystemreset affects the processor chip and all other devices or peripherals external to the processor chip that are connected to the same system-reset network. The scope of a system reset depends on the system implementation. Power-on reset (POR) is a form of system reset.

Input signals are provided to the processor block for each reset type. The signals are used to reset the processor block and to record the reset type in the debug-status register (DBSR[MRR]). The processor block can produce reset-request output signals for each reset type. External reset logic can process these output signals and generate the appropriate reset input signals to the processor block. Reset activity does not occur when the processor block requests the reset. Reset activity only occurs when external logic asserts the appropriate reset input signal.

Reset Requirements

FPGA logic (external to the processor block) is required to generate the reset input signals to the processor block. The reset input signals can be based on the reset-request output signals from the processor block, system-speciﬁc reset-request logic, or some combination of the two. Reset input signals must meet the following minimum requirements:

• The reset input signals must be synchronized with the PPC405x3 clock.

• The reset input signals must be asserted for at least eight clock cycles.

• Only the combinations of signals shown in Table 2-5 are used to cause a reset.

POR (power-on reset) is handled by logic within the processor block. This logic asserts the RSTC405RESETCORE, RSTC405RESETCHIP, RSTC405RESETSYS, and JTGC405TRSTNEG signals for at least eight clock cycles. FPGA designers cannot modify the processor block power-on reset mechanism.

The reset logic is not required to support all three types of reset. However, distinguishing resets by type can make it easier to isolate errors during system debug. For example, a system could reset the core to recover from an external error that affects software operation. Following the chip reset, a debugger could be used to locate the external error source which is preserved because neither a chip or system reset occurred.

Table 2-5 shows the valid combinations of reset signals and their effect on the DBSR[MRR]

ﬁeld following reset.

PowerPC 405 Processor Block Reference Guide www.xilinx.com 39

EDK 6.1 October 6, 2003 1-800-255-7778

Chapter 2: Input/Output Interfaces

Table 2-5: Valid Reset Signal Combinations and Effect on DBSR(MRR)

Reset Input Signal

None Core Chip System Power-On RSTC405RESETCORE Deassert Assert Assert Assert Assert RSTC405RESETCHIP Deassert Deassert Assert Assert Assert RSTC405RESETSYS Deassert Deassert Deassert Assert Assert JTGC405TRSTNEG Deassert Deassert Deassert Deassert Assert Value of DBSR[MRR]

following reset

DBSR[MRR]

Notes:

1. Handled automatically by logic within the

Reset Interface I/O Signal Summary

Figure 2-3 shows the block symbol for the reset interface. The signals are summarized in Table 2-6.

RSTC405RESETCORE

RSTC405RESETCHIP

RSTC405RESETSYS

JTGC405TRSTNEG

Reset Type

0b01 0b10 0b11 0b11

processor block.

PPC405

C405RSTCORERESETREQ C405RSTCHIPRESETREQ C405RSTSYSRESETREQ

UG018_03_102001

Figure 2-3: Reset Interface Block Symbol

Table 2-6: Reset Interface I/O Signals

Signal

C405RSTCORERESETREQ O Required Indicates a core-reset request occurred. C405RSTCHIPRESETREQ O Required Indicates a chip-reset request occurred. C405RSTSYSRESETREQ O Required Indicates a system-reset request occurred. RSTC405RESETCORE I Required Resets the

RSTC405RESETCHIP I Required Indicates a chip-reset occurred. RSTC405RESETSYS I Required Indicates a system-reset occurred. Resets the logic in the

JTGC405TRSTNEG I Required Performs a JTAG test reset (TRST).

I/O

Type

If Unused Function

processor block, including the PPC405x3 core

logic, data cache, instruction cache, and the on-chip memory controller (OCM).

PPC405x3 JTAG unit.

Reset Interface I/O Signal Descriptions

The following sections describe the operation of the reset interface I/O signals.

40 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Reset Interface

C405RSTCORERESETREQ (output)

When asserted, this signal indicates the processor block is requesting a core reset. If this signal is asserted, it remains active until two clock cycles after external logic asserts the RSTC405RESETCORE input to the processor block. When deasserted, no core-reset request exists. The processor asserts this signal when one of the following occurs:

• A JTAG debugger sets the reset ﬁeld in the debug-control register 0 (DBCR0[RST]) to 0b01.

• Software sets the reset ﬁeld in the debug-control register 0 (DBCR0[RST]) to 0b01.

• The timer-control register watchdog-reset control ﬁeld (TCR[WRC]) is set to 0b01 and a watchdog time-out causes the watchdog-event state machine to enter the reset state.

C405RSTCHIPRESETREQ (output)

When asserted, this signal indicates the processor block is requesting a chip reset. If this signal is asserted, it remains active until two clock cycles after external logic asserts the RSTC405RESETCHIP input to the processor block. When deasserted, no chip-reset request exists. The processor asserts this signal when one of the following occurs:

• A JTAG debugger sets the reset ﬁeld in the debug-control register 0 (DBCR0[RST]) to 0b10.

• Software sets the reset ﬁeld in the debug-control register 0 (DBCR0[RST]) to 0b10.

• The timer-control register watchdog-reset control ﬁeld (TCR[WRC]) is set to 0b10 and a watchdog time-out causes the watchdog-event state machine to enter the reset state.

C405RSTSYSRESETREQ (output)

When asserted, this signal indicates the processor block is requesting a system reset. If this signal is asserted, it remains active until two clock cycles after external logic asserts the RSTC405RESETSYS input to the processor block. When deasserted, no system-reset request exists. The processor asserts this signal when one of the following occurs:

• A JTAG debugger sets the reset ﬁeld in the debug-control register 0 (DBCR0[RST]) to 0b11.

• Software sets the reset ﬁeld in the debug-control register 0 (DBCR0[RST]) to 0b11.

• The timer-control register watchdog-reset control ﬁeld (TCR[WRC]) is set to 0b11 and a watchdog time-out causes the watchdog-event state machine to enter the reset state.

RSTC405RESETCORE (input)

External logic asserts this signal to reset the processor block (core). This includes the PPC405x3 core logic, data cache, instruction cache, and the on-chip memory controller (OCM). The PPC405x3 also uses this signal to record a core reset type in the DBSR[MRR] ﬁeld. This signal should be asserted for at least eight clock cycles to guarantee that the processor block initiates its reset sequence. No reset occurs and none is recorded in DBSR[MRR] when this signal is deasserted.

Table 2-5, page 40 shows the valid combinations of the RSTC405RESETCORE,

RSTC405RESETCHIP, and RSTC405RESETSYS signals and their effect on the DBSR[MRR] ﬁeld following reset.

RSTC405RESETCHIP (input)

External logic asserts this signal to reset the chip. A chip reset involves the FPGA logic, onchip peripherals, and the processor block (the PPC405x3 core logic, data cache, instruction cache, and the OCM). The signal does not reset logic in the processor block. The PPC405x3

PowerPC 405 Processor Block Reference Guide www.xilinx.com 41

EDK 6.1 October 6, 2003 1-800-255-7778

uses this signal only to record a chip reset type in the DBSR[MRR] ﬁeld. The RSTC405RESETCORE signal must be asserted with this signal to cause a core reset. Both signals must be asserted for at least eight clock cycles to guarantee that the processor block recognizes the reset type and initiates the core-reset sequence. The PPC405x3 does not record a chip reset type in DBSR[MRR] when this signal is deasserted.

Table 2-5, page 40 shows the valid combinations of the RSTC405RESETCORE,

RSTC405RESETCHIP, and RSTC405RESETSYS signals and their effect on the DBSR[MRR] ﬁeld following reset.

RSTC405RESETSYS (input)

External logic asserts this signal to reset the system. A system reset involves logic external to the FPGA, the FPGA logic, on-chip peripherals, and the processor block (the PPC405x3 core logic, data cache, instruction cache, and the OCM). This signal resets the logic in the PPC405x3 JTAG unit, but it does not reset any other processor block logic. The PPC405x3 uses this signal to record a system reset type in the DBSR[MRR] ﬁeld. The RSTC405RESETCORE signal must be asserted with this signal to cause a core reset. The RSTC405RESETCORE, RSTC405RESETCHIP, and RSTC405RESETSYS signals must be asserted for at least eight clock cycles to guarantee that the processor block recognizes the reset type and initiates the core-reset sequence. The PPC405x3 does not record a system reset type in DBSR[MRR] when this signal is deasserted.

Chapter 2: Input/Output Interfaces

This signal must be asserted during a power-on reset to properly initialize the JTAG unit.

Table 2-5, page 40 shows the valid combinations of the RSTC405RESETCORE,

RSTC405RESETCHIP, and RSTC405RESETSYS signals and their effect on the DBSR[MRR] ﬁeld following reset.

JTGC405TRSTNEG (input)

This input is the JTAG test reset (TRST) signal. It can be connected to the chip-level TRST signal. Although optional in IEEE Standard 1149.1, this signal is automatically used by the processorblockduringpower-onreset to properly reset all processor block logic, including the JTAG and debug logic. When deasserted, no JTAG test reset exists.

This is a negative active signal.

42 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Instruction-Side Processor Local Bus Interface

The instruction-side processor local bus (ISPLB) interface enables the PPC405x3 instruction cache unit (ICU) to fetch (read) instructions from any memory device connected to the processor local bus (PLB). The ICU cannot write to memory.This interface has a dedicated 30-bit address bus output and a dedicated 64-bit read-data bus input. The interface is designed to attach as a master to a 64-bit PLB, but it also supports attachment as a master to a 32-bit PLB. The interface is capable of one transfer (64 or 32 bits) every PLB cycle.

At the chip level, the ISPLB can be combined with the data-side read-data bus (also a PLB master) to create a shared read-data bus. This is done if a single PLB arbiter services both PLB masters and the PLB arbiter implementation only returns data to one PLB master at a time.

Refer to the PowerPC Processor Reference Guide for more information on the operation of the PPC405x3 ICU.

Instruction-Side PLB Operation

Fetch requests are produced by the ICU and communicated over the PLB interface. Fetch requests occur when an access misses the instruction cache or the memory location that is accessed is non-cacheable. A fetch request contains the following information:

• A fetch request is indicated by C405PLBICUREQUEST (page 47).

• The target address of the instruction to be fetched is speciﬁed by the address bus, C405PLBICUABUS[0:29] (page 48). Bits 30:31 of the 32-bit instruction-fetch address are always zero and must be tied to zero at the PLB arbiter. The ICU always requests an aligned doubleword of data, so the byte enables are not used.

• The transfer size is speciﬁed as four words (quadword) or eight words (cache line) using C405PLBICUSIZE[2:3] (page 48). The remaining bits of the transfer size (0:1) must be tied to zero at the PLB arbiter.

• The cacheability storage attribute is indicated by C405PLBICUCACHEABLE (page 48). Cacheable transfers are always performed with an eight-word transfer size.

• The user-deﬁned storage attribute is indicated by C405PLBICUU0ATTR (page 49).

• The request priority is indicated by C405PLBICUPRIORITY[0:1] (page 49). The PLB arbiter uses this information to prioritize simultaneous requests from multiple PLB masters.

The processor can abort a PLB fetch request using C405PLBICUABORT(page 49). This can occur when a branch instruction is executed or when an interrupt occurs.

Fetched instructions are returned to the ICU by a PLB slave device over the PLB interface. A fetch response contains the following information:

• The fetch-request address is acknowledged by the PLB slave using PLBC405ICUADDRACK (page 50).

• Instructions sent from the PLB slave to the ICU during a line transfer are indicated as valid using PLBC405ICURDDACK (page 51).

• The PLB-slave bus width, or size (32-bit or 64-bit), is speciﬁed by PLBC405ICUSSIZE1 (page 50). The PLB slave is responsible for packing data bytes from non-word devices so that the information sent to the ICU is presented appropriately, as determined by the transfer size.

• The instructions returned to the ICU by the PLB slave are sent using four-word or eight-word line transfers, as speciﬁed by the transfer size in the fetch request. These

PowerPC 405 Processor Block Reference Guide www.xilinx.com 43

EDK 6.1 October 6, 2003 1-800-255-7778

instructions are returned over the ICU read-data bus, PLBC405ICURDDBUS[0:63] (page 51). Line transfers operate as follows:

- A four-word line transfer returns the quadword aligned on the address speciﬁed

by C405PLBICUABUS[0:27]. This quadword contains the target instruction requested by the ICU. The quadword is returned using two doubleword or four word transfer operations, depending on the PLB slave bus width (64-bit or 32-bit, respectively).

- An eight-word line transfer returns the eight-word cache line aligned on the

address speciﬁed by C405PLBICUABUS[0:26]. This cache line contains the target instruction requested by the ICU. The cache line is returned using four doubleword or eight word transfer operations, depending on the PLB slave bus width (64-bit or 32-bit, respectively).

• The words returned during a line transfer can be sent from the PLB slave to the ICU in any order (target-word-ﬁrst, sequential, other). This transfer order is speciﬁed by PLBC405ICURDWDADDR[1:3] (page 52).

Interaction with the ICU Fill Buffer

As mentioned above, the PLB slave can transfer instructions to the ICU in any order (target-word-ﬁrst, sequential, other). When instructions are received by the ICU from the PLB slave, they are placed in the ICU ﬁll buffer. When the ICU receives the target instruction, it forwards it immediately from the ﬁll buffer to the instruction-fetch unit so that pipeline stalls due to instruction-fetch delays are minimized. This operation is referred to as a bypass. The remaining instructions are received fromthe PLB slave and placed in the ﬁll buffer. Subsequent instruction fetches read from the ﬁll buffer if the instruction is already present in the buffer. For the best possible software performance, the PLB slave should be designed to return the target word ﬁrst.

Chapter 2: Input/Output Interfaces

Non-cacheable instructions are transferred using a four-word or eight-word line-transfer size. Software controls this transfer size using the non-cacheable request-size bit in the coreconﬁguration register (CCR0[NCRS]). This enables non-cacheable transfers to take advantage of the PLB line-transfer protocol to minimize PLB-arbitration delays and bus delays associated with multiple, single-word transfers. The transferred instructions are placed in the ICU ﬁll buffer,but not in the instruction cache. Subsequent instruction fetches from the same non-cacheable line are read from the ﬁll buffer instead of requiring a separate arbitration and transfer sequence across the PLB. Instructions in the ﬁll buffer are fetched with the same performance as a cache hit. The non-cacheable line remains in the ﬁll buffer until the ﬁll buffer is needed by another line transfer.

Cacheable instructions are always transferred using an eight-word line-transfer size. The transferred instructions are placed in the ICU ﬁll buffer as they are received from the PLB slave. Subsequent instruction fetches from the same cacheable line are read from the ﬁll buffer during the time the line is transferred from the PLB slave. When the ﬁll buffer is full, its contents are transferred to the instruction cache. Software can prevent this transfer by setting the fetch without allocate bit in the core-conﬁguration register (CCR0[FWOA]). In this case, the cacheable line remains in the ﬁll buffer until the ﬁll buffer is needed by another line transfer. An exception is that the contents of the ﬁll buffer are always transferred if the line was fetched because an icbt instruction was executed.

Prefetch and Address Pipelining

A prefetch is a request for the eight-word cache line that sequentially follows the current eight-word fetch request. Prefetched instructions are fetched before it is known that they are needed by the sequential execution of software.

44 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Instruction-Side Processor Local Bus Interface

The ICU can overlap a single prefetch request with the prior fetch request. This process, known as address pipelining, enables a second address to be presented to a PLB slave while the slave is returning data associated with the ﬁrst address. Address pipelining can occur if a prefetch request is produced before all instructions from the previous fetch request are transferred by the slave. This capability maximizes PLB-transfer throughput by reducing dead cycles between instruction transfers associated with the two requests. The ICU can pipeline the prefetch with any combination of sequential, branch, and interrupt fetch requests. A prefetch request is communicated over the PLB two or more cycles after the prior fetch request is acknowledged by the PLB slave.

Address pipelining of prefetch requests never occurs under any one of the following conditions:

• The PLB slave does not support address pipelining.

• The prefetch address falls outside the 1 KB physical page holding the current fetch address. This limitation avoids potential problems due to protection violations or storage-attribute mismatches.

• Non-cacheable transfers are programmed to use a four-word line-transfer size (CCR0[NCRS]=0).

• For non-cacheable transfers, prefetching is disabled (CCR0[PFNC]=0).

• For cacheable transfers, prefetching is disabled (CCR0[PFC]=0).

Address pipelining of non-cacheable prefetch requests can occur if all of the following conditions are met:

• Address pipelining is supported by the PLB slave.

• The ICU is not already involved in an address-pipelined PLB transfer.

• A branch or interrupt does not modify the sequential execution of the current (ﬁrst) instruction-fetch request.

• Non-cacheable prefetching is enabled (CCR0[PFNC]=1).

• A non-cacheable instruction-prefetch is requested, and the instruction is not in the ﬁll buffer or being returned over the ISOCM interface.

• The prefetch address does not fall outside the current 1 KB physical page.

Address pipelining of cacheable prefetch requests can occur if all of the following conditions are met:

• Address pipelining is supported by the PLB slave.

• The ICU is not already involved in an address-pipelined PLB transfer.

• A branch or interrupt does not modify the sequential execution of the current (ﬁrst) instruction-fetch request.

• Cacheable prefetching is enabled (CCR0[PFC]=1).

• A cacheable instruction-prefetch is requested, and the instruction is not in the instruction cache, the ﬁll buffer, or being returned over the ISOCM interface.

• The prefetch address does not fall outside the current 1 KB physical page.

Guarded Storage

Accesses to guarded storage are not indicated by the ISPLB interface. This is because the PowerPC Architecture allows instruction prefetching when:

• The processor is in real mode (instruction address translation is disabled).

• The fetched instruction is located in the same physical page (1 KB) as an instruction that is required by the sequential execution model, or

PowerPC 405 Processor Block Reference Guide www.xilinx.com 45

EDK 6.1 October 6, 2003 1-800-255-7778

• The fetched instruction is located in the next physical page (1 KB) as an instruction that is required by the sequential execution model.

Memory should be organized such that real-mode instruction prefetching from the same or next 1 KB page does not affect sensitive addresses, such as memory-mapped I/O devices.

If the processor is in virtual mode, an attempt to prefetch from guarded storage causes an instruction-storage interrupt. In this case, the prefetch never appears on the ISPLB.

Instruction-Side PLB I/O Signal Table

Figure 2-4 shows the block symbol for the instruction-side PLB interface. The signals are

summarized in Table 2-7.

PLBC405ICUADDRACK

PLBC405ICUSSIZE1

PLBC405ICURDDACK

PLBC405ICURDDBUS[0:63]

PLBC405ICURDWDADDR[1:3]

PLBC405ICUBUSY

PLBC405ICUERR

PPC405

Chapter 2: Input/Output Interfaces

C405PLBICUREQUEST C405PLBICUABUS[0:29] C405PLBICUSIZE[2:3] C405PLBICUCACHEABLE C405PLBICUU0ATTR C405PLBICUPRIORITY[0:1] C405PLBICUABORT

UG018_04_020702

Figure 2-4: Instruction-Side PLB Interface Block Symbol

Table 2-7: Instruction-Side PLB Interface Signal Summary

Signal

C405PLBICUREQUEST O No Connect Indicates the ICU is making an instruction-fetch request. C405PLBICUABUS[0:29] O No Connect Speciﬁes the memory address of the instruction-fetch

C405PLBICUSIZE[2:3] O No Connect Speciﬁes a four word or eight word line-transfer size. C405PLBICUCACHEABLE O No Connect Indicates the value of the cacheability storage attribute for

C405PLBICUU0ATTR O No Connect Indicates the value of the user-deﬁned storage attribute for

C405PLBICUPRIORITY[0:1] O No Connect Indicates the priority of the ICU fetch request. C405PLBICUABORT O No Connect Indicates the ICU is aborting an unacknowledged fetch

PLBC405ICUADDRACK I 0 Indicates a PLB slave acknowledges the current ICU fetch

I/O

Type

If Unused Function

request. Bits 30:31 of the 32-bit address are assumed to be zero.

the target address.

request.

PLBC405ICUSSIZE1 I 0 Speciﬁesthe bus width (size) of the PLB slave that accepted

the request.

PLBC405ICURDDACK I 0 Indicates the ICU read-data bus contains valid instructions

for transfer to the ICU.

46 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Instruction-Side Processor Local Bus Interface

Table 2-7: Instruction-Side PLB Interface Signal Summary (Continued)

Signal

PLBC405ICURDDBUS[0:63] I 0x0000_0000

PLBC405ICURDWDADDR[1:3] I 0b000 Indicates which word or doubleword of a four-word or

PLBC405ICUBUSY I 0 Indicates the PLB slave is busy performing an operation

PLBC405ICUERR I 0 Indicates an error was detected by the PLB slave during the

I/O

Type

If Unused Function

The ICU read-data bus used to transfer instructions from

_0000_0000

the PLB slave to the ICU.

eight-wordline transfer is presenton the ICU read-data bus.

requested by the ICU.

transfer of instructions to the ICU.

Instruction-Side PLB Interface I/O Signal Descriptions

The following sections describe the operation of the instruction-side PLB interface I/O signals.

Throughout these descriptions and unless otherwise noted, the term clock refers to the PLB clock signal, PLBCLK (see page 133 for information on this clock signal). The term cycle refers to a PLB cycle. To simplify the signal descriptions, it is assumed that PLBCLK and the PPC405x3 clock (CPMC405CLOCK) operate at the same frequency.

C405PLBICUREQUEST (output)

When asserted, this signal indicates the ICU is requesting instructions from a PLB slave device. The PLB slave asserts PLBC405ICUADDRACK to acknowledge the request. The request can be acknowledged in the same cycle it is presented by the ICU. The request is deasserted in the cycle after it is acknowledged by the PLB slave. When deasserted, no unacknowledged instruction-fetch request exists.

The following output signals contain information for the PLB slave device and are valid when the request is asserted. The PLB slave must latch these signals by the end of the same cycle it acknowledges the request:

• C405PLBICUABUS[0:31] contains the word address of the instruction-fetch request.

• C405PLBICUSIZE[2:3] indicates the instruction-fetch line-transfer size.

• C405PLBICUCACHEABLE indicates whether the instruction-fetch address is cacheable.

• C405PLBICUU0ATTR indicates the value of the user-deﬁned storage attribute for the instruction-fetch address.

C405PLBICUPRIORITY[0:1] is also valid when the request is asserted. This signal indicates the priority of the instruction-fetch request. It is used by the PLB arbiter to prioritize simultaneous requests from multiple PLB masters.

The ICU supports two outstanding fetch requests over the PLB. The ICU can make a second fetch request (a prefetch) after the current request is acknowledged. The ICU deasserts C405PLBICUREQUEST for at least one cycle after the current request is acknowledged and before the subsequent request is asserted.

PowerPC 405 Processor Block Reference Guide www.xilinx.com 47

EDK 6.1 October 6, 2003 1-800-255-7778

slave. This third request can be presented two cycles after the last read acknowledge (PLBC405ICURDDACK) is sent from the PLB slave to the ICU, completing the ﬁrst request.

The ICU can abort a fetch request if it no longer requirestherequestedinstruction. The ICU removes a request by asserting C405PLBICUABORT while the request is asserted. In the next cycle the request is deasserted and remains deasserted for at least one cycle.

C405PLBICUABUS[0:29] (output)

This bus speciﬁes the memory address of the instruction-fetch request. Bits 30:31 of the 32bit address are assumed to be zero so that all fetch requests are aligned on a word boundary. The fetch address is valid during the time the fetch request signal (C405PLBICUREQUEST) is asserted. It remains valid until the cycle following acknowledgement of the request by the PLB slave (the PLB slave asserts PLBC405ICUADDRACK to acknowledge the request).

C405PLBICUSIZE[2:3] indicates the instruction-fetch line-transfer size. The PLB slave uses memory-address bits [0:27] to specify an aligned four-word address for a four-word transfer size. Memory-addressbits[0:26]areusedtospecifyanalignedeight-wordaddress for an eight-word transfer size.

C405PLBICUSIZE[2:3] (output)

Chapter 2: Input/Output Interfaces

These signals are used to specify the line-transfer size of the instruction-fetch request. A four-word transfer size is speciﬁed when C405PLBICUSIZE[2:3]=0b01. An eight-word transfer size is speciﬁed when C405PLBICUSIZE[2:3]=0b10. The transfer size is valid during the cycles the fetch-request signal (C405PLBICUREQUEST) is asserted. It remains valid until the cycle following acknowledgement of the request by the PLB slave (the PLB slave asserts PLBC405ICUADDRACK to acknowledge the request).

A four-word line transfer returns the quadword aligned on the address speciﬁed by C405PLBICUABUS[0:27]. This quadword contains the target instruction requested by the ICU. The quadword is returned using two doubleword or four word transfer operations, depending on the PLB slave bus width (64-bit or 32-bit, respectively).

An eight-word line transfer returns the eight-word cache line aligned on the address speciﬁed by C405PLBICUABUS[0:26]. This cache line contains the target instruction requested by the ICU. The cache line is returned using four doubleword or eight word transfer operations, depending on the PLB slave bus width (64-bit or 32-bit, respectively).

The words returned during a line transfer can be sent from the PLB slave to the ICU in any order (target-word-ﬁrst, sequential, other). This transfer order is speciﬁed by PLBC405ICURDWDADDR[1:3].

C405PLBICUCACHEABLE (output)

This signal indicates whether the requested instructions are cacheable. It reﬂects the value of the cacheability storage attribute for the target address. The requested instructions are non-cacheable when the signal is deasserted (0). They are cacheable when the signal is asserted (1). This signal is valid during the time the fetch-request signal (C405PLBICUREQUEST) is asserted. It remains valid until the cycle following acknowledgement of the request by the PLB slave (the PLB slave asserts PLBC405ICUADDRACK to acknowledge the request).

48 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Instruction-Side Processor Local Bus Interface

advantage of the PLB line-transfer protocol to minimize PLB-arbitration delays and bus delays associated with multiple, single-word transfers. The transferred instructions are placed in the ICU ﬁll buffer,but not in the instruction cache. Subsequent instruction fetches from the same non-cacheable line are read from the ﬁll buffer instead of requiring a separate arbitration and transfer sequence across the PLB. Instructions in the ﬁll buffer are fetched with the same performance as a cache hit. The non-cacheable line remains in the ﬁll buffer until the ﬁll buffer is needed by another line transfer.

C405PLBICUU0ATTR (output)

This signal reﬂects the value of the user-deﬁned (U0) storage attribute for the target address. The requested instructions are not in memory locations characterized by this attribute when the signal is deasserted (0). They are in memory locations characterized by this attribute when the signal is asserted (1). This signal is valid during the time the fetchrequest signal (C405PLBICUREQUEST) is asserted. It remains valid until the cycle following acknowledgement of the request by the PLB slave (the PLB slave asserts PLBC405ICUADDRACK to acknowledge the request).

The system designer can use this signal to assign special behavior to certain memory addresses. Its use is optional.

C405PLBICUABORT (output)

When asserted, this signal indicates the ICU is aborting the current fetch request. It is used by the ICU to abort a request that has not been acknowledged, or is in the process of being acknowledged by the PLB slave. The fetch request continues normally if this signal is not asserted. This signal is only valid during the time the fetch-request signal (C405PLBICUREQUEST) is asserted. It must be ignored by the PLB slave if the fetchrequestsignalisnot asserted. In the cycle after the abort signal is asserted, the fetch-request signal is deasserted and remains deasserted for at least one cycle.

If the abort signal is asserted in the same cycle that the fetch request is acknowledged by the PLB slave (PLBC405ICUADDRACK is asserted), the PLB slave is responsible for ensuring that the transfer does not proceed further. The PLB slave cannot assert the ICU read-data bus acknowledgement signal (PLBC405ICURDDACK) for an aborted request.

The ICU can abort an address-pipelined fetch request while the PLB slave is responding to a previous fetch request. The PLB slave is responsible for completing the previous fetch request and aborting the new (pipelined) request.

C405PLBICUPRIORITY[0:1] (output)

These signals are used to specify the priority of the instruction-fetch request. Table 2-8 shows the encoding of the 2-bit PLB-request priority signal. The priority is valid during the cycles the fetch-request signal (C405PLBICUREQUEST) is asserted. It remains valid until the cycle following acknowledgement of the request by the PLB slave (the PLB slave asserts PLBC405ICUADDRACK to acknowledge the request).

PowerPC 405 Processor Block Reference Guide www.xilinx.com 49

EDK 6.1 October 6, 2003 1-800-255-7778

Table 2-8: PLB-Request Priority Encoding

Bit 0 Bit 1 Deﬁnition

0 0 Lowest PLB-request priority. 0 1 Next-to-lowest PLB-request priority. 1 0 Next-to-highest PLB-request priority. 1 1 Highest PLB-request priority.

Softwareestablishes the instruction-fetch request priority by writing the appropriate value into the ICU PLB-priority bits 0:1 of the core-conﬁguration register (CCR0[IPP]). After a reset, the priority is set to the highest level (CCR0[IPP]=0b11).

PLBC405ICUADDRACK (input)

When asserted, this signal indicates the PLB slave acknowledges the ICU fetch request (indicated by the ICU assertion of C405PLBICUREQUEST). When deasserted, no such acknowledgement exists. A fetch request can be acknowledged by the PLB slave in the same cycle the request is asserted by the ICU. The PLB slave must latch the following fetchrequest information in the same cycle it asserts the fetch acknowledgement:

Chapter 2: Input/Output Interfaces

• C405PLBICUABUS[0:29], which contains the word address of the instruction-fetch request.

• C405PLBICUSIZE[2:3], which indicates the instruction-fetch line-transfer size.

• C405PLBICUCACHEABLE, which indicates whether the instruction-fetch address is cacheable.

• C405PLBICUU0ATTR, which indicates the value of the user-deﬁned storage attribute for the instruction-fetch address (use of this signal is optional).

During the acknowledgement cycle, the PLB slave must return its bus width indicator (32 bits or 64 bits) using the PLBC405ICUSSIZE1 signal.

The acknowledgement signal remains asserted for one cycle. In the next cycle, both the fetch request and acknowledgement are deasserted. Instructions can be returned to the ICU from the PLB slave beginning in the cycle following the acknowledgement. The PLB slave must abort an ICU fetch request (return no instructions) if the ICU asserts C405PLBICUABORT in the same cycle the PLB slave acknowledges the request.

The ICU supports two outstanding fetch requests over the PLB. The ICU can make a second fetch request after the current request is acknowledged. The ICU deasserts C405PLBICUREQUEST for at least one cycle after the current request is acknowledged and before the subsequent request is asserted.

If the PLB slave supports address pipelining, it must respond to the two fetch requests in the order they are presented by the ICU. All instructions associated with the ﬁrst request must be returned before any instruction associated with the second request is returned. The ICU cannot present a third fetch request until the ﬁrst request is completed by the PLB slave. This third request can be presented two cycles after the last read acknowledge (PLBC405ICURDDACK) is sent from the PLB slave to the ICU, completing the ﬁrst request.

PLBC405ICUSSIZE1 (input)

This signal indicates the bus width (size) of the PLB slave device that acknowledged the ICU fetch request. A 32-bit PLB slave responded when the signal is deasserted (0). A 64-bit

50 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Instruction-Side Processor Local Bus Interface

PLB slave responded when the signal is asserted (1). This signal is valid during the cycle the acknowledge signal (PLBC405ICUADDRACK) is asserted.

The size signal is used by the ICU to determine how instructions are read from the 64-bit PLB interface during a transfer cycle (a transfer occurs when the PLB slave asserts PLBC405ICURDDACK). The ICU uses the size signal as follows:

• When a 32-bit PLB slave responds, an aligned word is sent from the slave to the ICU during each transfer cycle. The 32-bit PLB slave bus should be connected to both the high and low 32 bits of the 64-bit ICU read-data bus (see Figure 2-5, page 52). This type of connection duplicates the word returned by the slave across the 64-bit bus. The ICU reads either the low 32 bits or the high 32 bits of the 64-bit interface, depending on the order of the transfer (PLBC405ICURDWDADDR[1:3]).

• When a 64-bit PLB slave responds, an aligned doubleword is sent from the slave to the ICU during each transfer cycle. Both words are read from the 64-bit interface by the ICU in this cycle.

Table 2-10, page 53 shows the location of instructions on the ICU read-data bus as a

function of PLB-slave size, line-transfer size, and transfer order.

PLBC405ICURDDACK (input)

When asserted, this signal indicates the ICU read-data bus contains valid instructions sent by the PLB slave to the ICU (read data is acknowledged). The ICU latches the data from the bus at the end of the cycle this signal is asserted. The contents of the ICU read-data bus are not valid when this signal is deasserted.

• The PLB slave size (bus width) speciﬁed by PLBC405ICUSSIZE1.

• The line-transfer size speciﬁed by C405PLBICUSIZE[2:3].

• The cacheability of the fetched instructions speciﬁed by C405PLBICUCACHEABLE.

• The value of the non-cacheable request-size bit (CCR0[NCRS]).

Table 2-9 summarizes the effect these parameters have on the number of transfers.

Table 2-9: Number of Transfers Required for Instruction-Fetch Requests

PLB-Slave

Size

32-Bit Four Words Non-Cacheable 0 4

64-Bit Four Words Non-Cacheable 0 2

Line-Transfer

Size

Eight Words 1 8 Eight Words Cacheable — 8

Eight Words 1 4 Eight Words Cacheable — 4

Instruction

Cacheability

CCR0[NCRS]

Number of

Transfers

PLBC405ICURDDBUS[0:63] (input)

This read-data bus contains the instructions transferred from a PLB slave to the ICU. The contents of the bus are valid when the read-data acknowledgement signal

PowerPC 405 Processor Block Reference Guide www.xilinx.com 51

EDK 6.1 October 6, 2003 1-800-255-7778

Chapter 2: Input/Output Interfaces

(PLBC405ICURDDACK) is asserted. This acknowledgment is asserted for one cycle per transfer. There is no limit to the number of cycles between two transfers. The bus contents are not valid when the read-data acknowledgement signal is deasserted.

The PLB slave returns either a single instruction (an aligned word) or two instructions (an aligned doubleword) per transfer.The number of instructions sent per transfer depends on the PLB slave size (bus width), as follows:

• When a 32-bit PLB slave responds, an aligned word is sent from the slave to the ICU during each transfer cycle. The 32-bit PLB slave bus should be connected to both the high and low 32 bits of the 64-bit read-data bus, as shown in Figure 2-5 below. This type of connection duplicates the word returned by the slave across the 64-bit bus. The ICU reads either the low 32 bits or the high 32 bits of the 64-bit interface, depending on the value of PLBC405ICURDWDADDR[1:3].

• When a 64-bit PLB slave responds, an aligned doubleword is sent from the slave to the ICU during each transfer cycle. Both words are read from the 64-bit interface by the ICU in this cycle.

Table 2-10 shows the location of instructions on the ICU read-data bus as a function of PLB-

slave size, line-transfer size, and transfer order.

64-Bit PLB Master 32-Bit PLB Slave

PLBC405ICURDDBUS[0:31]

PLBC405ICURDDBUS[32:63]

C405PLBICUABUS[0:29]

PLBC405ICURDDBUS[0:31]

C405PLBICUABUS[0:29] C405PLBICUABUS[30:31]

UG018_10_102001

Figure 2-5: Attachment of ISPLB Between 32-Bit Slave and 64-Bit Master

PLBC405ICURDWDADDR[1:3] (input)

These signals are used to specify the transfer order. They identify which word or doubleword of a line transfer is present on the ICU read-data bus when the PLB slave returns instructions to the ICU. The words returned during a line transfer can be sent from the PLB slave to the ICU in any order (target-word-ﬁrst, sequential, other). The transferorder signals are valid when the read-data acknowledgement signal (PLBC405ICURDDACK) is asserted. This acknowledgment is asserted for one cycle per transfer. Thereis no limit to the number of cycles between two transfers. The transfer-order signals are not valid when the read-data acknowledgement signal is deasserted.

Table 2-10 shows the location of instructions on the ICU read-data bus as a function of PLB-

slave size, line-transfer size, and transfer order. In this table, the Transfer Order column contains the possible values of PLBC405ICURDWDADDR[1:3]. For 64-bit PLB slaves, PLBC405ICURDWDADDR[3] should always be 0 during a transfer. In this case, the transfer order is invalid if this signal asserted. The entries for a 32-bit PLB slave assume the connection to a 64-bit master shown in Figure 2-5, page 52.

52 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Instruction-Side Processor Local Bus Interface

Table 2-10: Contents of ICU Read-Data Bus During Line Transfer

PLB-Slave

Size

32-Bit Four Words x00 Instruction 0 Instruction 0

64-Bit Four Words x00 Instruction 0 Instruction 1

Line-Transfer

Size

Eight Words 000 Instruction 0 Instruction 0

Transfer

Order

x01 Instruction 1 Instruction 1 x10 Instruction 2 Instruction 2 x11 Instruction 3 Instruction 3

001 Instruction 1 Instruction 1 010 Instruction 2 Instruction 2 011 Instruction 3 Instruction 3 100 Instruction 4 Instruction 4 101 Instruction 5 Instruction 5 110 Instruction 6 Instruction 6 111 Instruction 7 Instruction 7

x10 Instruction 2 Instruction 3 xx1 Invalid

ICU Read-Data Bus

[0:31]

ICU Read-Data Bus

[32:63]

Eight Words 000 Instruction 0 Instruction 1

010 Instruction 2 Instruction 3 100 Instruction 4 Instruction 5 110 Instruction 6 Instruction 7 xx1 Invalid

Notes:

1. “x” indicates a don’t-care value in PLBC405ICURDWDADDR[1:3].

2. An instruction shown in italics is ignored by the ICU during the transfer.

PLBC405ICUBUSY (input)

When asserted, this signal indicates the PLB slave acknowledged and is responding to (is busy with) an ICU fetch request. When deasserted, the PLB slave is not responding to an ICU fetch request.

This signal should be asserted in the cycle after an ICU fetch request is acknowledged by the PLB slave and remain asserted until the request is completed by the PLB slave. It should be deasserted in the cycle after the last read-data acknowledgement signal is asserted by the PLB slave, completing the transfer. If multiple fetch requests are initiated and overlap, the busy signal should be asserted in the cycle after the ﬁrst request is acknowledged and remain asserted until the cycle after the ﬁnal read-data acknowledgement is completed for the last request.

Following reset, the processor block prevents the ICU from fetching instructions until the busy signal is deasserted for the ﬁrst time. This is useful in situations where the processor

PowerPC 405 Processor Block Reference Guide www.xilinx.com 53

EDK 6.1 October 6, 2003 1-800-255-7778

block is reset by a core reset, but PLB devices are not reset. Waitingfor the busy signal to be deasserted prevents fetch requests following reset from interfering with PLB activity that was initiated before reset.

PLBC405ICUERR (input)

When asserted, this signal indicates the PLB slave detected an error when attempting to access or transfer the instructions requested by the ICU. This signal should be asserted with the read-data acknowledgement signal that corresponds to the erroneous transfer. The error signal should be asserted for only one cycle. When deasserted, no error is detected.

If a cacheable instruction is transferred with an error indication, it is loaded into the ICU ﬁll buffer. However, the cache line held in the ﬁll buffer is not transferred to the instruction cache.

The PLB slave must not terminate instruction transfers when an error is detected. The processor block is responsible for responding to any error detected by the PLB slave. A machine-check exception occurs if the PPC405x3 attempts to execute an instruction that was transferred to the ICU with an error indication. If an instruction is transferred with an error indication but is never executed, no machine-check exception occurs.

The PLB slave should latch error information in DCRs so that software diagnostic routines can attempt to report and recover from the error. A bus-error address register (BEAR) should be implemented for storing the address of the access that caused the error. A buserror syndrome register (BESR) should be implemented for storing information about cause of the error.

Chapter 2: Input/Output Interfaces

54 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Instruction-Side Processor Local Bus Interface

Instruction-Side PLB Interface Timing Diagrams

The following timing diagrams show typical transfers that can occur on the ISPLB interface between the ICU and a bus-interface unit (BIU). These timing diagrams represent the optimal timing relationships supported by the processor block. The BIU can be implemented using the FPGA processor local bus (PLB) or using customized hardware. Not all BIU implementations support these optimal timing relationships.

The ICU only performs reads (fetches) when accessing instructions across the ISPLB interface.

ISPLB Timing Diagram Assumptions

The following assumptions and simpliﬁcations were made in producing the optimal timing relationships shown in the timing diagrams:

• Fetch requests are acknowledged by the BIU in the same cycle they are presented by the ICU. This represents the earliest cycle a BIU can acknowledge a fetch request.

• The ﬁrst read-data acknowledgement for a line transfer is asserted in the cycle immediately following the fetch-request acknowledgement. This represents the earliest cycle a BIU can begin transferring instructions to the ICU in response to a fetch request. However, the earliest the FPGA PLB begins transferring instructions is two cycles after the fetch request is acknowledged.

• Subsequent read-data acknowledgements for a line transfer are asserted in the cycle immediately following the prior read-data acknowledgement. This represents the fastest rate at which a BIU can transfer instructions to the ICU (there is no limit to the number of cycles between two transfers).

• All line transfers assume the target instruction (word) is returned ﬁrst. Subsequent instructions in the line are returned sequentially by address, wrapping as necessary to the lower addresses in the same line.

• The rate at which the ICU makes instruction-fetch requests to the BIU is not limited by the rate instructions are executed.

• An ICU fetch request to the BIU occurs two cycles after a miss is determined by the ICU.

• The ICU latches instructions into the ﬁll buffer in the cycle after the instructions are received from the BIU on the PLB.

• The transfer of instructions from the ﬁll buffer to the instruction cache takes three cycles. This transfer takes place after all instructions are read into the ﬁll buffer from the BIU.

• The BIU size (bus width) is 64 bits, so PLBC405ICUSSIZE1 is not shown.

• No instruction-access errors occur, so PLBC405ICUERR is not shown.

• The abort signal, C405PLBICUABORT is shown only in the last example.

• The storage attribute signals are not shown.

• The ICU activity is shown only as an aide in describing the examples. The occurrence and duration of this activity is not observable on the ISPLB.

The following abbreviations appear in the timing diagrams:

PowerPC 405 Processor Block Reference Guide www.xilinx.com 55

EDK 6.1 October 6, 2003 1-800-255-7778

Table 2-11: Key to ISPLB Timing Diagram Abbreviations

Abbreviation

Description Where Used

Chapter 2: Input/Output Interfaces

rl# Fetch-request identiﬁer Request

Request acknowledge Read-data acknowledge

(C405PLBICUREQUEST) (PLBC405ICUADDRACK)

(PLBC405ICURDDACK) adr# Fetch-request address Request address (C405PLBICUABUS[0:29]) d#

Doublewords (two instructions) transferred

ICU read-data bus (PLBC405ICURDDBUS[0:63])

as a result of a fetch request

miss# The ICU detects a cache miss that causes a

ICU

fetch request on the PLB ﬁll# The ICU is busy performing a ﬁll operation ICU byp# The ICU forwards instructions to the

ICU PPC405x3 instruction-fetch unit from the ﬁll buffer as they become available (bypass)

prefetch# The ICU speculatively prefetches

ICU instructions from the BIU

Subscripts Used to identify the instruction words

returned by a transfer

Read-data acknowledge

ICU read-data bus

(PLBC405ICURDDACK) (PLBC405ICURDDBUS[0:63])

ICU forward (bypass)

# Used to identify the order doublewords are

Transfer order (PLBC405ICURDWDADDR[1:3]) sent to the ICU

Notes:

1. “#” indicates a number.

56 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Instruction-Side Processor Local Bus Interface

ISPLB Non-Pipelined Cacheable Sequential Fetch (Case 1)

The timing diagram in Figure 2-6 shows two consecutive eight-word line fetches that are not address pipelined. The example assumes instructions are fetched sequentially from the beginning of the ﬁrst line through the end of the second line.

The ﬁrst line read (rl1) is requested by the ICU in cycle 3 in response to a cache miss (represented by the miss1 transaction in cycles 1 and 2). Instructions are sent from the BIU to the ICU ﬁll buffer in cycles 4 through 7. Instructions in the ﬁll buffer are bypassed to the instruction fetch unit to prevent a processor stall during sequential execution (represented by the byp1 transaction in cycles 5 through 8). After all instructions are received, they are transferred by the ICU from the ﬁll buffer to the instruction cache. This is represented by the ﬁll1 transaction in cycles 9 through 11.

After the last instruction in the line is fetched, a sequential fetch from the next cache line causes a miss in cycle 13 (miss2). The second line read (rl2) is requested by the ICU in cycle 15 in response to the cache miss. Instructions are sent from the BIU to the ICU ﬁll buffer in cycles 16 through 19. Instructions in the ﬁll buffer are bypassed to the instruction fetch unit to prevent a processor stall during sequential execution (represented by the byp2 transaction in cycles 17 through 20). After all instructions are received, they are transferred by the ICU from the ﬁll buffer to the instruction cache (not shown).

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Cycle

PLBCLK a nd CPMC405CLK

ICU

PPC405 Outputs:

C405PLBICUREQUEST

C405PLBICUABUS[0:29]

PLB/BIU Outputs:

PLBC405ICUADDRACK

PLBC405ICURDDACK

PLBC405ICURDDBUS[0:63]

PLBC405ICURDWDADDR[1:3]

PLBC405ICUBUSY

adr1 adr2

rl101rl123rl145rl1

d101d123d145d1

0246 0246

fill1byp1 byp2miss2miss1

rl2rl1

Figure 2-6: ISPLB Non-Pipelined Cacheable Sequential Fetch (Case 1)

rl201rl223rl245rl2

d201d223d245d2

UG018_11_101701

PowerPC 405 Processor Block Reference Guide www.xilinx.com 57

EDK 6.1 October 6, 2003 1-800-255-7778

Chapter 2: Input/Output Interfaces

ISPLB Non-Pipelined Cacheable Sequential Fetch (Case 2)

The timing diagram in Figure 2-7 shows two consecutive eight-word line fetches that are not address pipelined. The example assumes instructions are fetched sequentially from the end of the ﬁrst line through the end of the second line. It provides an illustration of a transfer where the target instruction returned ﬁrst by the BIU is not located at the start of the cache line.

The ﬁrst line read (rl1) is requested by the ICU in cycle 3 in response to a cache miss (represented by the miss1 transaction in cycles 1 and 2). Instructions are sent from the BIU to the ICU ﬁll buffer in cycles 4 through 7. The target instruction is bypassed to the instruction fetch unit in cycle 5 (byp1). After all instructions are received, they are transferred by the ICU from the ﬁll buffer to the instruction cache. This is represented by the ﬁll1 transaction in cycles 8 through 10.

After the target instruction is bypassed, a sequential fetch from the next cache line causes a miss in cycle 6 (miss2). The second line read (rl2) is requested by the ICU in cycle 8 in response to the cache miss. After the ﬁrst line is read from the BIU, instructions for the second line are sent from the BIU to the ICU ﬁll buffer. This occurs in cycles 9 through 12. Instructions in the ﬁll buffer are bypassed to the instruction fetch unit to prevent a processor stall during sequential execution (represented by the byp2 transaction in cycles 11through 13). After all instructions are received, they are transferred by the ICU from the ﬁll buffer to the instruction cache (represented by the ﬁll2 transaction in cycles 14 through

16).

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Cycle

PLBCLK a nd CPMC405CLK

rl2rl1

fill1 fill2byp1 byp2miss2miss1

rl201rl223rl245rl2

d201d223d245d2

ICU

PPC405 Outputs:

C405PLBICUREQUEST

C405PLBICUABUS[0:29]

PLB/BIU Outputs:

PLBC405ICUADDRACK

PLBC405ICURDDACK

PLBC405ICURDDBUS[0:63]

PLBC405ICURDWDADDR[1:3]

PLBC405ICUBUSY

adr1 adr2

rl167rl101rl123rl1

d167d101d123d1

6024 0246

Figure 2-7: ISPLB Non-Pipelined Cacheable Sequential Fetch (Case 2)

UG018_12_101701

58 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Instruction-Side Processor Local Bus Interface

ISPLB Pipelined Cacheable Sequential Fetch (Case 1)

The timing diagram in Figure 2-8 shows two consecutive eight-word line fetches that are address pipelined. The example assumes instructions are fetched sequentially from the beginning of the ﬁrst line through the end of the second line. It shows the fastest speed at which the ICU can request and receive instructions over the PLB.

After the ﬁrst miss is detected, the ICU performs a prefetch in anticipation of requiring instructions from the next cache line (represented by the prefetch2 transaction in cycles 3 and 4). The second line read (rl2) is requested by the ICU in cycle 5 in response to the prefetch. After the ﬁrst line is read from the BIU, instructions for the second line are sent from the BIU to the ICU ﬁll buffer. This occurs in cycles 8 through 11.After all instructions are received, they are transferred by the ICU from the ﬁll buffer to the instruction cache (represented by the ﬁll2 transaction in cycles 13 through 15). Instructions from this second line are not bypassed because the ﬁll buffer is transferred to the cache before the instructions are required.

Cycle

PLBCLK a nd CPMC405CLK

ICU

PPC405 Outputs:

C405PLBICUREQUEST

C405PLBICUABUS[0:29]

PLB/BIU Outputs:

PLBC405ICUADDRACK

PLBC405ICURDDACK

PLBC405ICURDDBUS[0:63]

PLBC405ICURDWDADDR[1:3]

PLBC405ICUBUSY

Figure 2-8: ISPLB Pipelined Cacheable Sequential Fetch (Case 1)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

fill1 fill2byp1prefetch2miss1

rl2rl1

adr1 adr2

rl2rl1

rl101rl123rl145rl167rl201rl223rl245rl2

d101d123d145d1

d201d223d245d2

02460246

UG018_13_101701

PowerPC 405 Processor Block Reference Guide www.xilinx.com 59

EDK 6.1 October 6, 2003 1-800-255-7778

ISPLB Pipelined Cacheable Sequential Fetch (Case 2)

The timing diagram in Figure 2-9 shows two consecutive eight-word line fetches that are address pipelined. The example assumes instructions are fetched sequentially from the end of the ﬁrst line through the end of the second line. As with the previous example, it shows the fastest speed at which the ICU can request and receive instructions over the PLB. It also illustrates a transfer where the target instruction returned ﬁrst by the BIU is not located at the start of the cache line.

The ﬁrst line read (rl1) is requested by the ICU in cycle 3 in response to a cache miss (represented by the miss1 transaction in cycles 1 and 2). Instructions are sent from the BIU to the ICU ﬁll buffer in cycles 4 through 7. The target instruction is bypassed to the instruction fetch unit in cycle 5 (byp1). After all instructions are received, they are transferred by the ICU from the ﬁll buffer to the instruction cache. This is represented by the ﬁll1 transaction in cycles 8 through 10.

After the ﬁrst miss is detected, the ICU performs a prefetch in anticipation of requiring instructions from the next cache line (represented by the prefetch2 transaction in cycles 3 and 4). The second line read (rl2) is requested by the ICU in cycle 5 in response to the prefetch. After the ﬁrst line is read from the BIU, instructions for the second line are sent from the BIU to the ICU ﬁll buffer. This occurs in cycles 8 through 11.Instructions in the ﬁll buffer are bypassed to the instruction fetch unit to prevent a processor stall during sequential execution (representedby the byp2 transaction in cycles 11through 12). After all instructions are received, they are transferred by the ICU from the ﬁll buffer to the instruction cache (represented by the ﬁll2 transaction in cycles 13 through 15).

Chapter 2: Input/Output Interfaces

Cycle

PLBCLK a nd CPMC405CLK

ICU

PPC405 Outputs:

C405PLBICUREQUEST

C405PLBICUABUS[0:29]

PLB/BIU Outputs:

PLBC405ICUADDRACK

PLBC405ICURDDACK

PLBC405ICURDDBUS[0:63]

PLBC405ICURDWDADDR[1:3]

PLBC405ICUBUSY

Figure 2-9: ISPLB Pipelined Cacheable Sequential Fetch (Case 2)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

fill1 fill2byp1 byp2prefetch2miss1

rl2rl1

adr1 adr2

rl2rl1

rl167rl101rl123rl145rl201rl223rl245rl2

d167d101d123d1

d201d223d245d2

02466024

UG018_14_101701

60 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Instruction-Side Processor Local Bus Interface

ISPLB Non-Pipelined Non-Cacheable Sequential Fetch

The timing diagram in Figure 2-10 shows two consecutive eight-word line fetches that are not address pipelined. The example assumes the instructions are not cacheable. It also assumes the instructions are fetched sequentially from the end of the ﬁrst line through the end of the second line. It provides an illustration of how all instructions in a line must be transferred even though some of the instructions are discarded.

The ﬁrst line read (rl1) is requested by the ICU in cycle 3 in response to a cache miss (represented by the miss1 transaction in cycles 1 and 2). Instructions are sent from the BIU to the ICU ﬁll buffer in cycles 4 through 7. The target instruction is bypassed to the instruction fetch unit in cycle 5 (byp1). Because the instructions are executing sequentially, the target instruction is the only instruction in the line that is executed. The line is not cacheable, so instructions are not transferred from the ﬁll buffer to the instruction cache.

After the target instruction is bypassed, a sequential fetch from the next cache line causes a miss in cycle 6 (miss2). The second line read (rl2) is requested by the ICU in cycle 8 in response to the cache miss. After the ﬁrst line is read from the BIU, instructions for the second line are sent from the BIU to the ICU ﬁll buffer. This occurs in cycles 9 through 12. These instructions overwrite the instructions from the previous line. After loading into the ﬁll buffer, instructions from the second line are bypassed to the instruction fetch unit to prevent a processor stall during sequential execution (represented by the byp2 transaction in cycles 10 through 15). The line is not cacheable, so instructions are not transferred from the ﬁll buffer to the instruction cache.

Cycle

PLBCLK a nd CPMC405CLK

ICU

PPC405 Outputs:

C405PLBICUREQUEST

C405PLBICUABUS[0:29]

PLB/BIU Outputs:

PLBC405ICUADDRACK

PLBC405ICURDDACK

PLBC405ICURDDBUS[0:63]

PLBC405ICURDWDADDR[1:3]

PLBC405ICUBUSY

Figure 2-10: ISPLB Non-Pipelined Non-Cacheable Sequential Fetch

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

byp1 byp2miss2miss1

rl2rl1

adr1 adr2

rl2rl1

rl167rl101rl123rl1

d167d101d123d1

6024 0246

rl201rl223rl245rl2

d201d223d245d2

UG018_15_101701

PowerPC 405 Processor Block Reference Guide www.xilinx.com 61

EDK 6.1 October 6, 2003 1-800-255-7778

ISPLB Pipelined Non-Cacheable Sequential Fetch

The timing diagram in Figure 2-11 shows two consecutive eight-word line fetches that are addresspipelined.Theexampleassumes the instructions arenotcacheable.It also assumes the instructions arefetched sequentially from the end of the ﬁrst line through the end of the second line. As with the previous example, it provides an illustration of how all instructions in a line must be transferred even though some of the instructions are discarded.

The ﬁrst line read (rl1) is requested by the ICU in cycle 3 in response to a cache miss (represented by the miss1 transaction in cycles 1 and 2). Instructions are sent from the BIU to the ICU ﬁll buffer in cycles 4 through 7. The target instruction is bypassed to the instruction fetch unit in cycle 5 (byp1). Because the instructions are executing sequentially, the target instruction is the only instruction in the line that is executed. The line is not cacheable, so instructions are not transferred from the ﬁll buffer to the instruction cache.

After the ﬁrst miss is detected, the ICU performs a prefetch in anticipation of requiring instructions from the next cache line (represented by the prefetch2 transaction in cycles 3 and 4). The second line read (rl2) is requested by the ICU in cycle 5 in response to the prefetch. After the ﬁrst line is read from the BIU, instructions for the second line are sent from the BIU to the ICU ﬁll buffer. This occurs in cycles 8 through 11. These instructions overwrite the instructions from the previous line. After loading into the ﬁll buffer, instructions from the second line are bypassed to the instruction fetch unit to prevent a processor stall during sequential execution (represented by the byp2 transaction in cycles 9 through 14). The line is not cacheable, so instructions are not transferred from the ﬁll buffer to the instruction cache.

Chapter 2: Input/Output Interfaces

Cycle

PLBCLK a nd CPMC405CLK

ICU

PPC405 Outputs:

C405PLBICUREQUEST

C405PLBICUABUS[0:29]

PLB/BIU Outputs:

PLBC405ICUADDRACK

PLBC405ICURDDACK

PLBC405ICURDDBUS[0:63]

PLBC405ICURDWDADDR[1:3]

PLBC405ICUBUSY

Figure 2-11: ISPLB Pipelined Non-Cacheable Sequential Fetch

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

byp2byp1prefetch2miss1

rl2rl1

adr1 adr2

rl2rl1

rl167rl101rl123rl145rl201rl223rl245rl2

d167d101d123d1

d201d223d245d2

02466024

UG018_16_101701

62 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Instruction-Side Processor Local Bus Interface

ISPLB 2:1 Core-to-PLB Line Fetch

The timing diagram in Figure 2-12 shows an eight-word line fetch in a system with a PLB clock that runs at one half the frequency of the PPC405x3 clock.

The line read (rl1) is requested by the ICU in PLB cycle 2, which corresponds to PPC405x3 cycle 3. The BIU responds in the same cycle. Instructions are sent from the BIU to the ICU ﬁll buffer in PLB cycles 3 through 6 (PPC405x3 cycles 5 through 12). After all instructions associated with this line are read, the line is transferred by the ICU from the ﬁll buffer to the instruction cache (not shown).

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Cycle

CPMC405CLK

PLBCLK

ICU

PPC405 Outputs:

C405PLBICUREQUEST

C405PLBICUABUS[0:29]

PLB/BIU Outputs:

PLBC405ICUADDRACK

PLBC405ICURDDACK

PLBC405ICURDDBUS[0:63]

PLBC405ICURDWDADDR[1:3]

PLBC405ICUBUSY

miss1

rl1

adr1

rl1

0246

rl1

UG018_18_101701

Figure 2-12: ISPLB 2:1 Core-to-PLB Line Fetch

PowerPC 405 Processor Block Reference Guide www.xilinx.com 63

EDK 6.1 October 6, 2003 1-800-255-7778

ISPLB 3:1 Core-to-PLB Line Fetch

The timing diagram in Figure 2-13 shows an eight-word line fetch in a system with a PLB clock that runs at one third the frequency of the PPC405x3 clock.

The line read (rl1) is requested by the ICU in PLB cycle 2, which corresponds to PPC405x3 cycle 4. The BIU responds in the same cycle. Instructions are sent from the BIU to the ICU ﬁll buffer in PLB cycles 3 through 6 (PPC405x3 cycles 7 through 18). After all instructions associated with this line are read, the line is transferred by the ICU from the ﬁll buffer to the instruction cache (not shown).

Cycle

CPMC405CLK

PLBCLK

ICU

PPC405 Outputs:

C405PLBICUREQUEST

C405PLBICUABUS[0:29]

PLB/BIU Outputs:

PLBC405ICUADDRACK

PLBC405ICURDDACK

PLBC405ICURDDBUS[0:63]

PLBC405ICURDWDADDR[1:3]

PLBC405ICUBUSY

Chapter 2: Input/Output Interfaces

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

miss1

rl1

adr1

rl1

0246

rl1

UG018_19_101701

Figure 2-13: ISPLB 3:1 Core-to-PLB Line Fetch

64 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Instruction-Side Processor Local Bus Interface

ISPLB Aborted Fetch Request

The timing diagram in Figure 2-14 shows an aborted fetch request. The request is aborted because of an instruction-ﬂow change, such as a taken branch or an interrupt. It shows the earliest-possible subsequent fetch-request that can be produced by the ICU.

The ﬁrst line read (rl1) is requested by the ICU in cycle 3 in response to a cache miss (represented by the miss1 transaction in cycles 1 and 2). The BIU responds in the same cycle the request is made by the ICU. However, the processor also aborts the request in cycle 3, possibly because a branch was mispredicted or an interrupt occurred. Therefore, the BIU ignores the request and does not transfer instructions associated with the request.

The change in control ﬂow causes the ICU to fetch instructions from a non-sequential address. The second line read (rl2) is requested by the ICU in cycle 7 in response to a cache miss of the new instructions. (represented by the miss2 transaction in cycles 5 and 6). Instructions are sent from the BIU to the ICU ﬁll buffer in cycles 8 through 11.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Cycle

PLBCLK a nd CPMC405CLK

ICU

miss2miss1

PPC405 Outputs:

C405PLBICUREQUEST

C405PLBICUABUS[0:29]

C405PLBICUABORT

PLB/BIU Outputs:

PLBC405ICUADDRACK

PLBC405ICURDDACK

PLBC405ICURDDBUS[0:63]

PLBC405ICURDWDADDR[1:3]

PLBC405ICUBUSY

rl2rl1

adr1 adr2

rl2rl1

rl201rl223rl245rl2

d201d223d245d2

0246

Figure 2-14: ISPLB Aborted Fetch Request

UG018_17_101701

PowerPC 405 Processor Block Reference Guide www.xilinx.com 65

EDK 6.1 October 6, 2003 1-800-255-7778

Data-Side Processor Local Bus Interface

The data-side processor local bus (DSPLB) interface enables the PPC405x3 data cache unit (DCU) to load (read) and store (write) data from any memory device connected to the processor local bus (PLB). This interface has a dedicated 32-bit address bus output, a dedicated 64-bit read-data bus input, and a dedicated 64-bit write-data bus output. The interface is designed to attach as a master to a 64-bit PLB, but it also supports attachment as a master to a 32-bit PLB. The interface is capable of one data transfer (64 or 32 bits) every PLB cycle.

At the chip level, the DSPLB can be combined with the instruction-side read-data bus (also a PLB master) to create a shared read-data bus. This is done if a single PLB arbiter services both PLB masters and the PLB arbiter implementation only returns data to one PLB master at a time.

Refer to PowerPC Processor Reference Guide for more information on the operation of the PPC405x3 DCU.

Data-Side PLB Operation

Data-access (read and write) requests are produced by the DCU and communicated over the PLB interface. A request occurs when an access misses the data cache or the memory location that is accessed is non-cacheable. A data-access request contains the following information:

Chapter 2: Input/Output Interfaces

• The request is indicated by C405PLBDCUREQUEST (page 70).

• The type of request (read or write) is indicated by C405PLBDCURNW (page 71).

• The target address of the data to be accessed is speciﬁed by the address bus, C405PLBDCUABUS[0:31] (page 71).

• The transfer size is speciﬁed as a single word or as eight words (cache line) using C405PLBDCUSIZE2 (page 71). The remaining bits of the transfer size (0, 1, and 3) must be tied to zero at the PLB arbiter.

• The byte enables for single-word accesses are speciﬁed using C405PLBDCUBE[0:7] (page 73). The byte enables specify one, two, three, or four contiguous bytes in either the upper or lower four byte word of the 64-bit data bus. The byte enables are not used by the processor during line transfers and must be ignored by the PLB slave.

• The cacheability storage attribute is indicated by C405PLBDCUCACHEABLE (page 72). Cacheable transfers are performed using word or line transfer sizes.

• The write-through storage attribute is indicated by C405PLBDCUWRITETHRU (page 72).

• The guarded storage attribute is indicated by C405PLBDCUGUARDED (page 73).

• The user-deﬁned storage attribute is indicated by C405PLBDCUU0ATTR (page 73).

• The request priority is indicated by C405PLBDCUPRIORITY[0:1] (page 75). The PLB arbiter uses this information to prioritize simultaneous requests from multiple PLB masters.

The processor can abort a PLB data-access request using C405PLBDCUABORT (page 75). This occurs only when the processor is reset.

Data is returned to the DCU by a PLB slave device over the PLB interface. The response to a data-access request contains the following information:

• The address of the data-access request is acknowledged by the PLB slave using PLBC405DCUADDRACK (page 77).

66 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Data-Side Processor Local Bus Interface

• Data sent during a read transfer from the PLB slave to the DCU over the read-data bus are indicated as valid using PLBC405DCURDDACK (page 79). Data sent during a write transfer from the DCU to the PLB slave over the write-data bus are indicated as valid using PLBC405DCUWRDACK (page 80).

• The PLB-slave bus width, or size (32-bit or 64-bit), is speciﬁed by PLBC405DCUSSIZE1 (page 78). The PLB slave is responsible for packing (during reads) or unpacking (during writes) data bytes from non-word devices so that the information sent to the DCU is presented appropriately, as determined by the transfer size.

• The data transferred between the DCU and the PLB slave is sent as a single word or as an eight-word line transfer, as speciﬁed by the transfer size in the data-access request. Data reads are transferred from the PLB slave to the DCU over the DCU read-data bus, PLBC405DCURDDBUS[0:63] (page 79). Data writes are transferred from the DCU to the PLB slave over the DCU write-data bus, PLBC405DCUWRDBUS[0:63] (page 76). Data transfers operate as follows:

- A word transfer moves the entire word speciﬁed by the address of the data-access

request. The speciﬁc bytes being accessed are indicated by the byte enables, C405PLBDCUBE[0:7] (page 73). The word is transferred using one transfer operation.

- An eight-word line transfer moves the eight-word cache line aligned on the

address speciﬁed by C405PLBDCUABUS[0:26]. This cache line contains the target data accessed by the DCU. The cache line is transferred using four doubleword or eight word transfer operations, depending on the PLB slave bus width (64-bit or 32-bit, respectively). The byte enables are not used by the processor for this type of transfer and they must be ignored by the PLB slave.

• The words read during a data-read transfer can be sent from the PLB slave to the DCU in any order (target-word-ﬁrst, sequential, other). This transfer order is speciﬁed by PLBC405DCURDWDADDR[1:3] (page 79). For data-write transfers, data is transferred from the DCU to the PLB slave in ascending-address order.

Interaction with the DCU Fill Buffer

As mentioned above, the PLB slave can transfer data to the DCU in any order (targetword-ﬁrst, sequential, other). When data is received by the DCU from the PLB slave, it is placed in the DCU ﬁll buffer. When the DCU receives the target (requested) data, it forwards it immediately from the ﬁll buffer to the load/store unit so that pipeline stalls due to load-miss delays are minimized. This operation is referred to as a bypass. The remainingdata is received fromthe PLB slave and placed in the ﬁll buffer. Subsequent data is read from the ﬁll buffer if the data is already present in the buffer. For the best possible software performance, the PLB slave should be designed to return the target word ﬁrst.

Non-cacheable data is usually transferred as a single word. Software can indicate that noncacheable reads be loaded using an eight-word line transfer by setting the load-word-as-line bit in the core-conﬁguration register (CCR0[LWL]) to 1. This enables non-cacheable reads to take advantage of the PLB line-transfer protocol to minimize PLB-arbitration delays and bus delays associated with multiple, single-word transfers. The transferred data is placed in the DCU ﬁll buffer, but not in the data cache. Subsequent data reads from the same noncacheable line are read from the ﬁll buffer instead of requiring a separate arbitration and transfer sequence across the PLB. Data in the ﬁll buffer is read with the same performance as a cache hit. The non-cacheable line remains in the ﬁll buffer until the ﬁll buffer is needed by another line transfer.

Non-cacheable reads from guarded storage and all non-cacheable writes are transferred as a single word, regardless of the value of CCR0[LWL].

PowerPC 405 Processor Block Reference Guide www.xilinx.com 67

EDK 6.1 October 6, 2003 1-800-255-7778

Chapter 2: Input/Output Interfaces

Cacheable data is transferred as a single word or as an eight-word line, depending on whether the transfer allocates a cache line. Transfers that allocate cache lines use eightword transfer sizes. Transfers that do not allocate cache lines use a single-word transfer size. Line allocation of cacheable data is controlled by the core-conﬁguration register. The

load without allocate bit CCR0[LWOA] controls line allocation for cacheable loads and the storewithout allocate bit CCR0[SWOA] controls line allocation for cacheable stores. Clearing

the appropriate bit to 0 enables line allocation (this is the default) and setting the bit to 1 disables line allocation. The dcbt and dcbtst instructions always allocate a cache line and ignore the CCR0 bits.

Data read during an eight-word line transfer (one that allocates a cache line) is placed in the DCU ﬁll buffer as it is received from the PLB slave. Cacheable writes that allocate a cache line also cause an eight-word read transfer from the PLB slave. The cacheable write replaces the appropriate bytes in the ﬁll buffer after they are read from the PLB. Subsequent data accesses to and from the same cacheable line access the ﬁll buffer during the time the remaining bytes are transferred from the PLB slave. When the ﬁll buffer is full, its contents are transferred to the data cache.

An eight-word line-write transfer occurs when the ﬁll buffer replaces an existing datacache line containing modiﬁed data. The existing cache line is written to memory before it is replaced with the ﬁll-buffer contents. The write is performed using a separate PLB transaction than the previous transfer that caused the replacement. Execution of the dcbf and dcbst instructions also cause an eight-word line write.

Address Pipelining

The DCU can overlap a data-access request with a previous request. This process, known as address pipelining, enables a second address to be presented to a PLB slave while the slave is transferring data associated with the ﬁrst address. Address pipelining can occur if a data-access request is produced before all data from a previous request are transferred by the slave. This capability maximizes PLB-transfer throughput by reducing dead cycles between multiple requests. The DCU can pipeline up to two read requests and one write request (multiple write requests cannot be pipelined). A pipelined request is communicated over the PLB two or more cycles after the prior request is acknowledged by the PLB slave.

Unaligned Accesses

If necessary,the processor automatically decomposes accesses to unaligned operands into two data-access requests that are presented separately to the PLB. This occurs if an operand crosses a word boundary (for a word transfer) or a cache line boundary (for an eight-word line transfer). For example, assume software reads the unaligned word at address 0x1F. This word crosses a cache line boundary: the byte at address 0x1F is in one cache line and the bytes at addresses 0x20:0x22 are in another cache line. If neither cache line is in the data cache, two consecutive read requests are presented by the DCU to the PLB slave. If one cache line is already in the data cache, only the missing portion is requested by the DCU.

Because write requestsarenot addresspipelinedbythe DCU, writes to unaligned data that cross cache line boundaries can take signiﬁcantly longer than aligned writes.

Guarded Storage

No bytes can be accessed speculatively from guarded storage. The PLB slave must return only the requested data when guarded storage is read and update only the speciﬁed memory locations when guarded storage is written. For single word transfers, only the

68 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Data-Side Processor Local Bus Interface

bytes indicated by the byte enables are transferred. For line transfers, all eight words in the line are transferred.

Data-Side PLB Interface I/O Signal Table

Figure 2-15 shows the block symbol for the data-side PLB interface. The signals are

summarized in Table 2-12.

PLBC405DCUADDRACK

PLBC405DCUSSIZE1

PLBC405DCURDDACK

PLBC405DCURDDBUS[0:63]

PLBC405DCURDWDADDR[1:3]

PLBC405DCUWRDACK

PLBC405DCUBUSY

PLBC405DCUERR

PPC405

C405PLBDCUREQUEST C405PLBDCURNW C405PLBDCUABUS[0:31] C405PLBDCUSIZE2 C405PLBDCUCACHEABLE C405PLBDCUWRITETHRU C405PLBDCUU0ATTR C405PLBDCUGUARDED C405PLBDCUBE[0:7] C405PLBDCUPRIORITY[0:1] C405PLBDCUABORT C405PLBDCUWRDBUS[0:63]

UG018_05_102001

Figure 2-15: Data-Side PLB Interface Block Symbol

Table 2-12: Data-Side PLB Interface I/O Signal Summary

Signal

C405PLBDCUREQUEST O No Connect Indicates the DCU is making a data-access request. C405PLBDCURNW O No Connect Speciﬁes whether the data-access request is a read or a

C405PLBDCUABUS[0:31] O No Connect Speciﬁes the memory address of the data-access request.

I/O

Type

If Unused Function

write.

C405PLBDCUSIZE2 O No Connect Speciﬁes a single word or eight-word transfer size. C405PLBDCUCACHEABLE O No Connect Indicates the value of the cacheability storage attribute for

the target address.

C405PLBDCUWRITETHRU O No Connect Indicates the value of the write-through storage attribute

for the target address.

C405PLBDCUU0ATTR O No Connect Indicates the value of the user-deﬁned storage attribute for

the target address.

C405PLBDCUGUARDED O No Connect Indicates the value of the guarded storage attribute for the

target address.

C405PLBDCUBE[0:7] O No Connect Speciﬁes which bytes are transferred during single-word

transfers. C405PLBDCUPRIORITY[0:1] O No Connect Indicates the priority of the data-access request. C405PLBDCUABORT O No Connect Indicates the DCU is aborting an unacknowledged data-

access request. C405PLBDCUWRDBUS[0:63] O No Connect The DCU write-data bus used to transfer data from the

DCU to the PLB slave.

PowerPC 405 Processor Block Reference Guide www.xilinx.com 69

EDK 6.1 October 6, 2003 1-800-255-7778

Table 2-12: Data-Side PLB Interface I/O Signal Summary (Continued)

Chapter 2: Input/Output Interfaces

Signal

PLBC405DCUADDRACK I 0 Indicates a PLB slave acknowledges the current data-access

PLBC405DCUSSIZE1 I 0 Speciﬁes the bus width (size) of the PLB slave that accepted

PLBC405DCURDDACK I 0 Indicates the DCU read-data bus contains valid data for

PLBC405DCURDDBUS[0:63] I 0x0000_0000

PLBC405DCURDWDADDR[1:3] I 0b000 Indicates which word or doubleword of an eight-word line

PLBC405DCUWRDACK I 0 Indicates the data on the DCU write-data bus is being

PLBC405DCUBUSY I 0 Indicates the PLB slave is busy performing an operation

PLBC405DCUERR I 0 Indicates an error was detected by the PLB slave during the

I/O

Type

If Unused Function

request.

the request.

transfer to the DCU.

The DCU read-data bus used to transfer data from the PLB

_0000_0000

slave to the DCU.

transfer is present on the DCU read-data bus.

accepted by the PLB slave.

requested by the DCU.

transfer of data to or from the DCU.

Data-Side PLB Interface I/O Signal Descriptions

The following sections describe the operation of the data-side PLB interface I/O signals. Throughout these descriptions and unless otherwise noted, the term clock refers to the PLB

clock signal, PLBCLK (see page 133 for information on this clock signal). The term cycle refers to a PLB cycle. To simplify the signal descriptions, it is assumed that PLBCLK and the PPC405x3 clock (CPMC405CLOCK) operate at the same frequency.

C405PLBDCUREQUEST (output)

When asserted, this signal indicates the DCU is presenting a data-access request to a PLB slave device. The PLB slave asserts PLBC405DCUADDRACK to acknowledge the request. The request can be acknowledged in the same cycle it is presentedby the DCU. The request is deasserted in the cycle after it is acknowledged by the PLB slave. When deasserted, no unacknowledged data-access request exists.

• C405PLBDCURNW, which speciﬁes whether the data-access request is a read or a write.

• C405PLBDCUABUS[0:31], which contains the address of the data-access request.

• C405PLBDCUSIZE2, which indicates the transfer size of the data-access request.

• C405PLBDCUCACHEABLE, which indicates whether the data address is cacheable.

• C405PLBDCUWRITETHRU, which speciﬁes the caching policy of the data address.

• C405PLBDCUU0ATTR, which indicates the value of the user-deﬁned storage attribute for the instruction-fetch address.

• C405PLBDCUGUARDED, which indicates whether the data address is in guarded storage.

70 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Data-Side Processor Local Bus Interface

If the transfer size is a single word, C405PLBDCUBE[0:7] is also valid when the request is asserted. These signals specify which bytes are transferred between the DCU and PLB slave. If the transfer size is an eight-word line, C405PLBDCUBE[0:7] is not used and must be ignored by the PLB slave.

C405PLBDCUPRIORITY[0:1] is valid when the request is asserted. This signal indicates the priority of the data-access request. It is used by the PLB arbiter to prioritize simultaneous requests from multiple PLB masters.

The DCU supports up to three outstanding requests over the PLB (two reads and one write). The DCU can make a subsequent requestafter the current request is acknowledged. The DCU deasserts C405PLBDCUREQUEST for at least one cycle after the current request is acknowledged and before the subsequent request is asserted.

If the PLB slave supports address pipelining, it must respond to multiple requests in the order they are presented by the DCU. All data associated with a prior request must be transferred before any data associated with a subsequent request is transferred. Multiple write requests are not pipelined. The DCU does not present a second write request until at least two cycles after the last write acknowledge (PLBC405DCUWRDACK) is sent from the PLB slave to the DCU, completing the ﬁrst request.

The DCU only aborts a data-access request if the processor is reset. The DCU removes a request by asserting C405PLBDCUABORT while the request is asserted. In the next cycle the request is deasserted and remains deasserted until after the processor is reset.

C405PLBDCURNW (output)

When asserted, this signal indicates the DCU is making a read request. When deasserted, this signal indicates the DCU is making a write request. This signal is valid when the DCU is presentinga data-access request to the PLB slave. The signal remains valid until the cycle following acknowledgement of the request by the PLB slave (the PLB slave asserts PLBC405DCUADDRACK to acknowledge the request).

C405PLBDCUABUS[0:31] (output)

This bus speciﬁes the memory address of the data-access request. The address is valid during the time the data-access request signal (C405PLBDCUREQUEST) is asserted. It remains valid until the cycle following acknowledgement of the request by the PLB slave (the PLB slave asserts PLBC405DCUADDRACK to acknowledge the request).

C405PLBDCUSIZE2 indicates the data-access transfer size. If an eight-word transfer size is used, memory-address bits [0:26] specify the aligned eight-word cache line to be transferred. If a single word transfer size is used, the byte enables (C405PLBDCUBE[0:7]) specify which bytes on the data bus are involved in the transfer.

C405PLBDCUSIZE2 (output)

This signal speciﬁes the transfer size of the data-access request. When asserted, an eightword transfer size is speciﬁed. When deasserted, a single word transfer size is speciﬁed. This signal is valid when the DCU is presenting a data-access request to the PLB slave. The signal remains valid until the cycle following acknowledgement of the request by the PLB slave (the PLB slave asserts PLBC405DCUADDRACK to acknowledge the request).

A single word transfer moves one to four consecutive data bytes beginning at the memory address of the data-access request. For this transfer size, C405PLBDCUBE[0:7] specify which bytes on the data bus are involved in the transfer.

An eight-word line transfer moves the cache line aligned on the address speciﬁed by C405PLBDCUABUS[0:26]. This cache line contains the target data accessed by the DCU.

PowerPC 405 Processor Block Reference Guide www.xilinx.com 71

EDK 6.1 October 6, 2003 1-800-255-7778

The cache line is transferred using four doubleword or eight word transfer operations, depending on the PLB slave bus width (64-bit or 32-bit, respectively).

The words moved during an eight-word line transfer can be sent from the PLB slave to the DCU in any order (target-word-ﬁrst, sequential, other). This transfer order is speciﬁed by PLBC405DCURDWDADDR[1:3].

C405PLBDCUCACHEABLE (output)

This signal indicates whether the accessed data is cacheable. It reﬂects the value of the cacheability storage attribute for the target address. The data is non-cacheable when the signal is deasserted (0). The data is cacheable when the signal is asserted (1). This signal is valid when the DCU is presenting a data-access request to the PLB slave. The signal remains valid until the cycle following acknowledgement of the request by the PLB slave (the PLB slave asserts PLBC405DCUADDRACK to acknowledge the request).

Non-cacheable data is usually transferred as a single word. Software can indicate that noncacheable reads be loaded using an eight-word line transfer by setting the load-word-as-line bit in the core-conﬁguration register (CCR0[LWL]) to 1. This enables non-cacheable reads to take advantage of the PLB line-transfer protocol to minimize PLB-arbitration delays and bus delays associated with multiple, single-word transfers. The transferred data is placed in the DCU ﬁll buffer, but not in the data cache. Subsequent data reads from the same noncacheable line are read from the ﬁll buffer instead of requiring a separate arbitration and transfer sequence across the PLB. Data in the ﬁll buffer are read with the same performance as a cache hit. The non-cacheable line remains in the ﬁll buffer until the ﬁll buffer is needed by another line transfer.

Chapter 2: Input/Output Interfaces

Cacheable data is transferred as a single word or as an eight-word line, depending on whether the transfer allocates a cache line. Transfers that allocate cache lines use an eightwordtransfersize. Transfers that do not allocate cache lines use a single-word transfer size. Line allocation of cacheable data is controlled by the core-conﬁguration register. The load

without allocate bit CCR0[LWOA] controls line allocation for cacheable loads and the store without allocate bit CCR0[SWOA] controls line allocation for cacheable stores. Clearing the

appropriate bit to 0 enables line allocation (this is the default) and setting the bit to 1 disables line allocation. The dcbt and dcbtst instructions always allocate a cache line and ignore the CCR0 bits.

C405PLBDCUWRITETHRU (output)

This signal indicates whether the accessed data is in write-through or write-back cacheable memory. It reﬂects the value of the write-through storage attribute which controls the caching policy of the target address. The data is in write-back memory when the signal is deasserted (0). The data is in write-through memory when the signal is asserted (1). This signal is valid when the DCU is presenting a data-access request to the PLB slave and when the data cacheability signal is asserted. The signal remains valid until the cycle following acknowledgement of the request by the PLB slave (the PLB slave asserts PLBC405DCUADDRACK to acknowledge the request).

The system designer can use this signal in systems that require shared memory coherency. Stores to write-through memory update both the data cache and system memory. Stores to write-back memory update the data cache but not system memory. Write-back memory locations are updated in system memory when a cache line is ﬂushed due to a line replacement or by executing a dcbf or dcbst instruction. See the PowerPC Processor

Reference Guide for more information on memory coherency and caching policy.

72 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Data-Side Processor Local Bus Interface

C405PLBDCUU0ATTR (output)

This signal reﬂects the value of the user-deﬁned (U0) storage attribute for the target address. The accessed data is not in a memory location characterized by this attribute when the signal is deasserted (0). It is in a memory location characterized by this attribute when the signal is asserted (1). This signal is valid when the DCU is presenting a dataaccess request to the PLB slave. The signal remains valid until the cycle following acknowledgement of the request by the PLB slave (the PLB slave asserts PLBC405DCUADDRACK to acknowledge the request).

The system designer can use this signal to assign special behavior to certain memory addresses. Its use is optional.

C405PLBDCUGUARDED (output)

This signal indicates whether the accessed data is in guarded storage. It reﬂects the value of the guarded storage attribute for the target address. The data is not in guarded storage when the signal is deasserted (0). The data is in guarded storage when the signal is asserted (1). This signal is valid when the DCU is presenting a data-access request to the PLB slave. The signal remains valid until the cycle following acknowledgement of the request by the PLB slave (the PLB slave asserts PLBC405DCUADDRACK to acknowledge the request).

No bytes are accessed speculatively from guarded storage. The PLB slave must return only the requested data when guarded storage is read and update only the speciﬁed memory locations when guarded storage is written. For single word transfers, only the bytes indicated by the byte enables are transferred. For line transfers, all eight words in the line are transferred.

C405PLBDCUBE[0:7] (output)

These signals, referred to as byte enables, indicate which bytes on the DCU read-data bus or write-data bus are valid during a word transfer. The byte enables are not used by the DCU during line transfers and must be ignored by the PLB slave. The byte enables are valid when the DCU is presenting a data-access request to the PLB slave. They remain valid until the cycle following acknowledgement of the request by the PLB slave (the PLB slave asserts PLBC405DCUADDRACK to acknowledge the request).

Attachment of a 32-bit PLB slave to the DCU (a 64-bit PLB master) requires the connections shown in Figure 2-16. These connections enable the byte enables to be presented properly to the 32-bit slave. Address bit 29 is used to select between the upper byte enables [0:3] and the lower byte enables [4:7] when making a request to the 32-bit slave. Words are always transferred to the 32-bit PLB slave using write-data bus bits [0:31], so bits [32:63] are not connected. The 32-bit read-data bus from the PLB slave is attached to both the high and low words of the 64-bit read-data bus into the DCU.

PowerPC 405 Processor Block Reference Guide www.xilinx.com 73

EDK 6.1 October 6, 2003 1-800-255-7778

64-Bit PLB Master 32-Bit PLB Slave

Chapter 2: Input/Output Interfaces

PLBC405DCURDDBUS[0:31]

PLBC405DCURDDBUS[32:63]

C405PLBDCUWRDBUS[0:31] C405PLBDCUWRDBUS[0:31]

C405PLBDCUWRDBUS[32:63]

C405PLBDCUABUS[0:31]

C405PLBDCUBE[0:3] C405PLBDCUBE[4:7]

Unconnected

[29]

PLBC405DCURDDBUS[0:31]

C405PLBDCUABUS[0:31]

C405PLBDCUBE[0:3]

UG018_20_101501

Figure 2-16: Attachment of DSPLB Between 32-Bit Slave and 64-Bit Master

Table 2-13 shows the possible values that can be presented by the byte enables and how

they are interpreted by the PLB slave. All encodings of the byte enables not shown are invalid and are not generated by the DCU. The column headed “32-Bit PLB Slave Data Bus” assumes an attachment to a 64-bit PLB master as shown in Figure 2-16.

Table 2-13: Interpretation of DCU Byte Enables During Word Transfers

Byte Enables [0:7]

32-Bit PLB Slave Data Bus 64-Bit PLB Slave Data Bus

Valid Bytes Bits Valid Bytes Bits

1000_0000 Byte 0 0:7 Byte 0 0:7 1100_0000 Bytes 0:1 (Halfword 0) 0:15 Bytes 0:1 (Halfword 0) 0:15

1110_0000 Bytes 0:2 0:23 Bytes 0:2 0:23

1111_0000 Bytes 0:3 (Word 0) 0:31 Bytes 0:3 (Word 0) 0:31 0100_0000 Byte 1 8:15 Byte 1 8:15 0110_0000 Bytes 1:2 8:23 Bytes 1:2 8:23

0111_0000 Bytes 1:3 8:31 Bytes 1:3 8:31 0010_0000 Byte 2 16:23 Byte 2 16:23 0011_0000 Bytes 2:3 (Halfword 1) 16:31 Bytes 2:3 (Halfword 1) 16:31 0001_0000 Byte 3 24:31 Byte 3 24:31 0000_1000 Byte 0 0:7 Byte 4 32:39 0000_1100 Bytes 0:1 (Halfword 0) 0:15 Bytes 4:5 (Halfword 2) 32:47

0000_1110 Bytes 0:2 0:23 Bytes 4:6 32:55

0000_1111 Bytes 0:3 (Word 0) 0:31 Bytes 4:7 (Word 1) 32:63 0000_0100 Byte 1 8:15 Byte 5 40:47 0000_0110 Bytes 1:2 8:23 Bytes 5:6 40:55

74 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Data-Side Processor Local Bus Interface

Table 2-13: Interpretation of DCU Byte Enables During Word Transfers (Continued)

Byte Enables [0:7]

0000_0111 Bytes 1:3 8:31 Bytes 5:7 40:63 0000_0010 Byte 2 16:23 Byte 6 48:55 0000_0011 Bytes 2:3 (Halfword 1) 16:31 Bytes 6:7 (Halfword 3) 48:63 0000_0001 Byte 3 24:31 Byte 7 56:63

32-Bit PLB Slave Data Bus 64-Bit PLB Slave Data Bus

Valid Bytes Bits Valid Bytes Bits

C405PLBDCUPRIORITY[0:1] (output)

These signals areused to specify the priority of the data-access request. Table 2-8 shows the encoding of the 2-bit PLB-request priority signal. The priority is valid when the DCU is presenting a data-access request to the PLB slave. It remains valid until the cycle following acknowledgement of the request by the PLB slave (the PLB slave asserts PLBC405DCUADDRACK to acknowledge the request).

Table 2-14: PLB-Request Priority Encoding

Bit 0 Bit 1 Deﬁnition

0 0 Lowest PLB-request priority. 0 1 Next-to-lowest PLB-request priority. 1 0 Next-to-highest PLB-request priority. 1 1 Highest PLB-request priority.

Bit 1 of the request priority is controlled by the DCU. It is asserted whenever a data-read request is presented on the PLB. The DCU can also assert this bit if the processor stalls due to an unacknowledged request. Software controls bit 0 of the request priority by writing the appropriate value into the DCU PLB-priority bit 1 of the core-conﬁguration register (CCR0[DPP1]).

If the least signiﬁcant bits of the DCU and ICU PLB priority signals are 1 and the most signiﬁcant bits are equal, the PLB arbiter should let the DCU win the arbitration. This generally results in better processor performance.

C405PLBDCUABORT (output)

When asserted, this signal indicates the DCU is aborting the current data-access request. It is used by the DCU to abort a request that has not been acknowledged, or is in the process of being acknowledged by the PLB slave. The data-access request continues normally if this signal is not asserted. This signal is only valid during the time the data-access request signal is asserted. It must be ignored by the PLB slave if the data-access request signal is not asserted. In the cycle after the abort signal is asserted, the data-access request signal is deasserted and remains deasserted for at least one cycle.

If the abort signal is asserted in the same cycle that the data-access request is acknowledged by the PLB slave (PLBC405DCUADDRACK is asserted), the PLB slave is responsible for ensuring that the transfer does not proceed further. The PLB slave must not assert the DCU read-data bus acknowledgement signal for an aborted request. It is possible for a PLB slave to return the ﬁrst write acknowledgement when acknowledging an aborted data-write request. In this case, memory must not be updated by the PLB slave

PowerPC 405 Processor Block Reference Guide www.xilinx.com 75

EDK 6.1 October 6, 2003 1-800-255-7778

and no further write acknowledgements can be presented by the PLB slave for the aborted request.

The DCU only aborts a data-access request when the processor is reset. Such an abort can occur during an address-pipelined data-access request while the PLB slave is responding to a previous data-access request. If the PLB is not also reset (as is the case during a core reset), the PLB slave is responsible for completing the previous request and aborting the new (pipelined) request.

PLBC405DCUWRDBUS[0:63] (output)

This write-data bus contains the data transferred from the DCU to a PLB slave during a write transfer. The operation of this bus depends on the transfer size, as follows:

• During a single word write, the write-data bus is valid when the write request is presented by the DCU. The data remains valid until the PLB slave accepts the data. The PLB slave asserts the write-data acknowledgement signal when it latches data transferred on the write-data bus, indicating that it accepts the data. This completes the word write.

The DCU replicates the data on the high and low words of the write data bus (bits [0:31] and [32:63], respectively) during a single word write. The byte enables indicate which bytes on the high word or low word are valid and should be latched by the PLB slave.

• During an eight-word line transfer, the write-data bus is valid when the write request is presented by the DCU. The data remains valid until the PLB slave accepts the data. The PLB slave asserts the write-data acknowledgement signal when it latches data transferred on the write-data bus, indicating that it accepts the data. In the cycle after the PLB slave accepts the data, the DCU presents the next word or doubleword of data (depending on the PLB slave size). Again, the PLB slave asserts the write-data acknowledgement signal when it latches data transferred on the write-data bus, indicating that it accepts the data. This continues until all eight words are transferred to the PLB slave.

Data is transferred from the DCU to the PLB slave in ascending address order. Word 0 (lowest address of the cache line) is transferred ﬁrst and word 7 (highest address) is transferred last. The byte enables are not used during a line transfer and must be ignored by the PLB slave.

The location of data on the write-data bus depends on the size of the PLB slave, as follows:

- If the slave has a 64-bit bus, the DCU transfers even words (words 0, 2, 4, and 6)

on write-data bus bits [0:31] and odd words (words 1, 3, 5, and 7) on write-data bus bits [32:63]. Four doubleword writes are required to complete the eight-word line transfer. The ﬁrst transfer writes words 0 and 1, the second transfer writes words 2 and 3, and so on.

- If the slave has a 32-bit bus, the DCU transfers all words on write-data bus bits

[0:31]. Eight doubleword writes are required to complete the eight-word line transfer. The ﬁrst transfer writes word 0, the second transfer writes word 1, and so on.

Table 2-15 summarizes the location of words on the write-data bus during an eight-

word line transfer.

Chapter 2: Input/Output Interfaces

76 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Data-Side Processor Local Bus Interface

Table 2-15: Contents of DCU Write-Data Bus During Eight-Word Line Transfer

PLB-Slave

Size

32-Bit First Word 0

64-Bit First Word 0 Word 1

Transfer

Second Word 1

Third Word 2

Fourth Word 3

Fifth Word 4

Sixth Word 5

Seventh Word 6

Eighth Word 7

Second Word 2 Word 3

Third Word 4 Word 5

Fourth Word 6 Word 7

DCU Write-Data Bus

[0:31]

DCU Write-Data Bus

[32:63]

Not Applicable

PLBC405DCUADDRACK (input)

When asserted, this signal indicates the PLB slave acknowledges the DCU data-access request(indicatedbytheDCU assertion of C405PLBDCUREQUEST). When deasserted, no such acknowledgement exists. A data-access request can be acknowledged by the PLB slave in the same cycle the request is asserted by the DCU. The PLB slave must latch the following data-access request information in the same cycle it asserts the request acknowledgement:

• C405PLBDCURNW, which speciﬁes whether the data-access request is a read or a write.

• C405PLBDCUABUS[0:31], which contains the address of the data-access request.

• C405PLBDCUSIZE2, which indicates the transfer size of the data-access request.

• C405PLBDCUCACHEABLE, which indicates whether the data address is cacheable.

• C405PLBDCUWRITETHRU, which speciﬁes the caching policy of the data address.

• C405PLBDCUU0ATTR, which indicates the value of the user-deﬁned storage attribute for the instruction-fetch address.

• C405PLBDCUGUARDED, which indicates whether the data address is in guarded storage.

During the acknowledgement cycle, the PLB slave must return its bus width indicator (32 bits or 64 bits) using the PLBC405DCUSSIZE1 signal.

The acknowledgement signal remains asserted for one cycle. In the next cycle, both the data-access request and acknowledgement are deasserted. The PLB slave can begin receiving data from the DCU in the same cycle the address is acknowledged. Data can be sent to the DCU beginning in the cycle after the address acknowledgement. The PLB slave must abort a DCU request (move no data) if the DCU asserts C405PLBDCUABORT in the same cycle the PLB slave acknowledges the request.

PowerPC 405 Processor Block Reference Guide www.xilinx.com 77

EDK 6.1 October 6, 2003 1-800-255-7778

The DCU supports up to three outstanding requests over the PLB (two read and one write). The DCU can make a subsequent requestafter the current request is acknowledged. The DCU deasserts C405PLBDCUREQUEST for at least one cycle after the current request is acknowledged and before the subsequent request is asserted.

If the PLB slave supports address pipelining, it must respond to multiple requests in the order they are presented by the DCU. All data associated with a prior request must be moved before data associated with a subsequent request is accessed. The DCU cannot present a third read request until the ﬁrst read request is completed by the PLB slave, or a second write request until the ﬁrst write request is completed. Such a request (third read or second write) can be presented two cycles after the last acknowledge is sent from the PLB slave to the DCU, completing the ﬁrst request (read or write, respectively).

PLBC405DCUSSIZE1 (input)

This signal indicates the bus width (size) of the PLB slave device that acknowledged the DCU request. A 32-bit PLB slave responded when the signal is deasserted (0). A 64-bit PLB slave responded when the signal is asserted (1). This signal is valid during the cycle the acknowledge signal (PLBC405DCUADDRACK) is asserted.

A 32-bit PLB slave must be attached to a 64-bit PLB master as shown in Figure 2-16,

page 74. In this ﬁgure, the 32-bit read-data bus from the PLB slave is attached to both the

high word and low word of the 64-bit read-data bus at the PLB master. The 32-bit writedata bus into the PLB slave is attached to the high word of the 64-bit write-data bus at the PLB master.The low word of the 64-bit write-data bus is not connected. When a 64-bit PLB master recognizes a 32-bit PLB slave (the size signal is deasserted), data transfers operate as follows:

Chapter 2: Input/Output Interfaces

• During a single word read, data is received by the 64-bit master over the high word (bits 0:31) or the low word (bits 32:63) of the read-data bus as speciﬁed by the byte enable signals.

• During an eight-word line read, data is received by the 64-bit master over the high word (bits 0:31) or the low word (bits 32:63) of the read-data bus as speciﬁed by bit 3 of the transfer order (PLBC405DCURDWDADDR[1:3]). Table 2-10, page 53, shows the location of data on the DCU read-data bus as a function of transfer order when an eight-word line read from a 32-bit PLB slave occurs.

• During a single word write or an eight-word line write, data is sent by the 64-bit master over the high word (bits 0:31) of the write-data bus. Table 2-15, page 77, shows the order data is transferred to a 32-bit PLB slave during an eight-word line write.

All bits of the read-data bus and write-data bus are directly connected between a 64-bit PLB slave and a 64-bit PLB master.When a 64-bit PLB master recognizes a 64-bit PLB slave (the size signal is asserted), data transfers operate as follows:

• During a single word read, data is received by the 64-bit master over the high word (bits 0:31) or the low word (bits 32:63) of the read-data bus as speciﬁed by the byte enable signals.

• During an eight-word line read, data is received by the 64-bit master over the entire read-data bus. Table 2-10, page 53, shows the location of data on the DCU read-data bus as a function of transfer order when an eight-word line read from a 64-bit PLB slave occurs.

• During a single word write, the DCU replicates the data on the high and low words of the write data bus. The byte enables indicate which bytes on the high word or low word are valid and should be latched by the PLB slave.

• During an eight-word line write, data is sent by the 64-bit master over the entire

78 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Data-Side Processor Local Bus Interface

write-data bus. Table 2-15, page 77, shows the order data is transferred to a 64-bit PLB slave during an eight-word line write. Data is written in order of ascending address, so the transfer order signals are not used during a line write.

PLBC405DCURDDACK (input)

When asserted, this signal indicates the DCU read-data bus contains valid data sent by the PLB slave to the DCU (read data is acknowledged). The DCU latches the data from the bus at the end of the cycle this signal is asserted. The contents of the DCU read-data bus are not valid when this signal is deasserted.

Read-data acknowledgement is asserted for one cycle per transfer. There is no limit to the number of cycles between two transfers. The number of transfers (and the number of readdata acknowledgements) depends on the PLB slave size (speciﬁed by PLBC405DCUSSIZE1) and the line-transfer size (speciﬁed by C405PLBDCUSIZE2). The number of transfers are summarized as follows:

• Single word reads require one transfer, regardless of the PLB slave size.

• Eight-word line reads require eight transfers when sent from a 32-bit PLB slave.

• Eight-word line reads require four transfers when sent from a 64-bit PLB slave.

PLBC405DCURDDBUS[0:63] (input)

This read-data bus contains the data transferred from a PLB slave to the DCU. The contents of the bus are valid when the read-data acknowledgement signal is asserted. This acknowledgment is asserted for one cycle per transfer. There is no limit to the number of cycles between two transfers. The bus contents are not valid when the read-data acknowledgement signal is deasserted.

The PLB slave returns data as an aligned word or an aligned doubleword. This depends on the PLB slave size (bus width), as follows:

• When a 32-bit PLB slave responds, an aligned word is sent from the slave to the DCU during each transfer cycle. The 32-bit PLB slave bus should be connected to both the high and low 32 bits of the 64-bit read-data bus (see Figure 2-16, page 74). This type of connection duplicates the word returned by the slave across the 64-bit bus. The DCU reads either the low 32 bits or the high 32 bits of the 64-bit interface, depending on the value of PLBC405DCURDWDADDR[1:3].

• When a 64-bit PLB slave responds, an aligned doubleword is sent from the slave to the DCU during each transfer cycle. Both words are read from the 64-bit interface by the DCU in this cycle.

For a single word transfer,the bytes enables are used to select the valid data bytes from the aligned word or doubleword. Table 2-13, page 74 shows how the byte enables are interpreted by the processor when reading data during single word transfers from 32-bit and 64-bit PLB slaves. Table 2-10 shows the location of data on the DCU read-data bus as a function of PLB-slave size and transfer order when an eight-word line read occurs.

PLBC405DCURDWDADDR[1:3] (input)

These signals are used to specify the transfer order. They identify which word or doubleword of an eight-word line transfer is present on the DCU read-data bus when the PLB slave returns instructions to the DCU. The words returned during a line transfer can be sent from the PLB slave to the DCU in any order (target-word-ﬁrst, sequential, other). The transfer-order signals are valid when the read-data acknowledgement signal (PLBC405DCURDDACK) is asserted. This acknowledgment is asserted for one cycle per

PowerPC 405 Processor Block Reference Guide www.xilinx.com 79

EDK 6.1 October 6, 2003 1-800-255-7778

Chapter 2: Input/Output Interfaces

transfer. Thereis no limit to the number of cycles between two transfers. The transfer-order signals are not valid when the read-data acknowledgement signal is deasserted.

These signals are ignored by the processor during single word transfers.

Table 2-10 shows the location of data on the DCU read-data bus as a function of PLB-slave

size and transfer order when an eight-word line read occurs. In this table, the “Transfer Order” column contains the possible values of PLBC405DCURDWDADDR[1:3]. For 64-bit PLB slaves, PLBC405DCURDWDADDR[3] should always be 0 during a transfer. In this case, the transfer order is invalid if this signal asserted. For 32-bit slaves, the connection to a 64-bit master shown in Figure 2-16, page 74 is assumed.

Table 2-16: Contents of DCU Read-Data Bus During Eight-Word Line Transfer

PLB-Slave

Size

32-Bit 000 Word 0 Word 0

64-Bit 000 Word 0 Word 1

Notes:

1. “x” indicates a don’t-care value in PLBC405DCURDWDADDR[1:3].

2. A word shown in italics is ignored by the DCU during the transfer.

Transfer

Order

001 Word 1 Word 1 010 Word 2 Word 2 011 Word 3 Word 3 100 Word 4 Word 4 101 Word 5 Word 5 110 Word 6 Word 6

111 Word 7 Word 7

010 Word 2 Word 3 100 Word 4 Word 5 110 Word 6 Word 7 xx1 Invalid

DCU Read-Data Bus

[0:31]

DCU Read-Data Bus

[32:63]

PLBC405DCUWRDACK (input)

When asserted, this signal indicates the PLB slave latched the data on the write-data bus sent from the DCU (write data is acknowledged). The DCU holds this data valid until the end of the cycle this signal is asserted. In the following cycle, the DCU presents new data and holds it valid until acknowledged by the PLB slave. This continues until all write data is transferred from the DCU to the PLB slave. If this signal is deasserted, valid data on the write data bus has not been latched by the PLB slave.

Write-data acknowledgement is asserted for one cycle per transfer. There is no limit to the number of cycles between two transfers. The number of transfers (and the number of write-data acknowledgements) depends on the PLB slave size (speciﬁed by PLBC405DCUSSIZE1 and the line-transfer size (speciﬁed by C405PLBDCUSIZE2). The number of transfers are summarized as follows:

• Single word writes require one transfer, regardless of the PLB slave size.

80 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Data-Side Processor Local Bus Interface

• Eight-word line writes require eight transfers when sent to a 32-bit PLB slave.

• Eight-word line writes require four transfers when sent to a 64-bit PLB slave.

PLBC405DCUBUSY (input)

When asserted, this signal indicates the PLB slave acknowledged and is responding to (is busy with) a DCU data-access request. When deasserted, the PLB slave is not responding to a DCU data-access request.

This signal should be asserted in the cycle after a DCU request is acknowledged by the PLB slave and remain asserted until the request is completed by the PLB slave. For read requests,itshould be deasserted in the cycle after the last read-dataacknowledgement. For write requests, it should be deasserted in the cycle after the target memory device is updated by the PLB slave. If multiple requests are initiated and overlap, the busy signal should be asserted in the cycle after the ﬁrst request is acknowledged and remain asserted until the cycle after the last request is completed.

The processor monitors the busy signal when executing a sync instruction. The sync instruction requires that all storage operations initiated prior to the sync be completed before subsequent instructions are executed. Storage operations are considered complete when there are no pending DCU requests and the busy signal is deasserted.

Following reset, the processor block prevents the DCU from accessing data until the busy signal is deasserted for the ﬁrst time. This is useful in situations where the processor block is reset by a core reset, but PLB devices are not reset. Waiting for the busy signal to be deasserted prevents data accesses following reset from interfering with PLB activity that was initiated before reset.

PLBC405DCUERR (input)

When asserted, this signal indicates the PLB slave detected an error when attempting to transfer data to or from the DCU. The error signal should be asserted for only one cycle. When deasserted, no error is detected.

For read operations, this signal should be asserted with the read-data acknowledgement signal that corresponds to the erroneous transfer. For write operations, it is possible for the error to not be detected until some time after the data is accepted by the PLB slave. Thus, the signal can be asserted independently of the write-data acknowledgement signal that corresponds to the erroneous transfer. However, it must be asserted while the busy signal is asserted.

The PLB slave must not terminate data transfers when an error is detected. The processor block is responsible for responding to any error detected by the PLB slave. A machinecheck exception occurs if the exception is enabled by software (MSR[ME]=1) and data is transferred between the processor block and a PLB slave while the error signal is asserted.

PowerPC 405 Processor Block Reference Guide www.xilinx.com 81

EDK 6.1 October 6, 2003 1-800-255-7778

Data-Side PLB Interface Timing Diagrams

The following timing diagrams show typical transfers that can occur on the DSPLB interface between the DCU and a bus-interface unit (BIU). These timing diagrams represent the optimal timing relationships supported by the processor block. The BIU can be implemented using the FPGA processor local bus (PLB) or using customized hardware. Not all BIU implementations support these optimal timing relationships.

DSPLB Timing Diagram Assumptions

The following assumptions and simpliﬁcations were made in producing the optimal timing relationships shown in the timing diagrams:

• Requests are acknowledged by the BIU in the same cycle they are presented by the DCU if the BIU is not busy. This represents the earliest cycle a BIU can acknowledge a request. If the BIU is busy, the request is acknowledged in a later cycle.

• The ﬁrst read-data acknowledgement for a data read is asserted in the cycle immediately following the read-request acknowledgement. This represents the earliest cycle a BIU can begin transferring data to the DCU in response to a read request. However, the earliest the FPGA PLB begins transferring data is two cycles after the read request is acknowledged.

• Subsequent read-data acknowledgements for eight-word line transfers are asserted in the cycle immediately following the prior read-data acknowledgement. This represents the fastest rate at which a BIU can transfer data to the DCU (there is no limit to the number of cycles between two transfers).

• The ﬁrst write-data acknowledgement for a data write is asserted in the same cycle as the write-request acknowledgement. This represents the earliest cycle a BIU can begin accepting data from the DCU in response to a write request.

• Subsequent write-data acknowledgements for eight-word line transfers are asserted in the cycle immediately following the prior write-data acknowledgement. This represents the fastest rate at which the DCU can transfer data to the BIU (there is no limit to the number of cycles between two transfers).

• All eight-word line reads assume the target data (word) is returned ﬁrst. Subsequent data in the line is returned sequentially by address, wrapping as necessary to the lower addresses in the same line.

• The transfer of read data from the ﬁll buffer to the data cache (ﬁll operation) takes three cycles. This transfer takes place after all data is read into the ﬁll buffer from the BIU.

• The queuing of data ﬂushed from the data cache (ﬂush operation) takes two cycles. The PPC405x3 can queue up to two ﬂush operations.

• The BIU size (bus width) is 64 bits, so PLBC405DCUSSIZE1 is not shown.

• No data-access errors occur, so PLBC405DCUERR is not shown.

• The abort signal, C405PLBDCUABORT is shown only in the last example.

• The storage attribute signals are not shown.

• The DCU activity is shown only as an aide in describing the examples. The occurrence and duration of this activity is not observable on the DSPLB.

Chapter 2: Input/Output Interfaces

The following abbreviations appear in the timing diagrams:

82 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Data-Side Processor Local Bus Interface

Table 2-17: Key to DSPLB Timing Diagram Abbreviations

Abbreviation

Description Where Used

rl#, wl# Eight-word line read-request or write-

request identiﬁer, respectively

rw#, ww# Single word read-request or write-request

identiﬁer, respectively

Request Request acknowledge Read-data acknowledge Write-data acknowledge

(C405PLBDCUREQUEST) (PLBC405DCUADDRACK) (PLBC405DCURDDACK) (PLBC405DCUWRDACK)

(C405PLBDCUREQUEST) (PLBC405DCUADDRACK) (PLBC405DCURDDACK)

(PLBC405DCUWRDACK) adr# Data-access request address Request address (C405PLBDCUABUS[0:31]) d#

A doubleword (eight data bytes) transferred as a result of an eight-word line transfer

DCU read-data bus DCU write-data bus

(PLBC405DCURDDBUS[0:63])

(PLBC405DCUWRDBUS[0:63])

request

d# A word (four data bytes) transferred as a

result of a single word transfer request

DCU read-data bus DCU write-data bus

(PLBC405DCURDDBUS[0:63])

(PLBC405DCUWRDBUS[0:63]) val Byte enables are valid Byte enables (C405PLBDCUBE[0:7]) ﬂush# The DCU is busy performing a ﬂush

DCU

operation ﬁll# The DCU is busy performing a ﬁll operation DCU Subscripts Used to identify the data words transferred

between the BIU and DCU

Read-data acknowledge DCU read-data bus Write-dataacknowledge DCU write-data bus

(PLBC405DCURDDACK) (PLBC405DCURDDBUS[0:63]) (PLBC405DCUWRDACK) (PLBC405DCUWRDBUS[0:63])

# Used to identify the order doublewords are

sent to the DCU

Notes:

1. “#” indicates a number.

Transfer order (PLBC405DCURDWDADDR[1:3])

PowerPC 405 Processor Block Reference Guide www.xilinx.com 83

EDK 6.1 October 6, 2003 1-800-255-7778

DSPLB Three Consecutive Line Reads

The timing diagram in Figure 2-17 shows three consecutive eight-word line reads that are address-pipelined between the DCU and BIU. It provides an example of the fastest speed at which the DCU can request and receive data over the PLB. All reads are cacheable.

The ﬁrst line read (rl1) is requested by the DCU in cycle 2. Data is sent from the BIU to the DCU ﬁll buffer in cycles 3 through 6. After all data associated with this line is read, it is transferred by the DCU from the ﬁll buffer to the data cache. This is representedby the ﬁll1 transaction in cycles 7 through 9.

The second line read (rl2) is requested by the DCU in cycle 4. The BIU responds to this request after it has completed all transactions associated with the ﬁrst request (rl1). Data is sent from the BIU to the DCU ﬁll buffer in cycles 7 through 10. After all data associated with this line is read, it is transferred by the DCU from the ﬁll buffer to the data cache. This is represented by the ﬁll2 transaction in cycles 11 through 13.

The third line read (rl3) cannot be requested until the ﬁrst request (rl1) is complete. The earliest this request can occur is in cycle 7. However, the request is delayed to cycle 10 because the DCU is busy transferring the ﬁll buffer to the data cache in cycles 7 through 9 (ﬁll1). The BIU responds to the rl3 request after it has completed all transactions associated with the second request (rl2). Data is sent from the BIU to the DCU ﬁll buffer in cycles 11 through14. After all data associated with this line is read, it is transferred by the DCU from the ﬁll buffer to the data cache. This is represented by the ﬁll3 transaction in cycles 15 through 17.

Chapter 2: Input/Output Interfaces

Cycle

PLBCLK a nd CPMC405CLK

DCU

PPC405 Outputs:

C405PLBDCUREQUEST

C405PLBDCUABUS[0:31]

C405PLBDCURNW

C405PLBDCUSIZE2

C405PLBDCUBE[0:7]

C405PLBDCUWRDBUS[0:63]

PLB/BIU Outputs:

PLBC405DCUADDRACK

PLBC405DCURDDACK

PLBC405DCURDDBUS[0:63]

PLBC405DCURDWDADDR[1:3]

PLBC405DCUWRDACK

PLBC405DCUBUSY

Figure 2-17: DSPLB Three Consecutive Line Reads

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

fill1 fill2 fill3

rl2 rl3rl1

adr1 adr2 adr3

rl2 rl3rl1

rl1

rl123rl145rl167rl201rl223rl245rl267rl301rl323rl345rl3

d101d123d145d167d201d223d245d267d301d323d345d3

024602460246

UG018_21_101701

84 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Data-Side Processor Local Bus Interface

DSPLB Line Read/Word Read/Line Read

The timing diagram in Figure 2-18 shows a sequence involving an eight-word line read, a word read, and another an eight-word line read. These requests are address-pipelined between the DCU and BIU. The line reads are cacheable and the word read is not cacheable.

The ﬁrst line read (rl1) is requested by the DCU in cycle 2 and the BIU responds in the same cycle. Data is sent from the BIU to the DCU ﬁll buffer in cycles 3 through 6. After all data associated with this line is read, it is transferred by the DCU from the ﬁll buffer to the data cache. This is represented by the ﬁll1 transaction in cycles 7 through 9.

The word read (rw2) is requested by the DCU in cycle 4. The BIU responds to this request after it has completed all transactions associated with the ﬁrst request (rl1). A single word is sent from the BIU to the DCU ﬁll buffer in cycle 7. The DCU uses the byte enables to select the appropriate bytes from the read-data bus. The data is not cacheable, so the ﬁll buffer is not transferred to the data cache after this transaction is completed.

The third line read (rl3) cannot be requested until the ﬁrst request (rl1) is complete. The earliest this request can occur is in cycle 7. However, the request is delayed to cycle 10 because the DCU is busy transferring the ﬁll buffer to the data cache in cycles 7 through 9 (ﬁll1). The BIU can respond immediately to the rl3 request because all transactions associated with the second request (rw2) are complete. Data is sent from the BIU to the DCU ﬁll buffer in cycles 11 through 14. After all data associated with this line is read, it is transferred by the DCU from the ﬁll buffer to the data cache. This is representedby the ﬁll3 transaction in cycles 15 through 17.

Cycle

PLBCLK a nd CPMC405CLK

DCU

PPC405 Outputs:

C405PLBDCUREQUEST

C405PLBDCUABUS[0:31]

C405PLBDCURNW

C405PLBDCUSIZE2

C405PLBDCUBE[0:7]

C405PLBDCUWRDBUS[0:63]

PLB/BIU Outputs:

PLBC405DCUADDRACK

PLBC405DCURDDACK

PLBC405DCURDDBUS[0:63]

PLBC405DCURDWDADDR[1:3]

PLBC405DCUWRDACK

PLBC405DCUBUSY

Figure 2-18: DSPLB Line Read/Word Read/Line Read

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

fill1 fill3

rw2 rl3rl1

adr1 adr2

val

rw2 rl3rl1

rl1

rl123rl145rl167rw2 rl301rl323rl345rl3

d101d123d145d167d2 d301d323d345d3

0246 0246

adr3

UG018_22_101701

PowerPC 405 Processor Block Reference Guide www.xilinx.com 85

EDK 6.1 October 6, 2003 1-800-255-7778

DSPLB Three Consecutive Word Reads

The timing diagram in Figure 2-19 shows three consecutive word reads. The word reads could be in response to non-cacheable loads or cacheable loads that do not allocate a cache line.

Figure 2-19 provides an example of the fastest speed at which the PPC405x3 DCU can

requestand receivesingle words over the PLB. The DCU is designed to wait for the current single-word read request to be satisﬁed before making a subsequent request. This requirement results in the delay between requests shown in the ﬁgure. It is possible for other PLB masters to request and receive single words at a faster rate than shown in this example.

The ﬁrst word read (rw1) is requested by the DCU in cycle 2 and the BIU responds in the same cycle. A single word is sent from the BIU to the DCU in cycle 3. The DCU uses the byte enables to select the appropriate bytes from the read-data bus.

The second word read(rw2)is requestedbythe DCU in cycle 7 and the BIU responds in the same cycle. A single word is sent from the BIU to the DCU in cycle 8. The DCU uses the byte enables to select the appropriate bytes from the read-data bus.

The third word read (rw3) is requested by the DCU in cycle 12 and the BIU responds in the same cycle. A single word is sent from the BIU to the DCU in cycle 13. The DCU uses the byte enables to select the appropriate bytes from the read-data bus.

Chapter 2: Input/Output Interfaces

Cycle

PLBCLK a nd CPMC405CLK

DCU

PPC405 Outputs:

C405PLBDCUREQUEST

C405PLBDCUABUS[0:31]

C405PLBDCURNW

C405PLBDCUSIZE2

C405PLBDCUBE[0:7]

C405PLBDCUWRDBUS[0:63]

PLB/BIU Outputs:

PLBC405DCUADDRACK

PLBC405DCURDDACK

PLBC405DCURDDBUS[0:63]

PLBC405DCURDWDADDR[1:3]

PLBC405DCUWRDACK

PLBC405DCUBUSY

Figure 2-19: DSPLB Three Consecutive Word Reads

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

rw2 rw3rw1

adr1 adr2 adr3

val valval

rw2 rw3rw1

d1 d2 d3

UG018_23_101701

86 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Data-Side Processor Local Bus Interface

DSPLB Three Consecutive Line Writes

The timing diagram in Figure 2-20 shows three consecutive eight-word line writes. It provides an example of the fastest speed at which the DCU can request and send data over the PLB. All writes are cacheable. Consecutive writes cannot be address pipelined between the DCU and BIU.

The ﬁrst line write (wl1) is requested by the DCU in cycle 3 in response to a cache ﬂush (representedby the ﬂush1 transaction in cycles 1 through 2). The BIU responds in the same cycle the request is made by the DCU. Data is sent from the DCU to the BIU in cycles 3 through 6.

The second line write (wl2) cannot be started until the ﬁrst request is complete. This request is made by the DCU in cycle 8 in response to the cache ﬂush in cycles 3 through 4 (ﬂush2). The BIU responds in the same cycle the request is made by the DCU. Data is sent from the DCU to the BIU in cycles 8 through 11.

The DCU can queue two outstanding data-cache ﬂush requests. In this example, a third ﬂush request cannot be queued until the ﬁrst is complete. The third ﬂush request (ﬂush3) is queued in cycles 8 and 9.

The third line write (wl3) cannot be started until the second request (wl2) is complete. This request is made by the DCU in cycle 13 in response to the ﬂush3 request. The BIU responds in the same cycle the request is made by the DCU. Data is sent from the DCU to the BIU in cycles 13 through 16.

Cycle

PLBCLK a nd CPMC405CLK

DCU

PPC405 Outputs:

C405PLBDCUREQUEST

C405PLBDCUABUS[0:31]

C405PLBDCURNW

C405PLBDCUSIZE2

C405PLBDCUBE[0:7]

C405PLBDCUWRDBUS[0:63]

PLB/BIU Outputs:

PLBC405DCUADDRACK

PLBC405DCURDDACK

PLBC405DCURDDBUS[0:63]

PLBC405DCURDWDADDR[1:3]

PLBC405DCUWRDACK

PLBC405DCUBUSY

Figure 2-20: DSPLB Three Consecutive Line Writes

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

flush1 flush2 flush3

wl2 wl3wl1

adr1 adr2 adr3

d101d123d145d1

wl101wl123wl145wl167wl201wl223wl245wl2

d201d223d245d2

wl2 wl3wl1

d301d323d345d3

wl301wl323wl345wl3

UG018_24_101701

PowerPC 405 Processor Block Reference Guide www.xilinx.com 87

EDK 6.1 October 6, 2003 1-800-255-7778

DSPLB Line Write/Word Write/Line Write

The timing diagram in Figure 2-21 shows a sequence involving an eight-word line write, a word write, and another an eight-word line write. Consecutive writes cannot be address pipelined between the DCU and BIU. The line writes are cacheable. The word writes could be in response to non-cacheable stores, cacheable stores to write-through memory, or cacheable stores that do not allocate a cache line.

The word write (ww2) cannot be started until the ﬁrst request is complete. This request is made by the DCU in cycle 8 and the BIU responds in the same cycle. A single word is sent from the DCU to the BIU in cycle 8. The BIU uses the byte enables to select the appropriate bytes from the write-data bus.

The DCU queues the second ﬂush request, ﬂush3. The second line write (wl3) cannot be started until the second request (ww2) is complete. This request is made by the DCU in cycle 10 in response to the ﬂush3 request. The BIU responds in the same cycle the request is made by the DCU. Data is sent from the DCU to the BIU in cycles 10 through 13.

Chapter 2: Input/Output Interfaces

Cycle

PLBCLK a nd CPMC405CLK

DCU

PPC405 Outputs:

C405PLBDCUREQUEST

C405PLBDCUABUS[0:31]

C405PLBDCURNW

C405PLBDCUSIZE2

C405PLBDCUBE[0:7]

C405PLBDCUWRDBUS[0:63]

PLB/BIU Outputs:

PLBC405DCUADDRACK

PLBC405DCURDDACK

PLBC405DCURDDBUS[0:63]

PLBC405DCURDWDADDR[1:3]

PLBC405DCUWRDACK

PLBC405DCUBUSY

Figure 2-21: DSPLB Line Write/Word Write/Line Write

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

flush1 flush3

ww2 wl3wl1

adr1 adr2 adr3

val

d101d123d145d1

wl101wl123wl145wl1

ww2 wl3wl1

ww2 wl301wl323wl345wl3

d301d323d345d3

UG018_25_101701

88 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Data-Side Processor Local Bus Interface

DSPLB Three Consecutive Word Writes

The timing diagram in Figure 2-22 shows three consecutive word writes. It provides an example of the fastest speed at which the DCU can request and send single words over the PLB. The word writes could be in response to non-cacheable stores, cacheable stores to write-through memory, or cacheable stores that do not allocate a cache line. Consecutive writes cannot be address pipelined between the DCU and BIU.

The ﬁrst word write (ww1) is requested by the DCU in cycle 2. The BIU responds in the same cycle the request is made by the DCU. A single word is sent from the DCU to the BIU in cycle 2. The BIU uses the byte enables to select the appropriate bytes from the write-data bus.

The second word write (ww2) is requested after the ﬁrst write is complete. The DCU makes the request in cycle 4 and the BIU responds in the same cycle. A single word is sent from the DCU to the BIU in cycle 4. The BIU uses the byte enables to select the appropriate bytes from the write-data bus.

The third word write (ww3) is requested after the second write is complete. The DCU makes the request in cycle 6 and the BIU responds in the same cycle. A single word is sent from the DCU to the BIU in cycle 6. The BIU uses the byte enables to select the appropriate bytes from the write-data bus.

Cycle

PLBCLK a nd CPMC405CLK

DCU

PPC405 Outputs:

C405PLBDCUREQUEST

C405PLBDCUABUS[0:31]

C405PLBDCURNW

C405PLBDCUSIZE2

C405PLBDCUBE[0:7]

C405PLBDCUWRDBUS[0:63]

PLB/BIU Outputs:

PLBC405DCUADDRACK

PLBC405DCURDDACK

PLBC405DCURDDBUS[0:63]

PLBC405DCURDWDADDR[1:3]

PLBC405DCUWRDACK

PLBC405DCUBUSY

Figure 2-22: DSPLB Three Consecutive Word Writes

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

ww2 ww3ww1

adr1 adr2 adr3

val val val

d1 d2 d3

ww2 ww3ww1

UG018_26_101701

PowerPC 405 Processor Block Reference Guide www.xilinx.com 89

EDK 6.1 October 6, 2003 1-800-255-7778

DSPLB Line Write/Line Read/Word Write

The timing diagram in Figure 2-23 shows a sequence involving an eight-word line write, an eight-word line read, and a word write. It provides an example of address pipelining involving writes and reads. It also demonstrates how read and write operations can overlap due to the split read-data and write-data busses.

The ﬁrst line read (rl2) is address pipelined with the previous line write. The rl2 request is made by the DCU in cycle 5 and the BIU responds in the same cycle. Data is sent from the BIU to the DCU ﬁll buffer in cycles 6 through 9. Because of the split data bus, a read operation overlaps with a previous write operation in cycle 6. After all data associated with this line is read, it is transferred by the DCU from the ﬁll buffer to the data cache. This is represented by the ﬁll2 transaction in cycles 10 through 12.

The word write (ww3) cannot be requested until the ﬁrst write request (wl1) is complete because address pipelining of multiple write requests is not supported. However, this request is address pipelined with the previous line read request (rl2). The ww3 request is made by the DCU in cycle 8 and the BIU responds in the same cycle. A single word is sent from the DCU to the BIU in cycle 8. The BIU uses the byte enables to select the appropriate bytes from the write-data bus. Because of the split data bus, this write operation overlaps with a read operation from the previous read request (rl2).

Chapter 2: Input/Output Interfaces

Cycle

PLBCLK a nd CPMC405CLK

DCU

PPC405 Outputs:

C405PLBDCUREQUEST

C405PLBDCUABUS[0:31]

C405PLBDCURNW

C405PLBDCUSIZE2

C405PLBDCUBE[0:7]

C405PLBDCUWRDBUS[0:63]

PLB/BIU Outputs:

PLBC405DCUADDRACK

PLBC405DCURDDACK

PLBC405DCURDDBUS[0:63]

PLBC405DCURDWDADDR[1:3]

PLBC405DCUWRDACK

PLBC405DCUBUSY

Figure 2-23: DSPLB Line Write/Line Read/Word Write

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

flush1 fill2

rl2 ww3wl1

adr1 adr2

d101d123d145d1

rl2 ww3wl1

wl101wl123wl145wl1

adr3

val

rl201rl223rl245rl2

d201d223d245d2

0246

ww3

UG018_27_101701

90 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Data-Side Processor Local Bus Interface

DSPLB Word Write/Word Read/Word Write/Line Read

The timing diagram in Figure 2-24 shows a sequence involving a word write, a word read, another word write, and an eight-word line read.

The ﬁrst word write (ww1) is requested by the DCU in cycle 2 and the BIU responds in the same cycle. A single word is sent from the DCU to the BIU in cycle 2. The BIU uses the byte enables to select the appropriate bytes from the write-data bus.

The ﬁrst word read (rw2) is requested by the DCU in cycle 4. Even though the previous request is completed in cycle 2, this is the earliest an address pipelined request can be started by the DCU. The BIU responds in the same cycle the rw2 request is made by the DCU. A single word is sent from the BIU to the DCU in cycle 5. The DCU uses the byte enables to select the appropriate bytes from the write-data bus.

The second word write (ww3) is requested by the DCU in cycle 6. Again, this is the earliest an address pipelined request can be started by the DCU. The BIU responds in the same cycle the ww3 request is made by the DCU. A single word is sent from the DCU to the BIU in cycle 6. The BIU uses the byte enables to select the appropriate bytes from the write-data bus.

The line read (rl4) is address pipelined with the word write. The rl4 request is made by the DCU in cycle 8 and the BIU responds in the same cycle. Data is sent from the BIU to the DCU ﬁll buffer in cycles 9 through 12. After all data associated with this line is read, it is transferred by the DCU from the ﬁll buffer to the data cache. This is representedby the ﬁll4 transaction in cycles 13 through 15.

Cycle

PLBCLK a nd CPMC405CLK

DCU

PPC405 Outputs:

C405PLBDCUREQUEST

C405PLBDCUABUS[0:31]

C405PLBDCURNW

C405PLBDCUSIZE2

C405PLBDCUBE[0:7]

C405PLBDCUWRDBUS[0:63]

PLB/BIU Outputs:

PLBC405DCUADDRACK

PLBC405DCURDDACK

PLBC405DCURDDBUS[0:63]

PLBC405DCURDWDADDR[1:3]

PLBC405DCUWRDACK

PLBC405DCUBUSY

Figure 2-24: DSPLB Word Write/Word Read/Word Write/Line Read

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

fill4

rw2 rl4ww1 ww3

adr1 adr2 adr3 adr4

val val val

d1 d3

rw2 rl4ww1 ww3

rw2 rl401rl423rl445rl4

ww3ww1

d401d423d445d4

0246

UG018_28_101701

PowerPC 405 Processor Block Reference Guide www.xilinx.com 91

EDK 6.1 October 6, 2003 1-800-255-7778

DSPLB Word Write/Line Read/Line Write

The timing diagram in Figure 2-25 shows a sequence involving a word write, an eightword line read, and an eight-word line write. It demonstrates how read and write operations can overlap due to the split read-data and write-data busses.

The wordwrite (ww1) is requested by the DCU in cycle 2 and the BIU responds in the same cycle. A single word is sent from the DCU to the BIU in cycle 2. The BIU uses the byte enables to select the appropriate bytes from the write-data bus.

The line read (rl2) is address pipelined with the previous word write. The rl2 request is made by the DCU in cycle 4 and the BIU responds in the same cycle. Data is sent from the BIU to the DCU ﬁll buffer in cycles 5 through 8. After all data associated with this line is read, it is transferred by the DCU from the ﬁll buffer to the data cache. This is represented by the ﬁll2 transaction in cycles 9 through 11.

The line write (wl3) is address pipelined with the previous line read. The wl3 request is made by the DCU in cycle 6 in response to the cache ﬂush in cycles 4 through 5 (ﬂush3). The BIU responds to the wl3 request in the same cycle it is asserted by the DCU. Data is sent from the DCU to the BIU in cycles 6 through 9. Because of the split data bus, the write operations in cycles 6 through 8 overlap read operations from the previous read request (rl2).

Chapter 2: Input/Output Interfaces

Cycle

PLBCLK a nd CPMC405CLK

DCU

PPC405 Outputs:

C405PLBDCUREQUEST

C405PLBDCUABUS[0:31]

C405PLBDCURNW

C405PLBDCUSIZE2

C405PLBDCUBE[0:7]

C405PLBDCUWRDBUS[0:63]

PLB/BIU Outputs:

PLBC405DCUADDRACK

PLBC405DCURDDACK

PLBC405DCURDDBUS[0:63]

PLBC405DCURDWDADDR[1:3]

PLBC405DCUWRDACK

PLBC405DCUBUSY

Figure 2-25: DSPLB Word Write/Line Read/Line Write

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

flush3 fill2

rl2ww1 wl3

adr1 adr2 adr3

val

ww1

d301d323d345d3

rl2ww1 wl3

rl201rl223rl245rl2

d201d223d245d2

0246

wl301wl323wl345wl3

UG018_29_101701

92 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Data-Side Processor Local Bus Interface

DSPLB 2:1 Core-to-PLB Line Read

The timing diagram in Figure 2-26 shows a line read in a system with a PLB clock that runs at one half the frequency of the PPC405x3 clock.

The line read (rl1) is requested by the DCU in PLB cycle 2, which corresponds to PPC405x3 cycle 3. The BIU responds in the same cycle. Data is sent fromthe BIU to the DCU ﬁll buffer in PLB cycles 3 through 6 (PPC405x3 cycles 5 through 12). After all data associated with this line is read, it is transferred by the DCU from the ﬁll buffer to the data cache. This is represented by the ﬁll1 transaction in PPC405x3 cycles 13 through 15.

CPMC405CLK

PLBCLK

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Cycle

DCU

PPC405 Outputs:

C405PLBDCUREQUEST

C405PLBDCUABUS[0:31]

C405PLBDCURNW

C405PLBDCUSIZE2

C405PLBDCUBE[0:7]

C405PLBDCUWRDBUS[0:63]

PLB/BIU Outputs:

PLBC405DCUADDRACK

PLBC405DCURDDACK

PLBC405DCURDDBUS[0:63]

PLBC405DCURDWDADDR[1:3]

PLBC405DCUWRDACK

PLBC405DCUBUSY

Figure 2-26: DSPLB 2:1 Core-to-PLB Line Read

rl1

adr1

rl1

0246

rl1

fill1

UG018_30_101701

PowerPC 405 Processor Block Reference Guide www.xilinx.com 93

EDK 6.1 October 6, 2003 1-800-255-7778

DSPLB 3:1 Core-to-PLB Line Write

The timing diagram in Figure 2-27 shows a line write in a system with a PLB clock that runs at one third the frequency of the PPC405x3 clock.

The line write (wl1) is requested by the DCU in PLB cycle 2, which corresponds to PPC405x3 cycle 4. The BIU responds in the same cycle. The request is made in response to a ﬂush in PPC405x3 cycles 1 and 2 (ﬂush1). Data is sent from the DCU to the BIU in PLB cycles 2 through 5 (PPC405x3 cycles 4 through 15).

Cycle

CPMC405CLK

PLBCLK

DCU

PPC405 Outputs:

C405PLBDCUREQUEST

C405PLBDCUABUS[0:31]

C405PLBDCURNW

C405PLBDCUSIZE2

C405PLBDCUBE[0:7]

C405PLBDCUWRDBUS[0:63]

PLB/BIU Outputs:

PLBC405DCUADDRACK

PLBC405DCURDDACK

PLBC405DCURDDBUS[0:63]

PLBC405DCURDWDADDR[1:3]

PLBC405DCUWRDACK

PLBC405DCUBUSY

Chapter 2: Input/Output Interfaces

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

flush1

wl1

adr1

wl1

UG018_31_101701

Figure 2-27: DSPLB 3:1 Core-to-PLB Line Write

94 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Data-Side Processor Local Bus Interface

DSPLB Aborted Data-Access Request

The timing diagram in Figure 2-28 shows an aborted data-access request. The request is aborted because of a core reset. The BIU is not reset.

A line write (wl1) is requested by the DCU in cycle 3 in response to a cache ﬂush (representedby the ﬂush1 transaction in cycles 1 through 2). The BIU responds in the same cycle the request is made by the DCU. Data is sent from the DCU to the BIU in cycles 3 through 6.

A line read (rl2) is address pipelined with the previous line write. The rl2 request is made by the DCU in cycle 5 and the BIU responds in the same cycle. However,the processor also aborts the request in cycle 5. Therefore, no data is transferred from the BIU to the DCU in response to this request.

Because the BIU is not reset, it must complete the ﬁrst line write even though the processor asserts the PLB abort signal during the line write.

PLBCLK a nd CPMC405CLK

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Cycle

flush1

DCU

PPC405 Outputs:

C405PLBDCUREQUEST

C405PLBDCUABUS[0:31]

C405PLBDCURNW

C405PLBDCUSIZE2

C405PLBDCUBE[0:7]

C405PLBDCUWRDBUS[0:63]

C405PLBDCUABORT

PLB/BIU Outputs:

PLBC405DCUADDRACK

PLBC405DCURDDACK

PLBC405DCURDDBUS[0:63]

PLBC405DCURDWDADDR[1:3]

PLBC405DCUWRDACK

PLBC405DCUBUSY

Figure 2-28: DSPLB Aborted Data-Access Request

rl2wl1

adr1 adr2

d101d123d145d1

rl2wl1

wl101wl123wl145wl1

UG018_32_101701

PowerPC 405 Processor Block Reference Guide www.xilinx.com 95

EDK 6.1 October 6, 2003 1-800-255-7778

Device-Control Register Interface

The device-control register (DCR) interface provides a mechanism for the processor block to initialize and control peripheral devices that reside on the same FPGA chip. For example, the memory-transfer characteristics and address assignments for a bus-interface unit (BIU) can be conﬁgured by software using DCRs. The DCRs are accessed using the PowerPC mfdcr and mtdcr instructions.

There are two types of device-control register (DCR) interface:

• Internal device-control registers in Processor Block gasket

• User-deﬁned device-control registers in CoreConnect DCR bus peripherals Both types of device control registers are deﬁned in a 10-bit, word-aligned domain,

independent from the PLB and OCM memory spaces.

Internal Device-Control Registers in Processor Block Gasket

The PowerPC 405 Processor Block gasket contains several internal device-control registers, which can be used to control, conﬁgure, and hold status for various functional units in the Processor Block gasket.

Chapter 2: Input/Output Interfaces

For Virtex-II Pro devices, there are two functional units that contain device-control registers:

1. DSCNTL, DSARC registers of data-side OCM (DSOCM)

2. ISCNTL, ISARC, ISINIT, ISFILL registers of instruction-side OCM (ISOCM) Since these registers shared the same 10-bit DCR address domain with user-deﬁned DCR

peripherals in CoreConnect Bus, users must deﬁned drive the “TIEDSOCMDCRADDR[0:7]” and TIEISOCMDCRADDR[0:7]” input ports of PowerPC 405 core to deﬁne the top 8 bits of DCR address, in order to differentiate these internal device control registers from user-deﬁned DCR peripherals on CoreConnect Bus.

More more information, please refer to Chap 3 PowerPC 405 OCM Controller, “OCM Controller Operation”.

User-Deﬁned Device-Control Registers in CoreConnect DCR Bus Peripherals

The DCR interface of CoreConnect DCR bus peripherals consists of the following:

• A 10-bit address bus.

• Separate 32-bit input data and output data busses.

• Separate read and write control signals.

• A read/write acknowledgement signal. Because the processor block is the only bus master on the bus, the address bus is driven by

the processor block and received by each peripheral containing DCRs. The read and write control signals are also distributed to each DCR peripheral.

The preferred implementation of the DCR data bus is as a distributed, multiplexed chain. Each peripheral in the chain has a DCR input-data bus connected to the DCR output-data bus of the previous peripheral in the chain (the ﬁrst peripheral is attached to the processor block). Each peripheral multiplexes this bus with the outputs of its DCRs and passes the

96 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Device-Control Register Interface

resulting DCR bus as an output to the next peripheral in the chain. The last peripheral in the chain has its DCR output-data bus attached to the processor block DCR input-data interface. This implementation enables future DCR expansion without requiring changes to I/O devices due to additional loading.

There are two options for connecting the acknowledge signals. The acknowledge signals from the DCRs can be latched and forwarded in the chain with the DCR data bus. Alternatively, combinatorial logic, such as OR gates, can be used to combine and forward the acknowledge signal to the processor block.

Figure 2-29, page 97 shows an example DCR chain implementation in an FPGA chip. The

acknowledge signal in this example is formed using combinatorial logic (OR gate).

PPC405

Core

C405DCRDBUSOUT[0:31]

C405DCRWRITE

C405DCRREAD

DCRC405ACK

C405DCRABUS[0:9]

DCR Slave 1

DCRs

DCR Slave 2

DCRs

DCR Slave 3

DCRs

DCRC405DBUSIN[0:31]

UG018_52_020702

Figure 2-29: DCR Chain Block Diagram

The acknowledge signal is interlocked with the read and write control signals. The interlock mechanism enables the DCR interface to communicate with peripheral devices that are clocked at different frequencies than the PPC405x3. A DCR access takes at least three PPC405x3 cycles. If a DCR access is not acknowledged in 64 processor cycles, the

PowerPC 405 Processor Block Reference Guide www.xilinx.com 97

EDK 6.1 October 6, 2003 1-800-255-7778

Chapter 2: Input/Output Interfaces

access times out. No error occurs when a DCR access times-out. Instead, the processor begins executing the next-sequential instruction.

The interlock mechanism requires that the rising edge of the slower clock (either the PPC405x3 clock or the peripheral clock) correspond to the rising edge of the faster clock. This means that the clocks for the DCR logic and the clocks for the PPC405x3 must be derived from a common source. The common source frequency is multiplied or divided before being sent to the PPC405x3 or DCR logic.

The DCR interface operates in two ways, referred to as mode 0 and mode 1 (these are hard wired modes, not programmable modes):

• In mode 0, the PPC405x3 and FPGA can be clocked at different frequencies without affecting the interface handshaking protocol. In this mode, an acknowledgement follows a read or write operation. The acknowledgement cannot be deasserted until the read or write signal is deasserted.

• In mode 1, the core and FPGA must run at the same frequency. In this mode, an acknowledgement follows a read or write operation. However, the acknowledgement can be deasserted one cycle after it is asserted. This enables the fastest back-to-back DCR access (three cycles).

Figure 2-30 illustrates a logical implementation of the DCR bus interface. This

implementation enables a DCR slave to run at a different clock speed than the PPC405x3. The acknowledge signal is latched and forwarded with the DCR bus. The bypass multiplexor minimizes data-bus path delays when the DCR is not selected. To ensure reusability across multiple FPGA environments, all DCR slave logic should use the speciﬁed implementation.

98 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

Device-Control Register Interface

Processor Core

C405DCRWRITE

C405DCRREAD

C405DCRABUS[0:9]

DCRC405ACK

DCRC405DBUSIN[0:31]

Full

Address

Decode

Lower

Address

Decode

DCR Slave

Bypass Mux

DCR1

DCR2

C405DCRDBUSOUT[0:31]

Figure 2-30: DCR Bus Implementation

DCR Interface I/O Signal Summary

Figure 2-31 shows the block symbol for the DCR interface. The signals are summarized in Table 2-18.

DCRC405ACK

DCRC405DBUSIN[0:31]

Figure 2-31: DCR Interface Block Symbol

PPC405

UG018_53_020702

C405DCRREAD C405DCRWRITE C405DCRABUS[0:9] C405DCRDBUSOUT[0:31]

UG018_06_020702

PowerPC 405 Processor Block Reference Guide www.xilinx.com 99

EDK 6.1 October 6, 2003 1-800-255-7778

Table 2-18: DCR Interface I/O Signals

Chapter 2: Input/Output Interfaces

Signal

C405DCRREAD O No Connect Indicates a DCR read request occurred. C405DCRWRITE O No Connect Indicates a DCR write request occurred. C405DCRABUS[0:9] O No Connect Speciﬁes the address of the DCR access request. C405DCRDBUSOUT[0:31] O No Connect

DCRC405ACK I 0 Indicatesa DCR access has been completed by a peripheral. DCRC405DBUSIN[0:31] I 0x0000_0000

I/O

Type

If Unused Function

The 32-bit DCR write-data bus.

or attach to

input bus

The 32-bit DCR read-data bus.

or attach to

output bus

DCR Interface I/O Signal Descriptions

The following sections describe the operation of the DCR interface I/O signals.

C405DCRREAD (output)

When asserted, this signal indicates the processor block is requesting the contents of a DCR (reading from the DCR) in response to the execution of a move-from DCR instruction (mfdcr). The contents of the DCR address bus are valid when this request is asserted (the request is asserted one processor cycle after the processor block begins driving the DCR address bus). This signal is deasserted two processor cycles after the DCR acknowledge signal is asserted. When deasserted, no DCR read request exists. DCRs must not drive the DCR bus if this signal is not asserted.

The processor block waits up to 64 cycles for a read request to be acknowledged. If a DCR does not acknowledge the request in this time, the read times out. No error occurs when a DCR read times-out. Instead, the processor begins executing the next-sequential instruction.

DCR readrequestsarenot interrupted by the processorblock. If this signal is asserted, only a DCR acknowledgement or read time-out cause the signal to be deasserted.

This signal is deasserted during reset.

C405DCRWRITE (output)

When asserted, this signal indicates the processor block is requesting that the contents of a DCR be updated (writing to the DCR) in response to the execution of a move-to DCR instruction (mtdcr). The contents of the DCR address bus are valid when this request is asserted (the request is asserted one processor cycle after the processor block begins driving the DCR address bus). This signal is deasserted two processor cycles after the DCR acknowledge signal is asserted. When deasserted, no DCR write request exists.

The processor block waits up to 64 cycles for a write request to be acknowledged. If a DCR does not acknowledge the request in this time, the write times out. No error occurs when a DCR write times-out. Instead, the processor begins executing the next-sequential instruction.

100 www.xilinx.com PowerPC 405 Processor Block Reference Guide

1-800-255-7778 EDK 6.1 October 6, 2003

IBM PowerPC 405GP (266Mhz), PowerPC 405GP (133Mhz), PowerPC 405GP (200Mhz) PowerPC 405 Processor Block Reference Guide Embedded Development Kit EDK 6.1 (Xilinx)

Specifications and Main Features

Frequently Asked Questions

User Manual

About This Guide

Document Organization

Document Conventions

General Conventions

Registers

Terms

Additional Reading

PowerPC Architecture

PowerPC Embedded-Environment Architecture

PPC405x3 Software Features

Privilege Modes

Address Translation Modes

Addressing Modes

Data Types

Register Set Summary

PPC405x3 Hardware Organization

Central-Processing Unit

Exception Handling Logic

Memory Management Unit

Instruction and Data Caches

Timer Resources

Debug

PPC405x3 Interfaces

PPC405x3 Performance

Input/Output Interfaces

Signal Naming Conventions

Clock and Power Management Interface

CPM Interface I/O Signal Summary

CPM Interface I/O Signal Descriptions

CPU Control Interface

CPU Control Interface I/O Signal Summary

CPU Control Interface I/O Signal Descriptions

Reset Interface

Reset Requirements

Reset Interface I/O Signal Summary

Reset Interface I/O Signal Descriptions

Instruction-Side Processor Local Bus Interface

Instruction-Side PLB Operation

Instruction-Side PLB I/O Signal Table

Instruction-Side PLB Interface I/O Signal Descriptions

Instruction-Side PLB Interface Timing Diagrams

Data-Side Processor Local Bus Interface

Data-Side PLB Operation

Data-Side PLB Interface I/O Signal Table

Data-Side PLB Interface I/O Signal Descriptions

Data-Side PLB Interface Timing Diagrams

Device-Control Register Interface

DCR Interface I/O Signal Summary

DCR Interface I/O Signal Descriptions