National Semiconductor DP83916 Technical data

查询DP83916供应商

DP83916 SONICTM-16
Systems-Oriented Network Interface Controller

General Description

The SONICTM-16 (Systems-Oriented Network Interface
Controller) is a second-generation Ethernet Controller de­signed to meet the demands of today’s high-speed 16-bit
systems. Its system interface operates with a high speed
DMA that typically consumes less than 8% of the bus band­width. Selectable bus modes provide both big and little endi­an byte ordering and a clean interface to standard micro­processors. The linked-list buffer management system of
SONIC-16 offers maximum flexibility in a variety of environ­ments from PC-oriented adapters to high-speed mother­board designs. Furthermore, the SONIC-16 integrates a ful­ly-compatible IEEE 802.3 Encoder/Decoder (ENDEC) al­lowing for a simple 2-chip solution for Ethernet when the
SONIC-16 is paired with the DP8392 Coaxial Transceiver
Interface.

For increased performance, the SONIC-16 implements a
unique buffer management scheme to efficiently process
receive and transmit packets in system memory. No inter­mediate packet copy is necessary. The receive buffer man­agement uses three areas in memory for (1) allocating addi­tional resources, (2) indicating status information, and (3)
buffering packet data. During reception, the SONIC-16
stores packets in the buffer area, then indicates receive
status and control information in the descriptor area. The
system allocates more memory resources to the SONIC-16
by adding descriptors to the memory resource area. The
transmit buffer management uses two areas in memory:

PRELIMINARY

November 1995

one for indicating status and control information and the
other for fetching packet data. The system can create a
transmit queue allowing multiple packets to be transmitted
from a single transmit command. The packet data can re­side on any arbitrary byte boundary and can exist in several
non-contiguous locations.

Features

Y

23-bit non-multiplexed address/16-bit data bus

Y

High-speed, interruptible DMA

Y

Linked-list buffer management maximizes flexibility

Y

Two independent 32-byte transmit and receive FIFOs

Y

Bus compatibility for all standard microprocessors

Y

Supports big and little endian formats

Y

Integrated IEEE 802.3 ENDEC

Y

Complete address filtering for up to 16 physical and/or
multicast addresses

Y

32-bit general-purpose timer

Y

Full-duplex loopback diagnostics

Y

Fabricated in low-power CMOS

Y

132 PQFP package

Y

Full network management facilities support the IEEE

802.3 layer management standard

Y

Integrated support for bridge and repeater applications

DP83916 SONIC-16 Systems-Oriented Network Interface Controller

System Diagram

IEEE 802.3 Ethernet/Thin-Ethernet/10BASE-T Station

TL/F/11722– 1

TRI-STATEÉis a registered trademark of National Semiconductor Corporation.

TM

RIC

and SONICTM-16 are trademarks of National Semiconductor Corporation.

C

1995 National Semiconductor Corporation RRD-B30M16/Printed in U. S. A.

TL/F/11722

1.0 FUNCTIONAL DESCRIPTION

1.1 IEEE 802.3 ENDEC Unit

1.1.1 ENDEC Operation

1.1.2 Selecting an External ENDEC

1.2 MAC Unit

1.2.1 MAC Receive Section

1.2.2 MAC Transmit Section

1.3 Byte Ordering

1.4 FIFO and Control Logic

1.4.1 Receive FIFO

1.4.2 Transmit FIFO

1.5 Status and Configuration Registers

1.6 Bus Interface

1.7 Loopback and Diagnostics

1.7.1 Loopback Procedure

1.8 Network Management Functions

2.0 TRANSMIT/RECEIVE IEEE 802.3
FRAME FORMAT

2.1 Preamble and Start Of Frame Delimiter (SFD)

2.2 Destination Address

2.3 Source Address

2.4 Length/Type Field

2.5 Data Field

2.6 FCS Field

2.7 MAC (Media Access Control) Conformance

3.0 BUFFER MANAGEMENT

3.1 Buffer Management Overview

3.2 Descriptor Areas

3.2.1 Naming Convention for Descriptors

3.2.2 Abbreviations

3.2.3 Buffer Management Base Address

3.3 Descriptor Data Alignment

3.4 Receive Buffer Management

3.4.1 Receive Resource Area (RRA)

3.4.2 Receive Buffer Area (RBA)

3.4.3 Receive Descriptor Area (RDA)

3.4.4 Receive Buffer Management Initialization

3.4.5 Beginning of Reception

3.4.6 End of Packet Processing

3.4.7 Overflow Conditions

3.5 Transmit Buffer Management

3.5.1 Transmit Descriptor Area (TDA)

3.5.2 Transmit Buffer Area (TBA)

3.5.3 Preparing to Transmit

3.5.4 Dynamically Adding TDA Descriptors

Table of Contents

4.0 SONIC-16 REGISTERS

4.1 The CAM Unit

4.1.1 The Load CAM Command

4.2 Status/Control Registers

4.3 Register Description

4.3.1 Command Register

4.3.2 Data Configuration Register

4.3.3 Receive Control Register

4.3.4 Transmit Control Register

4.3.5 Interrupt Mask Register

4.3.6 Interrupt Status Register

4.3.7 Data Configuration Register 2

4.3.8 Transmit Registers

4.3.9 Receive Registers

4.3.10 CAM Registers

4.3.11 Tally Counters

4.3.12 General Purpose Timer

4.3.13 Silicon Revision Register

5.0 BUS INTERFACE

5.1 Pin Configurations

5.2 Pin Description

5.3 System Configuration

5.4 Bus Operations

5.4.1 Acquiring the Bus

5.4.2 Block Transfers

5.4.3 Bus Status

5.4.4 Bus Mode Compatibility

5.4.5 Master Mode Bus Cycles

5.4.6 Bus Exceptions (Bus Retry)

5.4.7 Slave Mode Bus Cycle

5.4.8 On-Chip Memory Arbiter

5.4.9 Chip Reset

6.0 NETWORK INTERFACING

6.1 Manchester Encoder and Differential Driver

6.1.1 Manchester Decoder

6.1.2 Collision Translator

6.1.3 Oscillator Inputs

7.0 AC AND DC SPECIFICATIONS

8.0 AC TIMING TEST CONDITIONS

2

1.0 Functional Description

The SONIC-16
(ENDEC) unit, media access control (MAC) unit, separate
receive and transmit FIFOs, a system buffer management
engine, and a user programmable system bus interface unit
on a single chip. SONIC-16 is highly pipelined providing
maximum system level performance. This section provides
a functional overview of SONIC-16.

1.1 IEEE 802.3 ENDEC UNIT

The ENDEC (Encoder/Decoder) unit is the interface be­tween the Ethernet transceiver and the MAC unit. It pro­vides the Manchester data encoding and decoding func­tions for IEEE 802.3 Ethernet/Thin-Ethernet type local area
networks. The ENDEC operations of SONIC-16 are identical
to the DP83910A CMOS Serial Network Interface device.
During transmission, the ENDEC unit combines non-return­zero (NRZ) data from the MAC section and clock pulses into
Manchester data and sends the converted data differentially
to the transceiver. Conversely, during reception, an analog
PLL decodes the Manchester data to NRZ format and re­ceive clock. The ENDEC unit is a functionally complete
Manchester encoder/decoder incorporating a balanced
driver and receiver, on-board crystal oscillator, collision sig­nal translator, and a diagnostic loopback. The features in­clude:

Compatible with Ethernet I and II, IEEE 802.3 10BASE5

#

and 10BASE2

10Mb/s Manchester encoding/decoding with receive

#

clock recovery

Requires no precision components

#

Loopback capability for diagnostics

#

Externally selectable half or full step modes of operation

#

at transmit output

Squelch circuitry at the receive and collision inputs reject

#

noise

Connects to the transceiver (AUI) cable via external

#

pulse transformer

(Figure 1-1 )

consists of an encoder/decoder

1.1.1 ENDEC Operation

The primary function of the ENDEC unit
perform the encoding and decoding necessary for compati­bility between the differential pair Manchester encoded data
of the transceiver and the Non-Return-to-Zero (NRZ) serial
data of the MAC unit data line. In addition to encoding and
decoding the data stream, the ENDEC also supplies all the
necessary special signals (e.g., collision detect, carrier
sense, and clocks) to the MAC unit.

Manchester Encoder and Differential Output Driver:

During transmission to the network, the ENDEC unit trans­lates the NRZ serial data from the MAC unit into differential
pair Manchester encoded data on the Coaxial Transceiver
Interface (e.g., National’s DP8392) transmit pair. To perform
this operation the NRZ bit stream from the MAC unit is
passed through the Manchester encoder block of the EN­DEC unit. Once the bit stream is encoded, it is transmitted
out differentially to the transmit differential pair through the
transmit driver.

Manchester Decoder: During reception from the network,
the differential receive data from the transceiver (e.g., the
DP8392) is converted from Manchester encoded data into
NRZ serial data and a receive clock, which are sent to the
receive data and clock inputs of the MAC unit. To perform
this operation the signal, once received by the differential
receiver, is passed to the phase locked loop (PLL) decoder
block. The PLL decodes the data and generates a data re­ceive clock and a NRZ serial data stream to the MAC unit.

Special Signals: In addition to performing the Manchester
encoding and decoding function, the ENDEC unit provides
control and clocking signals to the MAC unit. The ENDEC
sends a carrier sense (CRS) signal that indicates to the
MAC unit that data is present from the network on the EN­DEC’s receive differential pair. The MAC unit is also provid­ed with a collision detection signal (COL) that informs the
MAC unit that a collision is taking place somewhere on the

(Figure 1-2 )

is to

FIGURE 1-1. SONIC-16 Block Diagram

3

TL/F/11722– 2

1.0 Functional Description (Continued)

TL/F/11722– 3

FIGURE 1-2. Block Diagram of Ethernet ENDEC

4

1.0 Functional Description (Continued)

network. The ENDEC section detects this when its collision
receiver detects a 10 MHz signal on the differential collision
input pair. The ENDEC also provides both the receive and
transmit clocks to the MAC unit. The transmit clock is one
half of the oscillator input. The receive clock is extracted
from the input data by the PLL.

Oscillator: The oscillator generates the 10 MHz transmit
clock signal for network timing. The oscillator is controlled
by a parallel resonant crystal or by an external clock (see
section 6.1.3). The 20 MHz output of the oscillator is divided
by 2 to generate the 10 MHz transmit clock (TXC) for the
MAC section. The oscillator provides an internal clock signal
for the encoding and decoding circuits.

The signals provided to the MAC unit from the on-chip EN­DEC are also provided as outputs to the user.

Loopback Functions: The SONIC-16 provides three loop­back modes. These modes allow loopback testing at the
MAC, ENDEC and external transceiver level (see section

1.7 for details). It is important to note that when the SONIC­16 is transmitting, the transmitted packet will always be
looped back by the external transceiver. The SONIC-16
takes advantage of this to monitor the transmitted packet.
See the explanation of the Receive State Machine in sec­tion 1.2.1 for more information about monitoring transmitted
packets.

1.1.2 Selecting An External ENDEC

An option is provided on SONIC-16 to disable the on-chip
ENDEC unit and use an external ENDEC. The internal IEEE

802.3 ENDEC can be bypassed by connecting the EXT pin
to V

(EXTe1). In this mode the MAC signals are redirect-

CC

ed out from the chip, allowing an external ENDEC to be
used. See section 5.2 for the alternate pin definitions.

1.2 MAC UNIT

The MAC (Media Access Control) unit performs the media
access control functions for transmitting and receiving pack­ets over Ethernet. During transmission, the MAC unit frames
information from the transmit FIFO and supplies serialized
data to the ENDEC unit. During reception, the incoming in­formation from the ENDEC unit is deserialized, the frame
checked for valid reception, and the data is transferred to
the receive FIFO. Control and status registers on the
SONIC-16 govern the operation of the MAC unit.

1.2.1 MAC Receive Section

The receive section
operations during reception, loopback, and transmission.
During reception, the deserializer goes active after detecting
the 2-bit SFD (Start of Frame Delimiter) pattern (section

2.1). It then frames the incoming bits into octet boundaries

(Figure 1-3 )

controls the MAC receive

and transfers the data to the 32-byte receive FIFO. Concur­rently the address comparator compares the Destination
Address Field to the addresses stored in the chip’s CAM
address registers (Content Addressable Memory cells). If a
match occurs, the deserializer passes the remainder of the
packet to the receive FIFO. The packet is decapsulated
when the carrier sense input pin (CRS) goes inactive. At the
end of reception the receive section checks the following:

Ð Frame alignment errors
Ð CRC errors
Ð Length errors (runt packets)
The appropriate status is indicated in the Receive Control

