DP8326 7.0 Signal Descriptions (Continued)

In document DP83261-2 (Page 99-109)

2-228

If RQRCLS remained asserted the token would be held as In Figure 7-14, prestaging is not used. Multiple requests are present at the interface, of which only the highest priority request is presented to the interface. RQRCLS is changing because higher priority requests become ready to be serv­

iced. The scheduling decision is made until a Service Op­

portunity occurs. Once TXRDY is asserted, RQRDY is as­

serted and the r6 request is serviced.

When the data associated with r6 is ready to be transmitted, RQSEND is asserted. This in turn causes TXRDY to be deasserted when transmission begins (entrance to MR2).

The deassertion of TXRDY causes RQSEND to be deas­

serted.

During the first frame of the request, the end of Service Opportunity condition becomes true as a result of:

THT reaching the THT priority threshold if the request was an asynchronous priority request,

THT expiration if the request was an asynchronous re­

quest or

TRT expiration if the request was a synchronous request.

TXPASS is asserted to indicate that this Service Opportunity is complete.

If RQRCLS remains greater than 0, the next usable token will be captured and servicing of the request will continue. If RQRCLS remained asserted the token would be held as long as possible and multiple frames could be transmitted.

In this case the T TXRDY - » T RQSEND -►

i TXRDY —> J, RQSEND handshake for the beginning of each frame remains identical.

Aborted Frame Transmission

A transmission as in Figure 7-14 is started. During the trans­

mission, an interface error occurs (for example) and RQABT is asserted to cause the current frame to be aborted (see Figure 7-15). TXACK is then deasserted and TXABORT is asserted to indicate that the frame was aborted as a result of a FIFO underrun or an equivalent reason. This is signaled with RQABT. After the frame is aborted, TXRDY is asserted to indicate that another frame may be transmitted. Since no frames are ready to be transmitted a Void fill frame is trans­

mitted. During the Void frame transmission, the interface then sets RQRCLS to zero to indicate that the Token should be issued. TXPASS is then asserted once the Ending Delim­

iter of the Void frame is transmitted.

In this scenario the transmitted Void frame serves two pur­

poses. It is transmitted because the interface was stalling waiting for another frame and also in response to the abort­

ed frame. A Void frame is transmitted every time a transmis­

sion is aborted.

MAC Reset

In Figure 7-16, a MAC reset occurs during a frame transmis­

sion. This causes the current frame to be aborted and the Ring Operational Flag (TXRINGOP) to be deasserted.

TXPASS is asserted with TXABORT after the frame is abort­

ed. Since the ring is not operational, no Void frames are transmitted.

7.0 Signal Descriptions

(Continued)

In Figure 7-16 the MAC Reset occurs while the Ending Del­

imiter is being transmitted. In Figure 7 -/7 the boundary case is shown where the MAC Reset occurs during the Frame Status. Note that the Ending Delimiter of the frame is trans­

mitted with the frame status. TXRDY is asserted for one cycle followed by TXPASS with TXABORT.

Synchronous Request followed by Asynchronous Request

In Figure 7-16, frames from two requests are serviced on the same Service Opportunity. Once the synchronous frame is being transmitted, the RQRCLS is changed to that for the asynchronous frame. At the end of the synchronous frame TXRDY is asserted since the token is still usable for the asynchronous request. RQRDY is then asserted and the Asynchronous frame is then transmitted.

Notice that the value of THTDIS changes after the Frame Status for the synchronous frame is transmitted. THT is dis­

abled for synchronous transmission and enabled for normal asynchronous transmission.

Restricted Begin

In Figure 7-19, a restricted dialogue is begun. A non-restrict- ed Token is captured, a single frame is transmitted and a Restricted Token is issued.

An Rbeg Request is a request to capture a Non-restricted Token and issue a Restricted Token. Since there is only one frame in this example, RQFINAL is asserted during the first frame. In the example, RQFINAL is asserted one byte time after RQSEND is deasserted while RQRDY is still asserted, but it may be asserted anytime while RQRDY is asserted.

Notice that TXCLASS changes to restricted after RQFINAL is asserted.

Immediate Claim

In Figure 7-20, an immediate Claim frame is transmitted from the Claim state.

A Lower_Claim frame is received from an upstream station, causing this station to enter its Claim state and deassert TXRINGOP.RQRCLS is set to immediate and RQCLM is as­

serted.

