Renesas Tsi301 HyperTransport User manual

®
6024 Silver Creek Valley Road, San Jose, California 95138
Telephone: [phone] • [phone] • FAX: [phone]
Printed in U.S.A.
©2009 Integrated Device Technology, Inc.
Tsi301™
HyperTransport to PCI
User Manual
80D3000_MA001_02
September 2009

GENERAL DISCLAIMER
Integrated Device Technology, Inc. reserves the right to make changes to its products or specifications at any time, without notice, in order to improve design or performance
and to supply the best possible product. IDT does not assume any responsibility for use of any circuitry described other than the circuitry embodied in an IDT product. The
Company makes no representations that circuitry described herein is free from patent infringement or other rights of third parties which may result from its use. No license is
granted by implication or otherwise under any patent, patent rights or other rights, of Integrated Device Technology, Inc.
CODE DISCLAIMER
Code examples provided by IDT are for illustrative purposes only and should not be relied upon for developing applications. Any use of the code examples below is completely
at your own risk. IDT MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE NONINFRINGEMENT, QUALITY, SAFETY OR SUITABILITY
OF THE CODE, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICU-
LAR PURPOSE, OR NON-INFRINGEMENT. FURTHER, IDT MAKES NO REPRESENTATIONS OR WARRANTIES AS TO THE TRUTH, ACCURACY OR COMPLETENESS
OF ANY STATEMENTS, INFORMATION OR MATERIALS CONCERNING CODE EXAMPLES CONTAINED IN ANY IDT PUBLICATION OR PUBLIC DISCLOSURE OR
THAT IS CONTAINED ON ANY IDT INTERNET SITE. IN NO EVENT WILL IDT BE LIABLE FOR ANY DIRECT, CONSEQUENTIAL, INCIDENTAL, INDIRECT, PUNITIVE OR
SPECIAL DAMAGES, HOWEVER THEY MAY ARISE, AND EVEN IF IDT HAS BEEN PREVIOUSLY ADVISED ABOUT THE POSSIBILITY OF SUCH DAMAGES. The code
examples also may be subject to United States export control laws and may be subject to the export or import laws of other countries and it is your responsibility to comply with
any applicable laws or regulations.
LIFE SUPPORT POLICY
Integrated Device Technology's products are not authorized for use as critical components in life support devices or systems unless a specific written agreement pertaining to
such intended use is executed between the manufacturer and an officer of IDT.
1. Life support devices or systems are devices or systems which (a) are intended for surgical implant into the body or (b) support or sustain life and whose failure to perform,
when properly used in accordance with instructions for use provided in the labeling, can be reasonably expected to result in a significant injury to the user.
2. A critical component is any components of a life support device or system whose failure to perform can be reasonably expected to cause the failure of the life support device
or system, or to affect its safety or effectiveness.
IDT, the IDT logo, and Integrated Device Technology are trademarks or registered trademarks of Integrated Device Technology, Inc.

*Notice: The information in this document is subject to change without notice
Tsi301 HyperTransport to PCI User Manual 6
Notes
About This Manual
This reference manual contains technical specifications for the Tsi301 HyperTransport PCI bridge chip.
The manual is intended for use by system designers and developers who are using the chipset in their
designs.
HyperTransportTM and LDT
In this manual, HyperTransportTM technology and LDT (Lightning Data Transport) are sometimes used
interchangeably. HyperTransportTM technology and LDT both refer to identical technology based on the same
specification.
Throughout the remainder of this manual HyperTransportTM technology is referred to as HyperTransport.
Silicon Revisions: Pass1 and Pass2
Silicon revisions are referred to as Pass1 and Pass 2 throughout this document. Pass1 refers to silicon
revisions 1.0 and 1.1. Pass2 refers to silicon revisions 2.0 and higher. Any information not flagged as specific
to Pass1 or Pass 2 is applicable to all Tsi301 bridges. Pass1 and Pass2 are italicized throughout this docu-
ment’s text to help identify the relevant information.
The following sections describe the intended audience, scope, and the organization of this reference
manual.
Audience
This reference manual is intended for system designers and others who design using the HyperTransport
PCI bridge, or who evaluate computer systems based on this chip.
Scope
This manual describes the features, requirements, and configurations for the HyperTransport PCI bridge,
including functional and physical details.
Specific details on industry standards (for example, PCI or ISA bus specifications) are not included. Addi-
tional information is available in the appropriate vendor and IEEE specifications.
Conventions and Definitions
This section describes stylistic conventions used in this manual, and defines product-specific terminology,
acronyms, and other technical language used throughout this manual.
Information Flags
Note: Notes highlight information that provides additional clarification or will ease tasks related to
the assembly and operation of the system.
Typographic Conventions
This manual uses the following type conventions:
•Italic type is used for document citations and information that provides supplemental clarification.
Pass1 and Pass2 are italicized throughout this document’s text to help identify the relevant
information.
•Courier font is used for type that appears on a screen, such as an example of computer
output.