register (section 4.3.3). In loopback operations, the receive
section operates the same as during normal reception.

During transmission, the receive section remains active to
allow monitoring of the self-received packet. The CRC
checker operates as normal, and the Source Address field
is compared with the CAM address entries. Status of the
CRC check and the source address comparison is indicated
by the PMB bit in the Transmit Control register (section

4.3.4). No data is written to the receive FIFO during transmit
operations.

The receive section consists of the following blocks detailed
below.

Receive State Machine (RSM): The RSM insures the prop­er sequencing for normal reception and self-reception dur­ing transmission. When the network is inactive, the RSM
remains in an idle state continually monitoring for network
activity. If the network becomes active, the RSM allows the
deserializer to write data into the receive FIFO. During this
state, the following conditions may prevent the complete
reception of the packet.

Ð FIFO OverrunÐThe receive FIFO has been completely

filled before the SONIC-16 could buffer the data to mem­ory.

Ð CAM Address MismatchÐThe packet is rejected be-

cause of a mismatch between the destination address of
the packet and the address in the CAM.

Ð Memory Resource ErrorÐThere are no more resources

(buffers) available for buffering the incoming packets.

Ð Collision or Other ErrorÐA collision occured on the net-

work or some other error, such as a CRC error, occurred
(this is true if the SONIC-16 has been told to reject pack­ets on a collision, or reject packets with errors).

If these conditions do not occur, the RSM processes the
packet indicating the appropriate status in the Receive Con­trol register.

FIGURE 1-3. MAC Receiver

5

TL/F/11722– 4

1.0 Functional Description (Continued)

During transmission of a packet from the SONIC-16, the
external transceiver will always loop the packet back to the
SONIC-16. The SONIC-16 will use this to monitor the packet
as it is being transmitted. The CRC and source address of
the looped back packet are checked with the CRC and
source address that were transmitted. If they do not match,
an error bit is set in the status of the transmitted packet (see
Packet Monitored Bad, PBM, in the Transmit Control Regis­ter, section 4.3.4). Data is not written to the receive FIFO
during this monitoring process unless Transceiver Loopback
mode has been selected (see section 1.7).

Receive Logic: The receive logic contains the command,
control, and status registers that govern the operations of
the receive section. It generates the control signals for writ­ing data to the receive FIFO, processes error signals ob­tained from the CRC checker and the deserializer, activates
the ‘‘packet reject’’ signal to the RSM for rejecting packets,
and posts the applicable status in the Receive Control regis­ter.

Deserializer: This section deserializes the serial input data
stream and furnishes a byte clock for the address compara­tor and receive logic. It also synchronizes the CRC checker
to begin operation (after SFD is detected), and checks for
proper frame alignment with respect to CRS going inactive
at the end of reception.

Address Comparator: The address comparator latches the
Destination Address (during reception or loopback) or
Source Address (during transmission) and determines
whether the address matches one of the entries in the CAM
(Content Addressable Memory).

CRC Checker: The CRC checker calculates the 4-byte
Frame Check Sequence (FCS) field from the incoming data
stream and compares it with the last 4-bytes of the received
packet. The CRC checker is active for both normal recep­tion and self-reception during transmission.

Content Addressable Memory (CAM): The CAM contains
16 user programmable entries and 1 pre-programmed
Broadcast address entry for complete filtering of received
packets. The CAM can be loaded with any combination of
Physical and Multicast Addresses (section 2.2). See section

4.1 for the procedure on loading the CAM registers.

1.2.2 MAC Transmit Section

The transmit section
data from the transmit FIFO and transmitting a serial data

(Figure 1-4 )

is responsible for reading

stream onto the network in conformance with the IEEE

802.3 CSMA/CD standard. The Transmit Section consists
of the following blocks.

Transmit State Machine (TSM): The TSM controls the
functions of the serializer, preamble generator, and JAM
generator. It determines the proper sequence of events that
the transmitter follows under various network conditions. If
no collision occurs, the transmitter prefixes a 62-bit pream­ble and 2-bit Start of Frame Delimiter (SFD) at the beginning
of each packet, then sends the serialized data. At the end of
the packet, an optional 4-byte CRC pattern is appended. If a
collision occurs, the transmitter switches from transmitting
data to sending a 4-byte Jam pattern to notify all nodes that
a collision has occurred. Should the collision occur during
the preamble, the transmitter waits for it to complete before
jamming. After the transmission has completed, the trans­mitter writes status in the Transmit Control register (section

4.3.4).

Protocol State Machine: The protocol state machine as­sures that the SONIC-16 obeys the CSMA/CD protocol. Be­fore transmitting, this state machine monitors the carrier
sense and collision signals for network activity. If another
node(s) is currently transmitting, the SONIC-16 defers until
the network is quiet, then transmits after its Interframe Gap
Timer (9.6 ms) has expired. The Interframe Gap time is divid­ed into two portions. During the first 6.4 ms, network activity
restarts the Interframe Gap timer. Beyond this time, howev­er, network activity is ignored and the state machine waits
the remaining 3.2 ms before transmitting. If the SONIC-16
experiences a collision during a transmission, the SONIC-16
switches from transmitting data to a 4-byte JAM pattern (4
bytes of all 1’s), before ceasing to transmit. The SONIC-16
then waits a random number of slot times (51.2 ms) deter­mined by the

rithm

rithm, the number of slot times to delay before the nth re­transmission is chosen to be a random integer r in the range
of:

If a collision occurs on the 16th transmit attempt, the SON­IC-16 aborts transmitting the packet and reports an ‘‘Exces­sive Collisions’’ error in the Transmit Control register.

Truncated Binary Exponential Backoff Algo-

before reattempting another transmission. In this algo-

k

srs

0

2

where kemin(n,10)

FIGURE 1-4. MAC Transmitter

6

TL/F/11722– 5

1.0 Functional Description (Continued)

Serializer: After data has been written into the 32-byte

transmit FIFO, the serializer reads byte wide data from the
FIFO and sends a NRZ data stream to the Manchester en­coder. The rate at which data is transmitted is determined
by the transmit clock (TXC). The serialized data is transmit­ted after the SFD.

Preamble Generator: The preamble generator prefixes a
62-bit alternating ‘‘1,0’’ pattern and a 2-bit ‘‘1,1’’ SFD pat­tern at the beginning of each packet. This allows receiving
nodes to synchronize to the incoming data. The preamble is
always transmitted in its entirety even in the event of a colli­sion. This assures that the minimum collision fragment is 96
bits (64 bits of normal preamble, and 4 bytes, or rather 32
bits, of the JAM pattern).

CRC Generator: The CRC generator calculates the 4-byte
FCS field from the transmitted serial data stream. If en­abled, the 4-byte FCS field is appended to the end of the
transmitted packet (section 2.6).

Jam Generator: The Jam generator produces a 4-byte pat­tern of all 1’s to assure that all nodes on the network sense
the collision. When a collision occurs, the SONIC-16 stops
transmitting data and enables the Jam generator. If a colli­sion occurs during the preamble, the SONIC-16 finishes
transmitting the preamble before enabling the Jam genera­tor (see Preamble Generator above).

1.3 BYTE ORDERING

The SONIC-16 will operate with 16-bit wide memory. The
SONIC-16 provides both Little Endian and Big Endian byte-

ordering capability for compatibility with National/Intel or
Motorola microprocessors respectively by selecting the
proper level on the BMODE pin. The byte ordering is depict­ed as follows:

Little Endian mode (BMODE

received and transmitted data in the Receive Buffer Area
(RBA) and Transmit Buffer Area (TBA) of system memory is
as follows:

15 8 7 0

Byte 1 Byte 0

MSB LSB

Big Endian mode (BMODE

received and transmitted data in the RBA and TBA is as
follows:

15 8 7 0

Byte 0 Byte 1

LSB MSB

e

0): The byte orientation for

16-Bit Word

e

1): The byte orientation for

16-Bit Word

FIGURE 1-5. Receive FIFO

7

TL/F/11722– 6

1.0 Functional Description (Continued)

1.4 FIFO AND CONTROL LOGIC

The SONIC-16 incorporates two independent 32-byte
FIFOs for transferring data to/from the system interface and
from/to the network. The FIFOs, providing temporary stor­age of data, free the host system from the real-time de­mands on the network.

The way in which the FIFOS are emptied and filled is con­trolled by the FIFO threshold values and the Block Mode
Select bits (BMS, section 4.3.2). The threshold values deter­mine how full or empty the FIFOs can be before the SONIC­16 will request the bus to get more data from memory or
buffer more data to memory. When block mode is set, the
number of bytes transferred is set by the threshold value.
For example, if the threshold for the receive FIFO is 4
words, then the SONIC-16 will always transfer 4 words from
the receive FIFO to memory. If empty/fill mode is set, how­ever, the number of bytes transferred is the number required
to fill the transmit FIFO or empty the receive FIFO. More
specific information about how the threshold affects recep­tion and transmission of packets is discussed in sections

1.4.1 and 1.4.2 below.

1.4.1 Receive FIFO

To accommodate the different transfer rates, the receive
FIFO

(Figure 1-5 )

work (deserializer) interface and the 16-bit system interface.
The FIFO is arranged as a 4-byte wide by 8 deep memory
array (8 long words, or 32 bytes) controlled by three sec­tions of logic. During reception, the Byte Ordering logic di­rects the byte stream from the deserializer into the FIFO
using one of four write pointers. Depending on the selected
byte-ordering mode, data is written either least significant
byte first or most significant byte first to accommodate little
or big endian byte-ordering formats respectively.

As data enters the FIFO, the Threshold Logic monitors the
number of bytes written in from the deserializer. The pro­grammable threshold (RFT1,0 in the Data Configuration
Register) determines the number of words (or long words)
written into the FIFO from the MAC unit before a DMA re­quest for system memory occurs. When the threshold is
reached, the Threshold Logic enables the Buffer Manage­ment Engine to read a programmed number of 16-bit words
(depending upon the selected word width) from the FIFO
and transfers them to the system interface (the system
memory) using DMA. The threshold is reached when the
number of bytes in the receive FIFO is greater than the
value of the threshold. For example, if the threshold is 4
words (8 bytes), then the Threshold Logic will not cause the
Buffer Management Engine to write to memory until there
are more than 8 bytes in the FIFO.

The Buffer Management Engine reads either the upper or
lower half (16 bits) of the FIFO. If, after the transfer is com­plete, the number of bytes in the FIFO is less then the
threshold, then the SONIC-16 is done. This is always the
case when the SONIC-16 is in empty/fill mode. If, however,
for some reason (e.g. latency on the bus) the number of
bytes in the FIFO is still greater than the threshold value,
the Threshold Logic will cause the Buffer Management En­gine to do a DMA request to write to memory again. This
later case is usually only possible when the SONIC-16 is in
block mode.

When in block mode, each time the SONIC-16 requests the
bus, only a number of bytes equal to the threshold value will

serves as a buffer between the 8-bit net-

be transferred. The Threshold Logic continues to monitor
the number of bytes written in from the deserializer and en­ables the Buffer Management Engine every time the thresh­old has been reached. This process continues until the end
of the packet.

Once the end of the packet has been reached, the serializer
will fill out the last word if the last byte did not end on a word
boundary. The fill byte will be 0FFh. Immediately after the
last byte (or fill byte) in the FIFO, the received packets
status will be written into the FIFO. The entire packet, in­cluding any fill bytes and the received packet status will be
buffered to memory. When a packet is buffered to memory
by the Buffer Management Engine, it is always taken from
the FIFO in words and buffered to memory on word bounda­ries. Data from a packet cannot be buffered on odd byte
boundaries (see Section 3.3). For more information on the
receive packet buffering process, see Section 3.4.

1.4.2 Transmit FIFO

Similar to the Receive FIFO, the Transmit FIFO
serves as a buffer between the 16-bit system interface and
the network (serializer) interface. The Transmit FIFO is also
arranged as a 4 byte by 8 deep memory array (8 long words
or 32 bytes) controlled by three sections of logic. Before
transmission can begin, the Buffer Management Engine
fetches a programmed number of 16-bit words from memo­ry and transfers them to the FIFO. The Buffer Management
Engine writes either the upper or lower half (16 bits) into the
FIFO.

The Threshold logic monitors the number of bytes as they
are written into the FIFO. When the threshold has been
reached, the Transmit Byte Ordering state machine begins
reading bytes from the FIFO to produce a continuous byte
stream for the serializer. The threshold is met when the
number of bytes in the FIFO is greater than the value of the
threshold. For example, if the transmit threshold is 4 words
(8 bytes), the Transmit Byte Ordering state machine will not
begin reading bytes from the FIFO until there are 9 or more
bytes in the buffer. The Buffer Management Engine contin­ues replenishing the FIFO until the end of the packet. It
does this by making multiple DMA requests to the system
interface. Whenever the number of bytes in the FIFO is
equal to or less than the threshold value, the Buffer Man­agement Engine will do a DMA request. If block mode is set,
then after each request has been granted by the system,
the Buffer Management Engine will transfer a number of
bytes equal to the threshold value into the FIFO. If empty/fill
mode is set, the FIFO will be completely filled in one DMA
request.

