MB86965
33
NODE ID REGISTERS
The
Node ID Registers are accessed in
register bank “0”
at register addresses xxx8H - xxxDH. During node
initialization,
the unique Ethernet address assigned to
the
node loads into these registers.
The first register at xxx8H
corresponds
to the first byte of the Node ID, or the first
address byte
to be received as a packet arrives from the
network. If EtherCoupler is configured to do so via
Address Filter bits, DLCR5<1:0>, the destination
address field of an incoming packet compares with the
Node
ID stored in these registers. The packet is accepted,
if it passes the error filter and there is a match.
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
, access the Node
ID
registers only when DLC EN, DLCR6<7>, is 1. 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. W
ithin
each
byte,
bits are transmitted and received on the network in a
least-significant-bit-first order.
Time Domain Reflectometry (TDR) Counter
The
TDR Counter approximately indicates the location
of a fault on the network, if one exists. When a node
transmits, a short or open on the network causes a
reflected signal to the node receiver, which can
sometimes be detected. The reflection causes failure
of
the carrier sense or detection of a false collision. Time
domain reflectometry allows estimates of the distance
along the network cable from the node to the fault.
The
TDR Counter counts the number of transmitted bits
before
occurrence of a collision or loss of carrier sense,
whichever comes first. If neither occurs during packet
transmission, the count clears. The elapsed time
represents
twice the signal delay from node to fault. An
open
on the network may cause a false collision, whereas
a short usually causes loss of carrier sense. The TDR
Count
comes from 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.
To
perform the TDR fault test, first enable interrupts for
TX
DONE, by setting DLCR2<7> high. An alternative to
use
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 FF86H to the Receive and T
ransmit 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 enabled. When this occurs, read the
Transmit Status register and the TDR register.
Interpreting
The Results
If
the count is zero, no fault was detected. If the count is
greater than zero, but smaller than the packet length, a
cable
fault my exist. If the count is less than 525, a
real
collision
may have occurred during
test. Real collisions
normally occur within the first 65 bytes of the packet,
including
preamble. Note the error messages, COL
and
CR
LOST
. COL
high suggests a cable open, whereas CR
LOST
suggests a
short. Repeat the measurement several
times,
throw out any anomalous values, and average the
rest. A cluster of readings at about the same value is a
strong indicator of a valid fault measurement. If such a
cluster of readings occurs, multiply the average of the
cluster
by 39 feet to estimate the distance from the node to
the
fault. [39 feet = (100 ns x 0.8 x 186,282 miles/second
x
5280 feet/mile)/2; this assumes the network is mostly
coaxial cable with signal propagation speed of
approximately 0.8 x C, the speed of light.]
HASH
T
ABLE
The Hash Table provides a way to filter incoming
multicast
packets so the host processor need not process
packets
that are not of interest. The principal behind this
filtering process is based on the arrangement of a large
number
of elements of an array
, or database, to facilitate
searching for elements associated with a given key or
datum. The hash function is a mathematical or logical
function
that maps all elements in a domain onto a smaller
domain called the hash table.
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 integer values 0 through
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