*Notice: The information in this document is subject to change without notice
About This Manual
Notes
Tsi301 HyperTransport to PCI User Manual 6
Signals and Bits
•Active-Low Signals—Signal names ending in _N, such as SFILL_N, indicate active-low signals.
Active-low signals are asserted in their low-voltage state and negated in their high-voltage state.
•Active-High Signals are asserted in their high-voltage state and negated in their low-voltage state.
•Differential Signals—Differential signals are indicated by the _H and _L suffixes. Signals ending in _H
are the active-high half of a differential pair whereas signals ending in _L are the active-low half of a
differential pair.
•Signal Ranges—The highest and lowest signal numbers in a range of signals are contained in
brackets and separated by a colon; for example D[63:0].
•Reserved Bits and Signals—Signals or bus bits marked reserved must be driven inactive or left
unconnected, as indicated in the signal descriptions. These bits and signals are reserved by API
NetWorks, Inc. for future implementations. When software reads registers with reserved bits, the
reserved bits must be masked. When software writes such registers, it must first read the register and
change only the non-reserved bits before writing back to the register.
Data
The following list defines data terminology:
•Quantities
–A word (W) is two bytes (16 bits).
–A doubleword (DW) is four bytes (32 bits).
–A quadword (QW) is eight bytes (64 bits).
•Abbreviations—The following notation is used for bits and bytes:
–Kilo—K, as in 4-Kbyte page (210).
–Mega—M, as in 4 Mbits/sec (220).
–Giga—G, as in 4 Gbytes of memory space (230).
•Little-Endian Convention—The byte with the address xx...xx00 is in the least-significant byte position
(little end). In byte diagrams, bit positions are numbered from right to left: The little end is on the right,
and the big end is on the left.
•Bit Ranges—In text, bit ranges are shown with a colon (for example, 3:0). When accompanied by a
signal or bus name, the highest and lowest bit numbers are contained in brackets and separated by a
colon (for example, AD[31:0]).
•Bit Values—Bits can either be set to 1 or cleared/reset to 0.
•Hexadecimal and Binary Numbers—Unless the context makes interpretation clear, hexadecimal
numbers are followed by an h, binary numbers are followed by a b, and decimal numbers are followed
by a d.
Acronyms
The following is a list of acronyms used in this document.
Acronym Definition
APIC Advanced Programmable Interrupt Controller
BIOS Basic Input/Output System
CSR Control/Status Register
DAC Dual Address Cycle
DDR Double Data Rate
DMA Direct Memory Access
DRAM Direct Random Access Memory
ESBGA Enhanced Super Ball Grid Array
FIFO First In, First Out
HSTL High-Speed Transistor Logic
I/O Input/Output

*Notice: The information in this document is subject to change without notice
About This Manual
Notes
Tsi301 HyperTransport to PCI User Manual 6
ISA Industry Standard Architecture
LSB Least Significant Bit
LVD Low Voltage Differential
LVTTL Low Voltage Transistor-Transistor Logic
MRL Memory Read Line
MRM Memory Read Multiple
MSB Most Significant Bit
MWI Memory Write Invalid
NDA Non-disclosure Agreement
NMI Non-maskable Interrupt
ORC Outbound Request Controller
OS Operating System
PBGA Plastic Ball Grid Array
PCB Printed Circuit Board
PIO Programmed Input/Output
PCI Peripheral Component Interconnect
PLL Phase Locked Loop
SBGA Super Ball Grid Array
SDRAM Synchronous Direct Random Access Memory
SE Single-ended
SIP Serial Initialization Packet
SPD Serial Presence Detect
SRI Serial ROM Interface
SROM Serial Read Only Memory
SRAM Static Random Access Memory
SRM System Reference Manual
Acronym Definition

*Notice: The information in this document is subject to change without notice
About This Manual
Notes
Tsi301 HyperTransport to PCI User Manual 6

