dp83261 National Semiconductor Corporation, dp83261 Datasheet - Page 100

• Manufacturer Part Number: dp83261
• Description: Bmac Device Fddi Media Access Controller
• Manufacturer: National Semiconductor Corporation

Figure 7-15 ) TXACK is then deasserted and TXABORT is
7 0 Signal Descriptions
If RQRCLS remained asserted the token would be held as
long as possible and multiple frames could be transmitted
In this case the
frame remains identical
Single Frame Transmission without Prestaging
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
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
v
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
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
x v
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
TXRDY
this
RQSEND handshake for the beginning of each
x v
case
u
RQSEND handshake for the beginning of
TXRDY
the
x u
u
TXRDY
RQSEND
x u
(Continued)
x v
RQSEND
TXRDY
x
100
In Figure 7-16 the MAC Reset occurs while the Ending Del-
imiter is being transmitted In Figure 7-17 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-18 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