Since data may be organized in big or little endian byte or­dering format, the Transmit Byte Ordering state machine
uses one of four read pointers to locate the proper byte
within the 4 byte wide FIFO. It also determines the valid
number of bytes in the FIFO. For packets which begin or
end at odd bytes in the FIFO, the Buffer Management En­gine writes extraneous bytes into the FIFO. The Transmit
Byte Ordering state machine detects these bytes and only
transfers the valid bytes to the serializer. The Buffer Man­agement Engine can read data from memory on any byte
boundary (see Section 3.3). See Section 3.5 for more infor­mation on transmit buffering.

(Figure 1-6 )

8

1.0 Functional Description (Continued)

FIGURE 1-6. Transmit FIFO

1.5 STATUS AND CONFIGURATION REGISTERS

The SONIC-16 contains a set of status/control registers for
conveying status and control information to/from the host
system. The SONIC-16 uses these registers for loading
commands generated from the system, indicating transmit
and receive status, buffering data to/from memory, and pro­viding interrupt control. Each register is 16 bits in length.
See section 4.0 for a description of the registers.

1.6 BUS INTERFACE

The system interface
essary for interfacing to a variety of buses. It includes the
I/O drivers for the data and address lines, bus access con­trol for standard microprocessors, ready logic for synchro­nous or asynchronous systems, slave access control, inter­rupt control, and shared-memory access control. The func­tional signal groups are shown in
for a complete description of the SONIC-16 bus interface.

1.7 LOOPBACK AND DIAGNOSTICS

The SONIC-16 furnishes three loopback modes for self­testing from the controller interface to the transceiver inter­face. The loopback function is provided to allow self-testing
of the chip’s internal transmit and receive operations. During
loopback, transmitted packets are routed back to the re­ceive section of the SONIC-16 where they are filtered by the
address recognition logic and buffered to memory if accept­ed. Transmit and receive status and interrupts remain active
during loopback. This means that when using loopback, it is
as if the packet was transmitted and received by two sepa­rate chips that are connected to the same bus and memory.

MAC Loopback: Transmitted data is looped back at the
MAC. Data is not sent from the MAC to either the internal
ENDEC or an external ENDEC (the external ENDEC inter­face pins will not be driven), hence, data is not transmitted
from the chip. Even though the ENDEC is not used in MAC
loopback, the ENDEC clock (an oscillator or crystal for the
internal ENDEC or TXC for an external ENDEC) must be
driven. Network activity, such as a collision, does not affect

(Figure 1-7 )

consists of the pins nec-

Figure 1-7

. See section 5.0

TL/F/11722– 7

MAC loopback. CSMA/CD MAC protocol is not completely
followed in MAC loopback.

ENDEC Loopback: Transmitted data is looped back at the
ENDEC. If the internal ENDEC is used, data is switched
from the transmit section of the ENDEC to the receive sec­tion (

Figure 1-2

the collision lines, CD
ty does not affect ENDEC loopback. The LBK signal from
the MAC tells the internal ENDEC to go into loopback mode.
If an external ENDEC is used, it should operate in loopback
mode when the LBK signal is asserted. CSMA/CD MAC
protocol is followed even though data is not transmitted
from the chip.

Transceiver Loopback: Transmitted data is looped back at
the external transceiver (which is always the case regard­less of the SONIC-16’s loopback mode). CSMA/CD MAC
protocol is followed since data will be transmitted from the
chip. This means that transceiver loopback is affected by
network activity. The basic difference between Transceiver
Loopback and normal, non-loopback, operations of the
SONIC-16 is that in Transceiver Loopback, the SONIC-16
loads the receive FIFO and buffers the packet to memory. In
normal operations, the SONIC-16 only monitors the packet
that is looped back by the transceiver, but does not fill the
receive FIFO and buffer the packet.

1.7.1 Loopback Procedure

The following procedure describes the loopback operation.

1. Initialize the Transmit and Receive Area as described in
Sections 3.4 and 3.5.

2. Load one of the CAM address registers (see Section 4.1),
with the Destination Address of the packet if you are veri­fying the SONIC-16’s address recognition capability.

3. Load one of the CAM address registers with the Source
Address of the packet if it is different than the Destination
Address to avoid getting a Packet Monitored Bad (PMB)
error in the Transmit status (see Section 4.3.4).

). Data is not transmitted from the chip and

g

, are ignored, hence, network activi-

9

1.0 Functional Description (Continued)

4. Program the Receive Control register with the desired re­ceive filter and the loopback mode (LB1, LB0).

5. Issue the transmit command (TXP) and enable the receiv­er (RXEN) in the Command register.

The SONIC-16 completes the loopback operation after the
packet has been completely received (or rejected if there is
an address mismatch). The Transmit Control and Receive
Control registers treat the loopback packet as in normal op­eration and indicate status accordingly. Interrupts are also
generated if enabled in the Interrupt Mask register.

Note: For MAC Loopback, only one packet may be queued for proper oper-

ation. This restriction occurs because the transmit MAC section,
which does not generate an Interframe Gap time (IFG) between
transmitted packets, does not allow the receive MAC section to up­date receive status. There are no restrictions for the other loopback
modes.

1.8 NETWORK MANAGEMENT FUNCTIONS

The SONIC-16 fully supports the Layer Management IEEE

802.3 standard to allow a node to monitor the overall per­formance of the network. These statistics are available on a
per packet basis at the end of reception or transmission. In
addition, the SONIC-16 provides three tally counters to tab­ulate CRC errors, Frame Alignment errors, and missed
packets. Table 1-1 shows the statistics indicated by the
SONIC-16.

*Note: DSACK0,1 are used for both Bus and Slave Access Control and are bidirectional. SMACK is used for both Slave access and shared memory access. The

BMODE pin selects between National/Intel or Motorola type buses.

TL/F/11722– 8

FIGURE 1-7. SONIC-16 Interface Signals

10

1.0 Functional Description (Continued)

TABLE 1-1. Network Management Statistics

Statistic Register Used Bits Used

Frames Transmitted OK TCR (Note) PTX

Single Collision Frames (Note) NC0–NC4

Multiple Collision Frames (Note) NC0–NC4

Collision Frames (Note) NC0–NC4

Frames with Deferred Transmissions TCR (Note) DEF

Late Collisions TCR (Note) OWC

Excessive Collisions TCR (Note) EXC

Excessive Deferral TCR (Note) EXD

Internal MAC Transmit Error TCR (Note) BCM, FU

Frames Received OK RCR (Note) PRX

Multicast Frames Received OK RCR (Note) MC

Broadcast Frames Received OK RCR (Note) BC

Frame Check Sequence Errors CRCT All

Alignment Errors FAET All

Frame Lost due to Internal MAC Receive Error MPT All

Note: The number of collisions and the contents of the Transmit Control register are posted in the TXpkt.status field (see
section 3.5.1.2). The contents of the Receive Control register are posted in the RXpkt.status field (see section 3.4.3.1).

2.0 Transmit/Receive IEEE 802.3 Frame Format

A standard IEEE 802.3 packet
following fields: preamble, Start of Frame Delimiter (SFD),
destination address, source address, length, data and
Frame Check Sequence (FCS). The typical format is shown
in

Figure 2-1

decoded by the ENDEC unit and transferred serially to/from
the MAC unit using NRZ data with a clock. All fields are of
fixed length except for the data field. The SONIC-16 gener­ates and appends the preamble, SFD and FCS field during
transmission. The Preamble and SFD fields are stripped
during reception. (The CRC is passed through to buffer
memory during reception.)

. The packets are Manchester encoded and

(Figure 2-1 )

consists of the

2.1 PREAMBLE AND START OF FRAME DELIMITER
(SFD)

The Manchester encoded alternating 1,0 preamble field is
used by the ENDEC to acquire bit synchronization with an
incoming packet. When transmitted, each packet contains
62 bits of an alternating 1,0 preamble. Some of this pream­ble may be lost as the packet travels through the network.
Byte alignment is performed when the Start of Frame Delim­iter (SFD) pattern, consisting of two consecutive 1’s, is de­tected.

2.2 DESTINATION ADDRESS

The destination address indicates the destination of the
packet on the network and is used to filter unwanted pack-

RCR CRC

RCR FAE

ISR RFO

Note: Bebytes

bebits TL/F/11722– 9

FIGURE 2-1. IEEE 802.3 Packet Structure

11

2.0 Transmit/Receive IEEE 802.3 Frame Format (Continued)

ets from reaching a node. There are three types of address
formats supported by the SONIC-16: Physical, Multicast,
and Broadcast.
Physical Address: The physical address is a unique ad­dress that corresponds only to a single node. All physical
addresses have the LSB of the first byte of the address set
to ‘‘0’’. These addresses are compared to the internally
stored CAM (Content Addressable Memory) address en­tries. All bits in the destination address must match an entry
in the CAM in order for the SONIC-16 to accept the packet.
Multicast Address: Multicast addresses, which have the
LSB of the first byte of the address set to ‘‘1’’, are treated
similarly as Physical addresses, i.e., they must match an
entry in the CAM. This allows perfect filtering of Multicast
packet’s and eliminates the need for a hashing algorithm for
mapping Multicast packets.
Broadcast Address: If the address consists of all 1’s, it is a
Broadcast address, indicating that the packet is intended for
all nodes.

The SONIC-16 also provides a promiscuous mode which
allows reception of all physical address packets. Physical,
Multicast, Broadcast, and promiscuous address modes can
be selected via the Receive Control register.

2.3 SOURCE ADDRESS

The source address is the physical address of the sending
node. Source addresses cannot be multicast or broadcast
addresses. This field must be passed to the SONIC-16’s
transmit buffer from the system software. During transmis­sion, the SONIC-16 compares the Source address with its
internal CAM address entries before monitoring the CRC of
the self-received packet. If the source address of the packet
transmitted does not match a value in the CAM, the packet
monitored bad flag (PMB) will be set in the transmit status
field of the transmit descriptor (see Sections 3.5.1.2 and

4.3.4). The SONIC-16 does not provide Source Address in-

sertion. However, a transmit descriptor fragment, containing
only the Source Address, may be created for each packet.
(See Section 3.5.1.)

2.4 LENGTH/TYPE FIELD

For IEEE 802.3 type packets, this field indicates the number
of bytes that are contained in the data field of the packet.
For Ethernet I and II networks, this field indicates the type of
packet. The SONIC-16 does not operate on this field.

2.5 DATA FIELD

The data field has a variable octet length ranging from 46 to
1500 bytes as defined by the Ethernet specification. Mes­sages longer than 1500 bytes need to be broken into multi­ple packets for IEEE 802.3 networks. Data fields shorter
than 46 bytes require appending a pad to bring the com­plete frame length to 64 bytes. If the data field is padded,
the number of valid bytes are indicated in the length field.
The SONIC-16 does not append pad bytes for short packets
during transmission, nor check for oversize packets during
reception. However, the user’s driver software can easily
append the pad by lengthening the TXpkt.pktÐsize field
and TXpkt.fragÐsize field(s) to at least 64 bytes (see Sec­tion 3.5.1). While the Ethernet specification defines the
maximum number of bytes in the data field the SONIC-16
can transmit and receive packets up to 64k bytes.

2.6 FCS FIELD

The Frame Check Sequence (FCS) is a 32-bit CRC field
calculated and appended to a packet during transmission to
allow detection of error-free packets. During reception, an
error-free packet results in a specific pattern in the CRC

generator. The AUTODIN II (X32
X16aX12aX11aX10aX8aX7aX5aX4
X2aX1a1) polynomial is used for the CRC calculations.
The SONIC-16 may optionally append the CRC sequence
during transmission, and checks the CRC both during nor­mal reception and self-reception during a transmission (see
Section 1.2.1).

2.7 MAC (MEDIA ACCESS CONTROL) CONFORMANCE

The SONIC-16 is designed to be compliant to the IEEE

802.3 MAC Conformance specification. The SONIC-16 im­plements most of the MAC functions in silicon and provides
hooks for the user software to handle the remaining func­tions. The MAC Conformance specifications are summa­rized in Table 2-1.

TABLE 2-1. MAC Conformance Specifications

Conformance

Test Name

Minimum Frame Size X

Maximum Frame Size X X 1

Address Generation X X 2

Address Recognition X

Pad Length Generation X X 3

Start Of Frame Delimiter X

