PCI-X & PCI Core

User's Guide

Version 7.1.0 27-Feb-2007 © PLD Applications, 1996-2007

PLD Applications Web: http://www.plda.com Europarc Pichaury A2 Email: [email protected] 1330, rue Guillibert USA : 1 866 513 0362 (toll free) 13856 Aix-en-Provence Intl : + 33 442 393 600 CEDEX 3 - France Fax : + 33 442 394 902 Associate Member

PCI-X & PCI Core User's Guide

Features

General ° 32-bit/64-bit PCI-X & PCI master/target interface ° Supports speed up to 133 MHz ° Multi-function core can implement up to 2 independent functions ° Full support for 64-bit addressing ° PCI-X Specification 2.0a mode 1 compliant ° PCI Specification 3.0 compliant ° Supports PCI power management ° Built-in support for in-site programming through JTAG interface ° Supports Message Signalled Interrupts

Customization ° Easy customization with the PCI Wizard's user interface and on-line help. ° PCI Wizard has built-in support for VHDL and Verilog. ° All features can be parameterized, removing all unused logic ° Full plug-and-play support

Configuration ° Supports all required and optional type 0 configuration registers ° Up to 6 BARs plus expansion ROM can be implemented ° Up to 32 user defined configuration registers

Data transfer ° Supports up to 4KB burst transfers with zero wait-state insertion. ° Supports all memory and I/O commands ° Supports interrupt acknowledge cycles in target mode ° Can insert wait-states and generate all types of terminations ° Up to two split channels and 32 outstanding split transactions

DMA ° Up to 4 independent DMA channels with rotating priority ° Flexible backend interface can directly control FIFO devices. ° Can generate all existing bus commands ° Optional scatter-gather support ° 64-bits data transactions are dynamically negotiated ° Split is fully supported on all DMA channels

Design files ° Standard VHDL and Verilog source code for ASIC design and simulation ° Highly optimized encrypted VHDL code for Altera & Xilinx FPGAs

2

PCI-X & PCI Core User's Guide

Table of Contents

PREFACE...... 4

1 – PCI-X & PCI CORE BASICS ...... 5 1.1. GENERAL ARCHITECTURE...... 5 1.2. PARITY CONTROL...... 6 1.3. TARGET STATE-MACHINE ...... 7 1.4. DATA PATH...... 9 1.5. CONFIGURATION SPACE...... 10 1.6. MULTIPLE FUNCTIONS...... 12 2 - TARGET MODE...... 13 2.1. ADDRESS DECODING ...... 13 2.2. TARGET DATA PATH ...... 14 2.3. TRANSACTION PROCESSING ...... 15 2.4. CONFIGURATION ACCESSES...... 19 2.5. TARGET INTERFACE DESCRIPTION ...... 20 3 - MASTER MODE...... 22 3.1. DMA MODES...... 22 3.2. DYNAMIC TRANSACTION NEGOTIATION...... 24 3.3. TRANSACTION ALIGNMENT ...... 24 3.4. DMA CHANNEL ...... 25 3.5. DMA DATA PATH ...... 29 3.6. DMA INTERFACE DESCRIPTION...... 32 4 – SPLIT PROCESSING ...... 34 4.1. GENERAL DESCRIPTION ...... 34 4.2. REQUESTING SPLIT TERMINATION ...... 35 4.3. SPLIT CHANNELS ...... 36 4.5. SPLIT INTERFACE SIGNALS ...... 37 5 - CORE EXTENSIONS...... 39 5.1. INTERRUPT SUPPORT & MSI...... 39 5.2. PLDA PCI-X BOARD INTERFACE...... 39 5.3. PLDA CORE STATUS REGISTER & JTAG INTERFACE...... 40 5.4. POWER MANAGEMENT ...... 41 5.5. COMPACTPCI HOTSWAP...... 43 5.6. CARDBUS ...... 44 5.7. CORE EXTENSIONS INTERFACE DESCRIPTION ...... 47 APPENDIXES...... 49 A1. REFERENCE DOCUMENTS...... 49 A2. PCI-X TERMINOLOGY ...... 50 A3. ILLUSTRATION INDEX ...... 51

3

PCI-X & PCI Core User's Guide

Preface

Introduction

© This document is the primary reference and technical manual for PLD Applications PCI-X & PCI core. This manual serves as a guide to incorporate PLD Applications PCI-X & PCI core into designs, for implementation in ASIC or in programmable logic devices.

Required Knowledge

© In order to take advantage of PCI-X & PCI core features, designers should have a basic understanding of PCI bus architecture and operations. Users can refer to "PCI Bus Fundamentals" document, for an introduction to PCI.

Organization

© This technical manual contains the following sections :

- Section 1, "PCI-X & PCI Core Basics", presents the general architecture of the core and details target-mode functions. - Section 2, "Target Mode", provides many examples depicting target-mode operations. - Section 3, "Master Mode", describes master-mode operations - Section 4, "Split processing", details how to use split transactions - Section 5, "Core Extensions", details features that are extensions to the PCI-X specifications.

4

PCI-X & PCI Core User's Guide

1 – PCI-X & PCI Core Basics

This document is the primary reference and technical manual for PLD Applications PCI-X & PCI core. This technical manual contains a complete functional description of the PCI-X & PCI core and its local interface.

1.1. GENERAL ARCHITECTURE

© PCI-X & PCI core provides an integrated solution for interfacing any user application or system to 32-bit and 64-bit PCI peripheral devices. It is mostly targeted to the add-in card market, including PLD Applications development/prototyping boards, but can also be used to design other applications. The core is programmable and customizable : almost all features can be enabled/disabled to suit specific needs and the core can be adapted to run in any PCI environment. This core is well suited for programmable logic designs but can also be implemented in ASIC designs.

© PCI-X core is built around a target and a master state machine that control all operations and insure coherency and synchronization with PCI bus operations. Data transfer is operated by a 32-bit/64-bit bi- directional registered data path as shown below :

P C I B u s D e v i c e

P C I C o r e U s e r B a c k e n d C o n t r o l S ig n a l s T A R G E T S TA T E M A C H I N E

CO N F I G U R A T I O N S P A C E D ata 3 2 / 6 4 B I T S D A TA P A T H

D M A C H A N N E L S

C o n t r o l S ig n a l s M A S T E R S TA T E M A C H I N E

P a r i t y S i g n a l s P A R I T Y I N T E R R U P T C O N T R O L S U P P O R T

Figure 1 – PCI-X & PCI Core Architecture

5

PCI-X & PCI Core User's Guide

© PCI-X & PCI core contain the following functional blocks :

- Target state-machine controls all operation in target mode. It is in charge of configuration accesses and controls memory/IO accesses to backend logic.

- Configuration space implements all PCI configuration space registers. It also contains address decoders that allow the core to respond to transactions when addresses are mapped in its memory or I/O address spaces.

- 32/64-bit data-path interfaces the PCI address/data bus to the internal and local address and data buses.

- Master state machine controls all operation in master mode. It ensures reliable data transfers and handles all PCI bus events automatically.

- DMA channels allow backend to program and control up to four separate data flows to/from system memory or other PCI devices.

- Parity control module computes data parity and reports errors to host system when this feature is enabled.

- Interrupt support module implements control logic for processing interrupt requests on the PCI bus.

1.2. PARITY CONTROL

© Parity management is completely handled by the core. It is independent from backend application and does not interact with it. This module is made of two separate blocks :

- The 32-bit parity block computes and checks even parity on ad_pci[31..0] and CBE#[3..0] during 32-bit and 64-bit data transfers. - The 64-bit parity block computes and checks even parity on ad_pci[63..32] and CBE#7..4].during 64-bit transactions only. It is not implemented in 32-bit core.

Parity errors are reported only if enabled by host system. If enabled, the following applies :

- Parity errors in address or attribute phases are reported on SERR# pin - Data parity errors are reported on PERR# whether the error occurs on the 32-bit data LSB or on the 32-bit data MSB.

∞ Devices that need to know when parity errors occurred can check s_conf_sc[] bus. This bus is the image of PCI status & command register.

6

PCI-X & PCI Core User's Guide

1.3. TARGET STATE-MACHINE

© Target state-machine is the central element that controls all transactions in target mode. Its state follows PCI bus activity and thus it can be used to track both PCI bus state and core activity.

Eight states are defined as shown on figure below :

idle 64-bit address /01/ busy dac /80/ Core is not target of /02/ single data transfer end of transfer 32-bit address core is not the target of burst transfer trans addr /40/ /04/

core is the target

start resp /20/ /08/ temp /10/

Figure 2 - Target state machine

Backend application can monitor target machine state using the one-hot encoding on s_sm[]. Figure that appears in each state is the hexadecimal code that appears on s_sm[] when the core is in this state. This state-machine is useful to understand core behavior and can be important for debug.

7

PCI-X & PCI Core User's Guide

© Target state machine switches from one state to another either because of a PCI bus event or because of a backend logic action. Designers should understand the different states behavior, ordering and interaction. Table below details each state :

State Bit Description idle 0 This is the default state : PCI bus is idle and no transaction is taking place. FRAME# and IRDY# are inactive.

dac 1 This state is entered whenever a dual-address cycle command is detected on the PCI bus : this means that master is broadcasting a 64-bit address on the PCI bus. Next state is always addr.

addr 2 Core indicates if it is the target of current transaction during this state :

- If core is the target of the transaction, then a single bit of s_bar[] is asserted in order to indicate which address space is target. Then state machine moves to resp state. - If core is not the target of the transaction then it switches to busy state.

resp 3 In this state core prepares to respond to the transaction :

- If transaction is a configuration access then core is always ready - If transaction is a memory/IO access then core waits for backend response in order to process or stop the transaction with any of the termination defined in the PCI-X specification. temp 4 This temporary state is entered when :

- Transaction is a read, in order to fetch necessary data from backend logic. - Transaction is a write and backend logic inserted an odd number of wait-states.

start 5 This state allows core to get prepared to start data transfer. Next state is always trans. trans 6 All read/write transfer in target mode occur during this state. Data transfer cannot be interrupted by backend and is only stopped for one of the following reasons :