*Notice: The information in this document is subject to change without notice
1-10
Notes
Chapter 1 Bridge Features
This chapter describes the features and operation of the API NetWorks HyperTransport PCI bridge.
1.1 HyperTransport PCI Bridge Features
The HyperTransport PCI bridge is an I/O bridge from HyperTransport to PCI with the following features:
•An 8-bit HyperTransport primary interface capable of running at data rates up to 800 Mb/s and
compliant with Lightning Data Transport I/O Link Protocol Specification, Revision 1.0.
•A 64-bit, 66 MHz PCI secondary interface compliant with the PCI Local Bus Specification, Revision
2.2.
•A PCI arbiter supporting six external bus masters (not counting the Tsi301) and compliant with the PCI
Local Bus Specification, Revision 2.2.
•A HyperTransport interrupt controller with configurable support for up to 20 interrupt sources in Pass1,
and 16 interrupt sources in Pass2.
•A configuration register set and programming model consistent with the PCI-to-PCI Bridge
Architecture Specification, Revision 1.1.
•Power-up configuration through Serial Initialization Packet (SIP) or pin sampling.
1.2 HyperTransport Interface
The HyperTransport PCI bridge primary interface is a HyperTransport tunnel. The primary interface is
compliant with Lightning Data Transport I/O Link Protocol Specification, Revision 1.0 with the exception that
the Tsi301 does not support 2 and 4 bit HyperTransport interfaces and does not support Dynamic Frequency
Programming. The interface contains two HyperTransport links which allow the connection of multiple bridge
chips in a daisy-chain configuration.
Each HyperTransport link has an 8-bit DDR transmit and an 8-bit DDR receive port running at clock speeds
up to 400 MHz, allowing for raw bandwidth of 800 MB/s simultaneously in each direction. With protocol over-
head, the maximum sustainable bandwidth in one direction is approximately 705 MB/s.
•For testing, or connection to slower devices, the HyperTransport PCI bridge may be programmed to
operate at slower link clock rates.
•The HyperTransport PCI bridge supports both the synchronous and asynchronous modes of link
initialization.
1.3 PCI Interface
The HyperTransport PCI bridge secondary interface is a 64-bit, 66 MHz capable PCI bus. The HyperTrans-
port PCI bridge supports running the bus in 32-bit mode at either 33 MHz or 66 MHz. A lower performance
mode is also supported in which the PCI bus runs at 25 or 50 MHz. The bus can be configured for compati-
bility with 3.3 V or 5.0 V operation, although 50 and 66 MHz are only supported at 3.3 V.
The HyperTransport PCI bridge supports the full 40-bit memory-mapped space and 25-bit I/O space
described in the Lightning Data Transport I/O Link Protocol Specification, Revision 1.0. In Pass1, PCI
addresses outside these spaces alias into them. In Pass2, PCI addresses outside these spaces are left on the
PCI bus. PCI dual address cycle (DAC) support is provided both inbound and outbound to support the
memory-mapped space.
•The HyperTransport PCI bridge supports configuration accesses to devices 0–15, using Address/Data
(AD) bits 16–31 for IDSEL#.
•The HyperTransport PCI bridge implements all parity and error-checking features described in the PCI
Local Bus Specification, Revision 2.2.

*Notice: The information in this document is subject to change without notice
Tsi301
Notes
Tsi301 HyperTransport to PCI User Manual 1-10
1.3.1 PCI Master
As a PCI master, the HyperTransport PCI bridge chip can generate MemRd/Wr, IORd/Wr, and ConfigRd/
Wr cycles.
•The HyperTransport PCI bridge does not implement a cacheline size register and does not prefetch to
PCI, so it never generates MemRdLine, MemRdMult, or MemWrInv cycles.
•The HyperTransport PCI bridge does not support a Southbridge connection to its PCI bus, so it never
generates INTA cycles.
•The HyperTransport PCI bridge does not generate Special cycles.
PCI master cycles that are retried or disconnected on the PCI bus are reissued locally by the HyperTrans-
port PCI bridge until they complete. The HyperTransport PCI bridge can track up to four outstanding requests
in the Outbound Request Controller, of which a maximum of three may be nonposted requests. The Hyper-
Transport PCI bridge rotates among these requests to maximize bandwidth in the presence of retries or
disconnects.
1.3.2 PCI Slave
As a PCI slave, the HyperTransport PCI bridge can respond to all types of memory and I/O cycles.
However, the HyperTransport PCI bridge never responds to PCI configuration cycles.
•The HyperTransport PCI bridge employs medium DEVSEL# timing.
•All PCI slave writes, including I/O writes, are posted.
•A total of 48 doublewords (DW) of write data buffering are provided on the chip.
•All PCI slave reads are implemented as delayed requests, with up to four delayed requests
outstanding at once.
Prefetching is supported for all flavors of memory read cycle, with separate prefetch controls for each cycle
type and a maximum prefetch per read of 128 DW. Prefetching may be done once at the beginning of each
read, or it may be enabled to continuously issue requests as data is drained to PCI. All prefetch data is
discarded when the read disconnects on the PCI bus. The bridge chip provides buffer space for a total of
256 DW of read prefetch data.
1.3.3 PCI Arbiter
The HyperTransport PCI bridge implements an on-chip two-level PCI Arbiter with request/grant pairs: 7
pairs in Pass1, 6 pairs in Pass2. The request/grant pairs in Pass1 include two high-priority sets for the on-chip
PCI master, one high priority set for an external requester, and five symmetrical sets for external device use.
In Pass2, there is one high-priority set for the on-chip PCI master.
All connections to the arbiter are through external pins, so its use is optional. The HyperTransport PCI
bridge chip may also be configured to use an external PCI arbiter.
1.4 Interrupt Controller
The HyperTransport PCI bridge implements a HyperTransport interrupt controller. In Pass1, there are
20 external interrupt sources. In Pass2, there are 16 external interrupt sources.
The interrupts pins may be programmed in groups of four to be level or edge-triggered and active high or
low. In Pass1, one group can also be used to generate the special PC compatibility interrupts: SMI, NMI, INIT,
and INTR. In Pass2, SMI, NMI, INIT, and INTR are not available.
1.5 Configuration
Most HyperTransport PCI bridge configuration is done under host software control through accesses
across HyperTransport to the bridge chip’s control/status register (CSR) set. However, some hardware initial-
ization is required to bring up the HyperTransport links before software configuration can occur. To support
hardware initialization, the HyperTransport PCI bridge provides a Serial Initialization Packet (SIP) interface to
read an external SROM during a cold reset sequence.

