CS4210 Datasheet, PDF (23/102 Pages) National Semiconductor (TI) – IEEE 1394 OHCI Controller

Operational Description (Continued)
3.4 LIST MANAGEMENT
All contexts use an identical method for controlling the pro-
cessing of descriptors associated with the context. This
presents a uniform interface to controlling software and
allows reuse of hardware on the CS4210.
3.4.1 Context Initialization
Software initializes the context by first checking to see that
ContextControl.run, ContextControl.active, and Context-
Control.dead are all 0. Then, CommandPtr.descriptorAd-
dress is written to point to a valid descriptor block and
CommandPtr.Z is set to a value that is consistent with the
descriptor block. Then ContextControl.run can be set.
3.4.2 Appending to Running List
Software may append to a list of descriptors at any time.
Software may append either a single descriptor or a linked
list of descriptors. When the to-be-appended list is properly
formatted, software updates the branch address and Z
value of the descriptor that was at the end of the list being
processed by the CS4210. When software completes the
linking process it must set ContextControl.wake for the con-
text. This ensures that the CS4210 resumes operation if it
had previously reached the end of the list and gone inac-
tive.
3.4.3 Stopping a Context
Software can stop a running context by clearing Context-
Control.run. The context might not stop immediately. To
ensure that the context has stopped, software must wait for
ContextControl.active to be cleared by the CS4210. This
indicates that the CS4210 has completed all processing
associated with the context.
3.4.4 Hardware Behavior
The CS4210 has several DMA controllers each of which
has one or more contexts. Each DMA controller is expected
to examine each of its contexts on a periodic basis and
make operational decisions based on the context state as
contained in ContextControl. The DMA controller examines
the state of the active, run, wake, and dead bits to govern
descriptor processing. This process is executed once each
time a context is ‘scheduled’. Scheduling of a context is
dependent on the DMA controller. For example, an isochro-
nous transmit context is scheduled once per cycle while an
asynchronous request transmit context is only scheduled
once per fairness interval.
3.5 ASYNCHRONOUS RECEIVE
The CS4210 accepts 1394 transactions and groups them
as follows:
Physical Requests - Physical requests, including physical
read, physical write, and lock requests to some CSR regis-
ters (see Section 4.4.4 "Autonomous CSR Resources" on
page 60) are handled directly by the CS4210 and are not
made visible to system software. The CS4210 uses a dedi-
cated physical response unit to handle these requests. This
unit will not block processing of other transaction types
while dealing with physical requests. Section 3.6 "Physical
Requests" on page 26 provides details on which requests
can be processed as physical.
Self-ID Packets - CS4103 packets with the Self-ID format
can be received at any time. However, only those packets
that are received during the Self-ID phase of bus initializa-
tion which immediately follows a bus reset are considered
to be Self-ID packets. Others are considered simply to be
PHY packets which are handled like asynchronous
requests. The CS4210 can be programmed to accept or
ignore Self-ID packets. When Self-ID packets are
accepted, they are stored in a special memory buffer which
has a dedicated controller and context. Because of this
special memory buffer, Self-ID packets can never get
‘stuck’ in a FIFO.
Asynchronous Responses - When the host system ini-
tiates a request through the asynchronous transmit request
context, the response is handled by the asynchronous
receive response context. The fact that host system soft-
ware initiates the process and the fact that the CS4210 has
a separate context for responses, allows system software
to budget for all responses which ensures that the CS4210
always has a place in system memory to store a response
when it arrives. In the unlikely event that the CS4210 does
not have a place for the response it is allowed to drop the
response when it arrives. This causes a split-transaction
time-out which is an error condition with which the software
is already able to deal.
Asynchronous Requests - A request may arrive at the
CS4210 at any time. Additionally, a request can be of any
size up to the limits imposed by the max_rec field in the
Bus_Info_Block (see Section 4.4.7 "Bus Options Register"
on page 62). Due to the unpredictable nature of this trans-
action type, it is impractical for the system software to
ensure that there is always sufficient buffer space defined
in the asynchronous request receive buffers. If the FIFO
which is receiving requests becomes full, all subsequent
requests are busied until there is room to receive them.
Revision 1.0
23
www.national.com