Length Field X

Preamble Generation X

Order of Bit Transmission X

Inconsistent Frame Length X X 1

Non-Integral Octet Count X

Incorrect Frame Check
Sequence

Frame Assembly X

FCS Generation and Insertion X

Carrier Deference X

Interframe Spacing X

Collision Detection X

Collision Handling X

Collision Backoff and
Retransmission

FCS Validation X

Frame Disassembly X

Back-to-Back Frames X

Flow Control X

Attempt Limit X

Jam Size (after SFD) X

Jam Size (in Preamble) X

Note 1: The SONIC-16 provides the byte count of the entire packet in the
RXpkt.byteÐcount (see Section 3.4.3). The user’s driver software may per­form further filtering of the packet based upon the byte count.

Note 2: The SONIC-16 does not provide Source Address insertion; however,
a transmit descriptor fragment, containing only the Source Address, may be
created for each packet. See Section 3.5.1.

Note 3: The SONIC-16 does not provide Pad generation; however, the us­er’s driver software can easily append the Pad by lengthening the
TXpkt.pktÐsize field and TXpkt.fragÐsize field(s) to at least 64 bytes. See
Section 3.5.1.

12

a

X26aX23aX22

Support By

SONIC User Driver

-16 Software

X

X

a
a

Notes

3.0 Buffer Management

3.1 BUFFER MANAGEMENT OVERVIEW

The SONIC-16’s buffer management scheme is based on
separate buffers and descriptors (
Packets that are received or transmitted are placed in buff­ers called the Receive Buffer Area (RBA) and the Transmit
Buffer Area (TBA). The system keeps track of packets in
these buffers using the information in the Receive Descrip­tor Area (RDA) and the Transmit Descriptor Area (TDA). A
single (TDA) points to a single TBA, but multiple RDAs can
point to a single RBA (one RDA per packet in the buffer).
The Receive Resource Area (RRA), which is another form
of descriptor, is used to keep track of the actual buffer.

When packets are transmitted, the system sets up the pack­ets in one or more TBAs with a TDA pointing to each TBA.
There can only be one packet per TBA/TDA pair. A single
packet, however, may be made up of several fragments of
data dispersed in memory. There is one TDA pointing to
each packet which specifies information about the packet’s
size, location in memory, number of fragments and status
after transmission. The TDAs are linked together in a linked
list. The system causes the SONIC-16 to transmit the pack­ets by passing the first TDA to the SONIC-16 and issuing
the transmit command.

Before a packet can be received, an RBA and RDA must be
set up by the system. RDAs are made up as a linked list
similar to TDAs. An RDA is not linked to a particular RBA,
though. Instead, an RDA is linked specifically to a packet
after it has been buffered into an RBA. More than one pack­et can be buffered into the same RBA, but each packet gets
its own RDA. A received packet can not be scattered into
fragments. The system only needs to tell the SONIC-16
where the first RDA and where the RBAs are. Since an RDA
never specifically points to an RBA, the RRA is used to
keep track of the RBAs. The RRA is a circular queue of
pointers and buffer sizes (not a linked list). When the SON­IC-16 receives a packet, it is buffered into a RBA and a RDA
is written to so that it points to and describes the new pack­et. If the RBA does not have enough space to buffer the
next packet, a new RBA is obtained from the RRA.

3.2 DESCRIPTOR AREAS

Descriptors are the basis of the buffer management scheme
used by the SONIC-16. A RDA points to a received packet
within a RBA, a RRA points to a RBA and a TDA points to a
TBA which contains a packet to be transmitted. The con­ventions and registers used to describe these descriptors
are discussed in the next three sections.

3.2.1 Naming Convention for Descriptors

The fields which make up the descriptors are named in a
consistent manner to assist in remembering the usage of
each descriptor. Each descriptor name consists of three
components in the following format.

[

RX/TX][descriptor name].[field

The first two capital letters indicate whether the descriptor is
used for transmission (TX) or reception (RX), and is then
followed by the descriptor name having one of two names.

Figures 3-2

and

3-11

]

e

rsrc

Resource descriptor

e

pkt

Packet descriptor

).

The last component consists of a field name to distinguish it
from the other fields of a descriptor. The field name is sepa­rated from the descriptor name by a period (‘‘.’’). An exam­ple of a descriptor is shown below.

RX rsrc buffÐptr 0,1

Descriptor consists of two
fields. ‘‘0’’ and ‘‘1’’
respectively indicate the
least and most significant
portions of the descriptor.

The ‘‘pointer’’ field of the
descriptor

A descriptor for a buffer
resource

A descriptor used for
reception

3.2.2 Abbreviations

The abbreviations in Table 3-1 are used to describe the
SONIC-16 registers and data structures in memory. The ‘‘0’’
and ‘‘1’’ in the abbreviations indicate the least and most
significant portions of the registers or descriptors. Table 3-1
lists the naming convention abbreviations for descriptors.

3.2.3 Buffer Management Base Addresses

The SONIC-16 uses three areas in memory to store descrip­tor information: the Transmit Descriptor Area (TDA), Re­ceive Descriptor Area (RDA), and the Receive Resource
Area (RRA). The SONIC-16 accesses these areas by con­catenating a 16-bit base address register with a 16-bit offset
register. The base address register supplies a fixed upper 8
bits of address and the offset registers provide the lower 16
bits of address. The base address registers are the Upper
Transmit Descriptor Address (UTDA), Upper Receive De­scriptor Address (URDA), and the Upper Receive Resource
Address (URRA) registers. The corresponding offset regis­ters are shown below.

Upper Address Registers Offset Registers

See Table 3-1 for definition of register mnemonics.

Figure 3-1

Area and the Receive Descriptor Area being located by the
UTDA and URDA registers. The descriptor areas, RDA,
TDA, and RRA are allowed to have the same base address.
i.e., URRA
to prevent these areas from overwriting each other.

URRA RSA,REA,RWP,RRP
URDA CRDA
UTDA CTDA

shows an example of the Transmit Descriptor

e

URDAeUTDA. Care, however, must be taken

13

3.0 Buffer Management (Continued)

TABLE 3-1. Descriptor Abbreviations

TRANSMIT AND RECEIVE AREAS

RRA Receive Resource Area

RDA Receive Descriptor Area

RBA Receive Buffer Area

TDA Transmit Descriptor Area

TBA Transmit Buffer Area

BUFFER MANAGEMENT REGISTERS

RSA Resource Start Area Register

REA Resource End Area Register

RRP Resource Read Pointer Register

RWP Resource Write Pointer Register

CRDA Current Receive Descriptor

Address Register

CRBA0,1 Current Receive Buffer Address

Register

TCBA0,1 Temporary Current Buffer Address

Register

RBWC0,1 Remaining Buffer Word Count

Register

TRBWC0,1 Temporary Remaining Buffer Word

Count Register

EOBC End of Buffer Count Register

TPS Transmit Packet Size Register

TSA0,1 Transmit Start Address Register

CTDA Current Transmit Descriptor

Address Register

BUFFER MANAGEMENT REGISTERS (Continued)

TFC Transmit Fragment Count Register

TFS Transmit Fragment Size Register

UTDA Upper Transmit Descriptor

Address Register

URRA Upper Receive Resource Address

Register

URDA Upper Receive Descriptor Address

Register

TRANSMIT AND RECEIVE DESCRIPTORS

RXrsrc.buffÐptr0,1 Buffer Pointer Field in the RRA

RXrsrc.buffÐwc0,1 Buffer Word Count Fields in the

RRA

RXpkt.status Receive Status Field in the RDA

RXpkt.byteÐcount Packet Byte Count Field in the

RDA

RXpkt.buffÐptr0,1 Buffer Pointer Fields in the RDA

RXpkt.link Receive Descriptor Link Field in

RDA

RXpkt.inÐuse ‘‘In Use’’ Field in RDA

TXpkt.fragÐcount Fragment Count Field in TDA

TXpkt.pktÐsize Packet Size Field in TDA

TXpkt.pktÐptr0,1 Packet Pointer Fields in TDA

TXpkt.fragÐsize Fragment Size Field in TDA

TXpkt.link Transmit Descriptor Link Field in

TDA

FIGURE 3-1. Transmit and Receive Descriptor Area Pointers

14

TL/F/11722– 10

3.0 Buffer Management (Continued)

3.3 DESCRIPTOR DATA ALIGNMENT

All fields used by descriptors (RXpkt.xxx, RXrsrc.xxx, and
TXpkt.xxx) are word quantities (16-bit) and must be aligned
to word boundaries (A0
(RBA) must also be aligned to a word boundary. The frag­ments in the Transmit Buffer Area (TBA), however, may be
aligned on any arbitrary byte boundary.

All descriptor areas follow little endian byte ordering, even
when BMODE

3.4 RECEIVE BUFFER MANAGEMENT

The Receive Buffer Management operates on three areas in
memory into which data, status, and control information are
written during reception
must be initialized (section 3.4.4) before enabling the receiv­er (setting the RXEN bit in the Command register). The re­ceive resource area (RRA) contains descriptors that locate
receive buffer areas in system memory. These descriptors
are denoted by R1, R2, etc. in
by P1, P2, etc.) can then be buffered into the corresponding
RBAs. Depending on the size of each buffer area and the
size of the packet(s), multiple or single packets are buffered
into each RBA. The receive descriptor area (RDA) contains
status and control information for each packet (D1, D2, etc.
in

Figure 3-2

goes with P1, D2 with P2, etc.).

When a packet arrives, the address recognition logic checks
the address for a Physical, Multicast, or Broadcast match
and if the packet is accepted, the SONIC-16 buffers the
packet contiguously into the selected Receive Buffer Area
(RBA). Because of the previous end-of-packet processing,
the SONIC-16 assures that the complete packet is written
into a single contiguous block. When the packet ends, the
SONIC-16 writes the receive status, byte count, and loca­tion of the packet into the Receive Descriptor Area (RDA).
The SONIC-16 then updates its pointers to locate the next
available descriptor and checks the remaining words avail­able in the RBA. If sufficient space remains, the SONIC-16
buffers the next packet immediately after the previous pack-

e

) corresponding to each received packet (D1

1.

e

0). The Receive Buffer Area

(Figure 3-2 )

. These three areas

Figure 3-2