- Transaction byte count is satisfied - Transaction reaches an address space end or a 4KB boundary - Master disconnects transaction busy 7 busy state is reached when either core is not the target of current transaction, or transaction is complete. Core returns to idle state when bus is idle (FRAME# and IRDY# are both high).

Table 1 – Target states

8

PCI-X & PCI Core User's Guide

1.4. DATA PATH

© The internal data path connects local data buses to the 32-bit/64-bit bi-directional PCI address/data bus. This module synchronizes all data buses to the PCI-X & PCI core, insuring a contention-free and synchronous data exchange.

Figure below gives a simplified representation of core data path :

S l a v e d a t a in p u t s _ d a t a _ i n P C I B u s r e g m _ d a t a _ i n M a s t e r d a t a i n p u t

r e g s _ d a t a _ o u t

Figure 3 – Core internal data path

Local interface comprises three data buses :

- s_data_in[] is the target-mode data input : it is used to write data to the PCI bus during target- read transactions.

- m_data_in[] is the master-mode data input : data on this bus is transferred to the PCI bus during DMA write transfers.

- s_data_out[] is data output for both target and master mode : it is used to read data received from the PCI bus during target-write transactions and DMA read transfers.

9

PCI-X & PCI Core User's Guide

1.5. CONFIGURATION SPACE

© Configuration space module automatically handles read and write accesses to core embedded configuration space registers. This space is a 256-byte area organized shown below as a set of 32-bit registers :

Address 31..24 23..16 15..8 7..0 00h DEVICE ID VENDOR ID 04h STATUS REGISTER COMMAND REGISTER 08h CLASS CODE REVISION ID 0Ch BIST HEADER TYPE LATENCY TIMER CACHE LINE SIZE 10h BASE ADDRESS REGISTER 0 14h BASE ADDRESS REGISTER 1 18h BASE ADDRESS REGISTER 2 1Ch BASE ADDRESS REGISTER 3 20h BASE ADDRESS REGISTER 4 24h BASE ADDRESS REGISTER 5 28h CARDBUS CIS POINTER 2Ch SUBSYSTEM DEVICE ID SUBSYSTEM VENDOR ID 30h EXPANSION ROM BASE ADDRESS 34h reserved CAP. POINTER 38h reserved 3Ch MAX. LATENCY MINIMUM GRANT INTERRUPT PIN INTERRUPT LINE 40h reserved 44h PLDA CORE STATUS 48h..4Ch PCI-X CAPABILITIES 50h..5Ch MSI REGISTERS 60h PLDA FLASH CONTROL 64h COMPACTPCI HOTSWAP 68h..74h CARDBUS STATUS REGISTERS 78h..7Ch POWER MANAGEMENT 80h .. user registers FCh Table 2 - Core configuration space

Core implements all required registers as defined in the PCI specification. Core specific registers and user-defined registers are shaded in the above table :

- Registers in address range 40h..7Ch are reserved by core and contain registers needed to provide information and control PLDA core specific feature support for PCI extensions and optional features. - Registers in address range 80h..FCh are user-defined and can be used for any application specific purpose.

∞ Configuration space set-up is done with the PCI Wizard. Its user-interface and extensive on-line help explains all possible settings in details.

10

PCI-X & PCI Core User's Guide

© Command register provides coarse control over the device and enables/disables response to some transactions or events. This register is implemented in core as shown below :

Command bit Description 0 I/O access enable : when set core can respond to I/O transactions as a target. This bit is usually set during device initialization process. This bit can be pre-defined using plug-n-play parameters. 1 Memory access enable : when set core can respond to memory transactions as a target. This bit is usually set during device initialization process. This bit can be pre- defined using plug-n-play parameters. 2 Master enable : enables the core to act as a bus master and thus enables DMA transfers. This bit is usually set during device initialization process. This bit can be pre- defined using plug-n-play parameters. 3 Hardwired to 0. Special cycles are not supported. 4 Hardwired to 0. Memory Write and Invalidate is not supported. 5 Hardwired to 0. VGA palette snooping is not supported. 6 Parity error response : when set core reports parity errors via PERR# pin. This bit can be pre-defined using plug-n-play parameters. 7 Reserved 8 System error enable : when set core reports address parity errors via SERR# pin. Bit 6 must also be set for this bit to take effect. 9 Hardwired to 0. Fast back-to-back is not supported. 10 Interrupt disable : when set this bit disables core function from asserting its interrupt pin. When disabled, interrupts are generated normally. 11..15 Reserved Table 3 - PCI command register

© Status register records information on some PCI bus related events. Core implementation is the following :

Status bit Description 18…16 Reserved 19 Set by core when function would normally assert interrupt pin, regardless of Interrupt disable bit state. 20 Hardwired to 1. Core implements a capabilities list. 21 Set by the core when 66MHz PCI mode is supported. 22 Reserved 23 Hardwired to 0. Fast back-to-back is not supported. 24 Set by the core acting as a master when it detects a data parity error if parity error response bit is set. 25…26 Hardwired to "10" : DEVSEL# timing is slow. 27 Set by the core acting as a target when it issues a target abort. 28 Set by the core acting as a master when it receives a target-abort. 29 Set by the core acting as a master when it receives a master-abort. 30 Set by the core to indicate an address parity error. SERR# line is also asserted. parity error response & system error enable bits must be set for this bit to take effect. 31 Set by the core to indicate a data or address parity error. This bit is set even if parity error response bit is disabled. Table 4 - PCI status register

11

PCI-X & PCI Core User's Guide

1.6. MULTIPLE FUNCTIONS

© Core can optionally act as a multi-function device : this means that a single device has the ability to act as up to two separate PCI devices. Each function is visible on the PCI bus and acts as an independent PCI device :

PCI Core

Function #0

PCI Bus s_function

Function #1 (optional)

Figure 4 - Multi-function core

Each function has its own configuration space and responds only when targeted :

- writing to a function's configuration register do not affect other functions - s_function signal is used to indicate which function is targeted during a target-access : ’0’ indicates that function #0 is targeted, and ‘1’ indicates that function #1 is targeted. - each function can control a separate interrupt pin

12

PCI-X & PCI Core User's Guide

2 - Target Mode

2.1. ADDRESS DECODING

When a transaction is started on the PCI bus, core acts as a target and checks if the address is mapped in its memory or I/O address spaces : this process is known as address decoding.

© 32-bit address decoding is performed in one step during idle state. Core takes one clock cycles before responding to the transaction when it is targeted :

0 ps 24 0.0 n s 3 8 0.0 n s clk_pci a d _pci ... A D D R A T T R X D A T A ... fra m e _pci d e v s e l_pci trd y _pci ta rg e t_s ta te id le a d d r re s p s ta rt tra n s b u s y id le s _b a r 00000000 000001 00 00000000 s _fu n ctio n X F U N C T IO N X s _a d d r[6 3 ..3 2] X 0 X s _a d d r[3 1 ..0] X A D D R ... X s _re a d X R _W X s _b y te co u n t X B Y T E _C O U N T X Waveform 1 - 32-bit address decoding

© 64-bit addresses are decoded in two steps : bits [31..0] are decoded during idle state and bits [63..32] are decoded during dac state :

0 ps 24 0.0 n s 3 8 0.0 n s clk_pci a d _pci ... A D _L S B A D _M S B A T T R X D A T A ... fra m e _pci d e v s e l_pci trd y _pci ta rg e t_s ta te id le d a c a d d r re s p s ta rt tra n s b u s y id le s _b a r 00000000 000001 00 00000000 s _fu n ctio n X F U N C T IO N X s _a d d r[6 3 ..3 2] X A D _M S B X s _a d d r[3 1 ..0] X A D _L S B ... X s _re a d X R _W X s _b y te co u n t X B Y T E _C O U N T X Waveform 2 - 64-bit address decoding

Local-side bus s_bar[] reflects the result of address decoding : each bit in s_bar[] is connected to an address decoder's output and are kept asserted form addr to turn state :

- bits 0..5 are set when BAR0 .. BAR5 are targeted - bit 6 is set when expansion ROM BAR is targeted - bit 7 is set when configuration space is accessed

© Multi-function designs must monitor s_function during target accesses to check which function is being targeted : core asserts s_function to indicate that function #1 is being targeted.

13

PCI-X & PCI Core User's Guide

2.2. TARGET DATA PATH

2.2.1. Data Flow

© Backend logic is responsible for checking s_bar[] during transactions in order to figure out which space is targeted :

s _ d a t a _ o u t [ ] t o a l l s p a c e s

B A R 0 d a t a 0 PC I C o re P C I B u s s _ d a t a _ i n 5 B A R 5 d a t a 6 E x p . R O M d a t a 7 C o n f i g u r a t i o n d a t a

s _ b a r [ ]

Figure 5 - Target data flow

Backend should typically implement a data multiplexer controlled by s_bar[] in order to select data source during read transactions. Data inputs selected by this multiplexer must be registered (either before or after the multiplexer) and data value is controlled by s_addr[].

∞ s_data_in[] must be tied to 0’s when a location where no implemented register/memory is targeted.

2.2.2. Control Signals

© All target mode transactions are handled with target interface. Core provides all necessary signals to handle and control target-mode data transfers :

s _ a d d r s _ r e a d s _ w r i t e s _ d a t a _ o u t r e g i s t e r s , s _ b y t e v a l i d m e m o r y , P C I B u s P C I - X C o r e p e r i p h e r a l s . . .

s _ d a t a _ i n s_ re s po ns e c o n t ro l s i g n a l

Figure 6 - Target interface

Core provides an address counter, read and write requests signals :

- s_addr[] is the transaction address counter, automatically incremented at each data transfer - s_read is read-request signal that indicates when transaction is a read - s_write is a write-request signals that indicates when backend logic must store data - s_bytevalid[] indicates which bytes must be read/written during a transaction.

14

PCI-X & PCI Core User's Guide

2.3. TRANSACTION PROCESSING

© Backend logic can control transaction with s_response[] which can be used to insert wait-state and issue all types of transaction termination.

Core takes s_response[] value into account when it is the target of a memory or IO transaction or configuration access in range 80h..FCh and when target state machine is in resp state only, except for DISCO response that is possible at any time during a transaction. Possible values of this signal are detailed below :

Encoding Response Meaning 000 OKAY This code indicates that backend logic is ready to read/write data. Target state machine moves to start state and data transfer proceeds.

001 WAIT Backend logic can delay data transfer by inserting wait-states with this response. Target state machine stays in resp state until response is changed.

Note that wait-states must be inserted in pairs during read transactions in PCI-X mode, core may add a wait-state if necessary.

Note that no wait-state can be inserted once data transfer is started.

010 ADB Forces transaction to be disconnected at next ADB (naturally aligned 128-byte boundary).

011 DISCO Forces transaction to be disconnected as soon as possible (at next ADB in PCIX bus mode, or at next data in PCI bus mode).

100 SINGLE Issues a single data disconnect : only one data word is transferred and transaction is stopped.

101 ABORT Issues a target-abort : transaction is stopped immediately and no data is transferred. This is usually treated by the master of the transaction as a fatal error. Target-abort can be signalled at the start of the transaction only.

110 RETRY Indicates that backend logic is temporarily unable to read/write data. A retry termination is issued and no data is transferred. Master will re- iterate transaction later.

111 SPLIT Used to end a transaction with a split termination :

- a target-abort is issued if bus is in PCI mode or transaction is not a configuration r/w, IO r/w or memory read. - a split termination is issued otherwise. See “Split Processing” chapter for detailed information.

Table 5 - Backend response encoding

∞ Note that s_response[] is ignored during configuration space header and core registers (registers at offset 00h to 7Ch) accesses.

15

PCI-X & PCI Core User's Guide

© Following waveforms illustrate examples of how target interface behaviour can be controlled by backend logic :

0 ps 1 20.0 n s 24 0.0 n s 3 4 0.0 n s clk_pci a d _pci ... A D D R A T T R X D A T A ... fra m e _pci d e v s e l_pci trd y _pci s to p_pci ta rg e t_s ta te id le a d d r re s p s ta rt tra n s b u s y s _re s po n s e X O K A Y X Waveform 3 - Backend indicates it is ready

0 ps 24 0.0 n s 4 20.0 n s clk_pci a d _pci ... A D D R A T T R X D A T A ... fra m e _pci d e v s e l_pci trd y _pci s to p_pci ta rg e t_s ta te id le a d d r re s p s ta rt tra n s b u s y s _re s po n s e X W A IT O K A Y X Waveform 4 - Backend insert two initial wait-states

0 ps 1 20.0 n s 24 0.0 n s 3 5 0.0 n s clk_pci a d _pci ... A D D R A T T R X D A T A ... fra m e _pci d e v s e l_pci trd y _pci s to p_pci ta rg e t_s ta te id le a d d r re s p s ta rt tra n s b u s y id le s _re s po n s e X W A IT S IN G L E X Waveform 5 - Backend insert one wait-state and issues single-data disconnect

16

PCI-X & PCI Core User's Guide

2.3.1. Typical read/write transactions

© Waveform below illustrates a typical write transaction :

0 ps 24 0.0 n s 3 9 0.0 n s clk_pci fra m e _pci trd y _pci ta rg e t_s ta te id le a d d r re s p s ta rt tra n s b u s y id le s _b a r 00000000 00000001 00000000 s _a d d r X A D D R 0 A D D R 1 A D D R 2 A D D R 3 X s _w rite s _d a ta _o u t X D 0 D 1 D 2 D 3 X s _b y te v a lid 00 B Y T E V A L ID 00 s _b y te co u n t X 1 0h X Waveform 6 - Typical target write transaction

© Waveform below illustrates a typical read transaction :

0 ps 24 0.0 n s 3 9 0.0 n s clk_pci fra m e _pci trd y _pci ta rg e t_s ta te id le a d d r re s p te m p s ta rt tra n s b u s y id le s _b a r 00000000 00000001 00000000 s _a d d r X A D D R 0 A D D R 1 A D D R 2 A D D R 3 A D D R 4 A D D R 5 A D D R 6 A D D R 7 X s _re a d s _d a ta _in X D 0 D 1 D 2 D 3 D 4 D 5 D 6 X s _b y te v a lid 00 F F 00 s _b y te co u n t X 1 0h X Waveform 7 - Typical target read transaction

∞ s_read is asserted during the whole duration of a target read transaction, regardless of how many data words are actually read by the initiator. This signal must be regarded as a “read-enable” signal.

17

PCI-X & PCI Core User's Guide

2.3.2. Access to BAR with 32-bit data-path

© For each BAR user can select in PCI Wizard if data-path is 32 or 64-bit. If data-path is 32-bit :

- Core responds to transactions targeting this BAR is 32-bit mode only (ACK64# is never asserted) - 32-bit data is always present on s_data_in[31..0] and s_data_out[31..0] - valid bytes for write are specified by s_bytevalid[3..0].

© Waveform below illustrates a 32-bit write transaction targeting a BAR with a 32-bit data path. A total of 13 bytes are transferred, starting at address 41h. Note how s_bytevalid[] is adjusted on each clock cycle in order to indicate which bytes need to be written :

0 ps 24 0.0 n s 3 9 0.0 n s clk_pci fra m e _pci re q 6 4 _pci trd y _pci a ck6 4 _pci ta rg e t_s ta te id le a d d r re s p s ta rt tra n s b u s y id le s _b a r 00000000 00000001 00000000 s _a d d r X 4 1 4 4 4 8 4 C X s _w rite s _d a ta _o u t X D A T A 0 D A T A 1 D A T A 2 D A T A 3 X s _b y te v a lid 00 0E 0F 03 00 s _b y te co u n t X 00D X Waveform 8 - 32-bit write to a 32-bit space

2.3.3 Access to BAR with 64-bit data-path

© If BAR data-path is selected to be 64-bit then :

- 64-bit data is always present on s_data_in[63..0] and s_data_out[63..0] - valid bytes for write are specified by s_bytevalid[7..0] - 64-bit data must always be present on s_data_in, regardless of start address and transaction type. If this causes a design problem, then select a 32-bit data-path for the BAR.

© Waveform below illustrates a 32-bit write transaction targeting a BAR with a 64-bit data path. 16 bytes are transferred, starting at address 80. s_bytevalid[] is adjusted to indicate valid bytes and data is automatically moved to the appropriate lanes on s_data_out[] :

0 ps 24 0.0 n s 3 9 0.0 n s clk_pci fra m e _pci re q 6 4 _pci trd y _pci a ck6 4 _pci ta rg e t_s ta te id le a d d r re s p s ta rt tra n s b u s y id le s _b a r 00000000 00000001 00000000 s _a d d r X 8 0 8 4 8 8 8 C X s _w rite s _d a ta _o u t[3 1 ..0] X D A T A 0 X D A T A 2 X s _d a ta _o u t[6 3 ..0] X D A T A 1 X D A T A 3 X s _b y te v a lid 00 0F F 0 0F F 0 00 s _b y te co u n t X 01 0 X Waveform 9 - 32-bit write to a 64-bit space

18

PCI-X & PCI Core User's Guide

© Waveform below illustrates a 64-bit write transaction targeting a BAR with a 64-bit data path. 24 bytes are transferred, starting at address 84h :

0 ps 24 0.0 n s 3 9 0.0 n s clk_pci fra m e _pci re q 6 4 _pci trd y _pci a ck6 4 _pci ta rg e t_s ta te id le a d d r re s p s ta rt tra n s b u s y id le s _b a r 00000000 00000001 00000000 s _a d d r X 8 4 8 8 9 0 9 8 X s _w rite s _d a ta _o u t[3 1 ..0] X D A T A 2 D A T A 4 D A T A 6 X s _d a ta _o u t[6 3 ..0] X D A T A 1 D A T A 3 D A T A 5 X s _b y te v a lid 00 F 0 F F 0F 00 s _b y te co u n t X 01 8 X Waveform 10 - 64-bit write to 64-bit space

2.4. CONFIGURATION ACCESSES

© Core detects configuration transactions and asserts s_bar[7] to indicate that PCI device’s configuration space is targeted. Accesses to registers in address range 00h...7Ch are automatically handled by core, however registers located in range 80h...FCh are user-application specific and handled by backend logic.

2.4.1. Configuration write

© During configuration write accesses s_addr[7..0] indicates the offset of targeted register :

- if targeted register is not implemented in user logic, then no action is necessary. - if targeted register is implemented in user logic, then backend logic must write data present on s_data_out[] using s_bytevalid[] byte enables when s_write is asserted.

∞ Backend logic of a multi-function core must also take s_function into account because no register should be shared between multiple functions. Writing to a register implemented in a function must not affect other functions.

2.4.2. Configuration read

© During configuration read accesses s_addr[7..0] indicates the offset of targeted register :

- if targeted register is not implemented in user logic, then backend logic must tie s_data_in[] to a zero value.

- if targeted register is implemented in user logic, then backend logic must provide the value of this register on next clock cycle on s_data_in[] and maintain this value as long as s_read is asserted.

19

PCI-X & PCI Core User's Guide

2.5. TARGET INTERFACE DESCRIPTION

© Core communicates with backend application with a simplified set of status, control and data signals. All existing target-interface signals are detailed below but note that PCI Wizard removes unnecessary signals :

Signal Size I/O Description s_sm[] 8 out Represents core target state machine. Each bit reflects a single state. s_busmode[] 3 out This signal indicates bus mode and speed detected by PCI core :

Code Bus mode 000 PCI 33 MHz 010 PCI 66 MHz 011 PCI-X 66 MHz 101 PCI-X 100 MHz 111 PCI-X 133 MHz other reserved s_pllmode[] 3 out This signal reports bus mode and bus frequency just like s_busmode[]. However it is not registered and gives accurate information even if no PCI clock is available. Thus this signal can be used to select appropriate PLL parameters for PCI clock upon bus reset. s_conf_sc0[] 32 out s_conf_scn[] reports information from PCI and PCI-X command/status s_conf_sc1[] registers for function #n. This signal is primarily intended for backend design that need to monitor parity errors and contains following fields :

Bits Reflect 31..16 PCI status register 15..13 PCI-X command register “Max outstanding split” 12..11 PCI-X command register “Max outstanding read byte count” 10..0 PCI command register bits 10..0 s_response[] 3 in Backend logic can control transaction with s_response[] which can be used to insert wait-state and issue all types of transaction termination including retry, target-abort, split... See “Control Signals” chapter for more details. s_function out This signal is for use in multi-function devices only : bits 0…3 are asserted when function #0..#3 is targeted during a target-mode access. s_addr[] 64 out This signal acts as a memory address counter. Address bits can be directly connected to internal or external static memory devices. Address is initialized with start address of transaction, and then automatically incremented whenever a data-word is written/read. s_bar[] 8 out s_bar[] shows which address space is targeted during a target access :

- Bits 0..5 are set when BAR0 .. BAR5 are targeted - Bit 6 is set when expansion ROM BAR is targeted - Bit 7 is set when configuration space is accessed

∞ If an address space is mapped in the 64-bit addressing space, then it occupies two BAR registers. This address space is targeted when LSB s_bar[] bit is asserted. For instance, if BAR2-BAR3 is a 64-bit BAR, then this BAR is targeted when s_bar[2] is asserted.

20

PCI-X & PCI Core User's Guide

s_command[] 4 out This signal reflects the bus command used by initiator to start current transaction. This signal is valid from addr to busy state. s_read out This read-request signals indicate when a data word must be read. If target response is not WAIT then backend logic must provide data word corresponding to address specified by s_addr[] on next clock cycle.

This signal can also be used to check data flow direction during target transactions. If s_read ='1' , transaction is a target read : core writes data to the PCI bus. s_write out Memory write signal is asserted to indicate that data present on s_data_out[] must be written at address specified by s_addr[]. s_64flag out This signal indicates if current data transfer is performed in 64-bit mode. This signal is valid from addr to busy state. s_int_ack out When interrupt acknowledge support is enabled, this signal is asserted (whenever an Interrupt Acknowledge command is detected.

Backend logic must immediately provide a valid interrupt vector on s_data_in[]. Data must be held until s_int_ack is de-asserted. s_data_in[] 64 in Target mode input data bus used by back-end application to transfer data to PCI bus during target-read transactions.

Backend must provide data from : - BAR0...BAR5 when s_bar[0]..s_bar[5] is asserted - Expansion ROM when s_bar[6] is asserted - Backend-implemented conf. registers when s_bar[7] is asserted.

∞ s_data_in[] must always be tied to 0 when reading from unimplemented configuration registers or memory locations. s_data_out[] 64 out Data output for both target and master mode : it is used to read data received from the PCI bus during target-write transactions and DMA read transfers. s_bytevalid[] 8 out This signal is indicates which bytes of s_data_out[] are valid during a transactions.

- s_bytevalid[0] enables data bits 7..0 - ... - s_bytevalid[7] enables data bits 63..

During a write transaction : Backend application must use this signal in conjunction with s_write in order to known which bytes it must store.

During a read transaction : All bits of this signals are set during PCI-X burst transactions. In all other cases s_bytevalid[] reports byte enable for first data word : this information must be used when reads have side-effects. s_bytecount[] 13 out Indicates transaction maximum size in units of byte. Value ranges from 1 to 4096 bytes. Note that actual transfer size can be smaller than this value if an initiator or a backend disconnection occurs.

Table 6- Target interface signals

21

PCI-X & PCI Core User's Guide

3 - Master Mode

Direct Memory Access capability is a master-specific feature that allows PCI-X & PCI core to start transactions on the PCI bus. Core DMA engine controls data flows to and from a targeted device.

Core implements up to four independent DMA channels that may be used simultaneously to manage four separate data flows :

Ch a n n e l 0

PC I Bu s Ch a n n e l 1 DM A Ba c ke nd lo gi c EN G I N E Ch a n n e l 2

Ch a n n e l 3

Figure 7 - DMA Controller

- Each channel can be independently controlled by backend logic and all channels can run simultaneously. - A rotating priority algorithm insures that all channels have an equal chance of being serviced regularly. - DMA engine controls data transfers over PCI bus and automatically handles all PCI bus events (wait-states, retry, disconnects, abort ..) without any user interaction.

3.1. DMA MODES

© Direct DMA transfer is the default mode : DMA start address is a pointer to a contiguous data buffer mapped in the PCI bus address space. Data is read/written in a sequential order until all data is read/written.

Sy st e m me m o r y

DM A st a r t ad d r e ss Bu ff e r

Figure 8 - Direct DMA mode

∞ Note that a DMA transfer must not cross a 4GB address boundary.

22

PCI-X & PCI Core User's Guide

© Scatter-gather DMA transfer is an optional mode usually used to perform large data transfers. DMA start address is a pointer to a chained list of page descriptors :

System memory

Page address [31..0] DMA start address Page address [63..32] Page #2 Page size (bytes) Next descriptor pointer

Page address [31..0] Page #1 Page address [63..32] Page size (bytes) Next descriptor pointer

End of chain bit Figure 9 - Scatter-gather DMA mode

Each page descriptor defines the address and size of a data block plus a pointer to next descriptor block. Descriptors are automatically fetched when needed and then data is read/written to corresponding page. Chain is processed until transfer is finished or end of chain is reached, whichever comes first.

Descriptor format is detailed in the table below :

Field Description Page address Indicates physical start address of memory page. If page is located in the 32-bit addressing space then bits [63..32] must be zeroed. If page resides in the 64-bit addressing space then a full 64-bit address must be initialized.

Page size Indicates the size of memory page in units of bytes. This value must be a multiple of 8 bytes.

Next descriptor Specifies physical address of next page descriptor. Page descriptors can only be pointer located in the 32-bit addressing space. Setting bit 0 to ‘1’ indicates that current descriptor is the last descriptor in the chain : DMA engine will not attempt to fetch other descriptors.

Table 7 - Page descriptor fields

∞ Note that a page must not cross a 4GB address boundary.

∞ Page descriptor blocks cannot be mapped in 64-bit addressing space. For best performance, these blocks should be aligned on 8-byte boundaries.

23

PCI-X & PCI Core User's Guide

3.2. DYNAMIC TRANSACTION NEGOTIATION

© Once a transfer request is detected, DMA engine takes transaction initiation, data transfer and access termination in charge. DMA engine negotiates transactions dynamically : this means that it detects if target device can perform requested transfer and acts accordingly.

When a 32-bit data transfer is requested, DMA engine always transfers data in 32-bit mode. Backend always reads/provides 32-bit words.

When a 64-bit data transfer is requested, DMA engine does not know if target device is 64-bit capable. It asserts REQ64# and waits for target response :

- If target device asserts ACK64# then it is 64-bit capable and transaction proceeds. Backend reads/provides 64-bit data words.

- If target device is not 64-bit capable then DMA engine detects that ACK64# is no asserted, and thus reverts to 32-bit mode. Data multiplexing is performed by core and backend provides 64-bit data words only.

3.3. TRANSACTION ALIGNMENT

© DMA read/writes data on PCI bus using burst transfers of 1 to 4096 bytes. Backend logic must drive m_dman_datacnt[] signal in order to indicate to DMA how much data it is ready to accept/provide. DMA starts when either :

- Backend logic can accept/provide enough data to complete transfer, - Backend logic can accept/provide enough data to reach next naturally aligned 128-byte address boundary (ADB).

24

PCI-X & PCI Core User's Guide

3.4. DMA CHANNEL

© Core can implement up to four DMA channels. Each channel operates independently and has its own set of registers and control signals :

m_dman_regin[] Address register m_dman_control[]

m_dman_datacnt[] DMA Engine CONTROL Size register

m_dman_status[]

Command register m_dman_regout[]

Figure 10 - DMA Channel architecture

© DMA register is programmed by backend with m_dman_regin[] and m_dman_control[] in order start a DMA transfer. Backend logic can read back this register with m_dman_regout[] with the following layout :

31 0 Ad d r e s s LS B

Ad dr e ss fi e l ds 63 3 2 Ad d r e s s MS B

95 6 4 Si ze fi el d Tr a ns f e r s iz e ( b y t e s )

12 7 109 108 1 0 7 1 04 1 0 3 1 00 9 9 9 8 97 9 6 Co m ma nd fi e ld s B yt e e na b le Co m ma n d

NS S c a t t e r -g a t h e r

6 4-bit m ode RO P r io r i t y I n i t i a t i ng f u n ct io n

Figure 11 - DMA register

© Writing to address register when DMA channel is busy has no effect. Address, size and command fields can be written simultaneously. However if these registers are not written simultaneously then command fields must always be written the last since this also starts DMA transfer :

0 ps 6 0.0 n s 1 20.0 n s 1 8 0.0 n s 225 .0 n s clk_pci m _d m a _re g in [3 1 ..0] X A D _L O W X m _d m a _re g in [6 3 ..3 2] X A D _H IG H X m _d m a _re g in [9 5 ..6 4 ] X S IZE X m _d m a _re g in [1 27 ..9 6 ] X C M D X m _d m a _co n tro l 00000 0001 1 00000 001 00 01 000 00000 m _d m a _re g o u t[3 1 ..0] X A D _L O W m _d m a _re g o u t[6 3 ..3 2] X A D _H IG H m _d m a _re g o u t[9 5 ..6 4 ] X S IZE m _d m a _re g o u t[1 27 ..9 6 ] X D M A _co m m a n d _a n d _s e ttin g s

Write address LSB and MSB simultaneously Write command and start transfer Write size Waveform 11 - Writing to DMA register

25

PCI-X & PCI Core User's Guide

3.4.1. DMA Commands

© DWORD commands are restricted to a single data phase and :

- Transfer size register is ignored and not decremented after transfer. - Address register is not incremented after transfer. - Data transfer can be 32-bit only. - Byte-enable bits specified in byte-enable register are used.

© Burst commands can be any size from 1 byte to 232-1 bytes and :

- Transfer size register is automatically decremented after transfer. - Address register is automatically incremented after transfer. - Data transfer can be 32 or 64-bit. - Byte-enable bits for memory write command are read from m_be_in[] backend signal. Appropriate byte-enable bits are automatically computed by DMA engine for all other commands.

© Table below illustrates possible commands :

Code Description Type Resulting Resulting PCI bus command PCI-X bus command 0000 Interrupt acknowledge DWORD Interrupt acknowledge 0001 Special cycle DWORD Special cycle 0010 I/O read DWORD I/O read 0011 I/O write DWORD I/O write 0100 reserved 0101 reserved 0110 Memory read DWORD DWORD Memory read Memory read DWORD 0111 Memory write Burst Memory write 1000 reserved 1001 reserved 1010 Configuration read DWORD Configuration read 1011 Configuration write DWORD Configuration write 1100 reserved 1101 reserved 1110 Memory read burst Burst Memory read multiple Memory read block 1111 Memory write burst Burst Memory write Memory write block Table 8 - DMA Commands

Note that memory read burst and memory write burst are the recommended commands for data transfers to/from system memory.

26

PCI-X & PCI Core User's Guide

3.4.2. DMA Registers

© Address fields indicate start address for next transfer. Exact meaning of these fields depends on selected DMA mode :

- Direct DMA mode : this registers specifies physical address of a contiguous memory buffer where data will be read/written. DMA engine automatically detects that a 64-bit address is present when address MSB is not zeroed. - Scatter-gather DMA mode : address LSB specifies an address that points to the first element of a chained-listed of page descriptors. Address MSB is meaningless in this mode.

This register is automatically incremented when using burst commands so that if a new transfer is started and DMA start address has not been re-initialized, then new transfer continues at the address where last data transfer ended. m_dman_regin[] bits 31..0 are written to address LSB when m_dman_control[0] is asserted, m_dman_regin[] bits 63..32 are written to address MSB when m_dman_control[1] is asserted

© Transfer size field indicates the total amount of data to transfer, in units of bytes. This register used for burst commands only and is automatically decremented so that it value reflects the number of bytes remaining to transfer if the transfer is stopped or ends because of an error. m_dman_regin[] bits 95..64 are written to size field when m_dman_control[2] is asserted.

© Writing to command fields automatically start DMA transfer with the following settings:

Field Size Description Initiating This bit is used in multi-function core only, it must always be set to ‘0’ in a Function single-function core. This bit indicates which function is initiating DMA transfer : ‘0’ indicates that function #0 started the transfer, ‘1’ indicates that function #1 started the transfer.

Priority Setting this bit marks DMA channel as high-priority. A high-priority channel takes precedence over all channels in the arbitration process and thus has access to the PCI bus more quickly.

64-bit mode Setting this bit indicates that DMA engine will transfer 64-bit words and thus requests 64-bit transactions on the PCI bus. Backend logic must be prepared to provide/store 64-bit data words. This bit is valid for burst commands only.

Scatter-Gather If this bit is set then DMA is in scatter-gather mode, otherwise it is in direct DMA mode. This bit is meaningless if core does not support scatter-gather.

Command 4 These four bits indicate the command to be used for the DMA transfer. See next paragraph for a list of possible commands.

Byte enable 4 This field indicates the byte enables that will be used for DWORD commands. Default value is “0000” indicating that all bytes must be transferred.

RO PCIX relaxed-ordering bit: See PCIX specification for details. This bit should be set 0 unless strictly necessary. NS PCIX no-snoop bit: see PCIX specification for details. This bit should be set 0 unless strictly necessary. Table 9 - DMA register command fields m_dman_regin[] bits 127..96 are written to command fields when m_dman_control[3] is asserted.

27

PCI-X & PCI Core User's Guide

3.5. Channel State

© DMA channel works has illustrated below :

idle

write to DMA register command fields

complete error stop

abort or chain error

transfer complete backend stop

busy

Figure 12 - DMA Channel operations

Channel is idle when no DMA is under progress. A transfer can be programmed and writing to DMA command fields starts a new transfer :

- DMA engine is busy while processing data transfer. It remains so until transfer is either complete or stopped. - When all data has been transferred, transfer is complete and channel becomes idle on the next clock cycle. - Transfer ends immediately if a target-abort or master-abort termination occurs during a transfer, or if an error is detected in the page descriptor chain.

This activity is reflected by m_dman_status[7..4] signal in state field according to the encoding shown in the table below :

Code Channel state Details 0000 Transfer completed successfully. 0001 Transfer was aborted by backend logic, or cannot take place because master-enable bit is not set. 0010 Transfer ended because a target-abort occurred during data transfer. 0011 Transfer ended because a master-abort occurred during data transfer. 0100 idle Transfer ended because a target-abort occurred while reading a page descriptor block. 0101 Transfer ended because a master-abort occurred while reading a page descriptor block. 0110 Transfer ended because end of page descriptor chain was encountered before all data could be transferred. 0111 Transfer ended because a split error was received 1000 Transfer is under progress. 1001 reserved 1010 busy Channel is waiting for backend to accept or provide data 1011 Channel is waiting for split completion 1100 Channel is waiting for access to DMA engine others reserved Table 10 - Channel state encoding

28

PCI-X & PCI Core User's Guide

3.5. DMA DATA PATH

© Backend logic transfers data to/from the PCI bus through DMA data path as illustrated below :

s _ d at a_ o u t[ ] t o a l l c h a n n e l s

c h a n n e l # 0 d a t a P C I B u s P C I C O R E m _ d a t a _ i n [ ] c h a n n e l # 3 d a t a

m _ d m a n _ s t a t u s [ 0 ]

Figure 13 - DMA data path

- Data read from the PCI bus during DMA transfers is available on s_data_out[] signal. This output is common to all channels and DMA channel #n must store data word when m_dman_status[1] is asserted.

- Backend logic must provide data to be transferred to the PCI bus on m_data_in[] input. If more than one DMA channel can write data to the PCI bus, then backend logic must multiplex data sources and provide data for channel #n when m_dman_status[0] is asserted.

3.5.1. 32-bit Read data path

© m_dman_status[1] is asserted each time a data word is available on s_data_out[] for DMA channel #n and thus can be directly used as a write-enable flag for a FIFO as shown below :

m_d man_ s tat u s [1 ] P CI Bus PC I CO RE wr i t e enable s_d ata_ ou t[ ] FI FO

Figure 14 - 32-bit read data path

© This is also illustrated in waveform below :

0 ps 1 20.0 n s 24 0.0 n s 3 6 0.0 n s 4 5 0.0 n s clk_pci a d _pci Z A D D R A T T R Z D 0 D 1 D 2 D 3 Z fra m e _pci ird y _pci d e v s e l_pci trd y _pci m _d m a _s ta tu s [1 ] m _d m a _s ta tu s [0] s _d a ta _o u t X D 0 D 1 D 2 D 3 X

Channel is no longer selected Backend must read data Waveform 11 – 32-bit Read DMA

29

PCI-X & PCI Core User's Guide

3.5.2. 32/64-bit Read data path

© Depending on target device behaviour, data requested in 64-bit mode can be received as 32-bit or 64-bit data words. Backend must implement a simple data cache mechanism in order to handle this situation : the goal of this mechanism is to store data LSB until data MSB is received and then recreate 64-bit data word.

m _d ma n_ st atu s [1 ]

63..32 PC I CO RE

3 1. .0 wr it e enable P CI Bus s_d a t a_ ou t[ ] 0 FI FO

1

m_d man_ st atu s [8 ]

Figure 15 - 32/64-bit Read data path m_dman_status[8] is asserted each time data cache must store a 32-bit LSB data or present this stored data on the output of the multiplexer. m_dman_status[1] has exactly the same meaning as in 32-bit mode : it is asserted each time a complete 64-bit data word is available for DMA channel #n and thus can be directly used as a write-enable flag for a FIFO as shown above.

© Following waveform illustrates a 64-bit read DMA receiving data in 64-bit mode :

0 ps 1 20.0 n s 24 0.0 n s 3 6 0.0 n s 4 5 0.0 n s clk_pci a d _pci Z A D D R A T T R Z D 0 D 1 D 2 D 3 Z fra m e _pci re q 6 4 _pci ird y _pci d e v s e l_pci a ck6 4 _pci trd y _pci m _d m a _s ta tu s [8 ] m _d m a _s ta tu s [1 ] m _d m a _s ta tu s [0] s _d a ta _o u t[3 1 ..0] X D O L D 1 L D 2L D 3 L X s _d a ta _o u t[6 3 ..3 2] X D 0M D 1 M D 2M D 3 M X Waveform 12 – 64-bit Read DMA receiving 64-bit data

Note that m_dman_status[8] is never asserted since data LSB and MSB are received simultaneously and thus there is no need to re-assemble data.

30

PCI-X & PCI Core User's Guide

© Following waveform illustrates a 64-bit read DMA receiving data in 32-bit mode :

0 ps 1 20.0 n s 24 0.0 n s 3 6 0.0 n s 4 5 0.0 n s clk_pci a d _pci Z A D D R A T T R Z D 0L D 0M D 1 L D 1 M Z fra m e _pci re q 6 4 _pci ird y _pci d e v s e l_pci a ck6 4 _pci trd y _pci m _d m a _s ta tu s [8 ] m _d m a _s ta tu s [1 ] m _d m a _s ta tu s [0] s _d a ta _o u t[3 1 ..0] X D 0L X D 1 L X s _d a ta _o u t[6 3 ..3 2] X D 0M X D 1 M X

Waveform 13 - 64-bit Read DMA receiving 32-bit data

3.5.3. Write data path

© m_dman_status[2] is asserted each time a data word must be provided by DMA channel #n during a DMA write transfer. It can be used as a read-enable flag for a legacy synchronous FIFO as shown below :

m_d man_ stat u s[2 ] re ad e na ble

P CI Bus FIFO P CI CO R E

m_d ata_i n []

m_d m an_ statu s[0 ]

Figure 16 - FIFO controller write path

© This is also illustrated in waveform below :

0 ps 1 20.0 n s 24 0.0 n s 3 6 0.0 n s 4 5 0.0 n s clk_pci a d _pci Z A D D R A T T R X D 0 D 1 D 2 D 3 Z fra m e _pci ird y _pci d e v s e l_pci trd y _pci m _d m a _s ta tu s [2] m _d m a _s ta tu s [0] m _d a ta _in X D 0 D 1 D 2 D 3 X Channel is no longer selected Data is read from backend Waveform 14 – Write DMA Note that behaviour is the same for a 32-bit DMA (backend will always provide 32-bit data words) or a 64-bit DMA (backend will always provide 64-bit data words).

31

PCI-X & PCI Core User's Guide

3.6. DMA INTERFACE DESCRIPTION

© DMA engine interacts with backend-logic through a simple I/O interface comprising status, control and data signals. All existing DMA-interface signals are listed below but some signals may not appear on a custom instance as the PCI Wizard removes unused signals :

Signal Size I/O Description m_data_in[] 64 in DMA data input : backend logic must provide data on this bus during DMA write transfers.

Data words must be 64-bit when a 64-bit DMA transfer is programmed, 32-bit otherwise. m_be_in[] 8 in DMA byte-enable input for memory write command : backend logic must provide BE on this bus during DMA memory write transfers. This signal must be tied to 0’s if BE are not used.

BE words must be 8-bit when a 64-bit DMA transfer is programmed, 4-bit otherwise. m_dman_regin[] 128 in Value to be written to DMA register when m_dman_control[] bits 0..3 are asserted. This signal as exactly the same layout as DMA register. m_dman_control[] 5 in This signal provides coarse control over DMA channel activity :

4 3 2 1 0 Abort W r it e W r i t e W r i t e W r it e command s ize address MSB addres s LSB

- Bit 0 is a write enable for DMA register address LSB field. - Bit 1 is a write enable for DMA register address MSB field. - Bit 2 is a write enable for DMA register transfer size field. - Bit 3 is a write enable for DMA register command fields.

Bit 4 can be used to abort a currently running DMA transfer :

- This bit can be asserted for one clock cycle at any moment during a DMA transfer. - If DMA channel is not transferring data, then it stops immediately and reverts to idle state. - If DMA channel is currently transferring a block of data, then it will stop. This means that up to 1-4096 bytes of data can be transferred even if “abort” bit was asserted.

∞ “abort” bit should only be used to stop a transfer data when some fatal error condition occurred. It is not meant to be used for flow control purpose.

32

PCI-X & PCI Core User's Guide

m_dman_datacnt[] 11 in The value of this signal indicates to DMA channel how many data words (dwords in a 32-bit transfer, or qwords in a 64-bit transfer) backend logic is currently able provide/accept :

- When a write transfer has been programmed this signal must indicate the number of words that can be provided by backend logic. If data comes from a FIFO, than it is equivalent to the number of data words stored in the FIFO. A backend design that can always provide data can tie this value to 400h.

- When a read transfer has been programmed this signal must indicate the number of data words that can be accepted by backend logic. If data is stored in a FIFO, than it is equivalent to the number of free data words (empty locations) in the FIFO. A backend design that can always accept data can tie this value to 400h.

This value is used by DMA engine to put data transfer on hold until backend logic can accept/provide enough data. m_dman_status[] 9 out This signal reflects the state of DMA channel :

- Bit 0 is indicates that channel is selected by DMA engine and that channel data must appear on m_data_in[]. Note that this bit is not asserted when DMA is receiving data via split completion. - Bit 1 is asserted each time a data word is read from the PCI bus : this data is available on s_data_out[]. It can be connected to a FIFO write-enable pin. - Bit 2 is asserted each time a data word must be provided by DMA channel #n during a DMA write transfer. It can be connected to a FIFO read-enable pin. - Bit 3 is asserted during one clock cycle when DMA transfer ends. - Bit 8 is asserted each time a the LSB part of a 64-bit data must be stored from s_data_out[31..0]. This bit must be used to control the read cache mechanism.

- Bits 7..4 report detailed channel state as specified in “Channel State” chapter. m_dman_regout[] 128 out This signal reflects the state of DMA register. It can be read back in order to check channel current address, remaining data count and other settings.

Table 11 - DMA interface signals

33

PCI-X & PCI Core User's Guide

4 – Split Processing

4.1. GENERAL DESCRIPTION

© Backend logic can use split to respond to target-mode read transactions when it is unable to provide requested data fast enough.The request/completion process is described below :

1 T a r g e t 2 I n i t i a t o r B a c k e n d D e v i ce L o g i c 3 S p l i t C h a n n e l 5 4

Figure 17 - Split processing

1. Backend logic can specify a “SPLIT” response when a read transaction starts. Initiator stops the transaction immediately and waits for the completion. 2. Backend logic stores transaction parameters available on backend interface. 3. Backend logic fetches requested data from a peripheral device, a memory, an other bus… 4. When data is ready, then backend logic programs a split channel with transaction parameters. 5. Split channel transfers data to initiator device in order to complete the split transaction.

∞ Note that : - Backend can be designed to handle several requests simultaneously : it can accept a transaction, fetch data and perform one or more split completions at the same time. - How split requests are stored, forwarded if necessary and completed is backend responsibility. - Backend does not need to complete split requests in the same order as they were requested.

4.1.1. Eligible Transactions

© Core allows split response for the following transaction types only :

- IO read/write - memory read DWORD & burst - configuration read/write in address range 80h…FFh

∞ Split is available in PCI-X mode only : applications designed to take advantage of split must also be able to operate seamlessly in conventional PCI mode.

34

PCI-X & PCI Core User's Guide

4.2. REQUESTING SPLIT TERMINATION

© Backend logic can specify a “SPLIT” response on s_response[] signal when a transaction starts. If transaction is eligible then a split termination is signalled :

0 ps 1 20.0 n s 24 0.0 n s 3 5 0.0 n s clk_pci a d _pci ... A D D R A T T R X D A T A ... fra m e _pci d e v s e l_pci trd y _pci s to p_pci ta rg e t_s ta te id le a d d r re s p s ta rt tra n s b u s y id le s _re s po n s e X W A IT S P L IT X s _a d d r X S T A R T _A D D R X s _b a r X T A R G E T E D _B A R X s _s plit_s ta rt s _s plit_pa ra m X P A R A M X s _s plit_b y te co u n t X B C X Waveform 15 - Split request

s_split_start is asserted during one clock cycle in order to indicate that a split response was issued. : backend logic must then latch s_split_param[] and s_split_bytecount[] plus any additional information it might need such as transaction address and targeted bar (s_addr[], s_bar, …).

s_response[] s_addr[] Target control s_bar[]

Split request parameters s_split_param[] s_split_bytecount[] s_split_start Waveform 16 - Target interface signals for split

- s_split_bytecount[12..0] indicates requested transfer size in units of bytes. Backend is not allowed to respond the split transaction using an other This value must not be modified by backend logic when programmed back to a split channel.

- s_split_param[31..0] contains packed information required by split channel to complete the transaction. These bits are intended for split channels internal use only and backend logic should not use this information for any purpose.

35

PCI-X & PCI Core User's Guide

4.3. SPLIT CHANNELS

© Split channels are special DMA channels dedicated to perform split completion transactions. Core can implement up to two split channel.

Split channels are programmed by backend logic with split parameters specified on m_split_param[] and m_split_bytecount[] signals. Split channel latches these two signals and starts performing split completion when m_splitn_start is asserted. Once it is programmed, a split channel behaves just like a DMA channel.

m_split0_param[] m_split0_bytecount[] m_split0_start

Split Channel #0 m_split0_error[] m_split0_datacnt[] m_split0_status[]

Figure 18- Split channel interface

© Split completion is handled according to the following process :

1. Backend logic must program a split channel with stored parameters when it is ready to complete the transaction. 2. Backend must either provide data on m_data_in[] to complete transfer or signal a split error with m_splitn_error[] signal. 3. Split channel completes transfer according to backend instructions.

s _ r e s p o n s e [ ] s _ a d d r [ ] Ta r g e t c o n t r o l s _ b a r [ ]

S p l i t r e q u e s t p a r a m e t e r s s _ s p l i t _ p a r a m [ ] s _ s p l i t _ b y te c o u n t [ ] s _ s p l i t _ s t a r t P C I b u s m _ s p l i t 0 _ p a r a m [ ] m _ s p l i t 0 _ b y t e c o u n t [ ] m _ s p l i t 0 _ s t a r t S p l i t C h a n n e l # 0 m _ s p li t 0 _ e r r o r[ ] m _ s p li t 0 _ d a t a c n t [ ] m _ s p li t 0 _ s t a t u s [ ]

m _ s p l i t 1 _ p a r a m [ ] m _ s p l i t 1 _ b y t e c o u n t [ ] m _ s p l i t 1 _ s t a r t S p l i t C h a n n e l # 1 m _ s p li t 1 _ e r r o r[ ] m _ s p li t 1 _ d a t a c n t [ ] m _ s p li t 1 _ s t a t u s [ ]

Figure 19 - Split Channel programming

© There is no difference between channel #0 and #1 and they can be used in any order and for any split completion transaction. Backend logic is free to complete split transactions in any order.

∞ Backend must never program a split channel with modified parameters. Values programmed on m_splitn_bytecount[] and m_splitn_param[] must always be identical to the values obtained from s_splitn_bytecount[] and s_splitn_param[].

36

PCI-X & PCI Core User's Guide

4.5. SPLIT INTERFACE SIGNALS

Signal Siz I/O Description e s_split_start out This signal is asserted during one clock cycle in order to indicate that a split request was accepted. s_split_param 32 out This signals contains parameters necessary for split channel to complete the split transaction. Backend must latch this signal when s_split_start is asserted.

- Bits 6..0 indicate start address bits [6..0] - Bit 7 is set when transaction type is DWORD - Bits 28..8 contain requester identification - Bit 29 is set when target BAR datapath is 64-bit - Bit 30 indicates targeted function number - Bit 31 indicates if transaction is read or write s_split_bytecount 13 out Indicates transaction size in units of byte, as requested by the initiator of the transaction. Value ranges from 1 to 4096 bytes. Backend must latch this signal when s_split_start is asserted. m_splitn_start in Asserting this signal programs split channel with parameters presented on m_splitn_param. Split channel starts processing the split completion transfer on next clock cycle. m_splitn_param 32 in This signals provides split channel with parameters necessary to complete the split transaction. Backend must provide valid information when m_splitn_start is asserted. m_splitn_bytecount 13 in Indicates transaction size in units of byte, as requested by the initiator of the transaction. Backend must provide valid information this signal when m_splitn_start is asserted. m_splitn_datacnt[] 11 in The value of this signal indicates to split channel how many data words (dwords in a 32-bit transfer, or qwords in a 64-bit transfer) backend logic is currently able to provide.

Behaviour is similar to m_dman_datacnt[].

37

PCI-X & PCI Core User's Guide

m_splitn_error[] 2 in This signals controls how split completion is performed and core can automatically send a split message :

Code Read transaction Write transaction 00 Normal read completion : Reserved for future use. Backend must provide data to finish the transfer. Split completion ends when all necessary data has been transferred successfully. 01 Byte count out of range error : Split write parity error : Core automatically sends a Core automatically sends a split split error message indicating error message indicating that a that transaction goes past parity error was detected. addressing space boundary.

10 Device-Specific error : Core automatically sends a split error message indicating that backend is unable to provide data because of some error.

11 Reserved for future use. Normal write completion : Core automatically sends a split message indicating that write was successful.

The value of this signal can be changed to signal an error either before data is transferred of after some amount of data has been transferred during a read completion. m_splitn_status[] 8 out This signal reflects the state of split channel :

7 4 C h a n n e l s t a t e 3 2 1 0 C h a n n el E nd W ri te Rs v d s e l e c t

- Bit 0 is indicates that channel is selected and that channel data must appear on m_data_in[]. - Bit 1 is reserved for future use - Bit 2 is asserted each time a data word must be provided by DMA channel #n during a DMA write transfer. It can be connected to a FIFO read-enable pin. - Bit 3 is asserted during one clock cycle when DMA transfer ends. - Bits 7..4 report detailed channel state as specified in “Channel State” chapter. Encoding is the same as for DMA channels.

Table 12 - Split interface signals

38

PCI-X & PCI Core User's Guide

5 - Core Extensions

PCI-X & PCI core supports all features that are necessary to operate in a standard PCI environment. This section details additional features that can be supported optionally. These additional features also provide compatibility with other standards such as Power Management, MiniPCI, Cardbus and CompactPCI Hotswap.

5.1. INTERRUPT SUPPORT & MSI

© Each function in the core can be connected to one or any available interrupt line : a single-function core can only drive INTA#, a two-function core can drive INTA# and INTB#. Only one interrupt pin CINT# is available in Cardbus mode.

Function #n backend logic can assert s_intrequest[n] to request an interrupt on its interrupt pin. This signal is level sensitive and causes core to assert function’s interrupt pin, depending also if interrupts are enabled (see PCI specification rev.2.3) and the status of the RST# pin.

I NT E R R U P T SU PP O R T

IN TA # s_ i n tr eq u e s t [ ] IN TB #

CI NT # (C a rd b u s o n l y)

Figure 20 - Interrupt support interface

∞ How interrupt status can be accessed and cleared by software driver is left to designer's choice. However it is recommended that interrupt state can be checked/controlled via a memory-mapped register.

© Interrupt lines are not asserted and MSI mechanism is used instead to signal interrupt when MSI is enabled by operating system. An MSI interrupt message is sent over PCI bus each time a rising edge of s_int_request[] is detected. Backend logic must not signal a second interrupt request until first request has been acknowledged by software.

5.2. PLDA PCI-X BOARD INTERFACE

© Three signals named prot0_out, prot1_out and prot1_in[] are provided on core interface. These signals are necessary when implementing core on PLDA PCI-X board only as core will not operate properly if these signals are not connected to the board.

If core is not implemented on a PLDA PCI-X board then :

- prot0_out, prot1_out must be left unconnected. - prot1_in[] must be tied to “00”.

39

PCI-X & PCI Core User's Guide

5.3. PLDA CORE STATUS REGISTER & JTAG INTERFACE

© PLDA Core status register (PLDA CSR) is a register implemented at address 44h in configuration space. This register provides helpful information about the core and also makes it possible to control a JTAG interface in order to perform in-site programming :

3 1 3 0 2 9 28 2 7 1 6 1 5 4 3 2 1 0 C o r e v er si o n P L D A S ig n a t ur e

b u s sp e e d J TA G T DO JT A G T D I b u s m o d e J TA G T MS r e s e r v ed J TA G e na b l e

Figure 21 - PLDA Core Status register

- Bus mode : 0 indicates that bus is in PCI mode and 1 means PCI-X mode. - Bus speed : this flag indicates bus speed as detailed below :

Code Bus speed 00 33 MHz 01 66 MHz 10 100 MHz 11 133 MHz Table 13 - PCI bus speed encoding

- Core version : identifies core release, for instance 100h means version 1.0.0 - PLDA Signature : 614h identifies a PCI-only core, 615h a PCI-X capable core - JTAG bits control the JTAG interface and are detailed below.

© Core can drive jtag_io[] backend JTAG interface in order to communicate with other devices : this makes it possible to detect, control and program devices located on the same board. Software driver controls JTAG operations using PLDA Core Status register :

- JTAG enable : JTAG interface is tri-stated when this bit is 0, PCI-X core writes to it when this bit is 1. This bit is hardwired to 0 when built-in JTAG interface is not implemented. - JTAG TMS : value of TMS signal, this value is written to jtag_io[] bit 1 when JTAG enable is 1. - JTAG TDI : value of TDI signal, this value is written to jtag_io[] bit 2 when JTAG enable is 1. - JTAG TDO : value of TDO signal, read from jtag_tdo.

Core automatically generates a clock pulse on TCK (jtag_io[] bit 0) when a write to JTAG control bits is detected. TCK clock frequency is PCI clock frequency divided by 8.

∞ In a multi-function device, PLDA core status register is visible in all functions but JTAG interface bits are implemented in function #0 only.

40

PCI-X & PCI Core User's Guide

5.4. POWER MANAGEMENT

PCI power management protocol enables host system to put a PCI device in low-power mode and restore its full functionality when appropriate. Power management is always implemented however there is a minimal configuration that provides only strictly necessary features for devices who do not need full support.

5.4.1. Overview

© Each function in a device implements a PMC (power management capabilities) and a PMCSR (power management control/status) register, mapped in the configuration space at address 78h and 7Ch. Device can request a change in its power state using PME# (CSTSCHG for Cardbus) pin :

P o w e r M a na g e m e n t R e gi s t e r s p m _ s t a t e P M E # p m _ r e s e t n p m _ s e l e c t C a rd b u s S t a t u s R e g is t e r s p m _ d a t a (C a rd b us o n ly ) C S T S C H G E d g e D e t e c t o r p m _ e v e n t ( C a rd b u s o n l y)

Figure 22 - Power Management Support

© Host system accesses PMC to check supported states and features. Core can support all states but custom capabilities can be set with the PCI Wizard. PMCSR is used to control function's power state and report advanced power consumption and dissipation information :

Address 31…24 23…16 15…8 7…0 78h PMC Next Item Offset Capability ID = 01h 7Ch Data Register PMCSR Figure 23 - Power Management Registers

- Backend logic must check power state using pm_state[] signal and behave accordingly. - Backend logic must report device power consumption with the data register. pm_select[] indicates which data has been selected by software and backend logic must provide corresponding value and scale information on pm_data[] bus.

41

PCI-X & PCI Core User's Guide

5.4.2. Power Management Events

© If backend logic wants to be restored to a functional state, then it must request a power management event. Core issues a power management interrupt when it detects a rising edge on pm_event[] and power management interrupt is enabled :

p c i_ c lk p m _ e v e n t

p c i_ p m e p c i_ c s t s ch g backend requests a PM event host restarts clock Waveform 17 - Power Management Event Request pm_event[] must be asserted for at least one clock cycle. PCI-X core detects rising edge of pm_event[] in order to avoid detecting multiple event requests.

∞ Note that PME# operation is asynchronous to the PCI clock. Backend design must not rely on the presence of the PCI clock to control pm_event[].

5.4.3. State Transitions

© State transition is performed by software in order to put a function in a low consumption state or restore a device to a functional state. PCI-X core supports all power management states, however D1 and D2 support is optional. Following figure illustrates allowed transitions :

D0 /00/

D1 D2 /01/ /10/ Soft-reset (optional) (optional)

D3 /11/

Figure 24 - PCI Core Power States

Backend logic can monitor current power state with pm_state[] signal :

- D0 : PCI-X core is fully functional - D1,D2,D3 : IO & memory access is disabled, DMA & functional interrupts are not allowed.

PCI-X core responds to configuration accesses in all power states, as long as power is available.

42

PCI-X & PCI Core User's Guide

© A software reset occurs when a function is moved from D3 to D0 state. Configuration space is cleared and function returns to an un-initialized state. pm_resetn[] can be used an active low reset signal for backend logic :

pci_clk

pm_event

pci_pme

pci_cstschg

pm_state 03 00

pm_resetn backend requests wake-up from D3 core is restored to D0 Waveform 18 - D3-D0 Transition

© When PME is supported from D3cold, “sticky” power management registers must be cleared at power-on of the device by the power-on reset “npor” signal (otherwise, incorrect behaviour can occur in ASIC implementation).

5.5. COMPACTPCI HOTSWAP

© CompactPCI devices are identical to PCI devices except that they can optionally support hotswap. An hotswap capable board can be inserted or removed from a live system without requiring system shut-down and restart.

CompactPCI hotswap control register is implemented in configuration space:

C o n f ig u r a t i o n S p a c e P C I B u s

c p c i _ l e d c p c i _ e n u m H o ts w a p R e g i s t e r

E d g e c p c i_ h a n d l e d e t e c t o r F i l t e r

Figure 25 - CompactPCI Hotswap architecture

PCI core generates an interrupt on cpci_enum signal when a change is detected on CompactPCI handle switch :

- a falling edge on cpci_handle signal indicates that the board is being inserted in the system - a rising edge on cpci_handle signal indicates that the board is being removed from the system

43

PCI-X & PCI Core User's Guide

5.6. CARDBUS

PCI-X & PCI core can optionally be fully compatible with Cardbus specification. This chapter details functional differences between Cardbus core and standard core.

5.6.1. Cardbus signals

© Pure Cardbus devices have no IDSEL# pin and respond to all configuration accesses. PCI/Cardbus shared silicon devices have an idsel_pci signal :

- idsel_pci must be connected to IDSEL# in a PCI system - idsel_pci must be tied to ‘1’ when the core is implemented in a Cardbus system.

© Functional interrupt pin is CINT# (instead of INTA#). PCI/Cardbus shared silicon devices have both cint_pci and inta_pci signals :

- inta_pci must be connected to INTA# in a PCI system, cint_pci must be left unconnected. - cint_pci must be connected to CINT# in a Cardbus system, inta_pci must be left unconnected.

© PME# pin does not exist in Cardbus systems and wake-up events are signaled with CSTSCHG pin. PCI/Cardbus shared silicon devices have both pme_pci and cstschg_pci signals:

- pme_pci must be connected to PME# in a PCI system, cstschg_pci must be left unconnected. - cstschg_pci must be connected to CSTSCHG in a Cardbus system, pme_pci must be left unconnected.

5.6.2. Cardbus Information Structure

© Each function in a Cardbus core implements a Cardbus Information Structure (CIS). This structure identifies the card and indicates card resource requirements. It is backend responsibility to implement a suitable CIS record otherwise card may not operate properly.

CIS Structure is a read-only set of registers that can be implemented either in configuration space or in a memory space. Refer to “PC Card Standard – Metaformat Specification” for a complete description of CIS structure.

© Cardbus CIS pointer is a PCI header register located in configuration space at address 28h. This register must indicates where CIS structure is located, either in configuration space or in a memory space. Refer to “PC Card Standard – Electrical Specification – Chapter 5.4.2.1.8” for a description of this register.

44

PCI-X & PCI Core User's Guide

5.6.3. Status Registers

© Cardbus status registers provide a way for Card Services to control and monitor functional and status-changed interrupts. These registers are implemented in PCI core that can generate functional interrupts or wake-up events.

These registers are located in configuration space at address 68h…74h and each function has a separate set of status registers:

1 5 4 0 6 8 h : FU N C T IO N E VE N T ( F E ) IN T R G WA K E 1 5 1 4 4 0 6 C h : FU N C T IO N E VE N T M A S K (F E M ) IN T R WK U P G WA K E 1 5 4 0 7 0 h : FU N C T IO N P RE S E N T S TA T E ( F P S ) IN T R G WA K E 1 5 4 0 7 4 h : FU N C T IO N F OR C E E V E N T ( F F E ) GWAKE IN T R Figure 26 - Cardbus status registers

- Function Present State (FPS) reflects the current state of core interrupt request (INTR) and power management event request (GWAKE). This register is read-only.

- Function Event register (FE) bits are set by PCI core to indicate pending interrupt or event requests. Card Service monitors these bits when an interrupt or status-changed event occurs and then clears them after interrupt is serviced.

- Function Event Mask (FEM) register bits indicate whether CINT# and CSTSCHG pins can be asserted as a result of specific events. Event mask is set by Card Service.

- Function Force Event (FFE) is provided as a way to simulate interrupt or status-changed request for debug purpose. Writing ‘1’s to this register sets corresponding bits in FE register.

∞ Refer to “PC Card Standard – Electrical Specification – Chapter 5.2.11” for detailed information.

45

PCI-X & PCI Core User's Guide

5.6.4. Functional interrupts

© Cardbus and PCI interrupt behavior is similar form backend logic point of view. However software handling and CINT# behavior also involves Cardbus status re registers :

Event Cardbus behavior PCI behavior Backend asserts - FPS_INTR is set INTA# is asserted s_int_request[] - FE_INTR is set - CINT# is asserted if FEM_INTR=’1’

Host system detects interrupt Int. handler is called Int. handler is called

Int. handler clears source - Backend de-asserts s_int_request[] - Backend de-asserts - FPS_INTR is reset s_int_request[] - FE_INTR is cleared - INTA# is de-asserted - CINT# is de-asserted

∞ Note that CINT# is asserted when FEM_INTR=’1’ and (FE_INTR=’1’ or FPS_INTR=’1’). Refer to “PC Card Standard – Electrical Specification – Chapter 5.2.11” for more information.

5.6.5. Wake-up events

© Cardbus devices operate in a transparent way with PCI power management: this means that a Cardbus device operates behaves like a PCI device in an ACPI operating system.

Setting and clearing power management control bits in PMCSR causes the changes to be reflected in Cardbus status registers :

- Setting/clearings PME_EN bit sets/clears FEM_WKUP and FEM_GWAKE bits - Clearing PME_STATUS bit clears FE_GWAKE bit

Wake-up events are processed as shown below:

Event Cardbus behavior PCI behavior Backend asserts pm_event[] - FPS_GWAKE is set PME# is asserted if PME_EN=’1’ - FE_GWAKE is set - CSTSCHG is asserted if FEM_WKUP, FEM_GWAKE and PME_EN are ’1’

Cardbus bridge detects Bridge asserts PME# status changed event

Host system detects event ACPI service is called ACPI service is called

ACPI service clears source - PME_STATUS is cleared PME_STATUS is cleared - FE_GWAKE is cleared

∞ Note that CSTSCHG is asserted when (FE_GWAKE=’1’ or FPS_GWAKE=’1’) and FEM_GWAKE=’1’ and FEM_WKUP=’1’ and PME_EN=’1’

Refer to “PC Card Standard – Electrical Specification – Chapter 5.2.11 and Chapter 6.6.2” for more information.

46

PCI-X & PCI Core User's Guide

5.7. CORE EXTENSIONS INTERFACE DESCRIPTION

Signal Size I/O Description s_intrequest[] 2 in Asserted by user application to request an interrupt. These signals are level sensitive and bits 0…1 control function #0...1 interrupt request lines. How requests are mapped to INTA#..INTB# depends on core settings.

Note that interrupt lines are not asserted and MSI mechanism is used instead to signal interrupt when MSI is enabled. prot0_out out Interface to PLDA PCI-X board. This signal must be left unconnected when core is not implemented in this board. prot1_out out Interface to PLDA PCI-X board. This signal must be left unconnected when core is not implemented in this board. prot1_in 2 in Interface to PLDA PCI-X board. This signal must be tied to “00” when core is not implemented in this board. jtag_io[] 3 out Part of backend JTAG interface. See PLDA core status register for more details. Bits must be connected as shown below : bit 0 : TCK bit 1 : TMS bit 2 : TDI jtag_tdo in Part of backend JTAG interface. This bit must be connected to JTAG TDO signal. See PLDA core status register for more details.

cpci_handle in This signal is used for CompactPCI hotswap-capable devices: extractor handle switch must be connected to it. Insertion is detected on a falling edge of this signal, and extraction on a rising edge. cpci_led out Controls hotswap blue LED on CompactPCI hotswap-capable boards. '1' = led on, '0' = led off cpci_enum out Controls ENUM# signal on the CompactPCI bus.

47

PCI-X & PCI Core User's Guide

npor in This is an active-low asynchronous power-on-reset pin that controls some power-management registers. It must be asserted only at device power-up. pm_state[] 4 out Indicates each function's power state. It is backend logic's responsibility to check power state and take appropriate actions :

bits 1…0 : function #0 state 00=D0,01=D1,10=D2,11=D3 bits 3…2 : function #1 state pm_event[] 2 in Power management event request : each function can assert a bit in this signal in order to generate a power management event when it needs to be wake up.

This signal must be asserted for a minimum of one clock cycle. If PCI clock is stopped then this signal must be kept asserted until first clock cycle after clock restart.

bits 0…1 are event request for functions #0…#1 pm_resetn[] 2 out Power management soft reset : each of these active low reset bit is asserted during one clock cycle when corresponding function is moved from D3 to D0 state.

∞ Function’s configuration space is cleared and backend must reset its logic as needed. It is recommended that pm_resetn[] is used as a synchronous reset in backend logic. pm_select[] 8 out Power management data register select : software can select any of the 16 data reported in the power management register. Backend must check pm_select[] bits and provide corresponding data/scale information on pm_data[].

bits 3…0 : function #0 select bits 3..0 bits 7…4 : function #1 select bits 3..0 pm_data[] 20 in Power management data register data and scale information : backend logic must provide on this bus

bits 1…0 : function #0 data scale bits 9…2 : function #0 data bits 11…10 : function #1 data scale bits 19…12 : function #1 data

Table 14 - Core extension signals

48

PCI-X & PCI Core User's Guide

Appendixes

A1. REFERENCE DOCUMENTS

© PLD Applications PCI-X & PCI core user's guide is based on some documents listed below. Users can find more detailed information about PCI bus architecture and design in this literature. Official specifications that were used are :

- PCI-X Addendum to the PCI Local Bus Specification , revision 2.0a – PCI SIG, July 2003 - PCI Local Bus Specification , revision 3.0 - PCI Special Interest Group, February 2004 - PCI Compliance Checklist , revision 3.0 - PCI Special Interest Group, March 2004 - PCI Mobile Design Guide, revision 1.1 - PCI Special Interest Group, December 1998 - PCI Bus Power Management Interface, revision 1.2 - PCI SIG, March 2004 - CompactPCI Hot Swap Specification , revision 1.0 - PICMG, August 1998 - MiniPCI Specification , revision 1.0 - PCI Special Interest Group, October 1999 - PC Cards Standard , release 8.0 - PCMCIA Association, April 2001

© In addition to specifications some books can provide more clear explanations as well as comprehensive examples :

- PCI-X System Architecture, 3rd edition - Tom Shanley, November 2000. - PCI System Architecture, 3rd edition - Tom Shanley & Don Anderson, September 1995. - Cardbus System Architecture - Tom Shanley & Don Anderson, December 1995, - PCI Hardware and Software architecture & design, 2nd edition - Edward Solari & George Willse, March 1995.

© Core users should refer to the following document for all licensing, installation and implementation related matters :

PCI-X & PCI Core Design Guide, version 7.0.9 - PLD Applications, October 2006

49

PCI-X & PCI Core User's Guide

A2. PCI-X TERMINOLOGY

© This section is provided as a quick reference guide to get information and definition for the most commonly encountered PCI-X & PCI terms in this user guide :

Term Definition # PCI-X bus signals ending with "#" are active low signals Abort An abnormal transaction termination due to a fatal error. Transaction is not repeated. ADB Allowable Disconnect Boundary : a naturally aligned 128-byte boundary. Initiators and targets are permitted to disconnect burst transactions only on ADBs. Arbiter A specific device that regulates PCI-X bus sharing among all master devices. Asserted Refers to a signal and means "driven to the active state" Attribute A 36-field contained on CBE#[3..0] and AD[31..0] during the attribute phase of a PCI-X transaction. Attribute phase The clock after the address phase. Back-end The overall user application regardless of its physical location. BAR Base Address Register Bridge A special component that interfaces the PCI bus to some other bus. Burst Consecutive read or write data transfers. Burst transaction PCI-X transaction that can have more than one data phase and can be initiated in 32-bit or 64-bit mode. Byte count The number of bytes to be included in a transaction. Configuration A set of registers used to set-up a PCI device Completer The device addressed by a transaction. Data transfer A clock cycle for which a valid data is transferred on the PCI bus. Disconnect A PCI-X bus transaction in which a target device prematurely ends a transaction intended for it. Transactions can be stopped after first data phase or on ADBs only. DMA Direct Memory Access DWORD transaction PCI-X transaction that can have a single data phase and can be initiated in 32-bit mode only. Dual-address cycle A PCI bus command and a scheme used to transfer 64-bit addresses in two consecutive 32-bit parts. Host The computer or system in which the PCI bus is implemented Initiator see Master Master An agent that can initiate transactions on the PCI bus. Master/Target An agent that acts either as a Master or as a Target. PCI Peripheral Component Interconnect local bus Requester Initiator that first introduces a transaction into PCI-X domain. Retry A PCI-X bus transaction in which a target device momentarily refuses a transaction intended for it. Target An agent that responds to a transaction initiated on the PCI-X bus (by a master agent) and intended for it. Transaction A session on the PCI-X bus composed by an address phase plus one or more data phases. Turn-around A period at the end of each PCI-X transaction where all PCI-X bus signals are driven high to avoid bus conflicts. Single-address cycle A scheme used to transfer 32-bit addresses on the PCI bus Slave see Target Split A mechanism in which the target of a transaction stops and completes a transaction itself later. Wait-state A bus clock cycle in which no transfer occurs. Table 15 – PCI-X Terminology

50

PCI-X & PCI Core User's Guide

A3. ILLUSTRATION INDEX

Waveform 1 - 32-bit address decoding...... 13 Waveform 2 - 64-bit address decoding...... 13 Waveform 3 - Backend indicates it is ready ...... 16 Waveform 4 - Backend insert two initial wait-states ...... 16 Waveform 5 - Backend insert one wait-state and issues single-data disconnect...... 16 Waveform 6 - Typical target write transaction ...... 17 Waveform 7 - Typical target read transaction...... 17 Waveform 8 - 32-bit write to a 32-bit space...... 18 Waveform 9 - 32-bit write to a 64-bit space...... 18 Waveform 10 - 64-bit write to 64-bit space...... 19 Waveform 11 – 32-bit Read DMA...... 29 Waveform 12 – 64-bit Read DMA receiving 64-bit data ...... 30 Waveform 13 - 64-bit Read DMA receiving 32-bit data...... 31 Waveform 14 – Write DMA...... 31 Waveform 15 - Split request...... 35 Waveform 16 - Target interface signals for split...... 35 Waveform 17 - Power Management Event Request ...... 42 Waveform 18 - D3-D0 Transition...... 43

Figure 1 – PCI-X & PCI Core Architecture ...... 5 Figure 2 - Target state machine ...... 7 Figure 3 – Core internal data path...... 9 Figure 4 - Multi-function core...... 12 Figure 5 - Target data flow ...... 14 Figure 6 - Target interface...... 14 Figure 7 - DMA Controller...... 22 Figure 8 - Direct DMA mode...... 22 Figure 9 - Scatter-gather DMA mode ...... 23 Figure 10 - DMA Channel architecture...... 25 Figure 11 - DMA register ...... 25 Figure 12 - DMA Channel operations...... 28 Figure 13 - DMA data path ...... 29 Figure 14 - 32-bit read data path...... 29 Figure 15 - 32/64-bit Read data path...... 30 Figure 16 - FIFO controller write path...... 31 Figure 17 - Split processing...... 34 Figure 18- Split channel interface...... 36 Figure 19 - Split Channel programming...... 36 Figure 20 - Interrupt support interface...... 39 Figure 21 - PLDA Core Status register...... 40 Figure 22 - Power Management Support ...... 41 Figure 23 - Power Management Registers...... 41 Figure 24 - PCI Core Power States...... 42 Figure 25 - CompactPCI Hotswap architecture...... 43 Figure 26 - Cardbus status registers ...... 45

Table 1 – Target states...... 8 Table 2 - Core configuration space ...... 10 Table 3 - PCI command register...... 11 Table 4 - PCI status register...... 11 Table 5 - Backend response encoding...... 15 Table 6- Target interface signals...... 21 Table 7 - Page descriptor fields...... 23 Table 8 - DMA Commands...... 26 Table 9 - DMA register command fields ...... 27 Table 10 - Channel state encoding...... 28 Table 11 - DMA interface signals ...... 33 Table 12 - Split interface signals ...... 38 Table 13 - PCI bus speed encoding ...... 40 Table 14 - Core extension signals...... 48 Table 15 – PCI-X Terminology ...... 50

51