The MB86964 is a high-performance, highly integrated single-chip device that incorporates a network controller with buffer management, Manchester encoder/decoder, 10BASE-T transceiver with on-chip transmit and receive filters, and generic bus interface for industry-standard microprocessor busses. The MB86964 allows implementation of adapter solutions with a minimum of additional support chips. Its generic bus interface makes it ideal for use on daughter and motherboards, as well as VESA Local Bus (VL Bus). It also can be easily integrated onto device controller and communication boards as an embedded LAN adapter.
The buffer management architecture of the MB86964 allows
packet data to flow through an external SRAM buffer memory
acting as an elastic buffer. On-chip FIFOs, together with the
SRAM buffer, pipeline both transmit and receive packets
through the system for maximum performance and minimum
overhead to the host microprocessor. All receive and transmit
pointers are managed automatically by the device to reduce
software overhead and increase packet processing speed. The
MB86964's transmit buffer is programmable as a single
2-kbyte bank or as two banks of 2, 4, or 8 kbytes each. These
buffers can store multiple data packets, allowing the MB86964
to transmit all of them following a single transmit command,
thereby offering greater design flexibility and throughput. A
ring buffer that can be sized from 4 to 30 kbytes, depending on
the size of the SRAM, acts as a large elastic FIFO buffer to
capture the bursts of receive packets.
The MB86964 performs pulse shaping and filtering internally, which eliminates the need for external filtering components and reduces overall system cost. The twisted pair interface is compatible with shielded and unshielded cables and provides outputs for transmit, collision and link test LED indicators. The twisted pair receive threshold can be reduced to allow an extended range between nodes in low-noise environments. Its wide range of features makes the MB86964 the ideal device for 10BASE-T twisted-pair Ethernet applications.
Possible configurations for the system bus interface include I/O mapping, memory mapping and DMA access, or a combination of these. With a 20 Mbyte/s bandwidth, the MB86964 system bus interface allows use of full throughput capacity of its packet-buffering architecture. The MB86964's bus modes are programmable, thereby providing 8- or 16-bit data path width and big or little endian byte-ordering, permitting efficient data interface with most microprocessors and higher-level protocols.
The MB86964, which is furnished in a space-efficient 100-pin plastic shrink quad flat package, is fabricated using Fujitsu's high-speed, low-power CMOS process.
Pin Configuration
Pin Assignments
Figure 1. MB86964 Pin Assignments
System Bus Interface Pins
Buffer Memory Interface Pins
Power and Transceiver Interface Pins
The MB86964 comprises five major functional blocks: system interface, buffer controller, transmitter, receiver and control and status registers, as illustrated in figure 2. The MB86964's receive and transmit sections fully implement the ISO/ANSI/IEEE 8802-3 CSMA/CD specification for 10 megabit per second Ethernet. The transmitter assembles data packets for transmission and the receiver disassembles received data packets. On-chip Ethernet protocol functions include: automatic generation and stripping of the 64-bit preamble; generation and verification of 32-bit cyclic redundancy check (CRC); collision resolution by binary exponential backoff and retransmission; several modes of address recognition, error detection and reporting; and serial/parallel and parallel/serial conversions.
As shown in the typical application, the MB86964 allows a highly integrated system configuration. The MB86964's architecture and high level of integration facilitate packet management and storage, and eliminate the need for a local microprocessor. The MB86964 connects with the host system bus to provide command and status interfaces as well as packet data access. The host processor can directly access command and status registers mapped into the host I/O or memory space. Data packets to be transmitted to the network initially transfer from host memory through a register in the MB86964 into the dedicated buffer memory where they are temporarily stored until transmitted. Buffer memory initially stores received data packets that are later transferred to the host memory.
For detailed design information on a typical adapter board application, refer to the Hardware Reference Manual included in the DK86964 Designer's Kit which is available for purchase from your authorized Fujitsu Microelectronics sales representative or distributor.
Figure 2. MB86964 Block Diagram
Figure 3. Typical Application, Block Diagram
Figure 4. Crystal Oscillator Connection
Use a crystal with the following specifications: quartz (AT-cut); 20-MHz; frequency acurracy of +50ppm at 255 C and +100ppm at 05C to 705C; parallel resonant with 20 pF-load in fundamental mode. Possible vendors include: Ecliptek Corp. (Costa Mesa, CA), p/n ECSM200-20.000; and M-tron Industries, Inc. (Yankton, SD), p/n MP-1 and MP-2.
See Buffer Access section for information on how the host accesses the buffer memory.
The byte-order control works by reversing, or not reversing, the bytes of all words as they pass between the buffer memory and the system bus. Thus all data stored in the transmit buffer or retrieved from the receive buffer is affected, including nontransmitted headers. This control bit does not affect the MB86964 registers other than the Buffer Memory Port registers, BMPR8 and BMPR9. When using this feature, ensure the reversal of header information as well as packet data in the software driver code. See table 1 for examples of using least..most and most..least byte ordering.
Direct access is available to two sets of registers in the device's register set at a time, via register addresses 00H through 0FH. The Data Link Control Registers set (DLCR0 - DLCR7) is always accessible via addresses 00H to 07H. Access to one of the remaining three sets is accomplished by programming the register bank select bits, DLCR7<3:2>. This selects the register set accessible via addresses 08H to 0FH. The bank-switched registers are the Node ID set , DLCR7 - DLCR15, (for setting the Ethernet Address and performing TDR diagnostics), the Hash Table set, HT8 - HT15, (for setting up multicast address filtering) and the Buffer Memory Port set, BMPR7 - BMPR15. During operation (excluding initialization or diagnostics), the Buffer Memory Port set should normally be selected.
Table 1. Byte Ordering
Items shown with an astertisk are in numerically reversed byte order
Data can transfer from the host memory to the transmit buffer,
or from the receive buffer to host memory by using string
moves, single-transfer programmed I/O moves, or DMA.
Select the method that yields the highest system-level
efficiency. A rapid transfer process results in best
performance. Slow transfer can result in poor throughput and
performance, and cause the receive buffer to overflow and lose
packets.
after completion of the current cycle. If a DMA interrupt (DLCR3<5>) is enabled, the MB86964 generates an interrupt after completion of DMA activity.
Usually only one DMA operation will be run at a time, although
the MB86964 could run two interleaving operations, one
reading and one writing. There is only one DMA EOP bit, and
only one DREQ pin and one DMACK pin, so most hosts could
not support more than one DMA operation at a time.
The DMA controller asserts the end of process input, EOP(EOP), concurrent with the last required data-transfer cycle to indicate completion of the entire transfer process. This action sets the DMA EOP status bit, DLCR1<5>, and discontinues further data requests from the MB86964. The MB86964 will also generate an interrupt if the DMA EOP interrupt enable bit, DLCR3<5>, is high. The host can use this interrupt to begin action to close the process. The host should reset the MB86964 DMA logic and clear the interrupt by writing 00H to BMPR12.
Note: DMA EOP, DLCR1<5> must be cleared to close the transmit DMA process before attempting another DMA process. This is accomplished by writing 00H to BMPR12. When this is done, the DMA EOP bit will clear automatically, clearing the EOP status and interrupt, (if enabled) so it is not necessary to clear the interrupt separately.
After finishing the loading of packets into the buffer, the host initiates packet transmission. This is done by loading the number of packets to be transmitted into the Transmit Start Register, BMPR10<6:0>, and asserting the Transmit Start bit, TXST, of the same register, BMPR10<7>.
Prior to beginning the transfer of a packet from the receive buffer to host memory via DMA, the host must first read the four-byte receive packet header from the buffer to obtain the packet status and the length of the packet in bytes. Calculating from the packet length the number of DMA cycles needed to read the packet, the host will load that number into the cycle counter of the host DMA controller. Next, RX DMA EN, BMPR12<1>, is set to high to enable DMA read operation to transfer the packet to host memory. The DMA burst control bits, BMPR13<1:0>, set the maximum number of data transfer cycles (bytes or words) in a single bus acquisition to be 1, 4, 8, or 12. When it is ready to begin, the MB86964 asserts its DMA Request output, DREQ. The host responds by asserting DMA Acknowledge, DMACK, followed by the Read Strobe, RD. The MB86964 will assert its RDY(RDY) output when it has placed the byte/word on the data bus and is ready to complete the data transfer cycle. The system memory will accept the data, then the host negates RD. The MB86964 shifts the data down in its bus read FIFO, then moves its internal read pointer to point to the next byte/word in the buffer, moving it into the FIFO.
In burst mode and depending on the value of the DREQ EXTND bit, DLCR4<2>, the MB86964 negates DREQ at the next-to-last or last transfer cycle of the burst. The host DMA then completes the last one or two transfer cycles and negates DMACK to terminate the burst. The MB86964 reasserts DREQ to repeat the process if it can transfer more data after the host negates DMACK. The DMA controller asserts the end of process input, EOP(EOP) concurrent with the last byte/word data transfer to indicate completion of the entire process. The MB86964 then stops requesting more DMA cycles.
When EOP(EOP) is asserted by the host DMA controller, the DMA EOP bit, DLCR1<5>, will be set high, and an interrupt will also be generated, provided it is enabled by a high in the associated interrupt enable bit, DLCR3<5>. This interrupt can be used by the host to initiate the final actions to close the DMA process. The interrupt is cleared and the DMA is disabled and reset by writing 00H to the DMA Enable Register, BMPR12.
Note: Clearing RX DMA EN must be done to close the receive DMA process before attempting another DMA process. This is accomplished by writing 00H to BMPR12. When this is done, the DMA EOP bit will clear automatically, clearing the EOP status and interrupt, so it is not necessary to clear the interrupt separately.
After completion of the DMA process, RX DMA EN must be reasserted when the host wants to begin reading another packet from the receive buffer by using DMA.
Buffer Controller
Figure 5. Buffer Memory Organization
The buffer controller keeps track of buffer memory
partitioning and allocation and updates internal address
pointers automatically for the tasks of transmit, retransmit,
receive, rejection of packets with errors and data transfers to
and from the host. The host and its drivers are thus relieved of
buffer management functions, making the MB86964 easy to
operate and substantially reducing software requirements.
Packets with errors are normally automatically rejected by the
MB86964 as are packets shorter than the IEEE minimum
length packet of 60 bytes, excluding Preamble and CRC. Since
these tasks can be done faster in hardware than in software, this
not only off-loads the host system, but it also speeds up the
communication processes, yielding higher throughput. As a
result, the MB86964 can typically win benchmark
performance tests over competing controllers.
1. Data from the network is stored in the receive buffer.
2. The host retreives packets from the receive buffer.
3. The host loads packet data into the transmit buffer.
4. The transmitter obtains data for transmission from the transmit buffer.
5. Any combination of the above can occur concurrently.
Figure 6. Simultaneous Access to Buffer Memory
At reset, internal pointers are initialized to point to the
beginning of one of the transmit buffers. Each time the host
writes data to the buffer via the Buffer Memory Port Register,
an internal pointer is advanced to the next memory location
within the transmit buffer. Once a data byte/word is written, it
cannot be read and the internal pointer cannot be reversed.
When the host completes loading the transmit buffer, it writes the number of packets it has loaded into TX PKT CNT, BMPR10<6:0> and sets the transmit start bit, BMPR10<7>. When this occurs, the MB86964 will switch banks and will start transmitting at the earliest opportunity. Another automatically-managed pointer, the transmit read pointer, sequences through the bank being transmitted to read the packet data into the transmitter through its FIFO. If a collision occurs, the packet will be automatically retransmitted after a pseudo-random waiting interval called the backoff interval. If there are multiple packets in the buffer, the MB86964 will continue down the list until all are transmitted. Upon reaching the end of the list or chain of packets, the transmitter will stop, update its status bits and, if enabled, generate an interrupt. The details of this operation are described in the section on packet transmission.
Figure 7. Transmit Buffer Configurations
The receive buffer size can vary between a maximum of 30 kilobytes when 2 kilobytes are allocated for the transmit section and a 32 kilobyte SRAM is used, to a minimum of 4 kilobytes if 4 kilobytes are allocated for the transmit section and an 8 kilobyte SRAM is used. The receive section dynamically allocates space for each individual incoming data packet, aligning each at an eight-byte 'page' boundary. Each received packet is preceded by a four byte header which provides packet status and the length of that data packet. The data packets are linked or chained by internal pointers which use the length value in the packet header to calculate the starting address of the next packet. This buffer format is shown in figure 9. Since the MB86964 controls its dedicated buffer memory, FIFO size and depth are unimportant in this architecture, and need not be considered in system timing considerations.
A status bit in one of the MB86964's internal registers informs the host when one or more packets are resident in the receive buffer and available to be read. The host retrieves these packets from the buffer memory by successive reads of BMPR8. Once a data byte/word is read from the buffer memory, internal pointers are advanced to the next byte/word. As data is thus read by the system, that memory becomes available for reception of new packets. The MB86964 automatically rejects an incoming packet if there is not enough buffer space to fully receive that packet. Therefore, there is no chance for packets already received to be 'overrun' by incoming packets.
Figure 8. Transmit Buffer Detail
When DLCR5<5>, the ACPT BAD PKTS bit, is set to a '0' (disabled), detection of a bad incoming packet causes the MB86964 to release the buffer space in which that packet is contained and to reset its internal pointers so as to use that space for the next incoming packet. If this bit is set to a '1', a packet with a CRC or alignment error will be accepted and the appropriate error bits in the status field of its header will be set. The same applies to DLCR5<3>, ACPT SHORT PKTS, which when high allows retention of packets below 60 bytes in length, excluding Preamble and CRC (which is shorter than IEEE 802.3 minimum packet size).
Figure 9. Receive Buffer Detail
The length stored in bytes 3 and 4 of the header specifies the
length of the portion of the packet stored in the buffer. This
length specification is in bytes, regardless of whether the
system interface is programmed for byte or word mode.
During reception, the MB86964 strips the Preamble field and
checks and strips the CRC field, so, as is the case for the
transmit buffer, those fields of the packet are not stored in the
buffer. The length specification thus includes only the
Destination ID, Source ID, Length, and Data fields of the
incoming packet.
Table 2. Receive Packet Header Status Indications
0/1 indicates that the value of the bit will be 0 or 1 depending on the condition of the packet. An 'X' indicates that the value should be ignored
The transmitter state machine provides sequencing of events for the transmitter, including idle, preamble, data, CRC, interpacket gap, jam and backoff. It detects various transmit error conditions and sets appropriate bits within the DLCR registers.
The pipeline FIFO provides elastic buffering that the buffer controller can load with data to be transmitted. The chip's CRC generator calculates the 32-bit CRC on the destination and source address, the length field and the data field as specified by the ISO/ANSI/IEEE 8802-3 specification for Ethernet. This value is appended to the end of the packet when it is transmitted.
Packets on the network must be separated by at least 9.6 microseconds, the 'interpacket gap' (IPG) during which the network medium is specified to be idle. The MB86964 transmitter state machine measures this IPG starting from the end of a packet on the network, and does not attempt to transmit until the end of the IPG. If carrier reappears on the network during the first two-thirds of the IPG, the MB86964 resets the timer to re-time the IPG from the end of the new transmission. Such an event can occur during a collision, since data and carrier indications can be corrupted by the superimposition of the two packets. During the last one-third of the IPG, the MB86964 ignores the occurrence of a carrier indication, in accordance with 8802-3, to ensure fairness and equality in access to the network. Thus, if one station begins transmission slightly ahead of another, there is no advantage to the earlier start. Both nodes transmit, a collision occurs, and backoff interval differentials resolve the media-access contention.
The transmitter transmits the packets in the transmit buffer in the order in which they were loaded. If a collision is detected by the transceiver, the transmitter automatically retransmits the packet until successful or until 16 consecutive attempts have ended in collision. In the latter case, depending on the mode selection made at initialization time, the transmitter continues to try to transmit the same packet starting again with a collision count of zero, skips the current packet and tries to transmit the next packet starting with a collision count of zero, or halts and waits for instruction from the host. In the last case, the host can elect to terminate transmission attempts by setting DLC EN, DLCR6<7> to one, continue to attempt to transmit the same packet (collision counter reset), or skip the current packet and try to transmit the next packet (collision count is zero).
Figure 10. Packet Format
A status bit in the Transmit Status Register is set in case a collision terminates transmission. Collision counter DLCR4<7:4>, automatically increments after each collision up to the sixteenth collision, at which time it rolls over to zero. Another status bit indicates that sixteen consecutive attempts to transmit a packet have been made and all have been terminated by collision. The occurrence of 16 collisions may indicate a network problem, such as a disconnected cable or terminator, that produces false collisions. While rare, 16 collisions may normally occur.
The MB86964 is equipped with a special counter to perform the TDR function. The contents of the counter after any transmission can be determined by reading the Time Domain Reflectometry registers, DLCR14 (the least-significant byte) and DLCR15 (the most-significant byte). Only the lower 14 bits of the counter are equipped, which is more than is needed for an IEEE or Ethernet LAN. The top two bits, DLCR15<7:6>, are always 0. The TDR counter counts the actual number of bits transmitted for each packet before a collision indication, carrier loss indication or completion of transmission, whichever comes first. A complete transmission with no error indications clears the TDR counter. The elapsed time represents twice the signal delay from node to fault.
To perform the TDR fault test, first enable interrupts for TX
DONE, by setting DLCR2<7> high. An alternative to using the
interrupt is to poll the TX DONE bit, looking for a high level.
Set the 16 Collisions Register, BMPR11, to 07H for this test (no
halt, skip-failed packet). Clear status bits by writing 0FF86H to
the Receive and Transmit Status registers. Next, try to transmit
a packet length of 600 or more bits. Up to 16 attempts may be
made automatically, if collisions are indicated. Upon
completion of the transmission attempts, TX DONE goes high,
generating an interrupt if so enabled. When this occurs, read
the Transmit Status register and the TDR register.
The receiver state machine provides sequencing of events for the receiver, including idle, busy, address filtering, and data storage, detects receive error conditions and sets appropriate bits within the DLC registers. A small data FIFO provides elastic buffering for synchronization with the buffer controller timing and buffering of data while the buffer controller is servicing other buffer memory access requests.
The receiver monitors the serial data stream from the transceiver for the end-of-preamble bit pattern, a four-bit pattern of 1011 ending the preamble's pattern of alternating ones and zeros. This pattern also provides byte and field synchronization for the receiver; the bit immediately following the end of preamble is the first bit of the first byte of the packet's destination address field.
When packet transmission is unflawed, carrier sense remains asserted for the duration of the packet, negating just after the last bit of the CRC field is received, when the transceiver detects the end-of-packet symbol at the end of the packet. Loss of carrier sense at any other time may also result from a collision or other network problem.
Among the address filtering selections possible with the MB86964 are the following examples:
1. All Pass (no filtering)
2. Node address and broadcast packets only
3. Node address xxx.xxx, multicast addresses yyy.yyy and zzz.zzz and broadcast packets only
Assume this hashing function as an example: treat the
multicast address as a nonnegative 48-bit integer, divide this
number by 64 and take the remainder. This function maps all
multicast addresses into a 64-element hash table because the
remainder must be an integer between 0 and 63. Applying this
hashing function results in taking the least-significant six bits
of the multicast address as an integer. In the hash table, for each
element, 0 through 63, a single bit is stored to indicate if the
address is accepted (1) or rejected (0). If, for example, the node
belongs to three multicast groups, only three or fewer of the
hash table elements store ones, and the rest store zeroes. The
scheme allows the acceptance of any number of addresses,
including all of them. However, while this filters out most
nonspecific addresses, there may be addresses not of interest
used on the network that also fall into the accept elements, so
filtering may be imperfect.
The actual hashing function used in the MB86964 is to calculate the CRC on the multicast address and to store the most-significant six bits of this calculation in a register . The six bits are used to address the elements of the hash table: the three MSBs are used as the Hash Table register address, and the three LSBs are used as the bit address within a register byte. If the addressed Hash Table element yields a `1' and the packet is a multicast packet (first bit of destination address equals 1), and it passes the error filters, the packet will be accepted. The hash filter criteria are only used on multicast addresses, which all start with a one. Node IDs that start with a zero are not filtered by the hash filter. The broadcast address, a special case of the multicast set wherein all the bits are ones, is accepted anyway unless the Reject All Packets mode is selected.
The hash filter is used only when the Address Filter mode select bit AF1 is 1 and mode select bit AF0 is 0, selecting the Node ID, Broadcast, Multicast + Hash Table mode. Hash Table registers should only be accessed when the Receiver is disabled, i.e., when DLC EN is high, to avoid interaction with the Receiver. There are eight bytes of registers in the Hash Table containing 64 one-bit elements, as shown in the table 7. Software code examples showing how to calculate entries for the Hash Table are available through Fujitsu sales offices.
The encoder also monitors the state of the internal transmit
enable signal from the transmitter section and appends an
end-of-packet symbol (illegal Manchester code) to the data
stream when that signal is negated at the end of the CRC field of
the transmitted packet.
During idle periods, the MB86964 transmits link integrity test pulses on the TPO circuit if LINK TEST EN, BMPR13<5>, is asserted and the AUI/TP port select bit, BMPR13<4> is set for twisted-pair (TP) operation (or if the transceiver is set for automatic port selection via BMPR13<3> and the TP port is auto-selected). The MB86964 is programmed for either shielded (150W) or unshielded (100W) twisted-pair through the STP/UTP bit BMBR13<2>.
An internal intelligent squelch function discriminates noise from link test pulses and valid data streams. The receiver is activated only by valid data streams above the squelch level and with proper timing. If the differential signal at the TPI or the DI circuit inputs falls below 75% of the threshold level (unsquelched) for eight bit times (typical), the receiver enters the idle state. The squelch threshold can be controlled via BMPR13<6>.
The transceiver automatically corrects reversed polarity. Polarity reversal is reported via BMPR15<3>.
The MB86964 provides additional loopback testing functions
controlled by LBC. When the twisted-pair port is selected and
LBC is asserted, the loopback is forced regardless of the state of
the TPI inputs or link test failure. When the AUI port is selected
and LBC is asserted, internal local loopback is enabled. If LBC
is negated, no local AUI loopback occurs.
During loopback data is routed from the transmit buffer to the transmit section of the data link controller, through the Manchester encoder, back through the Manchester decoder, through the receiver section of the data link controller, and is then stored in the receive buffer. Software can then read and check the received packet that has traveled through the MB86964 transmit and receive sections. Receipt of the loopback data into the receive buffer can be disabled by asserting FILTER SELF RX, BMPR14<0>. The transmitted data is blocked from appearing at the network outputs while the MB86964 is in forced loopback mode (LBC asserted).
Figure 11. Typical TP Port and AUI Port Connections
The control and status registers on the MB86964 are accessed
through register addresses 00H through 0FH, and register
bank-switching bits RBS1 and RBS0, DLCR7<3:2>. Table 3
summarizes the internal registers and their addresses. In 16-bit
mode, even-numbered direct addresses select the registers. For
example, address 00H accesses the Transmit and Receive
Status registers simultaneously. Transmit Status would be on
the low byte and Receive Status on the high byte. Appropriate
byte-access processor instructions can access high and low
bytes separately.
Tables 4 - 8 summarize the control and status bits within each addressable register, as well as the bits in the receive and transmit packet headers. The registers are descibed more fully in the tables that follow. The abbreviation that appears in the TYPE column of each table is described in the table below.
Table 3. Internal Register Address Map
Table 4. Control and Status Bits, DLCR0-7
Table 5. Control and Status Bits, BMPR8-15
Table 6. Control and Status Bits, DLCR8-15
Table 7. Control and Status Bits, HT8-15
Table 8. Status Bits, Packet Buffer Headers
Bits 7, 3, 2, and 1 of this register, which can generate interrupts, are cleared by writing a `1' to the bit. Writing `0' to these bits has no effect. Only the MB86964 control logic can set these bits to high. Clearing the bit that causes an interrupt clears the bit and the interrupt. Because two or more status conditions may occur simultaneously, the interrupt routine must read and act on all status conditions that are set.
One method to clear interrupts is to read the contents of the status register, then write the same value back to the register, thus clearing all bits that were set. Another technique is to clear each status bit separately, by writing its mask (interrupt enable) to the register. This might be done as the corresponding interrupt service is performed. Note that wholesale clearing of all status bits by writing FFH to the register is not recommended, because this action may clear a just-set status that has not yet been read by the system. Note also that the transmitter must be idle and TX DONE, DLCR0<7>, must be cleared by writing 1 to it before starting the transmitter by writing 1 to TXSTART, BMPR10<7>.
Table 9. DLCR0 - Transmit Status Register
The bits in this register, except bit 5, are cleared by writing `1' to the bit. Writing `0' to these bits has no effect. Only internal control logic can set these bits high. Clearing the bit that causes an interrupt clears the bit and the interrupt. Because two or more status conditions can occur simultaneously, the interrupt routine must read and act on all status conditions that are set. One method to clear interrupts is to read the contents of the status register, then write the same value back to the register, thus clearing all bits that were set. Another technique is to clear each status bit separately, by writing its (interrupt enable) mask to the register. This might be done as the corresponding interrupt service is performed. Note that wholesale clearing of all status bits by writing 0FFH to the register is not recommended, because this action may clear a just-set status that has not yet been read by the system.
Table 10. DLCR1 - Receive Status Register
Table 11. DLCR2 - Transmit Interrupt Enable Register
Table 12. DLCR3 - Receive Interrupt Enable Register
Table 13. Network Error Monitoring Modes
Table 14. DLCR4 - Transmit Mode Register
Table 15. Collision Count
Status bit RX BUF EMPTY, DLCR5<6>, is necessary to the software routine which reads receive packets from the buffer. It tells the host whether there are any packets in the receive buffer that are complete and ready to read. In a multitasking system, this indicator would be used in conjunction with an interrupt when RX PKT asserts, which means a packet has arrived in memory. The interrupt would be used to start the routine that reads packets from the buffer.
As this routine begins, the interrupt on RX PKT can be disabled to prevent unneeded interrupts. After the first packet is read from the buffer, the RX BUF EMPTY bit would be read to see if more packets have come in (packets may, at times, arrive in bursts). If the buffer is not empty, another packet would be read out, and this procedure repeated until the buffer is empty. After emptying the buffer, the host clears RX PKT, then reenables interrupts on RX PKT, checks the buffer status one more time (because a packet can arrive at any time), then exits to do other tasks. Note that the packet header can reflect acceptance of a short packet (bytes 3 to 59).
Two of the control bits allow reception of packets with certain types of errors. The ACPT BAD PKTS bit, when set, causes the Receiver to retain and store in the buffer packets with CRC, alignment or short-length errors, provided that there was no indication of collision during reception. Likewise, the ACPT SHORT PKTS bit, when set, allows the retention of short packets down to and including only six bytes in length, excluding Preamble and CRC, provided that there was no indication of collision during reception and no alignment or CRC error. Under normal operation, packets with less than 60 bytes, the IEEE 802.3 lower limit, would be discarded. These functions are provided for diagnostic purposes.
Address Filter Mode bits AF1 and AF0 select the destination addresses for which the MB86964 will accept packets for processing. Table 17 provides additional information on the relationship of the setting of these bits with other control bits and how they interact in terms of packet reception.
Table 16. DLCR5 - Receive Mode Register
Table 17. Reception Destination Address Filtering
1. A NODE ID match occurs when the incoming packet has a destination address whose first bit is a zero, and whose second through forty-eighth
bits match bits 1-47 respectiverly of the address stored in the Node ID registers.
Software engineers who want to use the same node driver for the MB86950/60/64/65 controllers from Fujitsu should note that the driver can determine which chip is being used by reading DLCR7 and DLCR6 after hardware reset. The MB86964 reads 60B6H or 70B6H (60H or 70H for DLCR7 and B6H for DLCR6); the MB86965 reads E0B6H or F0B6H; the MB86960 reads 30B6H or 20B6H; the MB86950 reads 0000H.
Power down mode saves power when the MB86964 is not in use. When ready to place the MB86964 chip in power down mode, first write 1 to DLC EN, DLCR6<7>, to turn off the receiver and transmitter, then write 0 to PWRDN, DLCR7<5>. To exit the power down mode, write 1 to PWRDN. Register contents are preserved, unless the chip is hardware reset. Hardware reset also terminates the power down mode.
Byte ordering determines in which portion of the data bus the high and low bytes of a word are contained. Refer to the System Interface section for additional information.
Table 18. DLCR6 - Configuration Register 0
Table 19. DLCR7 - Configuration Register 1
The Node ID registers are readable and writable registers, and should not be accessed while the Receiver is enabled. To avoid interaction with the Receiver, it is recommended that the Node ID registers be written and read only during initialization, before enabling the receiver, i.e., before writing 0 to DLC EN. The address contained in the Node ID registers is used only for receive (destination) address filtering, not for the source address of outgoing packets. The system provides outgoing packet addresses as part of the packet data. Within each byte, bits are transmitted and received on the network in a least-significant-bit-first order.
Refer to the transmitter section for additional information on the TDR counter, performing a TDR test and interpreting the results.
Writing a byte/word to BMPR8 transfers that data to the currently addressed location in the transmit buffer, and increments the transmit buffer pointer to point to the next byte/word. Reading a byte/word from this port transfers the contents of the currently addressed location in the receive buffer to the host, and increments the receive buffer pointer to point to the next byte/word.
BMPR9 is used only in word mode as the high byte of the word.
In word mode, all transfers must be 16-bits wide, as the Buffer
Memory Port register does not support byte-wide transfers in
this mode. All other registers can be accessed word-wide,
high-byte-only or low-byte-only.
Table 20. BMPR10 - Transmit Start Register
Table 21. BMPR11 - 16 Collisions Control Register
Table 22. Collision Action Codes Written to BMPR11
Table 23. BMPR12 - DMA Enable Register
Table 24. BMPR13 - DMA Burst and Transceiver Mode Register
Writing a `1' to bit 2 of this register commands the buffer controller to skip the balance of the current receive packet in memory. The bit can then be read to determine that completion of the skip process is complete (within 300 ns). If there is another packet, the bit returns to 0 when the chip is ready to read the next packet or, if there is not another packet, stop reading. Do not use this feature before reading at least four times from the beginning of the packet, nor if there are eight or fewer bytes left of the packet in the buffer; doing so may corrupt the receive buffer pointers.
As shown in the table, this register also provides control for enabling interrupts based on the setting of status bits in BMPR15, the Transceiver Status Register.
Table 25. BMPR14 - Filter Self Receive Register
Table 26. BMPR15 -Transceiver Status Register
Table 27. Absolute Maximum Ratings
Permanent device damage may occur if absolute maximum ratings are exceeded. Exposure to absolute maximum rating conditions for extended
periods may affect device reliability. No more than one output may be shorted to ground or VCC at a time for a maximum duration of one second.
Table 28. Recommended Operating Conditions
See figure 11 for recommended terminations for the AUI and twisted-pair ports.
Table 29. DC Specifications
Table 30. General Capacitance
Table 31. AUI Electrical Characteristics
1. Values are at 255 C and are used for design aid only; not guaranteed and not subject to production testing.
Table 32. Twisted-pair Electrical Characteristics
Typical figures are at 255 C and are used for design aid only; not guaranteed and not subject to production testing.
Table 33. Jabber and Link Test Timing
Table 35. Write Cycle
Table 36. Single-cycle DMA Timing
1. All of the RD, WR and EOP asserted pulses must fall inside of the DMACK asserted pulse. An asserted EOP terminates any further DREQ
after DMACK returns high. The DMA cycle uses DMACK as the chip select. DMACK overrides SA<3:0>, forcing selection of the buffer
memory port in a DMA cycle.
2. Timing shown for EOP also applies to EOP when EOP(EOP) is programmed to be asserted high.
Table 37. Burst DMA Timing
Table 38. Burst DMA terminated by EOP
Table 39. RESET Timing
Table 40. Skip Packet Timing
Table 41. INT Timing
Table 42. SRAM Read Timing
Table 43. SRAM Write Timing
All rights reserved. This publication contains information considered proprietary by Fujitsu Limited and Fujitsu Microelectronics, Inc. (collectively, "Fujitsu"). No part of this document may be copied or reproduced in any form or by any means or transferred to any third party without the prior written consent of Fujitsu Microelectronics, Inc.
Circuit diagrams utilizing Fujitsu products are included as a means of illustrating typical semiconductor applications. Consequently, complete information sufficient for design purposes is not necessarily given.
Fujitsu Limited and its subsidiaries reserve the right to change products or specifications without notice. Fujitsu advises its customers to obtain the latest version of device specifications to verify, before placing orders, that the information being relied upon by the customer is current.
The information contained in this document does not convey any license under copyrights, mask work rights, patent rights or trademarks claimed and owned by Fujitsu Limited or its subsidiaries. Fujitsu assumes no liability for Fujitsu applications assistance, customer's product design, or infringement of patents arising from use of this publication or other Fujitsu proprietary information in creating semiconductor devices, modules, printed circuit board assemblies and/or other assemblies for a user's system design. Nor does Fujitsu warrant any patent right, copyright, or other intellectual property right covering or relating to information herein or to Fujitsu semiconductor devices or any combination, or machine, or process in which such information and/or semiconductor devices might be or are used.
Fujitsu Microelectronics, Inc.'s products are not authorized for use in life-support devices or systems. Life-support devices or systems are devices or systems that are:
1. Intended for surgical implant into the human body.
2. Designed to support or sustain life, and when properly used according to label instructions, can reasonably be expected to cause significant injury to the user in the event of failure.
The information contained in this document has been carefully checked and is believed to be entirely accurate. However, Fujitsu Limited and Fujitsu Microelectronics, Inc. assume no responsibility for inaccuracies.
This document is a published by the marketing department of Fujitsu Microelectronics, Inc., 3545 North First Street, San Jose, California, U.S.A. 95134-1804.
Copyright { 1993, Fujitsu Microelectronics, Inc.