An internally generated Claim frame is first transmitted (at least one internally generated Claim or Beacon frame is al­

ways transmitted upon entry to the Claim or Beacon state).

After the internally generated Claim frame is transmitted, TXRDY is asserted since the transmitter is still in the Claim state (the ring can hold more than one Claim frame). The frame is then transmitted following the normal handshake.

Similar timing applies for externally generated Beacon frames.

Remember that for Immediate Requests from the Claim and Beacon States, RQSEND must be asserted no later than 8 byte times after TXRDY is asserted. This guarantees that a minimum size preamble will be generated.

After the frame is transmitted, TXRDY is asserted again since the transmitter is still in the Claim state.

If this station wins the Claim Process TXPASS is asserted without TXABORT. If another station causes this station to backoff (this station receives a Higher_Claim), TXPASS is asserted with TXABORT.

83 26 1

D P 83 26 7.0 Signal Descriptions

(Continued)

d !

E

i/jQ

£

£o; l/)z o

£o O '

P £

2-230

83 26 1

D P 83 26 7.0 Signal Descriptions

(Continued)

TL /F /1 0387-23

FIGURE 7-16. MAC Reset

2-232

7.0 Signal Descriptions (continued)

TXRINGOP

1___

TXPASS r4

|

r5

|

r6

_... 1

RQRCLS ___

|

r1

|

r2

|

r3

|

r4

|

r5

|

r6

RQRDY r6

TXTHTDIS r5

|

r6

1

R

TXRDY jk fc tt | r4 | r5 | r6

I

FR OPTIONS valid

|

RQSEND

I ...I

MRD ii ii 11

|

12

|

13

|

14

|

15

|

16

|

17

|

i8

m :

TXACK

|

jk 11 12 13 14 15 16 i7 ix iy

|

RQABT

TXABORT

| |

tr

|

rr ii

RQEOF

. R _____ ______

TXED j j tr rr ii

RQFINAL

TXCLASS

|

PRD ii Ii ii ii

|

jk

|

ii ii ii ii ii ii ii ii ii

|

jk ii i2 i3 S A i6 iw ix iy iz f1 f2 f3 f4 tr rr

|

ii

FIGURE 7-17. MAC Reset at End of Frame

T L /F /1 0387-24

83 26 1

D P 83 26

2-234

7.0 Signal Descriptions

(Continued)

83 26 1

D P 83 26

2-236

7.0 Signal Descriptions

(continued) 7.5 ELECTRICAL INTERFACE

The Electrical Interface signals comprise all of the clocking, power supply, and ground pins.

Symbol Pin # I/O Description

LSC 87 I Local Symbol Clock: 25 MHz clock with a 40/60 duty-cycle. Typically generated by the CDD.

LBC 86 I Local Byte Clock: 12.5 MHz clock 50/50 duty-cycle in phase with LSC. Typically generated by the CDD.

RST 118 I Master Reset: Equivalent to setting the Master Reset bit in the Function Register. An asynchronous input that must be asserted for at least 5 LSC clock cycles. When asserted, all bi-directional signals are tri-stated. Active low signal.

VCC[11] 4,17, 34 58, 78 94,100 106,117

I Positive Power Supply: 5V, ± 5% relative to GND.

GND[11] 5,18, 33 57, 77, 88-91, 101, 116,128

I Power Supply Return

7.6 PINOUT SUMMARY

TABLE 7-6. Pinout Summary

Pin # Signal Name Symbol I/O

1 Control Bus Data 1 CBD1 I/O

2 Control Bus Data 2 CBD2 I/O

3 Control Bus Data 3 CBD3 I/O

4 Positive Power Supply Vcc I

5 Ground GND I

6 Control Bus Data 4 CBD4 I/O

7 Control Bus Data 5 CBD5 I/O

8 Control Bus Data 6 CBD6 I/O

9 Control Bus Data 7 CBD7 I/O

10 Control Bus Parity CBP I/O

11 Source Address l/G Transparency SAIGT I

12 Source Address Transparency SAT I

13 Void Strip STRIP I

14 Frame Check Sequence Transparency FCST I

15 Request Claim RQCLM I

16 Request Beacon RQBCN I

17 Positive Power Supply Vcc I

18 Ground GND I

19 Request Class 3 RQRCLS3 I

83 26 1

D P 83 26 7.0 Signal Descriptions

(continued)

In document DP83261-2 (Page 99-109)