CS4210 datasheet(23/102 Pages) NSC

23 / 102 page

Revision 1.0

www.national.com

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.

CS4210 датащи(PDF) 23 Page - National Semiconductor (TI)

CS4210 датащи(HTML) 23 Page - National Semiconductor (TI)

Html Pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 ...More

датащи скачать

ссылки URL