*Notice: The information in this document is subject to change without notice
Tsi301
Notes
Tsi301 HyperTransport to PCI User Manual 1-10
To reduce external part count, a small number of configurations are pre-programmed into the HyperTrans-
port PCI bridge. These pre-programmed configurations may be selected using PCI bus pins during cold reset
in the absence of an SROM.
1.6 Interface Levels
A complete pinout of the HyperTransport PCI bridge is given in the Signals Chapter. The rough grouping of
signal types is shown in Table 1.
1.7 Clocking
In normal operation, the HyperTransport PCI bridge’s reference clock (REFCLK_H/L) comes from a PCI
bus clock. This clock is received from the same source that drives clocks to devices on the bridge’s PCI bus
and is nominally in phase with it; although it may be delayed relative to the other PCI bus clocks. Reference
clock frequency is indicated by the P_M66EN pin. From this input, an internal phase locked loop (PLL) gener-
ates the HyperTransport PCI bridge internal core clock and the HyperTransport transmit clocks.
Note: In Pass1, the reference clock frequency and P_M66EN can be set at either 33 or 66 MHz at
L_PWROK and must remain static. In Pass2, clocks and P_M66EN can be used in the same way;
or the PCI bus frequency can be changed without resetting the HyperTransport PCI bridge. To
support changing the PCI bus frequency without resetting the HyperTransport PCI bridge,
REFCLK_H/L must always run at 33 MHz and P_M66EN must indicate 33 MHz at the rising edge of
L_PWROK. The clock frequency to the PCI devices and P_M66EN can then be switched between
33 and 66 MHz whenever AP_RST is asserted. The clocks must still be nominally in phase and
rising edges of the reference clock must be aligned with rising edges of the PCI bus clock.
If the HyperTransport PCI bridge is to perform synchronous link initialization with the HyperTransport
devices on either side of it, the reference clock must be derived from the same base frequency source. If not,
asynchronous link initialization must be used. No phase relationship is required in either mode.
For debug and test purposes, the HyperTransport PCI bridge allows bypassing of the PLL. It provides
separate bypass clock inputs for the core and HyperTransport transmit clocks. The bypass clocks run directly
at the frequency provided. Both bypass clocks must be derived from the same base frequency source.
Interface Group Voltages
PCI PCI 3.3V, 5.0V tolerant
HyperTransport HyperTransport Differential, 600 mV swing, centered on 600 mV
Interrupts INT In Pass1, 2.5 V
In Pass2, 3.3 V
Table 1 HyperTransport PCI Bridge Interface Voltages

*Notice: The information in this document is subject to change without notice
Tsi301
Notes
Tsi301 HyperTransport to PCI User Manual 1-10

*Notice: The information in this document is subject to change without notice
2-6
Notes
Chapter 2 Signal Descriptions
2.1 HyperTransport Signals
Note: The Lx_ prefix denotes signals associated with either HyperTransport Link 0 (x=0) or Hyper-
Transport Link 1 (x=1).
The PCI bridge HyperTransport implementation is a standard HyperTransport design. Table 2.1 lists all
HyperTransport signals. For details on the characteristics of these signals, refer to the Lightning Data Trans-
port I/O Link Protocol Specification, Revision 1.0 and the Lightning Data Transport Electrical Specification,
Revision 0.77, both from AMD.
2.2 PCI Signals
The HyperTransport PCI bridge implements a standard PCI interface, as detailed in PCI Local Bus Specifi-
cation, Revision 2.2. Table 2.2 lists all HyperTransport PCI bridge PCI signals.
Signal Name I/O Type Signal Type
Lx_RX_CLK_H/L Input HyperTransport
Lx_RX_CTL_H/L Input HyperTransport
Lx_RX_CAD[7:0]_H/L Input HyperTransport
Lx_TX_CLK_H/L Output HyperTransport
Lx_TX_CTL_H/L Output HyperTransport
Lx_TX_CAD[7:0]_H/L Output HyperTransport
Lx_VLDT[2:0] Power 1.2 volt
L_TSTRST_N Input 2.5 volt LVCMOS
L_POWER_OK Input 2.5 volt LVCMOS
L_RST_N Input 2.5 volt LVCMOS
Table 2.1 HyperTransport Bridge Signals
Signal
Name I/O Type Signal Type
P_CBE_N[7:0] Bidirectional PCI
P_AD[63:0] Bidirectional PCI
P_PAR Bidirectional PCI
P_SERR_N Input PCI
P_PERR_N Bidirectional PCI
P_LOCK_N Bidirectional PCI
P_STOP_N Bidirectional PCI
P_DEVSEL_N Bidirectional PCI
P_TRDY_N Bidirectional PCI
Table 2.2 HyperTransport Bridge PCI Signals