. Packets (denoted

et. If the current buffer is out of space the SONIC-16 fetches
a Resource descriptor from the Receive Resource Area
(RRA) acquiring an additional buffer that has been previous­ly allocated by the system.

3.4.1 Receive Resource Area (RRA)

As buffer memory is consumed by the SONIC-16 for storing
data, the Receive Resource Area (RRA) provides a mecha­nism that allows the system to allocate additional buffer
space for the SONIC-16. The system loads this area with
resource descriptors that the SONIC-16, in turn, reads as its
current buffer space is used up. Each resource descriptor
consists of a 23-bit buffer pointer locating the starting point
of the RBA and a 32-bit Word Count that indicates the size
of the buffer in words (2 bytes per word). The buffer pointer
and word count are contiguously located using the format
shown in

Figure 3-3

bit fields. The SONIC-16 stores this information internally
and concatenates the corresponding fields to create 23­and 32-bit long words for the buffer pointer and word count.

The SONIC-16 organizes the RRA as a circular queue for
efficient processing of descriptors. Four registers define the
RRA. The first two, the Resource Start Area (RSA) and the
Resource End Area (REA) registers, determine the starting
and ending locations of the RRA, and the other two regis­ters update the RRA. The system adds descriptors at the
address specified by the Resource Write Pointer (RWP),
and the SONIC-16 reads the next descriptor designated by
the Resource Read Pointer (RRP). The RRP is advanced 4
words after the SONIC-16 finishes reading the RRA and
automatically wraps around to the beginning of the RRA
once the end has been reached. When a descriptor in the
RRA is read, the RXrsc.buffÐpt0,1 is loaded into the
CRBA0,1 registers and the RXrsc.buffÐwc0,1 is loaded into
the RBWC0,1 registers.

The alignment of the RRA is confined to word boundaries
(A0 is always zero).

with each component composed of 16-

FIGURE 3-2. Overview of Receive Buffer Management

15

TL/F/11722– 11

3.0 Buffer Management (Continued)

3.4.2 Receive Buffer Area (RBA)

The SONIC-16 stores the actual data of a received packet
in the RBA. The RBAs are designated by the resource de­scriptors in the RRA as described above. The
RXrsrc.buffÐwc0,1 fields of the RRA indicate the length of
the RBA. When the SONIC-16 gets a RBA from the RRA,
the RXrsrc.buffÐwc0,1 values are loaded into the Remain­ing Buffer Word Count registers (RBWC0,1). These regis­ters keep track of how much space (in words) is left in the
buffer. When a packet is buffered in a RBA, it is buffered
contiguously (the SONIC-16 will not scatter a packet into
multiple buffers or fragments). Therefore, if there is not
enough space left in a RBA after buffering a packet to buffer
at least one more maximum sized packet (the maximum
legal sized packet expected to be received from the net­work), a new buffer must be acquired. The End of Buffer
Count (EOBC) register is used to tell the SONIC-16 the max­imum packet size that the SONIC-16 will need to buffer.

3.4.2.1 End of Buffer Count (EOBC)

The EOBC is a boundary in the RBA based from the bottom
of the buffer. The value written into the EOBC is the maxi­mum expected size (in words) of the network packet that
the SONIC-16 will have to buffer. This word count creates a
line in the RBA that, when crossed, causes the SONIC-16 to
fetch a new RBA resource from the RRA.

Note: The EOBC is a word count, not a byte count.

3.4.2.2 Buffering the Last Packet in an RBA

At the start of reception, the SONIC-16 stores the packet
beginning at the Current Receive Buffer Address (CRBA0,1)
and continues until the reception is complete. Concurrent
with reception, the SONIC-16 decrements the Remaining
Buffer Word Count (RBWC0,1) by one. At the end of recep­tion, if the packet has crossed the EOBC boundary, the
SONIC-16 knows that the next packet might not fit in the
RBA. This check is done by comparing the RBWC0,1 regis­ters with the EOBC. If RBWC0,1 is less than the EOBC (the
last packet buffered has crossed the EOBC boundary), the
SONIC-16 fetches the next resource descriptor in the RRA.
If RBWC0,1 is greater than or equal to the EOBC (the EOBC
boundary has not been crossed) the next packet reception
continues at the present location pointed to by CRBA0,1 in
the same RBA.
tions for (1) RBWC0,1

Figure 3-4

illustrates the SONIC-16’s ac-

t

EOBC and (2) RBWC0,1kEOBC.
See Section 3.4.4.4 for specific information about setting
the EOBC.

Note: It is important that the EOBC boundary be ‘‘crossed.’’ In other words,

Ý

1in

Figure 3-4

case
occurs without case

k

EOBC will not work properly and the SONIC-16 will not fetch a new
buffer. The result of this will be a buffer overflow (RBAE in the Inter­rupt Status Register, section 4.3.6).

must exist before caseÝ2 exists. If caseÝ2

Ý

1 having occurred first, the test for RBWC0,1

FIGURE 3-3. Receive Resource Area Format

CaseÝ1

t

Case
Case

(RBWC0,1

Ý

Ý

EOBC)

1: SONIC-16 buffers next packet in same RBA.
2: SONIC-16 detects an exhausted RBA and will buffer the next packet in another RBA.

Ý

Case
(RBWC0,1

2

k

EOBC)

FIGURE 3-4. Receive Buffer Area

16

TL/F/11722– 12

TL/F/11722– 13

3.0 Buffer Management (Continued)

3.4.3 Receive Descriptor Area (RDA)

After the SONIC-16 buffers a packet to memory, it writes 5
words of status and control information into the RDA, reads
the link field to the next receive descriptor and writes to the
in use field of the current discriptor. Each receive descriptor
consists of the following sections (

FIGURE 3-5. Receive Descriptor Format

receive status: indicates status of the received packet. The

SONIC-16 writes the Receive Control register into this field.

Figure 3-6

shows the receive status format. This field is
loaded from the contents of the Receive Control register.
Note that ERR, RNT, BRD, PRO, and AMC are configura­tion bits and are programmed during initialization. See Sec­tion 4.3.3 for the description of the Receive Control register.

15 14 13 12 11 10 9 8

ERR RNT BRD PRO AMC LB1 LB0 MC

7654 3 2 10

BC LPKT CRS COL CRCR FAER LBK PRX

FIGURE 3-6. Receive Status Format

byte count: gives the length of the complete packet from

the start of Destination Address to the end of FCS.

packet pointer: a 23-bit pointer that locates the packet in
the RBA. The SONIC-16 writes the contents of the
CRBA0,1 registers into this field.

sequence numbers: this field displays the contents of two
8-bit counters (modulo 256) that sequence the RBAs used
and the packets buffered. These counters assist the system
in determining when an RBA has been completely process­ed. The sequence numbers allow the system to tally the
packets that have been processed within a particular RBA.
There are two sequence numbers that describe a packet:
the RBA Sequence Number and the Packet Sequence
Number. When a packet is buffered to memory, the SONIC­16 maintains a single RBA Sequence Number for all pack­ets in an RBA and sequences the Packet Number for suc­ceeding packets in the RBA. When the SONIC-16 uses the
next RBA, it increments the RBA Sequence Number and
clears the Packet Sequence Number. The RBA’s sequence
counter is not incremented when the read RRA command is
issued in the Command register. The format of the Receive
Sequence Numbers are shown in
ters are reset during hardware reset or by writing zero to
them.

Figure 3-5

Figure 3-7

).

TL/F/11722– 14

. These coun-

15 8 7 0

RBA Sequence Number Packet Sequence Number

(Modulo 256) (Modulo 256)

FIGURE 3-7. Receive Sequence Number Format

receive link field: a 15-bit pointer (A15–A1) that locates

the next receive descriptor. The LSB of this field is the End
Of List (EOL) bit, and indicates the last descriptor in the list.
(Initialized by the system.)

in use field: this field provides a handshake between the
system and the SONIC-16 to indicate the ownership of the
descriptor. When the system avails a descriptor to the SON­IC-16, it writes a non-zero value into this field. The SONIC­16, in turn, sets this field to all ‘‘0’s’’ when it has finished
processing the descriptor. (That is, when the CRDA register
has advanced to the next receive descriptor.) Generally, the
SONIC-16 releases control after writing the status and con­trol information into the RDA. If, however, the SONIC-16 has
reached the last descriptor in the list, it maintains ownership
of the descriptor until the system has appended additional
descriptors to the list. The SONIC-16 then relinquishes con­trol after receiving the next packet. (See Section 3.4.6.1 for
details on when the SONIC-16 writes to this field.) The re­ceive packet descriptor format is shown in

Figure 3-5

.

3.4.4 Receive Buffer Management Initialization

The Receive Resource, Descriptor, and Buffer areas (RRA,
RDA, RBA) in memory and the appropriate SONIC-16 regis­ters must be properly initialized before the SONIC-16 begins
buffering packets. This section describes the initialization
process.

3.4.4.1 Initializing The Descriptor Page

All descriptor areas (RRA, RDA, and TDA) used by the
SONIC-16 reside within areas up to 32k (word) pages. This
page may be placed anywhere within the 23-bit address
range by loading the upper 8 address lines into the UTDA,
URDA, and URRA registers.

3.4.4.2 Initializing The RRA

The initialization of the RRA consists of loading the four
SONIC-16 RRA registers and writing the resource descriptor
information to memory.

The RRA registers are loaded with the following values.
Resource Start Area (RSA) register: The RSA is loaded

with the lower 16-bit address of the beginning of the RRA.
Resource End Area (REA) register: The REA is loaded

with the lower 16-bit address of the end of the RRA. The
end of the RRA is defined as the address of the last
RXrsrc.ptr0 field in the RRA plus 4 words (

Figure 3-3

).

Resource Read Pointer (RRP) register: The RRP is load­ed with the lower 16-bit address of the first resource de­scriptor the SONIC-16 reads.

Resource Write Pointer (RWP) register: The RWP is load­ed with the lower 16-bit address of the next vacant location
where a resource descriptor will be placed by the system.

Note: The RWP register must only point to either (1) the RXrsrc.ptr0 field of

one of the RRA Descriptors, (2) the memory address that the RSA
points to (the start of the RRA), or (3) the memory address that the
REA points to (the end of the RRA). When the RWP
son is made, it is performed after the complete RRA descriptor has
been read and not during the fetch. Failure to set the RWP to any of
the above values prevents the RWP
becoming true.

e

e

RRP compari-

RRP comparison from ever

17

3.0 Buffer Management (Continued)

All RRA registers are concatenated with the URRA register
for generating the full 23-bit address.

The resource descriptors that the system writes to the RRA
consists of four fields: (1) RXrsrc.buffÐptr0, (2)
RXrsrc.buffÐptr1, (3) RXrsrc.buffÐwc0, and (4)
RXrsrc.buffÐwc1. The fields must be contiguous (they can­not straddle the end points) and are written in the order
shown in
denote the least and most significant portions for the Buffer
Pointer and Word Count. The first two fields supply the
23-bit starting location of the Receive Buffer Area (RBA),
and the second two define the number of 16-bit words that
the RBA occupies. Note that a restriction applies to the
Buffer Pointer and Word Count. The Buffer Pointer must be
pointing to a word boundary. Note also that the descriptors
must be properly aligned in the RRA as discussed in Section

3.3.

Figure 3-8

. The ‘‘0’’ and ‘‘1’’ in the descriptors

when it finishes using the descriptor. At startup, the Current
Receive Descriptor Address (CRDA) register must be load­ed with the address of the first RXpkt.status field in order for
the SONIC-16 to begin receive processing at the first de­scriptor. An example of two descriptors linked together is
shown in

Figure 3-9

displayed in larger type. The other fields are written by the
SONIC-16 after a packet is accepted. The RXpkt.inÐuse
field is first written by the system, and then by the SONIC-

16. Note that the descriptors must be aligned properly as
discussed in section 3.3. Also note that the URDA register is
concatenated with the CRDA register to generate the full
23-bit address.

. The fields initialized by the system are

FIGURE 3-8. RRA Initialization

After configuring the RRA, the RRA Read command (setting
RRRA bit in the Command register) may be given. This
command causes the SONIC-16 to read the RRA descriptor
in a single block operation, and load the following registers
(see Section 4.2 for register mnemonics):

CRBA0 register
CRBA1 register
RBWC0 register
RBWC1 register

When the command has completed, the RRRA bit in the
Command register is reset to ‘‘0’’. Generally this command
is only issued during initialization. At all other times, the RRA
is automatically read as the SONIC-16 finishes using an
RBA.

3.4.4.3 Initializing The RDA

To accept multiple packets from the network, the receive
packet descriptors must be linked together via the
RXpkt.link fields. Each link field must be written with a 15-bit
(A15–A1) pointer to locate the beginning of the next de­scriptor in the list. The LSB of the RXpkt.link field is the End
of List (EOL) bit and is used to indicate the end of the de­scriptor list. EOL
the first or middle descriptors. The RXpkt.inÐuse field indi­cates whether the descriptor is owned by the SONIC-16.
The system writes a non-zero value to this field when the
descriptor is available, and the SONIC-16 writes all ‘‘0’s’’

w

RXrsrc.buffÐptr0

w

RXrsrc.buffÐptr1

w

RXrsrc.buffÐwc0

w

RXrsrc.buffÐwc1

e

1 for the last descriptor and EOLe0 for

TL/F/11722– 15

FIGURE 3-9. RDA Initialization Example

TL/F/11722– 16

3.4.4.4 Initializing the Lower Boundary of the RBA

A ‘‘false bottom’’ is set in the RBA by loading the End Of
Buffer Count (EOBC) register with a value equal to the maxi­mum size packet in words (16 bits) that may be received.
This creates a lower boundary in the RBA. Whenever the
Remaining Buffer Word Count (RBWC0,1) registers decre­ment below the EOBC register, the SONIC-16 buffers the
next packet into another RBA. This also guarantees that a
packet is always contiguously buffered into a single Receive
Buffer Area (RBA). The SONIC-16 does not buffer a packet
into multiple RBAs.

After a hardware reset, the EOBC register is automatically
initialized to 2F8h (760 words or 1520 bytes).

Sometimes it may be desired to buffer a single packet per
RBA. When doing this, it is important to set EOBC and the
buffer size correctly. The suggested practice is to set EOBC
to a value that is at least 2 bytes less than the buffer size.

18

3.0 Buffer Management (Continued)

e

An example would be EOBC
the buffer size set to 760 words (1520 bytes). The buffer
can be any size, but as long as the EOBC is 1 word less
than the buffer size, only one packet will be buffered in that
RBA.

Note 1: It is possible to filter out most oversized packets by setting the buff-

er size to 759 words (1518 bytes). EOBC would be set to 758 words
(1516 bytes) for both cases. With this configuration, any packet over
1518 bytes, will not be completely buffered because the packet will
overflow the buffer. When a packet overflow occurs, a Receive Buff­er Area Exceeded interrupt (RBAE in the Interrupt Status Register,
Section 4.3.6) will occur.

Note 2: When buffering one packet per buffer, it is suggested that the val-

ues in Note 1 above be used. Since the minimum legal sized Ether­net packet is 64 bytes, however, it is possible to set EOBC as much
as 64 bytes less than the buffer size and still end up with one packet

Figure 3-10

per buffer.

3.4.5 Beginning of Reception

At the beginning of reception, the SONIC-16 checks its in­ternally stored EOL bit from the previous RXpkt.link field for
a ‘‘1’’. If the SONIC-16 finds EOL
the previous reception, there were no more remaining re­ceive packet descriptors. It re-reads the same RXpkt.link
field to check if the system has updated this field since the
last reception. If the SONIC-16 still finds EOL
ceases. (See Section 3.5 for adding descriptors to the list.)
Otherwise, the SONIC-16 begins storing the packet in the
RBA starting at the Current Receive Buffer Address
(CRBA0,1) registers and continues until the packet has
completed. Concurrent with the packet reception, the Re­maining Buffer Word Count (RBWC0,1) registers are decre­mented after each word is written to memory. This register
determines the remaining words in the RBA at the end of
reception.

3.4.6 End of Packet Processing

At the end of a reception, the SONIC-16 enters its end of
packet processing sequence to determine whether to ac­cept or reject the packet based on receive errors and pack­et size. At the end of reception the SONIC-16 enters one of
the following two sequences:

Ð Successful reception sequence

Ð Buffer recovery for runt packets or packets with errors

759 words (1518 bytes) and

shows this ‘‘range.’’

e

1, it recognizes that after

e

1, reception

3.4.6.1 Successful Reception

If the SONIC-16 accepts the packet, it first writes 5 words of
descriptor information in the RDA beginning at the address
pointed to by the Current Receive Descriptor Address
(CRDA) register. It then reads the RXpkt.link field to ad­vance the CRDA register to the next receive descriptor. The
SONIC-16 also checks the EOL bit for a ‘‘1’’ in this field. If

e

EOL

1, no more descriptors are available for the SONIC-

16. The SONIC-16 recovers the address of the current
RXpkt.link field (from a temporary register) and generates a
‘‘Receive Descriptors Exhausted’’ indication in the Interrupt
Status register. (See Section 3.4.7 on how to add descrip­tors.) The SONIC-16 maintains ownership of the descriptor
by

not

writing to the RXpkt.inÐuse field. Otherwise, if

e

EOL

0, the SONIC-16 advances the CRDA register to the
next descriptor and resets the RXpkt.inÐuse field to all
‘‘0’s’’.

The SONIC-16 accesses the complete 7 word RDA descrip­tor in a single block operation.

The SONIC-16 also checks if there is remaining space in the
RBA. The SONIC-16 compares the Remaining Buffer Word
Count (RBWC0,1) registers with the static End Of Buffer
Count (EOBC). If the RBWC is less than the EOBC, a maxi­mum sized packet will no longer fit in the remaining space in
the RBA; hence, the SONIC-16 fetches a resource descrip­tor from the RRA and loads its registers with the pointer and
word count of the next available RBA.

3.4.6.2 Buffer Recovery for Runt Packets or
Packets with Errors

If a runt packet (less than 64 bytes) or packet with errors
arrives and the Receive Control register has been config­ured to not accept these packets, the SONIC-16 recovers
its pointers back to the original positions. The CRBA0,1 reg­isters are not advanced and the RBWC0,1 registers are not
decremented. The SONIC-16 recovers its pointers by main­taining a copy of the buffer address in the Temporary Re­ceive Buffer Address registers (TRBA0,1). The SONIC-16
recovers the value in the RBWC0,1 registers from the Tem­porary Buffer Word Count registers (TBWC0,1).

3.4.7 Overflow Conditions

When an overflow condition occurs, the SONIC-16 halts its
DMA operations to prevent writing into unauthorized memo­ry. The SONIC-16 uses the Interrupt Status register (ISR) to
indicate three possible overflow conditions that can occur

Range of EOBCe(RXrsrc.wc0,1b2 to RXrsrc.wc0,1b32)

FIGURE 3-10. Setting EOBC for Single Packet RBA

19

TL/F/11722– 17

3.0 Buffer Management (Continued)

when its receive resources have been exhausted. The sys­tem should respond by replenishing the resources that have
been exhausted. These overflow conditions (Descriptor Re­sources Exhausted, Buffer Resources Exhausted, and RBA
Limit Exceeded) are indicated in the Interrupt Status register
and are detailed as follows:

Descriptor Resources Exhausted: This occurs when the
SONIC-16 has reached the last receive descriptor in the list,
meaning that the SONIC-16 has detected EOL
tem must supply additional descriptors for continued recep­tion. The system can do this in one of two ways: 1) append­ing descriptors to the existing list, or 2) creating a separate
list.

