CN8478/CN8474A/CN8472A/CN8471A
3.0 Expansion Bus (EBUS)
Multichannel Synchronous Communications Controller (MUSYCC™)
3.1 Operation
3.1.7 Bus Access Interval
MUSYCC can be configured to wait a specified amount of time after it releases
the EBUS and before it requests the EBUS a subsequent time. This is
accomplished by specifying a value 0–7 in BLAPSE bit field (refer to
Table 5-6, Global Configuration Descriptor). The value specifies the additional
ECLK periods MUSYCC waits immediately after releasing the bus; that is, a
value of 0 specifies MUSYCC will wait for one ECLK period, and a value of 5
specifies six ECLK periods. Disabling the ECLK signal output does not affect
this wait mechanism. Refer to the timing diagrams in Section 7.2.4 for more
details.
The bus grant signal (HLDA/BG*) is deasserted by the bus arbiter only after
the bus request signal (HOLD/BR*) is deasserted by MUSYCC. As the amount
of time between bus request deassertion and bus grant deassertion can vary from
system to system, it is possible for a misinterpretation of the “old” bus grant
signal as an approval to access the EBUS. MUSYCC provides the flexibility
through the bus access interval feature to wait a specific number of ECLK periods
between subsequent bus requests. (Refer to EBUS arbitration timing diagrams,
Figure 7-13, EBUS Write/Read Transactions, Intel-Style and Figure 7-14, EBUS
Write/Read Transactions, Motorola-Style.)
3.1.8 PCI to EBUS Interaction
Using the EBUS to perform extensive polling of peripheral devices substantially
increases PCI bus utilization. The EBUS interface within MUSYCC performs
single dword access without burst cycles. Also, the access time for data on the
EBUS is dependent on how fast the peripherals respond to an EBUS read or write
cycle.
PCI write access cycles targeted at the EBUS are not at issue because they
complete immediately. MUSYCC’s host interface autonomously completes
writing data to the EBUS after successfully terminating the host’s PCI write
access cycle.
PCI read access cycles targeted at the EBUS are at issue because they cause
MUSYCC’s host interface to first claim the access cycle, then immediately
initiate a PCI Target Retry sequence. This causes the PCI bridge device to retry
the same EBUS access at a later time. Concurrently, the EBUS interface is
activated to access the requested data from the EBUS. Because this process may
take many EBUS clock cycles to complete, the host interface is capable of
holding off each retry request by initiating a subsequent Target Retry sequence
until the EBUS interface delivers the required data to the host interface. Target
Retry sequences may occur multiple times.
As EBUS data is made available to the host interface, and on the next retry
from the bridge chip, the host interface checks whether or not the retry cycle
address matches the address latched in during the initial EBUS access cycle and,
if so, forwards the EBUS data to the requester. If the addresses do not match,
MUSYCC starts a new EBUS access cycle.
The amount of time to complete a single EBUS cycle accessing a single dword
at a time and the number of bus turnovers between successive retries affect PCI
bus utilization. To avoid affecting the PCI bus adversely, systems must be
designed to throttle EBUS access or use a local microprocessor on the EBUS to
filter the information from peripheral devices.
100660E
Conexant
3-5
CONEXANT [ CONEXANT SYSTEMS, INC ]
