DP83266VF datasheet(105/152 Pages) NSC

105 / 152 page

70 Control Information (Continued)

Request Channel 0 and 1 Configuration Registers 0 (R0CR0 and R1CR0)

The two Request Configuration Registers 0 (R0CR0 and R1CR0) are programmed with operational parameters for each of the

Request Channels Additional Request Channel parameters are configured in Request Configuration Registers 1 These regis-

ters may only be altered between Requests ie while the particular Request Channel does not have a Request loaded

These registers are not altered upon reset

Access Rules

Address

Read

Write

110–111h

Always

TT1

TT0

PRE

HLD

FCT

SAT

VST

FCS

Bit

Symbol

Description

FCS

Frame Check Sequence Disable

When this bit is set the MACSI device asserts the FCST signal throughout

the request This drives the Ring Engine FCST signal This bit is used to program the Ring Engine (MAC) not to

concatenate its generated FCS to the transmitted frame The Valid FCS bit in the Expected Frame Status

VST

Vold Stripping

When this bit is set the MACSI device asserts the STRIP signal out throughout the request

This drives the Ring Engine STRIP (Void Strip) signal The STRIP signal may also drive the Ring Engine SAT

signal depending on the state of the BOSEL bit See ‘‘MAC Mode Register 2 (MCMR2)’’

SAT

Source Address Transparency

When this bit is set the MACSI device asserts the SAT output signal

throughout the request This drives the Ring Engine SAIGT signal It may optionally drive the SAT signal

depending upon the setting of the BOSEL bit See ‘‘MAC Mode Register 2 (MCMR2)’’ When SAT is set Full

Confirmation requires the use of the EM (External SA Match) signal

FCT

Frame Control Transparency

When this bit is set the FC will be sourced from the ODU (not the REQFirst or

REQOnly Descriptor) When Full Confirmation is enabled and FCT e 0 all bits of the FC in returning frames

must match the FC field in the REQ Descriptor if FCT e 1 only the C L and r bits must match

Note that since the MACSI device decodes the REQF Descriptor FC field to determine whether to assert

RQCLMRQBCN FC transparency may be used to send Beacons or Claims in any ring non-operational state

as long as the FC in the REQ Descriptor is not set to Beacon or Claim By programming a Beacon or Claim FC

in the REQ Descriptor then using FC transparency any type of frame may be transmitted in the Beacon or

Claim state

HLD

Hold

When this bit is set the MACSI device will not end a service opportunity until the Request is complete

When this bit is Zero the MACSI device ends the service opportunity on the Request Channel when all of the

following conditions are met

1 There is no valid request active on the Request Channel

2 The service class is non-immediate

3 There is no data in the FIFO

4 There is no valid REQ fetched by the MACSI device

This bit also affects Prestaging on RCHN1 (Request Channel 1) When HLD e 0 prestaging is enabled on

RCHN1 regardless of the state of the PRE bit (except for Immediate service classes) When HLD e 1

prestaging is determined by the PRE bit This option can potentially waste ring bandwidth but may be required

(particularly on RCHN0 Request Channel 0) if a guaranteed service time is required

When using the Repeat option HLD is required for small frames If HLD is not used the other Request

Channel will be checked for service before releasing the token between frames This may not be the desired

action particularly if there is a request on RCHN1 that needs servicing after the completion of RCHN0’s

Repeated Request

105

DP83266VF Datasheet(PDF) 105 Page - National Semiconductor (TI)

DP83266VF Datasheet(HTML) 105 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

Datasheet Download

Link URL