User Manual
BCM1250/BCM1125/BCM1125H
10/21/02
B r o a d c o m C o r p o r a t i o n
Document
1250_1125-UM100CB-R
Section 8: PCI Bus and HyperTransport Fabric Page
235
Accesses to the configuration range with bus 0 device 0 and bus 0 device 1 will be directed to the internal
configuration registers for the PCI and HyperTransport interfaces. Once the CPU has performed a series of
writes to the internal configuration registers it should read back at least one. This will ensure the writes have
taken effect before any other operations will proceed. Although the transfers will be in order on the ZBbus the
data phase will be behind the address. If there is no read separating a configuration write from a subsequent
transaction it is possible for the address of the transaction to reach the interface before the data of the
configuration write, in this case the address decode for the transaction would be done based on the old value
of the configuration register.
Other accesses to bus 0 devices will be sent as Type 0 configuration cycles on the PCI bus, the mapping used
for generating IDSEL is to convert the device number into a single one on AD[31:11]. Since the internal PCI
and HyperTransport headers are device 0 and 1 the external devices start with AD[13] being set for device 2,
AD[14] being set for device 3 and so on up to AD[31] being set for device 20 (note that the internal PCI arbiter
only supports four external devices). During PCI configuration cycles the interface will pre-drive the address
on the bus for a cycle (as described in section 3.2.2.3.5 of the PCI Specification revision 2.2), this allows a
resistor to be used to connect to the IDSEL inputs of PCI devices. A PCI configuration read to a nonexistent
device will be terminated with a master abort and set the status flags to indicate this happened, the data
returned will be marked valid and will contain 32’hFFFF_FFFF (for normal accesses, a master abort will result
in a bus error return). When a PCI configuration read is aborted in this way all other reads that are in flight in
the PCI bridge will be terminated with a bus error. Software should therefore ensure that there are no reads in
progress through the PCI bridge when it is probing the PCI bus for devices. Note that configuration reads that
encounter other PCI errors (e.g. a parity error) will also return 32'hFFFF_FFFF.
If the bus number of an access to the configuration range matches the secondary bus number configured in
the HyperTransport Bridge, the request will be forwarded as Type 0 configuration accesses on the
HyperTransport fabric. This is done by turning it in to an access to the address range given in the
HyperTransport specification for configuration. Accesses that have a bus number greater than the
HyperTransport bridge secondary bus and less than or equal to the HyperTransport subordinate bus number
are sent as Type 1 configuration accesses on the HyperTransport fabric. Errors generated from configuration
accesses to HT will be forwarded to the ZBus rahter than the PCI bridge. All other accesses are sent as Type
1 configuration accesses on the PCI bus. This is shown algorithmically in the pseudo-code below.
endian = zbaddr[29] ? match bit lanes : match byte lanes
bus = zbaddr[23:16]
device = zbaddr[15:11]
func = zbaddr[10:8]
reg = zbaddr[7:0]
if (bus == 0)
{
if (dev == 0)
access PCI config reg
else if (dev == 1)
access HyperTransport config reg
else
do PCI Type 0 cycle (dev, func, reg)
}
else if (bus == HT secondary bus)
{
// Form special HT Type 0 config address
htaddr = FD_FE0 zbaddr[15:0]
do HT access
}
else if (HT secondary bus < bus <= HT subordinate bus)
{
// Form special HT Type 1 config address
htaddr = FD_FF0 zbaddr[23:0]
do HT access
}
else
do PCI Type 1 cycle (bus, dev, func, reg)