1) Appending descriptors to the existing list. This is the eas­iest and preferred way. To do this, the system, after cre­ating the new list, joins the new list to the existing list by
simply writing the beginning address of the new list into
the RXpkt.link field and setting EOL
reception, the SONIC-16 re-reads the last RXpkt.link
field, and updates its CRDA register to point to the next
descriptor.

2) Creating a separate list. This requires an additional step
because the lists are not joined together and requires
that the CRDA register be loaded with the address of the
RXpkt.link field in the new list.

During this overflow condition, the SONIC-16 maintains
ownership of the descriptor (RXpkt.inÐuse
waits for the system to add additional descriptors to the list.
When the system appends more descriptors, the SONIC-16
releases ownership of the descriptor after writing 0000h to
the RXpkt.inÐuse field.

Buffer Resources Exhausted: This occurs when the
SONIC-16 has detected that the Resource Read Pointer
(RRP) and Resource Write Pointer (RWP) registers are
equal (i.e., all RRA descriptors have been exhausted). The
RBE bit in the Interrupt Status register is set when the SON­IC-16 finishes using the second to last receive buffer and
reads the last RRA descriptor. Actually, the SONIC-16 is not
truly out of resources, but gives the system an early warning
of an impending out of resources condition. To continue
reception after the last RBA is used, the system must supply
additional RRA descriptor(s), update the RWP register, and
clear the RBE bit in the ISR. The SONIC-16 rereads the
RRA after this bit is cleared.

RBA Limit Exceeded: This occurs when a packet does not
completely fit within the remaining space of the RBA. This
can occur if the EOBC register is not programmed to a value
greater than the largest packet that can be received. When
this situation occurs, the packet is truncated and the SON­IC-16 reads the RRA to obtain another RBA. Indication of
an RBA limit being exceeded is signified by the Receive
Buffer Area Exceeded (RBAE) interrrupt being set (see sec­tion 4.3.6). An RDA will not be set up for the truncated pack­et and the buffer space will not be re-used. To rectify this
potential overflow condition, the EOBC register must be
loaded with a value equal to or greater than the largest
packet that can be accepted. See Section 3.4.2.

3.5 TRANSMIT BUFFER MANAGEMENT

To begin transmission, the system software issues the
Transmit command (TXP

e

1 in the CR). The Transmit Buff­er Management uses two areas in memory for transmitting
packets

(Figure 3-11),

the Transmit Descriptor Area (TDA)

e

1. The sys-

e

0. At the next

i

00h) and

and the Transmit Buffer Area (TBA). During transmission,
the SONIC-16 fetches control information from the TDA,
loads its appropriate registers, and then transmits the data
from the TBA. When the transmission is complete, the SON­IC-16 writes the status information in the TDA. From a single
transmit command, packets can either be transmitted singly
or in groups if several descriptors have been linked togeth­er.

FIGURE 3-11. Overview of Transmit Buffer Management

TL/F/11722– 18

3.5.1 Transmit Descriptor Area (TDA)

The TDA contains descriptors that the system has generat­ed to exchange status and control information. Each de­scriptor corresponds to a single packet and consists of the
following 16-bit fields.

TXpkt.status: This field is written by the SONIC-16 and pro­vides status of the transmitted packet. See Section 3.5.1.2
for more details.

TXpkt.config: This field allows programming the SONIC-16
to one of the various transmit modes. The SONIC-16 reads
this field and loads the corresponding configuration bits
(PINTR, POWC, CRCI, and EXDIS) into the Transmit Control
register. See Section 3.5.1.1 for more details.

TXpkt.pktÐsize: This field contains the byte count of the
entire packet

TXpkt.fragÐcount: This field contains the number of frag­ments the packet is segmented into.

TXpkt.fragÐptr0,1: This field contains a 23-bit pointer
which locates the packet fragment to be transmitted in the
Transmit Buffer Area (TBA). This pointer is not restricted to
any byte alignment.

TXpkt.fragÐsize: This field contains the byte count of the
packet fragment. The minimum fragment size is 1 byte.

TXpkt.link: This field contains a 15-bit pointer (A15 –A1) to
the next TDA descriptor. The LSB, the End Of List (EOL) bit,
indicates the last descriptor in the list when set to a ‘‘1’’.
When descriptors have been linked together, the SONIC-16
transmits back-to-back packets from a single transmit com­mand.

The data of the packet does not need to be contiguous, but
can exist in several locations (fragments) in memory. In this
case, the TXpkt.fragÐcount field is greater than one, and
additional TXpkt.fragÐptr0,1 and TXpkt.fragÐsize fields
corresponding to each fragment are used. The descriptor
format is shown in

Figure 3-12.

20

3.0 Buffer Management (Continued)

FIGURE 3-12. Transmit Descriptor Area

3.5.1.1 Transmit Configuration

The TXpkt.config field allows the SONIC-16 to be pro­grammed into one of the transmit modes before each trans­mission. At the beginning of each transmission, the SONIC­16 reads this field and loads the PINTR, POWC, CRCI, and
EXDIS bits into the Transmit Control register (TCR). The
configuration bits in the TCR correspond directly with the
bits in the TXpkt.config field as shown in
Section 4.3.4 for the description on the TCR.

15 14 13 12 11 10 9 8

PINTR POWC CRCI EXDIS X X X X

7654321 0

XXXXXXX X

Note: xedon’t care

3.5.1.2 Transmit Status

At the end of each transmission the SONIC-16 writes the
status bits (
and the number of collisions experienced during the trans­mission into the TXpkt.status field
served). Bits NC4-NC0 indicate the number of collisions
where NC4 is the MSB. See Section 4.3.4 for the descrip­tion of the TCR.

15 14 13 12 11 10 9 8

NC4 NC3 NC2 NC1 NC0 EXD DEF NCRS

CRSL EXC OWC res PMB FU BCM PTX

3.5.2 Transmit Buffer Area (TBA)

The TBA contains the fragments of packets that are defined
by the descriptors in the TDA. A packet can consist of a
single fragment or several fragments, depending upon the
fragment count in the TDA descriptor. The fragments also
can reside anywhere within the full 23-bit address range,
and be aligned to any byte boundary. When an odd byte
boundary is given, the SONIC-16 automatically begins read­ing data at the corresponding word boundary. The SONIC­16 ignores the extraneous bytes which are written into the

FIGURE 3-13. TXpkt.config Field

k

10:0l) of the Transmit Control Register (TCR)

76543210

FIGURE 3-14. TXpkt.status Field

TL/F/11722– 19

Figure 3-13.

(Figure 3-14

See

, resere-

FIFO during odd byte alignment fragments. The minimum
allowed fragment size is 1 byte.
tionship between the TDA and the TBA for single and multi­fragmented packets.

3.5.3 Preparing To Transmit

All fields in the TDA descriptor and the Current Transmit
Descriptor Address (CTDA) register of the SONIC-16 must
be initialized before the Transmit Command (setting the
TXP bit in the Command register) can be issued. If more
than one packet is queued, the descriptors must be linked
together with the TXpkt.link field. The last descriptor must
have EOL
To begin transmission, the system loads the address of the
first TXpkt.status field into the CTDA register. Note that the
upper 8-bits of address are loaded in the Upper Transmit
Descriptor (UTDA) register. The user performs the following
transmit initialization.

1) Initialize the TDA

2) Load the CTDA register with the address of the first

3) Issue the transmit command

Note that if the Source Address of the packet being trans­mitted is not in the CAM, the Packet Monitored Bad (PMB)
bit in the TXpxt.status field will be set (see Section 4.3.4).

3.5.3.1 Transmit Process

When the Transmit Command (TXP
register) is issued, the SONIC-16 fetches the control infor­mation in the TDA descriptor, loads its appropriate registers
(shown below) and begins transmission. (See Section 4.2
for register mnemonics.)

TCR
TPS
TFC
TSA0
TSA1
TFS
CTDA

(CTDA is loaded after all fragments have been read and
successfully transmitted. If the halt transmit command is is­sued (HTX bit in the Command register is set) the CTDA
register is not loaded.)

