OXCB950 Datasheet, PDF (12/68 Pages) List of Unclassifed Manufacturers – Integrated High Performance UART Cardbus / PCI interface

OXFORD SEMICONDUCTOR LTD.
6 PCI TARGET CONTROLLER
6.1 Operation
The OXCB950 responds to the following cardbus/PCI
transactions:-
• Configuration access: For cardbus applications, the
OXCB950 responds to type 0 configuration reads and
writes if the bus address is selecting the configuration
registers for function 0. For pci applications, the
OXCB950 will respond to the same configuration
cycles provided that the signal IDSEL is also asserted
The device will respond to these configuration
transactions by asserting DEVSEL#. Data transfer
then follows. Any other configuration transaction will
be ignored by the OXCB950.
• IO reads/writes: The address is compared with the
addresses reserved in the I/O Base Address Registers
(BARs). If the address falls within one of the assigned
ranges, the device will respond to the IO transaction
by asserting DEVSEL#. Data transfer follows this
address phase. For all modes, only byte accesses are
possible to the function BARs (excluding the local
configuration registers for which WORD, DWORD
access is supported). For IO accesses to these
regions, the controller compares AD[1:0] with the byte-
enable signals as defined in the PCI specification. The
access is always completed; however if the correct BE
signal is not present the transaction will have no
effect.
• Memory reads/writes: These are treated in the same
way as I/O transactions, except that the memory
ranges are used. With the exception of Memory
accesses to the local configuration registers and the
cardbus status registers, Memory access to single-
byte regions such as the UART registers is always
expanded to DWORDs in the OXCB950. In other
words, the OXCB950 reserves a DWORD per byte in
single-byte regions. The device allows the user to
define the active byte lane using LCC[4:3] so that in
Big-Endian systems the hardware can swap the byte
lane automatically. For Memory mapped access in
single-byte regions, the OXCB950 compares the
asserted byte-enable with the selected byte-lane in
LCC[4:3] and completes the operation if a match
occurs, otherwise the access will complete normally
on the PCI bus, but it will have no effect on the UART.
• All other cycles (64-bit, special cycles, reserved
encoding etc.) are ignored.
Data Sheet Revision 1.1
OXCB950
The OXCB950 will complete all transactions as disconnect-
with-data, i.e. the device will assert the STOP# signal
alongside TRDY#, to ensure that the Bus Master does not
continue with a burst access. The exception to this is Retry,
which will be signalled in response to any access while the
OXCB950 is reading from the serial EEPROM.
The OXCB950 performs medium-speed address decoding
as defined by the PCI specification. It asserts the
DEVSEL# bus signal two clocks after FRAME# is first
sampled low on all bus transaction frames which address
the chip. Fast back-to-back transactions are supported by
the OXCB950 as a target, so a bus master can perform
faster sequences of write transactions to the UART
registers, the PCI configuration space and the local
configuration registers when an inter-frame turn-around
cycle is not required.
The device supports any combination of byte-enables for
accesses to the PCI Configuration Registers, the Local
Configuration registers, the Cardbus Information Structure,
and the cardbus status registers. If a byte-enable is not
asserted, that byte is unaffected by a write operation and
undefined data is returned upon a read.
The OXCB950 performs parity generation and checking on
all cardbus/PCI bus transactions as defined by the 2
standards. If a parity error occurs during the bus address
phase, the device will report the error in the standard way
by asserting the SERR# bus signal. However if that
address/command combination is decoded as a valid
access, it will still complete the transaction as though the
parity check was correct.
The OXCB950 does not support any kind of caching or
data buffering, other than those in the UART function. In
general, all registers cannot be pre-fetched because there
may be side-effects on reads.
Page 12