NSC DP83932CVF-33, DP83932CVF-25, DP83932CVF-20 Datasheet

July 1995
DP83932C-20/25/33 MHz SONIC Systems-Oriented Network Interface Controller
DP83932C-20/25/33 MHz SONIC
TM
Systems-Oriented Network Interface Controller
General Description
The SONIC (Systems-Oriented Network Interface Control­ler) is a second-generation Ethernet Controller designed to meet the demands of today’s high-speed 32- and 16-bit sys­tems. Its system interface operates with a high speed DMA that typically consumes less than 3% of the bus bandwidth (25 MHz bus clock). Selectable bus modes provide both big and little endian byte ordering and a clean interface to stan­dard microprocessors. The linked-list buffer management system of SONIC offers maximum flexibility in a variety of environments from PC-oriented adapters to high-speed motherboard designs. Furthermore, the SONIC integrates a fully-compatible IEEE 802.3 Encoder/Decoder (ENDEC) al­lowing for a simple 2-chip solution for Ethernet when the SONIC is paired with the DP8392 Coaxial Transceiver Inter­face or a 10BASE-T transceiver.
For increased performance, the SONIC 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 stores packets in the buffer area, then indicates receive status and control information in the descriptor area. The system allo­cates more memory resources to the SONIC by adding de­scriptors to the memory resource area. The transmit buffer
management uses two areas in memory: one for indicating status and control information and the other for fetching packet data. The system can create a transmit queue allow­ing multiple packets to be transmitted from a single transmit command. The packet data can reside on any arbitrary byte boundary and can exist in several non-contiguous locations.
Features
Y
32-bit non-multiplexed address and 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 802.3 layer management standard
Y
Integrated support for bridge and repeater applications
System Diagram
TL/F/10492– 2
TRI-STATEÉis a registered trademark of National Semiconductor Corporation.
TM
SONIC
is a trademark of National Semiconductor Corporation.
C
1995 National Semiconductor Corporation RRD-B30M105/Printed in U. S. A.
TL/F/10492
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 Data Width and 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 Addresses
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 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
6.1.4 Power Supply Considerations
7.0 AC AND DC SPECIFICATIONS
8.0 AC TIMING TEST CONDITIONS
2
1.0 Functional Description
The SONIC (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 is highly pipelined providing maxi­mum system level performance. This section provides a functional overview of SONIC.
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 are identical to the DP83910A CMOS Serial Network Interface device. Dur­ing 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. The signals provided to the MAC unit from the on-chip ENDEC are also provided as outputs to the user.
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 ENDEC unit. Once the bit stream is encoded, it is transmit­ted 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 ENDEC’s receive differential pair. The MAC unit is also pro­vided with a collision detection signal (COL) that informs the MAC unit that a collision is taking place somewhere on
(Figure 1-2 )
is to
FIGURE 1-1. SONIC Block Diagram
3
TL/F/10492– 1
1.0 Functional Description (Continued)
TL/F/10492– 3
FIGURE 1-2. Block Diagram of Ethernet ENDEC
4
1.0 Functional Description (Continued)
the network. The ENDEC section detects this when its colli­sion receiver detects a 10 MHz signal on the differential collision input pair. The ENDEC also provides both the re­ceive 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.
Loopback Functions: The SONIC provides three loopback 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 is trans­mitting, the transmitted packet will always be looped back by the external transceiver. The SONIC takes advantage of this to monitor the transmitted packet. See the explanation of the Receive State Machine in Section 1.2.1 for more in­formation about monitoring transmitted packets.
1.1.2 Selecting An External ENDEC
802.3 ENDEC can be bypassed by connecting the EXT pin to V
(EXTe1). In this mode the MAC signals are redirect-
CC
ed, 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 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 one byte SFD (Start of Frame Delimiter) pattern (Section
2.1) consisting of a ‘‘10101011’’ sequence. It then frames the incoming bits into octet boundaries and transfers the
(Figure 1-3 )
controls the MAC receive
data to the 32-byte receive FIFO. Concurrently the address comparator compares the Destination Address Field to the addresses stored in the chip’s CAM address registers (Con­tent Addressable Memory cells). If a match occurs, the de­serializer 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 could buffer the data to memory.
Ð 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 has been told to reject packets 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/10492– 4
1.0 Functional Description (Continued)
During transmission of a packet from the SONIC, the exter­nal transceiver will always loop the packet back to the SONIC. The SONIC 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, PMB, in the Transmit Control Register, Sec­tion 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).
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 Sec­tion 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.
Protocol State Machine: The protocol state machine as­sures that the SONIC obeys the CSMA/CD protocol. Before transmitting, this state machine monitors the carrier sense and collision signals for network activity. If another node(s) is currently transmitting, the SONIC defers until the network is quiet, then transmits after its Interframe Gap Timer (9.6 ms) has expired. The Interframe Gap time is divided into two portions. During the first 6.4 ms, network activity restarts the Interframe Gap timer. Beyond this time, however, net­work activity is ignored and the state machine waits the re­maining 3.2 ms before transmitting. If the SONIC experi­ences a collision during a transmission, the SONIC switches from transmitting data to a 4-byte JAM pattern (4 bytes of all 1’s), before ceasing to transmit. The SONIC then waits a random number of slot times (51.2 ms) determined by the
Truncated Binary Exponential Backoff Algorithm
reattempting another transmission. In this algorithm, the number of slot times to delay before the nth retransmission is chosen to be a random integer r in the range of:
where kemin(n,10)
If a collision occurs on the 16th transmit attempt, the SONIC aborts transmitting the packet and reports an ‘‘Excessive Collisions’’ error in the Transmit Control register.
0
srs
k
2
before
FIGURE 1-4. MAC Transmitter
6
TL/F/10492– 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 7 byte alternating ‘‘1,0’’ pattern and a 1 byte ‘‘10101011’’ SFD pattern 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 collision. 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).
For bridging or switched ethernet applications the CRC Generator can be inhibited by setting bit 13 in the Transmit Control Register (Section 4.3.4). This feature is used when an ethernet segment has already received a packet with a CRC appended and needs to forward it to another ethernet segment.
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 stops transmitting data and enables the Jam generator. If a colli­sion occurs during the preamble, the SONIC finishes trans­mitting the preamble before enabling the Jam generator (see Preamble Generator above).
1.3 DATA WIDTH AND BYTE ORDERING
The SONIC can be programmed to operate with either 32-bit or 16-bit wide memory. The data width is configured during initialization by programming the DW bit in the Data Configuration Register (DCR, Section 4.3.2). If the 16-bit data path is selected, data is driven on pins D15–D0. The SONIC also 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 below.
Little Endian mode (National/Intel, BMODE
byte orientation for received and transmitted data in the Re­ceive Buffer Area (RBA) and Transmit Buffer Area (TBA) of system memory is as follows:
16-Bit Word
15 8 7 0
Byte 1 Byte 0
MSB LSB
32-Bit Long Word
31 24 23 16 15 8 7 0
Byte 3 Byte 2 Byte 1 Byte 0
MSB LSB
Big Endian mode (Motorola, BMODE
entation for received and transmitted data in the RBA and TBA is as follows:
16-Bit Word
15 8 7 0
Byte 0 Byte 1
LSB MSB
32-Bit Long Word
31 24 23 16 15 8 7 0
Byte 0 Byte 1 Byte 2 Byte 3
LSB MSB
e
e
1): The byte ori-
0): The
FIGURE 1-5. Receive FIFO
7
TL/F/10492– 6
1.0 Functional Description (Continued)
1.4 FIFO AND CONTROL LOGIC
The SONIC incorporates two independent 32-byte FIFOs for transferring data to/from the system interface and from/ to the network. The FIFOs, providing temporary storage of data, free the host system from the real-time demands 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 de­termine how full or empty the FIFOs can be before the SONIC 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 will always transfer 4 words from the receive FIFO to memory. If empty/fill mode is set, however, 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 reception 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/32-bit system inter­face. The FIFO is arranged as a 4-byte wide by 8 deep memory array (8 long words, or 32 bytes) controlled by three sections of logic. During reception, the Byte Ordering logic directs 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 sig­nificant byte first or most significant byte first to accommo­date 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- or 32-bit words (depending upon the selected data width) from the FIFO and transfers them to the system interface (the sys­tem 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 in 16-bit mode or reads the complete long word (32 bits) in 32-bit mode. If, after the transfer is complete, the number of bytes in the FIFO is less then the threshold, then the SONIC is done. This is always the case when the SONIC 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 is in block mode.
When in block mode, each time the SONIC requests the bus, only a number of bytes equal to the threshold value will be transferred. The Threshold Logic continues to monitor
serves as a buffer between the 8-bit net-
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 (16-bit mode) or long word (32-bit mode) if the last byte did not end on a word or long word boundary respectively. The fill byte will be 0FFh. Immediate­ly after the last byte (or fill byte) in the FIFO, the received packets status will be written into the FIFO. The entire pack­et, including any fill bytes and the received packet status will be buffered to memory. When a packet is buffered to mem­ory by the Buffer Management Engine, it is always taken from the FIFO in words or long words and buffered to mem­ory on word (16-bit mode) or long word (32-bit mode) boundaries. Data from a packet cannot be buffered on odd byte boundaries for 16-bit mode, and odd word boundaries for 32-bit mode (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/32-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 En­gine fetches a programmed number of 16- or 32-bit words from memory and transfers them to the FIFO. The Buffer Management Engine writes either the upper or lower half (16 bits) into the FIFO for 16-bit mode or writes the com­plete long word (32 bits) during 32-bit mode.
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.
8
(Figure 1-6 )
1.0 Functional Description (Continued)
FIGURE 1-6. Transmit FIFO
1.5 STATUS AND CONFIGURATION REGISTERS
The SONIC contains a set of status/control registers for conveying status and control information to/from the host system. The SONIC uses these registers for loading com­mands generated from the system, indicating transmit and receive status, buffering data to/from memory, and provid­ing 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
5.0 for a complete description of the SONIC bus interface.
1.7 LOOPBACK AND DIAGNOSTICS
The SONIC furnishes three loopback modes for self-testing from the controller interface to the transceiver interface. The loopback function is provided to allow self-testing of the chip’s internal transmit and receive operations. During loop­back, transmitted packets are routed back to the receive section of the SONIC where they are filtered by the address recognition logic and buffered to memory if accepted. 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
(Figure 1-7 )
consists of the pins nec-
Figure 1-7
. See Section
TL/F/10492– 7
internal ENDEC or TXC for an external ENDEC) must be driven. Network activity, such as a collision, does not affect 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.
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’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 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 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 provides three tally counters to tabulate CRC errors, Frame Alignment errors, and missed packets. Table 1-1 shows the statistics indicated by the SONIC.
*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/10492– 8
FIGURE 1-7. SONIC Bus 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).
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 generates and appends the preamble, SFD and FCS field during trans­mission. 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/10492– 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: 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 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 packets 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 also provides a promiscuous mode which al­lows 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’s trans­mit buffer from the system software. During transmission, the SONIC 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 trans­mitted does not match a value in the CAM, the packet moni­tored 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 does not provide Source Address insertion. Howev­er, a transmit descriptor fragment, containing only the Source Address, may be created for each packet. (See Sec­tion 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 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 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 can transmit and receive packets up to 64k bytes in length.
2.6 FCS FIELD
generator. The AUTODIN II (X
16
12
a
X
1
a
X
11
a
X
a
X
1) polynomial is used for the CRC calculations. The SONIC may optionally append the CRC sequence during transmission, and checks the CRC both during normal re­ception and self-reception during a transmission (see Sec­tion 1.2.1).
2.7 MAC (MEDIA ACCESS CONTROL) CONFORMANCE
The SONIC is designed to be compliant to the IEEE 802.3 MAC Conformance specification. The SONIC implements most MAC functions in silicon and provides hooks for the user software to handle the remaining functions. The MAC Conformance specifications are summarized 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 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 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 does not provide Pad generation; 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 Section
3.5.1.
12
32
26
23
a
a
10
a
X
X
8
7
a
X
5
a
X
X
22
a
X
a
a
X
4
2
a
a
X
X
Support By
User Driver
SONIC
Software
Notes
X
X
Ð
3.0 Buffer Management
3.1 BUFFER MANAGEMENT OVERVIEW
The SONIC’s buffer management scheme is based on sep­arate buffers and descriptors ( ets that are received or transmitted are placed in buffers called the Receive Buffer Area (RBA) and the Transmit Buff­er Area (TBA). The system keeps track of packets in these buffers using the information in the Receive Descriptor 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 Re­ceive Resource Area (RRA), which is another form of de­scriptor, 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 TBA, however, may be made up of several fragments of data dispersed in memory. There is one TDA pointing to each TBA which specifies information about the buffer’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 to transmit the packets by passing the first TDA to the SONIC and issuing the trans­mit command.
3.2 DESCRIPTOR AREAS
Descriptors are the basis of the buffer management scheme used by the SONIC. A RDA points to a received packet within a RBA, 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
]
). Pack-
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.
TL/F/10492– 86
3.2.2 Abbreviations
The abbreviations in Table 3.1 are used to describe the SONIC 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 uses three areas in memory to store descriptor information: the Transmit Descriptor Area (TDA), Receive Descriptor Area (RDA), and the Receive Resource Area (RRA). The SONIC accesses these areas by concatenating a 16-bit base address register with a 16-bit offset register. The base address register supplies a fixed upper 16 bits of address and the offset registers provide the lower 16 bits of address. The base address registers are the Upper Trans­mit Descriptor Address (UTDA), Upper Receive Descriptor Address (URDA), and the Upper Receive Resource Address (URRA) registers. The corresponding offset registers are shown below.
Upper Address Registers Offset Registers
See Table 3-1 for definition of register mnemonics.
Figure 3-1
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 Pointers
14
TL/F/10492– 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 word boundaries (A1,A0 ceive Buffer Area (RBA) must also be aligned to a word boundary in 16-bit mode and a long word boundary in 32-bit mode. The fragments in the Transmit Buffer Area (TBA), however, may be aligned on any arbitrary byte boundary.
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 re­ceiver (setting the RXEN bit in the Command register). The receive resource area (RRA) contains descriptors that lo­cate receive buffer areas in system memory. These descrip­tors are denoted by R1, R2, etc. in noted by P1, P2, etc.) can then be buffered into the corre­sponding 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 packet (D1 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 buffers the packet contiguously into the selected Receive Buffer Area (RBA). Because of the previous end-of-packet processing, the SONIC assures that the complete packet is written into a single contiguous block. When the packet ends, the SONIC writes the receive status, byte count, and location of the packet into the Receive Descriptor Area (RDA). The SONIC then updates its pointers to locate the next available de­scriptor and checks the remaining words available in the RBA. If sufficient space remains, the SONIC buffers the next packet immediately after the previous packet. If the current buffer is out of space the SONIC fetches a Re­source descriptor from the Receive Resource Area (RRA) acquiring an additional buffer that has been previously allo­cated by the system.
Figure 3-2
e
0) for 16-bit memory and to long
e
0,0) for 32-bit memory. The Re-
(Figure 3-2 )
) corresponding to each received
. These three areas
Figure 3-2
. Packets (de-
3.4.1 Receive Resource Area (RRA)
As buffer memory is consumed by the SONIC for storing data, the Receive Resource Area (RRA) provides a mecha­nism that allows the system to allocate additional buffer space for the SONIC. The system loads this area with re­source descriptors that the SONIC, in turn, reads as its cur­rent buffer space is used up. Each resource descriptor con­sists of a 32-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 16-bit fields. The SONIC stores this information internally and concatenates the corresponding fields to create 32-bit long words for the buffer pointer and word count. Note that in 32-bit mode the upper word (D the SONIC. This area may be used for other purposes since the SONIC never writes into the RRA.
The SONIC organizes the RRA as a circular queue for effi­cient 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 reads the next descriptor designated by the Resource Read Pointer (RRP). The RRP is advanced 4 words in 16-bit mode (4 long words in 32-bit mode) after the SONIC 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 regis­ters.
The alignment of the RRA is confined to either word or long word boundaries, depending upon the data width mode. In 16-bit mode, the RRA must be aligned to a word boundary (A0 is always zero) and in 32-bit mode, the RRA is aligned to a long word boundary (A0 and A1 are always zero).
Figure 3-3
with each component composed of
k
31:16l) is not used by
FIGURE 3-2. Overview of Receive Buffer Management
15
TL/F/10492– 11
3.0 Buffer Management (Continued)
3.4.2 Receive Buffer Area (RBA)
The SONIC stores the actual data of a received packet in the RBA. The RBAs are designated by the resource descrip­tors in the RRA as described above. The RXrsrc.buff wc0,1 fields of the RRA indicate the length of the RBA. When the SONIC gets a RBA from the RRA, the RXrsrc.buffÐwc0,1 values are loaded into the Remaining Buffer Word Count registers (RBWC0,1). These registers keep track of how much space (in words) is left in the buffer. When a packet is buffered in a RBA, it is buffered contigu­ously (the SONIC will not scatter a packet into multiple buff­ers 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 network), a new buffer must be acquired. The End of Buffer Count (EOBC) register is used to tell the SONIC the maximum packet size that the SONIC 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 will have to buffer. This word count creates a line in the RBA that, when crossed, causes the SONIC to fetch a new RBA resource from the RRA.
Note: The EOBC is a word count, not a byte count. Also, the value pro-
grammed into EOBC must be a double word (32-bit) quantity when the SONIC is in 32-bit mode (e.g. in 32-bit mode, EOBC should be set to 758 words, not 759 words even though the maximum size of an
Ð
IEEE 802.3 packet is 759 words).
3.4.2.2 Buffering the Last Packet in an RBA
At the start of reception, the SONIC stores the packet be­ginning at the Current Receive Buffer Address (CRBA0,1) and continues until the reception is complete. Concurrent with reception, the SONIC decrements the Remaining Buff­er Word Count (RBWC0,1) by one in 16-bit mode or by two in 32-bit mode. At the end of reception, if the packet has crossed the EOBC boundary, the SONIC knows that the next packet might not fit in the RBA. This check is done by comparing the RBWC0,1 registers with the EOBC. If RBWC0,1 is less than the EOBC (the last packet buffered has crossed the EOBC boundary), the SONIC 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.
Figure 3-4
t
illustrates the SONIC’s actions for (1) RBWC0,1
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 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 buffers next packet in same RBA. 2: SONIC 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/10492– 12
TL/F/10492– 13
3.0 Buffer Management (Continued)
3.4.3 Receive Descriptor Area (RDA)
After the SONIC buffers a packet to memory, it writes 6 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 descriptor. In 32-bit mode, the upper word, D memory should not be used for other purposes, since the SONIC may still write into these locations. Each receive de­scriptor consists of the following sections (
receive status: indicates status of the received packet. The SONIC writes the Receive Control register into this field.
Figure 3-6
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
byte count: gives the length of the complete packet from the start of Destination Address to the end of FCS.
packet pointer: a 32-bit pointer that locates the packet in the RBA. The SONIC 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 maintains a single RBA Sequence Number for all packets in an RBA and sequences the Packet Number for succeeding packets in the RBA. When the SONIC 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 Se­quence Numbers are shown in are reset during hardware reset or by writing zero to them.
k
31:16l, is not used. This unused area in
Figure 3-5
FIGURE 3-5. Receive Descriptor Format
TL/F/10492– 14
shows the receive status format. This field is
FIGURE 3-6. Receive Status Format
Figure 3-7
. These counters
).
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 to indicate the ownership of the de­scriptor. When the system avails a descriptor to the SONIC, it writes a non-zero value into this field. The SONIC, 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 releas­es control after writing the status and control information into the RDA. If, however, the SONIC 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 then relinquishes control after receiving the next packet. (See Section 3.4.6.1 for details on when the SONIC writes to this field). The receive 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 registers must be properly initialized before the SONIC begins buffer­ing packets. This section describes the initialization pro­cess.
3.4.4.1 Initializing The Descriptor Page
All descriptor areas (RRA, RDA, and TDA) used by the SONIC reside within areas up to 32k (word) or 16k (long word) pages. This page may be placed anywhere within the 32-bit address range by loading the upper 16 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 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 in 16-bit mode or 4 long words in 32-bit mode (
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 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 32-bit address.
Note that two restrictions apply to the Buffer Pointer and Word Count. First, in 32-bit mode, since the SONIC always writes long words, an even count must be written to RXrsrc.buffÐwc0. Second, the Buffer Pointer must either be pointing to a word boundary in 16-bit mode (A0 long word boundary in 32-bit mode (A0,A1 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
e
e
0) or a
0,0). Note also
the SONIC to begin receive processing at the first descrip­tor. An example of two descriptors linked together is shown in
Figure 3-9
played in bold type. The other fields are written by the SONIC after a packet is accepted. The RXpkt.inÐuse field is first written by the system, and then by the SONIC. Note that the descriptors must be aligned properly as discussed in Section 3.3. Also note that the URDA register is concate­nated with the CRDA register to generate the full 32-bit ad­dress.
. The fields initialized by the system are dis-
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 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
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. The system writes a non-zero value to this field when the de­scriptor is available, and the SONIC writes all ‘‘0’s’’ when it finishes using the descriptor. At startup, the Current Receive Descriptor Address (CRDA) register must be loaded with the address of the first RXpkt.status field in order for
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/10492– 15
FIGURE 3-9. RDA Initialization Example
TL/F/10492– 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 buffers the next packet into another RBA. This also guarantees that a pack­et is always contiguously buffered into a single Receive Buffer Area (RBA). The SONIC does not buffer a packet into multiple RBAs. Note that in 32-bit mode, the SONIC holds the LSB always low so that it properly compares with the RBWC0,1 registers.
After a hardware reset, the EOBC reset, the EOBC register is automatically initialized to 2F8h (760 words or 1520 bytes). For 32-bit applications this is the suggested value for EOBC. EOBC defaults to 760 words (1520 bytes) instead of 759 words (1518 bytes) because 1518 is not a double word (32-bit) boundary (see Section 3.4.2.1). If the SONIC is used in 16-bit mode, then EOBC should be set to 759 words (1518 bytes) because 1518 is a word (16-bit) boundary.
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 4 bytes, in 32-bit mode, or 2 bytes, in 16-bit mode, less than the buffer size. An example of this for 32-bit mode is to set EOBC to 760 words (1520 bytes)
18
3.0 Buffer Management (Continued)
and the buffer size to 762 words (1524 bytes). A similar example for 16-bit mode would be EOBC (1518 bytes) and the buffer size set to 760 words (1520 bytes). The buffer can be any size, but as long as the EOBC is 2 words, for 32-bit mode, or 1 word, for 16-bit mode, 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 760 words (1520 bytes) in 32-bit mode or 759 words (1518 bytes) in 16-bit mode. EOBC would be set to 758 words (1516 bytes) for both cases. With this configuration, any packet over 1520 bytes, in 32-bit mode, or 1518 bytes, in 16-bit mode, will not be completely buffered because the packet will overflow the buffer. When a packet overflow occurs, a Receive Buffer 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 per buffer.
Figure 3-10
shows this ‘‘range.’’
3.4.5 Beginning Of Reception
e
1, it recognizes that after the previous reception, there were no more remaining receive 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 still finds EOL es. (See Section 3.5 for adding descriptors to the list.) Oth­erwise, the SONIC 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 Remaining Buffer Word Count (RBWC0,1) registers are decremented 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 enters its end of pack­et processing sequence to determine whether to accept or reject the packet based on receive errors and packet size. At the end of reception the SONIC enters one of the follow­ing two sequences:
Ð Successful reception sequence
Ð Buffer recovery for runt packets or packets with errors
e
759 words
e
1, reception ceas-
3.4.6.1 Successful Reception
If the SONIC 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 also checks the EOL bit for a ‘‘1’’ in this field. If
e
EOL
1, no more descriptors are available for the SONIC. The SONIC 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 descriptors.) The SONIC maintains ownership of the descriptor by not writing to the RXpkt.inÐuse field. Otherwise, if EOL
e
0, the SONIC advances the CRDA register to the next descriptor and re­sets the RXpkt.inÐuse field to all ‘‘0’s’’.
The SONIC accesses the complete 7 word RDA descriptor in a single block operation.
The SONIC also checks if there is remaining space in the RBA. The SONIC 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 fetches a resource descriptor 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 recovers its pointers back to the original positions. The CRBA0,1 regis­ters are not advanced and the RBWC0,1 registers are not decremented. The SONIC recovers its pointers by maintain­ing a copy of the buffer address in the Temporary Receive Buffer Address registers (TRBA0,1). The SONIC recovers the value in the RBWC0,1 registers from the Temporary Buffer Word Count registers (TBWC0,1).
3.4.7 Overflow Conditions
When an overflow condition occurs, the SONIC halts its DMA operations to prevent writing into unauthorized memo­ry. The SONIC 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/10492– 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 has reached the last receive descriptor in the list, meaning that the SONIC has detected EOL must supply additional descriptors for continued reception. The system can do this in one of two ways: 1) appending 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 re-reads the last RXpkt.link field, and updates its CRDA register to point to the next de­scriptor.
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 maintains owner­ship of the descriptor (RXpkt.inÐuse the system to add additional descriptors to the list. When the system appends more descriptors, the SONIC releases ownership of the descriptor after writing 0000h to the RXpkt.inÐuse field.
Buffer Resources Exhausted: This occurs when the SONIC 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 SONIC finishes using the second to last receive buffer and reads the last RRA descriptor. Actually, the SONIC is not truly out of re­sources, but gives the system an early warning of an im­pending out of resources condition. To continue reception after the last RBA is used, the system must supply addition­al RRA descriptor(s), update the RWP register, and clear the RBE bit in the ISR. The SONIC 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 SONIC 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 Section 4.3.6). An RDA will not be set up for the truncated packet 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 system
e
0. At the next
i
00h) and waits for
and the Transmit Buffer Area (TBA). During transmission, the SONIC fetches control information from the TDA, loads its appropriate registers, and then transmits the data from the TBA. When the transmission is complete, the SONIC 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/10492– 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 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 to one of the various transmit modes. The SONIC reads this field and loads the corresponding configuration bits (PINT, POWC, CRCI, and EXDIS) into the Transmit Control regis­ter. (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 32-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 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 upper word, D
Figure 3-12.
k
31:16l, is not used.
Note that in 32-bit mode the
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 to be programmed into one of the transmit modes before each transmission. At the beginning of each transmission, the SONIC reads this field and loads the PINT, 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
4.3.4 for the description on the TCR.
15 14 13 12 11 10 9 8
PINT 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 writes the status bits ( the number of collisions experienced during the transmis­sion 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 32-bit address range, and be aligned to any byte boundary. When an odd byte boundary is given, the SONIC automatically begins reading data at the corresponding word boundary in 16-bit mode or a long word boundary in 32-bit mode. The SONIC ignores the extraneous bytes which are written into the FIFO during
FIGURE 3-13. TXpkt.config Field
k
10:0l) of the Transmit Control Register (TCR) and
76543210
FIGURE 3-14. TXpkt.status Field
Figure 3-13.
(Figure 3-14
TL/F/10492– 19
See Section
, resere-
odd byte alignment fragments. The minimum allowed frag­ment size is 1 byte. tween 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 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
e
EOL
1 and all other descriptors must have EOLe0. To begin transmission, the system loads the address of the first TXpkt.status field into the CTDA register. Note that the up­per 16-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
transmit descriptor
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 6.3.4).
3.5.3.1 Transmit Process
When the Transmit Command (TXP register) is issued, the SONIC fetches the control informa­tion in the TDA descriptor, loads its appropriate registers (shown below) and begins transmission. (See Section 4.2 for register mnemonics.)
TCR
w
TXpkt.config
TPS
w
TXpkt.pktÐsize
TFC
w
TXpkt.fragÐcount
TSA0
w
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 reads the packet descriptor in the TDA and transmits the data from the TBA. If TXpkt.fragÐcount is greater than one, the SONIC, after fin­ishing 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 then reads the TXpkt.link field and checks if EOL and transmits the next packet. If EOL erates a ‘‘Transmission Done’’ indication in the Interrupt Status register and resets the TXP bit in the Command reg­ister.
In the event of a collision, the SONIC recovers its pointer in the TDA and retransmits the packet up to 15 times. The SONIC maintains a copy of the CTDA register in the Tempo­rary Transmit Descriptor Address (TTDA) register.
The SONIC performs a block operation of 6, 3, or 2 access­es in the TDA, depending on where the SONIC is in the transmit process. For the first fragment, it reads the
TXpkt.fragÐptr0
w
TXpkt.fragÐptr1
w
TXpkt.fragÐsize
w
TXpkt.link
e
0. If it is ‘‘0’’, the SONIC fetches the next descriptor
Figure
3-11 shows the relationship be-
e
1 in the Command
e
1 the SONIC gen-
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 stops transmitting under two conditions. In the normal case, the SONIC transmits the complete list of de­scriptors in the TDA and stops after it detects EOL the second case, certain transmit errors cause the SONIC to abort transmission. If FIFO Underrun, Byte Count Mis­match, Excessive Collision, or Excessive Deferral (if en­abled) errors occur, transmission ceases. The CTDA regis­ter 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 writes to the TXpkt.status field.
3.5.4 Dynamically Adding TDA Descriptors
Descriptors can be dynamically added during transmission without halting the SONIC. The SONIC can also be guaran­teed to transmit the complete list including newly appended descriptors (barring any transmit abort conditions) by ob­serving 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
Figure 3-15
). The procedure for ap-
pending 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’’.
3. Re-issuing the Transmit command (setting the TXP bit in the Command register).
Step 3 assures that the SONIC will transmit all the packets in the list. If the SONIC is currently transmitting, the Trans­mit command has no effect and continues transmitting until it detects EOL
e
1. If the SONIC had just finished transmit­ting, it continues transmitting from where it had previously stopped.
FIGURE 3-15. Initializing Last Link Field
e
1. In
TL/F/10492– 20
4.0 SONIC Registers
The SONIC contains two sets of registers: The status/con-
Ð
trol registers and the CAM memory cells. The status/control registers are used to configure, control, and monitor SONIC operation. They are directly addressable registers and occu­py 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 follow­ing categories:
User Registers: These registers are accessed by the user to configure, control, and monitor SONIC operation. These are the only SONIC registers the user needs to access.
ure 4-3
shows the programmer’s model and Table 4-1 lists
Fig-
the attributes of each register.
Internal Use Registers: These registers (Table 4-2) are used by the SONIC 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.
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 uses the CAM for a relatively long peri­od of time during reception, it can only be written to via the CAM Descriptor Area (CDA) and is only readable when the
22
4.0 SONIC Registers (Continued)
FIGURE 4-1. CAM Organization
SONIC 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 regis­ters. These descriptors are contiguous and each descriptor consists of four 16-bit fields upper word, D
k
31:16l, is not used. The first field contains
(Figure 4-2).
In 32-bit mode the
the value to be loaded into the CAM Entry Pointer and the remaining fields are for the three CAM Address Ports (see Section 4.3.10). In addition, there is one more field after the last descriptor containing the mask for the CAM Enable reg­ister. 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 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).
TL/F/10492– 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 completes the Load CAM command, the CDP register points to the next location after the CAM en­able field and the CDC equals zero. The SONIC 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/10492– 22
4.0 SONIC Registers (Continued)
k
l
5:0
RA
0h Command Register Status and C 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
15 0
4
5
FIGURE 4-3. Register Programming Model
24
4.0 SONIC 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. 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 Port1 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 and providing the necessary ad­dress on register address pins RA5–RA0. Tables 4-1, 4-2, and 4-3 show the locations of all SONIC registers and where information on the registers can be found in the data sheet.
Description
(section)
25
4.0 SONIC 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 is in reset mode (RST bit in the CR is set). The SONIC gives invalid data when these registers are read in non-reset mode.
Note 2: This register can only be written to when the SONIC 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 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 in 16-bit mode and shifted twice in 32-bit mode.
TABLE 4-3. Internal Use Registers (Users should not access these registers)
(RA5–RA0) Access Register Symbol
30 These registers are for factory use only. Users must not
#
R/W address these registers as improper SONIC operation none none
3E can occur.
Description
(section)
Description
(section)
Description
(section)
26
4.0 SONIC Registers (Continued)
4.3 REGISTER DESCRIPTION
4.3.1 Command Register
k
l
(RA
This register ing bits for the function. For all bits, except for the RST bit, the SONIC 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; 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. These commands are issued by setting the correspond-
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
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 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 will lock up if both bits are set simultaneously.
8 RRRA: READ RRA
Setting this bit causes the SONIC 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 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 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 Registers (Continued)
4.3 REGISTER DESCRIPTION (Continued)
4.3.1 Command Register (Continued)
Bit Description
3 RXEN: RECEIVER ENABLE
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 will not start buffering in the middle of a packet being received).
2 RXDIS: RECEIVER DISABLE
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 is currently receiving a packet, both RXEN and RXDIS are set until the packet is fully received. When both RXEN and RXDIS are set, RXDIS could be cleared by writing zero to it.
1 TXP: TRANSMIT PACKET(S)
Setting this bit causes the SONIC to transmit packets which have been set up in the Transmit Descriptor Area (TDA). The SONIC loads its appropriate registers from the TDA, then begins transmission. The SONIC clears this bit after any of the following conditions have occurred: (1) transmission had completed (i.e., after the SONIC has detected
e
EOL
1), (2) the Halt Transmission command (HTX) has taken effect, or (3) a transmit abort condition has occurred. This condition occurs when any of the following bits in the TCR have been set: EXC, EXD, FU, or BCM. This bit must not be set if a Load CAM operation is in progress (LCAM is set). The SONIC will lock up if both bits are set simultaneously.
0 HTX: HALT TRANSMISSION
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 samples this bit after writing to the TXpkt.status field.
28
4.0 SONIC 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 should be to set up this register.) All bits are unaffected by a software reset. This register must only be accessed when the SONIC is in reset mode (i.e., the RST bit is set in the Command register).
Bits 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 DW 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/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,
k
3:0l: This changes the TXD, LBK, RXC and RXD pins from the
k
3:0lrespectively, which are similar to
these four pins will be TRI-STATE and will remain that way until the DCR is changed. If EXBUS is enabled, then these pins will remain TRI-STATE until the SONIC 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 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 is operating in asynchronous mode (bit 10 below is set to ‘‘0’’). If EXBUS is not set, XTO (BRT) is sampled synchronously off the rising edge of bus clock. (See Section 5.4.6.)
The LBR bit controls the mode of operation of the BRT
signal (see pin description). It allows the BUS Retry operation to be latched or unlatched. 0:Unlatched mode: The assertion of BRT
The SONIC will retry the operation when BRT
forces the SONIC to finish the current DMA operation and get off the bus.
is deserted.
1:Latched mode: The assertion of BRT forces the SONIC to finish the current DMA operation as above, however, the
SONIC will not retry until BRT
is deasserted, the BR bit in the ISR (see Section 4.3.6) has been reset, and BRT is
deasserted. 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 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 is a bus master (HLDA or BGACK 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.
is
29
4.0 SONIC Registers (Continued)
4.3.2 Data Configuration Register (Continued)
Bits Description
10 SBUS: SYNCHRONOUS BUS MODE
The SBUS bit is used to select the mode of system bus operation when SONIC is a bus master. This bit selects the internal ready line to be either a synchronous or asynchronous input to SONIC during block transfer DMA operations.
0: Asynchronous mode. RDYi
at the falling edge of the bus clock (T2 of the DMA cycle). No setup or hold times need to be met with respect to this edge to guarantee proper bus operation. The minimum memory cycle time is 3 bus clocks.
1: Synchronous mode. RDYi (BMODEe0) and DSACK0,1 (BMODEe1) must respectively meet the setup and
hold times with respect to the rising edge of T1 or T2 to guarantee proper bus operation.
9, 8 USR1,0: USER DEFINABLE PINS
The USR1,0 bits report the level of the USR1,0 signal pins, respectively, after a chip hardware reset. If the USR1,0 signal pins are at a logical 1 (tied to V to ground) during a hardware reset the USR1,0 bits are set to a 0. These bits are latched on the rising edge of RST they remain set/reset until the next hardware reset.
7, 6 WC1,0: WAIT STATE CONTROL
These encoded bits determine the number of additional bus cycles (T2 states) that are added during each DMA cycle.
WC1 WC0 Bus Cycles Added
00 0 01 1 10 2 11 3
5DW: DATA WIDTH SELECT
These bits select the data path width for DMA operations.
DW Data Width
0 16-bit 1 32-bit
4 BMS: BLOCK MODE SELECT FOR DMA
Determines how data is emptied or filled into the Receive or Transmit FIFO. 0: Empty/fill mode: All DMA transfers continue until either the Receive FIFO has emptied or the Transmit FIFO has
filled completely.
1: Block mode: All DMA transfers continue until the programmed number of bytes (RFT0, RFT1 during reception or TF0,
TF1 during transmission) have been transferred. (See note for TFT0, TFT1.)
3, 2 RFT1,RFT0: RECEIVE FIFO THRESHOLD
These encoded bits determine the number of words (or long words) that are written into the receive FIFO from the MAC unit before a receive DMA request occurs. (See Section 1.4.)
LB1 LB0 Function
0 0 2 words or 1 long word (4 bytes) 0 1 4 words or 2 long words (8 bytes) 1 0 8 words or 4 long words (16 bytes) 1 1 12 words or 6 long words (24 bytes)
Note: In block mode (BMS bite1), the receive FIFO threshold sets the number of words (or long words) written to memory during a receive DMA block cycle.
1, 0 TFT1,TFT0: TRANSMIT FIFO THRESHOLD
These encoded bits determine the minimum number of words (or long words) the DMA section maintains in the transmit FIFO. A bus request occurs when the number of words drops below the transmit FIFO threshold. (See Section 1.4.)
LB1 LB0 Function
0 0 4 words or 2 long words (8 bytes) 0 1 8 words or 4 long words (16 bytes) 1 0 12 words or 6 long words (24 bytes) 1 1 14 words or 7 long words (28 bytes)
Note: In block mode (BMSe1), the number of bytes the SONIC reads in a single DMA burst equals the transmit FIFO threshold value. If the number of words or long words needed to fill the FIFO is less than the threshold value, then only the number of reads required to fill the FIFO in a single DMA burst will be made. Typically, with the FIFO threshold value set to 12 or 14 words, the number of memory reads needed is less than the FIFO threshold value.
(BMODEe0) or DSACK0,1 (BMODEe1) are respectively internally synchronized
) during a hardware reset the USR1,0 bits are set to a 1. If the USR1,0 pins are at a logical 0 (tied
CC
. Once set
30
Loading...
+ 68 hidden pages