*Notice: The information in this document is subject to change without notice
Tsi301
Notes
Tsi301 HyperTransport to PCI User Manual 2-6
Table 2.3 lists the PCI Arbitration signals, which are not defined by the PCI specification.
Note: Any unused P_REQ[5:0]_N or P_PREQ_N requests should be pulled to 3.3 volts (inactive).
2.2.1 PCI Signal Levels
The HyperTransport bridge supports PCI 3.3 V levels and PCI 5.0 V levels as determined by
AP_TYPEDET_N and VDD3050_PCI[7:0]. AP_TYPEDET_N is related to PCI functionality but not part of the
PCI specification.
If AP_TYPEDET_N is pulled low and VDD3050_PCI[7:0] is at 3.3 V, PCI signals conform to the PCI 3.3 V
signalling rules.
If AP_TYPEDET_N is pulled high and VDD3050 PCI[7:0] is at 5.0 V, PCI signals conform to the PCI 5.0 V
signalling rules.
No other combinations of AP_TYPEDET_N and VDD3050 PCI[7:0] are supported.
P_IRDY_N Bidirectional PCI
P_FRAME_N Bidirectional PCI
P_REQ64_N Bidirectional PCI
P_ACK64_N Bidirectional PCI
P_PAR64 Bidirectional PCI
AP_RST_N Pass1 Output
Pass2 Input/Output
Open Drain
P_M66EN Input PCI
P_WSC_N Reserved PCI
Signal Name I/O Type Signal Type
P_REQ_OUT_N Output PCI
P_GNT_IN_N Input PCI
P_REQ[5:0]_N Input PCI
P_GNT[5:0]_N Output PCI
P_PREQ_N Input PCI
P_PGNT_N Output PCI
Table 2.3 PCI Arbitration Signals
Signal
Name I/O Type Signal Type
Table 2.2 HyperTransport Bridge PCI Signals<Emphasis> (Continued)

*Notice: The information in this document is subject to change without notice
Tsi301
Notes
Tsi301 HyperTransport to PCI User Manual 2-6
2.3 Interrupt and Error Signals
Note: In Pass2, SMI, NMI, INIT, and INTR are not available. Customers should use the
BLKx_INT[y] signals instead.
BLKx_IRQ[y]
Functionally input only. In Pass1, 2.5 volt LVCMOS. In Pass2, 3.3 volt LVCMOS.
Generic interrupt input signals. The HyperTransport PCI bridge has four blocks of generic interrupts, with
four interrupts per block. The lower 2 bits of the vector are contained in each interrupt. The upper 6 bits are in
the interrupt block description register.
The y denotes four separate signals associated with each of the four interrupt blocks x, for a total of 16
signals.
Note: In Pass1 if this pin is not needed for an interrupt, it can be floated or pulled to 2.5 volts.
In Pass2 if this pin is not needed for an interrupt, it can be floated or pulled to 3.3 or 2.5 volts. 3.3 volts is
preferable.
NMI
Bidirectional. In Pass1, 2.5 volt LVCMOS. In Pass2, this signal is absent.
Non-Maskable Interrupt Signal. This signal is not available in Pass2. Customers should use the
BLKx_INT[y] signals instead.
Note: In Pass1 if this pin is not needed for an interrupt, it can be floated or pulled to 2.5 volts.
SMI_N
Bidirectional. In Pass1, 2.5 volt LVCMOS. In Pass2, this signal is absent.
System Management Interrupt Signal. This signal is not available in Pass2. Customers should use the
BLKx_INT[y] signals instead.
Note: In Pass1 if this pin is not needed for an interrupt, it can be floated or pulled to 2.5 volts.
INTR
Input. In Pass1, 2.5 volt LVCMOS. In Pass2, this signal is absent.
Interrupt Input Signal. This signal is not available in Pass2. Customers should use the BLKx_INT[y] signals
instead.
INIT
Bidirectional. In Pass1, 2.5 volt LVCMOS. In Pass2, this signal is absent.
x86 INIT signal. This signal is not available in Pass2. Customers should use the BLKx_INT[y] signals
instead.
Note: In Pass1 if this pin is not needed for an interrupt, it can be floated or pulled to 2.5 volts.
FATA L_E RR_ N
Open Drain Output. In Pass1, 2.5 volt open drain LVCMOS. In Pass2, 3.3 volt open drain LVCMOS.
The HyperTransport PCI bridge has detected a fatal error.
NONFATAL_ERR_N
Open Drain Output. In Pass1, 2.5 volt open drain LVCMOS. In Pass2, 3.3 volt open drain LVCMOS.
The HyperTransport PCI bridge has detected a non-fatal error.

