
MB86964
17
Assume this hashing function as an example: treat the multi-
cast 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 ele-
ment, 0 through 63, a single bit is stored to indicate if the ad-
dress 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, in-
cluding all of them. However, while this filters out most non-
specific addresses, there may be addresses not of interest used
on the network that also fall into the accept elements, so filter-
ing may be imperfect.
The actual hashing function used in the MB86964 is to calcu-
late the CRC on the multicast address and to store the most-sig-
nificant 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 ad-
dressed Hash Table element yields a ‘1’ and the packet is a mul-
ticast 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 ex-
amples showing how to calculate entries for the Hash Table are
available through Fujitsu sales offices.
Receive Packet Processing
As a packet arrives from the network, its destination address
field is tested for the various address filter criteria selected by
the Address Filter Mode bits, DLCR5<1:0>, and the Hash
Table. Only if the address meets the filter criteria selected will
the packet be accepted for storage in the receive buffer. In addi-
tion, the packet must be error-free, unless the chip has been en-
abled to receive flawed packets for diagnostic purposes. If
these conditions are met, the packet reception results in the
packet being stored in the buffer, its 4-byte header being up-
dated at the end of reception, the RBUF EMPTY status bit,
DLCR5<6>, being cleared, the RX PKT status bit,
DLCR1<7>, being set high and an interrupt being generated if
so enabled. The last four bytes of the packet are the CRC field
and are checked for correct CRC. The CRC bytes are not trans-
ferred to the Receive Buffer. If the packet has an error and re-
ception of such packets has not been enabled, it will be dis-
carded and pointers will be reset to reuse the same portion of the
receive buffer for the next packet to arrive. If a flawed packet is
accepted for storage for diagnostic purposes, its error(s) will be
reported in the status byte of its header (see Receive Packet
Header section ).
Receive Error Processing
Status bits in the receive status register are set to indicate errors
associated with packet reception. These errors are: 1) bus read
error, which occurs if the host system attempts to read from an
empty receive buffer (this need never occur if the RX BUF
EMPTY bit is checked), 2) short packet error, 3) alignment er-
ror (incomplete byte fragment at end of packet), 4) CRC error
and 5) buffer overflow, which occurs if the receive buffer space
is insufficient to hold the entire received packet (the receive
controller automatically removes such packets from the re-
ceive buffer and packets already stored in the buffer are not
lost). Each of these receive error conditions may optionally
generate an interrupt. None of these errors requires special host
processing or intervention, other than optional tallying of the
error for network management purposes.
TRANSCEIVER
The MB86964’s transceiver section provides the electrical in-
terface for DB15 (AUI) and RJ45 (10BASE-T) connections to
the Ethernet local area network. Its functions include Man-
chester encoding and decoding of serial data streams to the
transmitter and from the receiver, level conversion, collision
detection, signal quality error (SQE) and link integrity testing,
jabber control, loopback, and automatic correction of polarity
reversal on the twisted-pair input. Pulse shaping and filtering
functions eliminate the need for external filtering components
and thus reduce overall system cost. Also provided are outputs
for transmit, collision and link test pass LEDs, and compatibili-
ty with shielded and unshielded twisted-pair cables. Receive
threshold can be reduced to allow an extended range between
nodes in low-noise environments. Programmable functions
are controlled via BMPR13. Transceiver status is presented in
BMPR15.
Data Encoder
The encoder converts the serialized NRZ data from the trans-
mitter to Manchester code, the format used on the network me-
dium. In Manchester code a one is represented as a bit cell
(nominally 100-nanoseconds) starting with a low, ending with
a high, with a low-to-high transition at the midpoint; Manches-
ter code for a zero is the inverse.