During transmission, the SONIC-16 reads the packet de­scriptor in the TDA and transmits the data from the TBA. If
TXpkt.fragÐcount is greater than one, the SONIC-16, after
finishing transmission of the fragment, fetches the next
TXpkt.fragÐptr0,1 and TXpkt.fragÐsize fields and transmits
the next fragment. This process continues until all frag­ments of a packet are transmitted. At the end of packet
transmission, status is written in to the TXpkt.status field.
The SONIC-16 then reads the TXpkt.link field and checks if
EOL
scriptor and transmits the next packet. If EOL
IC-16 generates a ‘‘Transmission Done’’ indication in the
Interrupt Status register and resets the TXP bit in the Com­mand register.

In the event of a collision, the SONIC-16 recovers its pointer
in the TDA and retransmits the packet up to 15 times. The
SONIC-16 maintains a copy of the CTDA register in the
Temporary Transmit Descriptor Address (TTDA) register.

The SONIC-16 performs a block operation of 6, 3, or 2 ac­cesses in the TDA, depending on where the SONIC-16 is in
the transmit process. For the first fragment, it reads the

e

1 and all other descriptors must have EOLe0.

transmit descriptor

w

TXpkt.config

w

TXpkt.pktÐsize

w

TXpkt.fragÐcount

w

TXpkt.fragÐptr0

w

TXpkt.fragÐptr1

w

TXpkt.fragÐsize

w

TXpkt.link

e

0. If it is ‘‘0’’, the SONIC-16 fetches the next de-

Figure

3-11 shows the rela-

e

1 in the Command

e

1 the SON-

21

3.0 Buffer Management (Continued)

TXpkt.config to TXpkt.fragÐsize (6 accesses). For the next
fragment, if any, it reads the next 3 fields from TXpkt.frag
ptr0 to TXpkt.fragÐsize (3 accesses). At the end of trans­mission it writes the status information to TXpkt.status and
reads the TXpkt.link field (2 accesses).

3.5.3.2 Transmit Completion

The SONIC-16 stops transmitting under two conditions. In
the normal case, the SONIC-16 transmits the complete list
of descriptors in the TDA and stops after it detects EOL

1. In the second case, certain transmit errors cause the
SONIC-16 to abort transmission. If

Count Mismatch, Excessive Collision,

(if enabled) errors occur, transmission ceases. The CTDA
register points to the last packet transmitted. The system
can also halt transmission under software control by setting
the HTX bit in the Command register. Transmission halts
after the SONIC-16 writes to the TXpkt.status field.

3.5.4 Dynamically Adding TDA Descriptors

Descriptors can be dynamically added during transmission
without halting the SONIC-16. The SONIC-16 can also be
guaranteed to transmit the complete list including newly ap­pended descriptors (barring any transmit abort conditions)
by observing the following rule: The last TXpkt.link field
must point to the next location where a descriptor will be
added (see step 3 below and
for appending descriptors consists of:

1. Creating a new descriptor with its TXpkt.link pointing to

the next vacant descriptor location and its EOL bit set to
a ‘‘1’’.

2. Resetting the EOL bit to a ‘‘0’’ of the previously last de-

scriptor.

3. Re-issuing the Transmit command (setting the TXP bit in

the Command register).

Step 3 assures that the SONIC-16 will transmit all the pack­ets in the list. If the SONIC-16 is currently transmitting, the
Transmit command has no effect and continues transmitting
until it detects EOL

e

1. If the SONIC-16 had just finished
transmitting, it continues transmitting from where it had pre­viously stopped.

FIGURE 3-15. Initializing Last Link Field

FIFO Underrun, Byte

or

Excessive Deferral

Figure 3-15

). The procedure

TL/F/11722– 20

4.0 SONIC-16 Registers

The SONIC-16 contains two sets of registers: The status/

Ð

e

control registers and the CAM memory cells. The status/
control registers are used to configure, control, and monitor
SONIC-16 operation. They are directly addressable regis­ters and occupy 64 consecutive address locations in the
system memory space (selected by the RA5 – RA0 address
pins). There are a total of 64 status/control registers divided
into the following categories:

User Registers: These registers are accessed by the user
to configure, control, and monitor SONIC-16 operation.
These are the only SONIC-16 registers the user needs to
access.

Figure 4-3

shows the programmer’s model and Ta-

ble 4-1 lists the attributes of each register.

Internal Use Registers: These registers (Table 4-2) are
used by the SONIC-16 during normal operation and are not
intended to be accessed by the user.

National Factory Test Registers: These registers (Table
4-3) are for National factory use only and should never be
accessed by the user. Accessing these registers during nor­mal operation can cause improper functioning of the
SONIC-16.

4.1 THE CAM UNIT

The CAM unit memory cells are indirectly accessed by pro­gramming the CAM descriptor area in system memory and
issuing the LCAM command (setting the LCAM bit in the
Control register). The CAM cells do not occupy address lo­cations in register space and, thus, are not accessible
through the RA5–RA0 address pins. The CAM control regis­ters, however, are part of the user register set and must be
initialized before issuing the LCAM command (see Section

4.3.10).

The Content Addressable Memory (CAM) consists of six­teen 48-bit entries for complete address filtering

(Figure 4-1)

of network packets. Each entry corresponds to a 48-bit des­tination address that is user programmable and can contain
any combination of Multicast or Physical addresses. Each
entry is partitioned into three 16-bit CAM cells accessible
through CAM Address Ports (CAP 2, CAP 1 and CAP 0) with
CAP0 corresponding to the least significant 16 bits of the
Destination Address and CAP2 corresponding to the most
significant bits. The CAM is accessed in a two step process.
First, the CAM Entry Pointer is loaded to point to one of the
16 entries. Then, each of the CAM Address Ports is ac­cessed to select the CAM cell. The 16 user programmable
CAM entries can be masked out with the CAM Enable regis­ter (see section 4.3.10).

Note: It is not necessary to program a broadcast address into the CAM

when it is desired to accept broadcast packets. Instead, to accept
broadcast packets, set the BRD bit in the Receive Control register. If
the BRD bit has been set, the CAM is still active. This means that it is
possible to accept broadcast packets at the same time as accepting
packets that match physical addresses in the CAM.

4.1.1 The Load CAM Command

Because the SONIC-16 uses the CAM for a relatively long
period of time during reception, it can only be written to via
the CAM Descriptor Area (CDA) and is only readable when

22

4.0 SONIC-16 Registers (Continued)

FIGURE 4-1. CAM Organization

the SONIC-16 is in software reset. The CDA resides in the
same 64k byte block of memory as the Receive Resource
Area (RRA) and contains descriptors for loading the CAM
registers. These descriptors are contiguous and each de­scriptor consists of four 16-bit fields
field contains the value to be loaded into the CAM Entry
Pointer and the remaining fields are for the three CAM Ad­dress Ports (see Section 4.3.10). In addition, there is one
more field after the last descriptor containing the mask for
the CAM Enable register. Each of the CAM descriptors are
addressed by the CAM Descriptor Pointer (CDP) register.

After the system has initialized the CDA, it can issue the
Load CAM command to program the SONIC-16 to read the
CDA and load the CAM. The procedure for issuing the Load
CAM command is as follows.

1. Initialize the Upper Receive Resource Address (URRA)
register. Note that the CAM Descriptor Area must reside
within the same 64k page as the Receive Resource
Area. (See Section 4.3.9).

(Figure 4-2).

The first

TL/F/11722– 21

2. Initialize the CDA as described above.

3. Initialize the CAM Descriptor Count with the number of
CAM descriptors. Note, only the lower 5 bits are used in
this register. The other bits are don’t cares. (See Section

4.3.10).

4. Initialize the CAM Descriptor Pointer to locate the first
descriptor in the CDA. This register must be reloaded
each time a new Load CAM command is issued.

5. Issue the Load CAM command (LCAM) in the Command
register. (See Section 4.3.1).

If a transmission or reception is in progress, the CAM DMA
function will not occur until these operations are complete.
When the SONIC-16 completes the Load CAM command,
the CDP register points to the next location after the CAM
Enable field and the CDC equals zero. The SONIC-16 resets
the LCAM bit in the Command register and sets the Load
CAM Done (LCD) bit in the ISR.

FIGURE 4-2. CAM Descriptor Area Format

23

TL/F/11722– 22

4.0 SONIC-16 Registers (Continued)

k

l

5:0

RA

0h Command Register Status and Control Fields

1 Data Configuration Register Control Fields

Status and

Control Registers

Transmit

Registers

Receive

Registers

CAM

Registers

2 Receive Control Register Status and Control Fields

3 Transmit Control Register Status and Control Fields

4 Interrupt Mask Register Mask Fields

5 Interrupt Status Register Status Fields

$

3F Data Configuration Register 2 Control Fields

6 Upper Transmit Descriptor Address Register Upper 16-bit Address Base

7 Current Transmit Descriptor Address Register Lower 16-bit Address Offset

Ð

0D Upper Receive Descriptor Address Register Upper 16-bit Address Base

0E Current Receive Descriptor Address Register Lower 16-bit Address Offset

14 Upper Receive Resource Address Register Upper 16-bit Address Base

15 Resource Start Address Register Lower 16-bit Address Offset

16 Resource End Address Register Lower 16-bit Address Offset

17 Resource Read Register Lower 16-Bit Address Offset

18 Resource Write Register Lower 16-bit Address Offset

2B Receive Sequence Counter Count Value 8 7 Count Value

$

21 CAM Entry Pointer Pointer

22 CAM Address Port 2 Most Significant 16 bits of CAM Entry

23 CAM Address Port 1 Middle 16 bits of CAM Entry

24 CAM Address Port 0 Least Significant 16 bits of CAM Entry

25 CAM Enable Register Mask Fields

26 CAM Descriptor Pointer Lower 16-bit Address Offset

$27 CAM Descriptor Count Count Value

Tally

Counters

Watchdog

Timer

2C CRC Error Tally Counter Count Value

2D Frame Alignment Error Tally Count Value

)

2E Missed Packet Tally Count Value

29 Watchdog Timer 0 Lower 16-bit Count Value

2A Watchdog Timer 1 Upper 16-bit Count Value

Ð

28 Silicon Revision Register Chip Revision Number

FIGURE 4-3. Register Programming Model

15 0

4

5

24

4.0 SONIC-16 Registers (Continued)

4.2 STATUS/CONTROL REGISTERS

This set of registers is used to convey status/control infor­mation to/from the host system and to control the operation
of the SONIC-16. These registers are used for loading com­mands generated from the system, indicating transmit and
receive status, buffering data to/from memory, and provid-

TABLE 4-1. User Registers

RA5–RA0 Access Register Symbol

COMMAND AND STATUS REGISTERS

00h R/W Command CR 4.3.1

01 (Note 3) R/W Data Configuration DCR 4.3.2

02 R/W Receive Control RCR 4.3.3

03 R/W Transmit Control TCR 4.3.4

04 R/W Interrupt Mask IMR 4.3.5

05 R/W Interrupt Status ISR 4.3.6

3F (Note 3) R/W Data Configuration 2 DCR2 4.3.7

TRANSMIT REGISTERS

06 R/W Upper Transmit Descriptor Address UTDA 4.3.8, 3.4.4.1

07 R/W Current Transmit Descriptor Address CTDA 4.3.8, 3.5.3

RECEIVE REGISTERS

0D R/W Upper Receive Descriptor Address URDA 4.3.9, 3.4.4.1

0E R/W Current Receive Descriptor Address CRDA 4.3.9, 3.4.4.3

13 R/W End of Buffer Word Count EOBC 4.3.9, 3.4.2

14 R/W Upper Receive Resource Address URRA 4.3.9, 3.4.4.1

15 R/W Resource Start Address RSA 4.3.9, 3.4.1

16 R/W Resource End Address REA 4.3.9, 3.4.1

17 R/W Resource Read Pointer RRP 4.3.9, 3.4.1

18 R/W Resource Write Pointer RWP 4.3.9, 3.4.1

2B R/W Receive Sequence Counter RSC 4.3.9, 3.4.3.2

CAM REGISTERS

21 R/W CAM Entry Pointer CEP 4.1, 4.3.10

22 (Note 1) R CAM Address Port 2 CAP2 4.1, 4.3.10

23 (Note 1) R CAM Address Port 1 CAP1 4.1, 4.3.10

24 (Note 1) R CAM Address Port 0 CAP0 4.1, 4.3.10

25 (Note 2) R/W CAM Enable CE 4.1, 4.3.10

26 R/W CAM Descriptor Pointer CDP 4.1, 4.3.10

27 R/W CAM Descriptor Count CDC 4.1, 4.3.10

TALLY COUNTERS

2C (Note 4) R/W CRC Error Tally CRCT 4.3.11

2D (Note 4) R/W FAE Tally FAET 4.3.11

2E (Note 4) R/W Missed Packet Tally MPT 4.3.11