*Notice: The information in this document is subject to change without notice
Tsi301
Notes
Tsi301 HyperTransport to PCI User Manual 2-6
2.4 SIP Signals
SROM_SCK
Bidirectional. In Pass1, 2.5 volt open drain LVCMOS. In Pass2, 3.3 volt open drain LVCMOS.
P_AD[1] drives the CLK pin of the SIP ROM. During reset, if this pin is pulled high with a 10 K resistor, the
SROM supplies the entire SIP packet. If low, the SIP packet is generated internally.
SROM_SDA
Bidirectional. In Pass1, 2.5 volt LVCMOS. In Pass2, 3.3 volt LVCMOS.
This pin is the data pin of the SIP ROM.
2.5 Test Signals
For systems using Pass1 of the HyperTransport PCI bridge, the TDI and TDO pins are not guaranteed to
be quiescent during scan operations. Customers should ensure their JTAG implementation on the PCB is
tolerant of this.
TCK
Input. In Pass1, 2.5 volt LVCMOS. In Pass2, 3.3 volt LVCMOS.
In Pass1, this is a reserved input and can be left floating or pulled to GND.
In Pass2, this is the JTAG clock input.
TDI
Pass1 output. Pass2 input. In Pass1, 2.5 volt open drain LVCMOS. In Pass2, 3.3 volt open drain
LVCMOS.
In Pass1, this is a reserved output and not guaranteed to be quiet.
In Pass2, this is the JTAG data input.
TDO
Output. In Pass1, 2.5 volt LVCMOS. In Pass2, 3.3 volt LVCMOS.
In Pass1, this is a reserved output and not guaranteed to be quiet.
In Pass2, this is the JTAG data output.
TMS
Input. In Pass1, 2.5 volt LVCMOS. In Pass2, 3.3 volt LVCMOS.
In Pass1, this is a reserved input and can be left floating or pulled to GND.
In Pass2, this is the JTAG mode select.
TRST_N
Input. In Pass1, 2.5 volt LVCMOS. In Pass2, 3.3 volt LVCMOS.
In Pass1, this is a reserved input.
In Pass2, this is the JTAG reset input.
Note: This signal should be pulled low for normal functional mode.
TMODE [3:0]
Input. Test pins. In Pass1, 2.5 volt LVCMOS. In Pass2, 3.3 volt LVCMOS.

*Notice: The information in this document is subject to change without notice
Tsi301
Notes
Tsi301 HyperTransport to PCI User Manual 2-6
TRISTATE_N
Input. In Pass1, 2.5 volt LVCMOS. In Pass2, 3.3 volt LVCMOS.
Tristate enable, see the Signals Chapter.
VBB
This pin is tied to the substrate for testing purposes. It should not be connected on the PCB. This signal is
not available in Pass2.
2.6 PLL/Clock Signals
REFCLK_H/L
Input. GTL+.
This 33/66 MHz input is the reference for the HyperTransport PCI bridge PLL. To improve 66 MHz timing, it
may be delayed relative to other PCI clocks on the PCI bus. This is a differential signal. The _L input can be
attached to the active-low half of a differential pair, or it can be tied to a reference voltage.
REFCLK_PLL_BYPASS
Input. 2.5 volt LVCMOS.
When this signal is asserted, the PLL is bypassed. REFCLK_H/L input pins are used directly to drive
internal clocks.
REFCLK_PLL_VCC
This is the 2.5 V power input for the PLL.
REFCLK_PLL_GND
This is the ground input for the PLL.
2.7 Core and I/O Power Signals
VDD
Core power. 2.5 V.
VSS
Ground.
VDDQ_AP[18:0]
PCI VDD supply voltage. Always 3.3 V, regardless of whether the HyperTransport bridge is using 3.3 V PCI
levels or 5.0 V PCI levels.
VDD3O5O_PCI[7:0]
If AP_TYPEDET_N is pulled low, these should be at 3.3 V. PCI signalling will conform to the 3.3 V rules.
If AP_TYPEDET _N is pulled high, these should be at 5.0 V. PCI signalling will conform to the 5.0 V rules.
VDD3P_AGP[3:1]
In Pass1, 3.3 V.
In Pass2, these signals are absent.
Lx_VLDT[y]
HyperTransport I/O power. 1.2 V.

*Notice: The information in this document is subject to change without notice
Tsi301
Notes
Tsi301 HyperTransport to PCI User Manual 2-6
2.8 Calibrator Logic Signals
Lx_RREF_GND/Lx_RREF
Bidirectional
These signals are used by the HyperTransport calibrator logic. A resistor should be placed between these
two pins. The resistor value should be equal to half of the differential impedance of the HyperTransport
signals, which is 100 ohms +/- 10%.
Note: The LDT_RREF_GND should not be connected to ground.

