DP83950BVQB National Semiconductor, DP83950BVQB Datasheet - Page 43
![IC CTRLR RIC REPEATER 160-PQFP](/photos/6/83/68312/14-160-pqfp_sml.jpg)
DP83950BVQB
Manufacturer Part Number
DP83950BVQB
Description
IC CTRLR RIC REPEATER 160-PQFP
Manufacturer
National Semiconductor
Datasheet
1.DP83950BVQB.pdf
(80 pages)
Specifications of DP83950BVQB
Controller Type
Ethernet Repeater Interface Controller
Interface
IEEE 802.3
Voltage - Supply
4.75 V ~ 5.25 V
Current - Supply
380mA
Operating Temperature
0°C ~ 70°C
Mounting Type
Surface Mount
Package / Case
160-MQFP, 160-PQFP
Lead Free Status / RoHS Status
Contains lead / RoHS non-compliant
Other names
*DP83950BVQB
Available stocks
Company
Part Number
Manufacturer
Quantity
Price
Company:
Part Number:
DP83950BVQB
Manufacturer:
NS
Quantity:
43
Company:
Part Number:
DP83950BVQB
Manufacturer:
Texas Instruments
Quantity:
10 000
5 0 Functional Description
Processor Access Cycles
Access to the RIC’s on-chip registers is made via its proces-
sor interface This utilizes conventional non-multiplexed ad-
dress (five bit) and data (eight bit) busses The data bus is
also used to provide data and address information to off
chip display latches during display update cycles While per-
forming these cycles the RIC behaves as a master of its
data bus Consequently a TRI-STATE bi-directional bus
transceiver e g 74LS245 must be placed between the RIC
and any processor bus
The processor requests a register access by asserting the
read ‘‘RD’’ or write ‘‘WR’’ input strobes The RIC responds
by finishing any current display update cycle and asserts the
tri-state buffer enable signal ‘‘BUFFEN’’ If the processor
cycle is a write cycle then the RIC’s data buffers are dis-
abled to prevent contention In order to interface to the RIC
in a processor controlled system it is likely a PAL device will
be used to perform the following operations
1 Locate the RIC in the processor’s memory map (address
2 Generate the RIC’s read and write strobes
3 Control the direction signal for the 74LS245
An example of the processor and display interfaces is
shown in Figure 5 13
6 0 Hub Management Support
The RIC provides information regarding the status of its
ports and the packets it is repeating This data is available in
three forms
1 Counted Events Network events accumulated into the
2 Recorded Events Network events that set bits in the
3 Hub Management Status Packets This is information
The counted and recorded event information is available
through the processor interface This data is port specific
and may be used to generate interrupts via the Event Log-
ging Interrupt ‘‘ELI’’ pin Since the information is specific to
each port each repeater port has its own event record reg-
ister and event counter The counters and event record reg-
isters have user definable masks which enable them to be
configured to count and record a variety of events The
counters and record registers are designed to be used to-
gether so that detailed information i e a count value can
be held on-chip for a specific network condition and more
general information i e certain types of events have oc-
curred may be retained in on-chip latches Thus the user
may configure the counters to increment upon a rapidly oc-
curring event (most likely to be used to count collisions)
and the record registers may log the occurrence of less
frequent error conditions such as jabber protect packets
decode)
RIC’s 16-bit Event Counter Registers
Event Record Registers
sent over the Management Bus in a serial function to be
decoded by an Ethernet Controller board
(Continued)
43
6 1 EVENT COUNTING FUNCTION
The counters may increment upon the occurrence of one of
the categories of event as described below
Potential sources for Counter increment
Jabber Protection (JAB) The port counter increments if
the length of a received packet from its associated port
causes the repeater state machine to enter the jabber pro-
tect state
Elasticity Buffer Error (ELBER) The port counter incre-
ments if a Elasticity Buffer underflow or overflow occurs dur-
ing packet reception The flag is held inactive if a collision
occurs during packet reception or if a phase lock error de-
scribed below has already occurred during the repetition of
the packet
Phase Lock Error (PLER) A phase lock error is caused if
the phase lock loop decoder looses lock during packet re-
ception Phase lock onto the received data stream may or
may not be recovered later in the packet and data errors
may have occurred This flag is held inactive if a collision
occurs
Non SFD Packet (NSFD) If a packet is received and the
start of frame delimiter is not found the port counter will
increment Counting is inhibited if the packet suffers a colli-
sion
Out of Window Collision (OWC) The out of window colli-
sion flag for a port goes active when a collision is experi-
enced outside of the network slot time
Transmit Collision (TXCOL) The transmit collision flag for
a port is enabled when a transmit collision is experienced by
the repeater Each port experiencing a collision under these
conditions is said to have suffered a transmit collision
Receive Collision (RXCOL) The receive collision flag for a
port goes active when the port is the receive source of net-
work activity and suffers a collision provided no other net-
work segments experience collision then the receive colli-
sion flag for the receiving port will be set
Partition (PART) The port counter increments when a port
becomes partitioned
Bad Link (BDLNK) The port counter increments when a
port is configured for 10BASE-T operation has entered the
link lost state
Short Event reception (SE) The port counter increments if
the received packet is less than 74 bits long and no collision
occurs during reception
Packet Reception (REC) When a packet is received the
port counter increments
In order to utilize the counters the user must choose from
the above list the desired statistic for counting This counter
mask information must be written to the appropriate Event
Count Mask Register There are two of these registers the
Upper and Lower Event Count Mask registers For the ex-
act bit patterns of these registers please see Section 8 of
the data sheet
For example if the counters are configured to count network
collisions and the appropriate masks have been set then
whenever a collision occurs on a segment this information
is latched by the hub management support logic At the end
of repetition of the packet the collision status respective to
each port is loaded into that port’s counter This operation
is completely autonomous and requires no processor inter-
vention