ing interrupt control. The registers are selected by asserting
chip select to the SONIC-16 and providing the necessary
address on register address pins RA5–RA0. Tables 4-1,
4-2, and 4-3 show the locations of all SONIC-16 registers
and where information on the registers can be found in the
data sheet.

Description

(section)

25

4.0 SONIC-16 Registers (Continued)

TABLE 4-1. User Registers (Continued)

RA5–RA0 Access Register Symbol

WATCHDOG COUNTERS

29 R/W Watchdog Timer 0 WT0 4.3.12

2A R/W Watchdog Timer 1 WT1 4.3.12

SILICON REVISION

28 R Silicon Revision SR 4.3.13

Note 1: These registers can only be read when the SONIC-16 is in reset mode (RST bit in the CR is set). The SONIC-16 gives invalid data when these registers are
read in non-reset mode.

Note 2: This register can only be written to when the SONIC-16 is in reset mode. This register is normally only loaded by the Load CAM command.

Note 3: The Data Configuration registers, DCR and DCR2, can only be written to when the SONIC-16 is in reset mode (RST bit in CR is set). Writing to these

registers while not in reset mode does not alter the registers.

Note 4: The data written to these registers is inverted before being latched. That is, if a value of FFFFh is written, these registers will contain and read back the
value of 0000h. Data is not inverted during a read operation.

TABLE 4-2. Internal Use Registers (Users should not write to these registers)

(RA5–RA0) Access Register Symbol

TRANSMIT REGISTERS

08 (Note 1) R/W Transmit Packet Size TPS 3.5

09 R/W Transmit Fragment Count TFC 3.5

0A R/W Transmit Start Address 0 TSA0 3.5

0B R/W Transmit Start Address 1 TSA1 3.5

0C (Note 2) R/W Transmit Fragment Size TFS 3.5

20 R/W Temporary Transmit Descriptor Address TTDA 3.5.4

2F R Maximum Deferral Timer MDT 4.3.4

RECEIVE REGISTERS

0F R/W Current Receive Buffer Address 0 CRBA0 3.4.2, 3.4.4.2

10 R/W Current Receive Buffer Address 1 CRBA1 3.4.2, 3.4.4.2

11 R/W Remaining Buffer Word Count 0 RBWC0 3.4.2, 3.4.4.2

12 R/W Remaining Buffer Word Count 1 RBWC1 3.4.2, 3.4.4.2

19 R/W Temporary Receive Buffer Address 0 TRBA0 3.4.6.2

1A R/W Temporary Receive Buffer Address 1 TRBA1 3.4.6.2

1B R/W Temporary Buffer Word Count 0 TBWC0 3.4.6.2

1C R/W Temporary Buffer Word Count 1 TBWC1 3.4.6.2

1F R/W Last Link Field Address LLFA none

ADDRESS GENERATORS

1D R/W Address Generator 0 ADDR0 none

1E R/W Address Generator 1 ADDR1 none

Note 1: The data that is read from these registers is the inversion of what has been written to them.

Note 2: The value that is written to this register is shifted once.

TABLE 4-3. National Factory Test Registers

(RA5–RA0) Access Register Symbol

30 These registers are for factory use only. Users must not

#

R/W address these registers or improper SONIC-16 operation none none

3E can occur.

Description

(section)

Description

(section)

Description

(section)

26

4.0 SONIC-16 Registers (Continued)

4.3 REGISTER DESCRIPTION

4.3.1 Command Register

k

l

(RA

This register
sponding bits for the function. For all bits, except for the RST bit, the SONIC-16 resets the bit after the command is completed.
With the exception of RST, writing a ‘‘0’’ to any bit has no effect. Before any commands can be issued, the RST bit must first be
reset to ‘‘0’’. This means that, if the RST bit is set, two writes to the Command Register are required to issue a command to the
SONIC-16; one to clear the RST bit, and one to issue the command.

This register also controls the general purpose 32-bit Watchdog Timer. After the Watchdog Timer register has been loaded, it
begins to decrement once the ST bit has been set to ‘‘1’’. An interrupt is issued when the count reaches zero if the Timer
Complete interrupt is enabled in the IMR.

During hardware reset, bits 7, 4, and 2 are set to a ‘‘1’’; all others are cleared. During software reset bits 9, 8, 1, and 0 are
cleared and bits 7 and 2 are set to a ‘‘1’’; all others are unaffected.

e

5:0

0h)

(Figure 4-4

) is used for issuing commands to the SONIC-16. These commands are issued by setting the corre-

15141312111098765432 10

000000LCAM RRRA RST 0 ST STP RXEN RXDIS TXP HTX

r/w r/w r/w r/w r/w r/w r/w r/w r/w

reread only, r/weread/write

FIGURE 4-4. Command Register

Field Meaning

LCAM LOAD CAM
RRRA READ RRA
RST SOFTWARE RESET
ST START TIMER
STP STOP TIMER
RXEN RECEIVER ENABLE
RXDIS RECEIVER DISABLE
TXP TRANSMIT PACKET(S)
HTX HALT TRANSMISSION

Bit Description

15–10 Must be 0

9 LCAM: LOAD CAM

Setting this bit causes the SONIC-16 to load the CAM with the descriptor that is pointed to by the CAM Descriptor
Pointer register.

Note: This bit must not be set during transmission (TXP is set). The SONIC-16 will lock up if both bits are set simultaneously.

8 RRRA: READ RRA

Setting this bit causes the SONIC-16 to read the next RRA descriptor pointed to by the Resource Read Pointer
(RRP) register. Generally this bit is only set during initialization. Setting this bit during normal operation can cause
improper receive operation.

7 RST: SOFTWARE RESET

Setting this bit resets all internal state machines. The CRC generator is disabled and the Tally counters are halted,
but not cleared. The SONIC-16 becomes operational when this bit is reset to ‘‘0’’. A hardware reset sets this bit to a
‘‘1’’. It must be reset to ‘‘0’’ before the SONIC-16 becomes operational.

6 Must be 0.

5 ST: START TIMER

Setting this bit enables the general-purpose watchdog timer to begin counting or to resume counting after it has
been halted. This bit is reset when the timer is halted (i.e., STP is set). Setting this bit resets STP.

4 STP: STOP TIMER

Setting this bit halts the general-purpose watchdog timer and resets the ST bit. The timer resumes when the ST bit is
set. This bit powers up as a ‘‘1’’. Note: Simultaneously setting bits ST and STP stops the timer.

27

4.0 SONIC-16 Registers (Continued)

4.3 REGISTER DESCRIPTION

4.3.1 Command Register (Continued)

k

l

(RA

Bit Description

3 RXEN: RECEIVER ENABLE

2 RXDIS: RECEIVER DISABLE

1 TXP: TRANSMIT PACKET(S)

0 HTX: HALT TRANSMISSION

e

5:0

0h)

Setting this bit enables the receive buffer management engine to begin buffering data to memory. Setting this bit
resets the RXDIS bit. Note: If this bit is set while the MAC unit is currently receiving a packet, both RXEN and RXDIS
are set until the network goes inactive (i.e., the SONIC-16 will not start buffering in the middle of a packet being
received).

Setting this bit disables the receiver from buffering data to memory or the Receive FIFO. If this bit is set during the
reception of a packet, the receiver is disabled only after the packet is processed. The RXEN bit is reset when the
receiver is disabled. Tally counters remain active regardless of the state of this bit. Note: If this bit is set while the
SONIC-16 is currently receiving a packet, both RXEN and RXDIS are set until the packet is fully received.

Setting this bit causes the SONIC-16 to transmit packets which have been set up in the Transmit Descriptor Area
(TDA). The SONIC-16 loads its appropriate registers from the TDA, then begins transmission. The SONIC-16 clears
this bit after any of the following conditions have occurred: (1) transmission had completed (i.e., after the SONIC-16
has detected EOL
has occurred. This condition occurs when any of the following bits in the TCR have been set: EXC, EXD, FU, or BCM.

Note: This bit must not be set if a Load CAM operation is in progress (LCAM is set). The SONIC-16 will lock up if
both bits are set simultaneously.

Setting this bit halts the transmit command after the current transmission has completed. TXP is reset after
transmission has halted. The Current Transmit Descriptor Address (CTDA) register points to the last descriptor
transmitted. The SONIC-16 samples this bit after writing to the TXpkt.status field.

e

1), (2) the Halt Transmission command (HTX) has taken effect, or (3) a transmit abort condition

28

4.0 SONIC-16 Registers (Continued)

4.3.2 Data Configuration Register

k

l

(RA

This register

During a hardware reset, bits 15 and 13 are cleared; all other bits are unaffected. (Because of this, the first thing the driver
software does to the SONIC-16 should be to set up this register.) All bits are unaffected by a software reset. This register must
only be accessed when the SONIC-16 is in reset mode (i.e., the RST bit is set in the Command register).

Bit Description

15 EXBUS: EXTENDED BUS MODE

14 Must be 0.

13 LBR: LATCHED BUS RETRY

12, 11 PO1, PO0: PROGRAMMABLE OUTPUTS

e

5:0

1h)

(Figure 4-5)

establishes the bus cycle options for reading/writing data to/from 16- or 32-bit memory systems.

1514131211109876543210

EXBUS 0 LBR PO1 PO0 SBUS USR1 USR0 WC1 WC0 0 BMS RFT1 RFT0 TFT1 TFT0

r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w r/w

r/weread/write

FIGURE 4-5. Data Configuration Register

Field Meaning

EXBUS EXTENDED BUS MODE
LBR LATCHED BUS RETRY
PO0,PO1 PROGRAMMABLE OUTPUTS
SBUS SYNCHRONOUS BUS MODE
USR0, USR1 USER DEFINABLE PINS
WC0, WC1 WAIT STATE CONTROL
DW DATA WIDTH SELECT
BMS BLOCK MODE SELECT FOR DMA
RFT0, RFT1 RECEIVE FIFO THRESHOLD
TFT0, TFT1 TRANSMIT FIFO THRESHOLD

Setting this bit enables the Extended Bus mode which enables the following:

1) Extended Programmable Outputs, EXUSR
external ENDEC interface into four programmable user outputs, EXUSR

k

USR

1:0l. These outputs are programed with bits 15-12 in the DCR2 (see Section 4.3.7). On hardware reset,

these four pins will be TRI-STATE

k

3:0l: This changes the TXD, LBK, RXC and RXD pins from the

and will remain that way until the DCR is changed. If EXBUS is enabled, then

É

k

3:0lrespectively, which are similar to

these pins will remain TRI-STATE until the SONIC-16 becomes a bus master, at which time they will be driven
according to the DCR2. If EXBUS is disabled, then these four pins work normally as external ENDEC interface pins.

2) Synchronous Termination, STERM
synchronous memory termination input for compatibility with Motorola style processors. This input is only useful
when Asynchronous Bus mode is selected (bit 10 below is set to ‘‘0’’) and BMODE

: This changes the TXC pin from the External ENDEC interface into a

e

1 (Motorola mode). On
hardware reset, this pin will be TRI-STATE and will remain that way until the DCR is changed. If EXBUS is enabled,
this pin will remain TRI-STATE until the SONIC-16 becomes a bus master, at which time it will become the STERM
input. If EXBUS is disabled, then this pin works normally as the TXC pin for the external ENDEC interface.

3) Asynchronous Bus Retry: Causes BRT

to be clocked in asynchronously off the falling edge of bus clock. This only
applies, however, when the SONIC-16 is operating in asynchronous mode (bit 10 below is set to ‘‘0’’). If EXBUS is
not set, BRT

The LBR bit controls the mode of operation of the BRT

is sampled synchronously off the rising edge of bus clock. (See Section 5.4.6.)

signal (see pin description). It allows the BUS Retry operation
to be latched or unlatched.
0: Unlatched mode: The assertion of BRT

The SONIC-16 will retry the operation when BRT

forces the SONIC-16 to finish the current DMA operation and get off the bus.

is deserted.

1: Latched mode: The assertion of BRT forces the SONIC-16 to finish the current DMA operation as above, however,

the SONIC-16 will not retry until BRT

is deasserted and the BR bit in the ISR (see Section 4.3.6) has been reset.

Hence, the mode has been latched on until the BR bit is cleared.

Note: Unless LBR is set to a ‘‘1’’, BRT must remain asserted at least until the SONIC-16 has gone idle. See Section 5.4.6 and the timing for Bus

Retry in Section 7.0.

The PO1,PO0 bits individually control the USR1,0 pins respectively when SONIC-16 is a bus master (HLDA or
BGACK

is active). When PO1/PO0 are set to a 1 the USR1/USR0 pins are high during bus master operations and

when these bits are set to a 0 the USR1/USR0 pins are low during bus master operations.

29