*Notice: The information in this document is subject to change without notice
3-20
Notes
Chapter 3 Functional Operation
This chapter details the operation of the HyperTransport PCI Bridge chip.
Figure 3.1 HyperTransport PCI Bridge Block Diagram
3.1 HyperTransport Interface
The HyperTransport PCI bridge HyperTransport interface consists of two identical link interfaces, each with
a HyperTransport transmitter and receiver. Some central reset and error-handling logic is shared between the
two links.
In the HyperTransport protocol, all logical packet transfer is between HyperTransport slaves and the host.
Direct peer-to-peer communication is not allowed. To support peer-to-peer operations, packets are reflected
through the host. Packets issued from the host to a HyperTransport slave are defined to travel downstream on
the HyperTransport chain. Packets issued from a HyperTransport slave to the host are defined to travel
upstream. Intermediate nodes in the daisy chain forward packets from link to link until they reach their final
destination, which accepts the packet.
Link interfaces in the HyperTransport PCI bridge are symmetrical, which allows connection of either bridge
link toward a host. The HyperTransport PCI bridge also supports being placed in a double-hosted chain with
hosts at both ends.
Figure 3.2 shows a block diagram of a single HyperTransport link interface.

*Notice: The information in this document is subject to change without notice
Tsi301
Notes
Tsi301 HyperTransport to PCI User Manual 3-20
Figure 3.2 Single HyperTransport Link Interface Block Diagram
3.2 HyperTransport Packet Reception
Packets received from HyperTransport are placed into the HyperTransport Receive (Rx) buffers. The
HyperTransport flow control algorithm guarantees that no packet is received without buffer space to store it.
Packet contents are divided into command information (including address) and data, with separate buffers for
each.
•Command buffers are statically partitioned among the three virtual channels (posted requests, non-
posted requests, and responses), with each channel allocated space to hold four commands.
•Data buffers are shared among the three virtual channels and dynamically allocated among them.
A total of eight data buffers are provided. Allocation of buffers to virtual channels is controlled by the Data
Buffer Allocation CSR (6Dh:6Ch). As data buffers are allocated, buffers are released from the pool to each
channel. As the buffers are retired, they return to the pool.
3.2.1 Data Buffer Allocation
Each virtual channel always needs at least one data buffer allocated to it to prevent deadlock. A data buffer
is considered allocated to a virtual channel if it has been released to that channel and is awaiting data, or if it
has received data but has not yet been retired. Two types of user specified data buffer allocation are allowed:
•Guaranteed buffers specified in the NeedPReq, NeedNpReq, and NeedResp CSR fields.
•Assigned but not guaranteed buffers specified in the WantPReq, WantNpReq, and WantResp CSR
fields.
Guaranteed data buffer allocations to each channel are user configurable using NeedPReq, NeedNpReq,
and NeedResp CSR fields to set minimum buffer allocations for each virtual channel. If retiring a data buffer to
the pool would cause a virtual channel to fall below its allocation, that buffer is immediately re-allocated to the
LDT
Receive
LDT
Trans-
End of
Chain
Com-
mand +
Trans-
mit Buf-
Receive
Buffer
Receive
Data
CRC
Rx Sync
Packet
Tx Sync
CRC Test
Receive
Com-
Posted
Non-
Re-
Packet
Pack-
CSR
32 bits @
LDT In
8 bits @
linkClk
LDT Out
8 bits @
linkClk
32 bits @ 32 bits @
32 bits
NOPs
Sync
Buffer
Forward Pack-
Tx Posted Req.
Tx Posted Req.
Tx Nonpost. Req.
Tx Nonpost. Req.
Tx Response Head-
Tx Response Data
Commit Hand-
Rx Data
Rx Re-
Rx Nonpost
Rx Posted Req.
Core Clock
Receive Clock
Transmit Clock
For-
ward

*Notice: The information in this document is subject to change without notice
Tsi301
Notes
Tsi301 HyperTransport to PCI User Manual 3-20
same channel. Re-allocation guarantees that the minimum allocation set in the Need CSR fields will always be
met as long as the sum of the CSR values is less than or equal to the total number of data buffers in the link
interface.
The buffer allocation strategy is to always keep some number of granted but unfilled buffers allocated to
each virtual channel so that data is always able to move. Once the minimum configured allocations are met,
remaining unallocated buffers are brought out of the pool and granted based on traffic demands. These are
the assigned buffers specified in WantPReq, WantNpReq, and WantResp.
The WantPReq, WantNpReq, and WantResp CSR fields specify the number of free buffers attempted (not
guaranteed) for each channel. Whenever the number of free buffers in a particular channel drops below its
Want value, a new buffer is allocated to that channel from the pool based on buffer availability. Depending on
the number of full data buffers, it may not be possible to always satisfy Want buffer assignments.
The WantPReq, WantNpReq, and WantResp CSR fields allow the user to assign free buffers to the traffic
most important to latency and performance. The goal is to set the Want values high enough for channels that
require maximum bandwidth so that there are enough buffers available to hide the latency of a buffer release
issued back to the transmitter when the first beat of a data packet is received. The pitfall is setting a channel’s
Want values so high that it prevents buffers from being available to the other channels, inadvertently throttling
performance.
Figure 3.3 Data Buffer Life Cycle
3.2.2 Packet Decode
As packets are placed in the Rx buffers, the associated commands and addresses are decoded to deter-
mine whether the HyperTransport PCI bridge is the packet target on the HyperTransport chain. These packets
are also checked for ordering collisions against other packets resident in the buffers. The decode and collision
results are stored in the buffers with the packets.
•Packets received on the HyperTransport interface may be routed to internal logic, including the PCI
interface. This is “accepting” a packet.
•Packets may also be routed to the other HyperTransport link interface for transmission to the next
device in the chain. This is “forwarding” a packet.
•A particular packet may be accepted, forwarded, or both.
The HyperTransport PCI bridge HyperTransport packet decode first determines whether the incoming
packet is travelling upstream or downstream. This determination is based on the packet source information
contained in the packet itself, not on which link is the upstream or downstream link.
•Upstream packets are always forwarded toward the host and are never accepted by the
HyperTransport PCI chip.
•Downstream RdSized and WrSized request packet addresses are decoded according to the
HyperTransport Address Map described in Section 3.3 and are accepted if they match any
HyperTransport PCI bridge address ranges.
•Downstream WrSized and RdSized that do not match any of the HyperTransport PCI bridge address
ranges are forwarded to the next device in the chain.
•Broadcast request addresses are also decoded and accepted if they match a HyperTransport PCI

*Notice: The information in this document is subject to change without notice
Tsi301
Notes
Tsi301 HyperTransport to PCI User Manual 3-20
bridge address range. However, these packets are also always forwarded.
•Fence and Flush requests are never accepted by the HyperTransport PCI bridge and are always
forwarded.
•Downstream response packets are accepted if their unitId field matches the value in the BaseUnitId
field of the HyperTransport PCI bridge LdtCmd register; otherwise, they are forwarded.
3.2.3 Collision Checking
Collision checking is performed according to the HyperTransport protocol to determine if incoming packets
are required to stay ordered behind packets already in the Rx buffers. Only packets headed to the same
accept or forward destination may have ordering requirements. If a packet has an ordering collision, it may not
be issued from the Rx buffers until the packet with which it collided has both been issued and reached an
appropriate commit point to guarantee ordering. This ordering point varies by destination.
Because the Outbound Request Controller (ORC) can reorder requests, requests accepted by the Hyper-
Transport PCI bridge may not be committed until they are retired by the ORC. For accesses to PCI, this
means that the request reached the PCI bus and all data was transferred. Packets forwarded from one link to
the other are streamed - meaning that transmission may start before the whole packet is received. It is the
transmitter’s responsibility to ensure that required packet ordering is maintained so packets can be committed
as soon as they are passed to the other link controller.
Packets that do not have any ordering requirements may leave the Rx buffers in a different order than they
reached them, both between and within virtual channels. In general, the Rx buffers select a packet choosing
the oldest non-blocked packet in each channel to a given destination.
3.3 HyperTransport Address Map
HyperTransport implements a single flat 40-bit address space for all accesses. All address spaces that can
be reached from HyperTransport are mapped into this space. The HyperTransport PCI bridge checks
addresses on incoming packets in each space for subranges that it accepts.
3.3.1 Memory Mapped Space
The HyperTransport specification places Memory Mapped Space in the address range of 00_0000_0000h
to FC_FFFF_FFFFh. The HyperTransport PCI bridge accepts two ranges within this space, as enabled by
MemSpaceEn in the Command (Cmd) CSR, consisting of the following:
•Memory Space, defined by the MemBase and MemLimit CSRs.
•Prefetchable Memory Space, defined by the PrefMemBaseUpper/ PrefMemBase and
PrefMemLimitUpper/PrefMemLimit CSRs.
Setting the VgaEn bit in the BrCtrl CSR creates the additional window of 00_000A_0000h –
00_000B_FFFFh, which is also accepted. The HyperTransport PCI bridge never does prefetching to PCI, so
the prefetchable/nonprefetchable attribute of these ranges does not matter. RdSized requests to these ranges
result in MemRd requests on the PCI bus. WrSized requests to these ranges result in MemWr requests on the
PCI bus. If above 4 GB, addresses are passed straight through as a DAC.
3.3.2 I/O Space
The HyperTransport specification places PCI I/O space in the address range of FD_FC00_0000h to
FD_FDFF_FFFFh. The HyperTransport PCI bridge strips the top 15 bits off of addresses in this range.
•If enabled by I/OSpaceEn in the Cmd CSR, the HyperTransport PCI bridge accepts requests that fall
in the range defined by the I/O Base and I/O Range Base Upper, and I/O Limit and I/O Range Limit
Upper CSRs.
•If set, the IsaEn bit in the Bridge Control CSR creates a series of holes (the top 768 bytes of each 1 KB
block in the low 64 KB) in this space that the HyperTransport PCI bridge does not accept.
•Setting the VgaEn bit in the Bridge Control CSR creates an additional set of windows (all addresses in
the low 64 KB where the bottom 10 bits are in the ranges 3B0h – 3BBh or 3C0h – 3DFh) which the
HyperTransport PCI bridge accepts. Accepted RdSized requests result in IoRd requests on the PCI