zl50400 Zarlink Semiconductor, zl50400 Datasheet - Page 35

• Manufacturer Part Number: zl50400
• Description: Lightly Managed/unmanaged 9-port 10/100 M Ethernet Switch
• Manufacturer: Zarlink Semiconductor

For example, in the above table a 1 denotes that an outgoing port is eligible to receive a packet from an incoming
port. A 0 (zero) denotes that an outgoing port is not eligible to receive a packet from an incoming port.
In this example:
•
•
•
6.0
6.1
When a frame enters the device at the RxMAC, the RxDMA will move the data from the MAC RxFIFO to the FDB.
Data is moved in 8-byte granules in conjunction with the scheme for the SRAM interface.
A switch request is sent to the Search Engine. The Search Engine processes the switch request.
A switch response is sent back to the Frame Engine and indicates whether the frame is unicast or multicast, and its
destination port or ports. On receiving the response, the Frame Engine will check all the QoS related information
and decide if this frame can be forwarded.
A Transmission Scheduling Request is sent in the form of a signal notifying the TxQ manager. Upon receiving a
Transmission Scheduling Request, the device will format an entry in the appropriate Transmission Scheduling
Queue (TxSch Q) or Queues. There are 2 TxSch Q for each RMAC port (and 4 per MMAC and CPU ports), one
for each priority. Creation of a queue entry either involves linking a new job to the appropriate linked list if unicast,
or adding an entry to a physical queue if multicast.
When the port is ready to accept the next frame, the TxQ manager will get the head-of-line (HOL) entry of one of
the TxSch Qs, according to the transmission scheduling algorithm (so as to ensure per-class quality of service).
(The unicast linked list and the multicast queue for the same port-class pair are treated as one logical queue. The
older HOL between the two queues goes first.
The TxDMA will pull frame data from the memory and forward it granule-by-granule to the MAC TxFIFO of the
destination port.
6.2
This section briefly describes the functions of each of the modules of the ZL50400 frame engine.
6.2.1
The FCB manager allocates FCB handles to incoming frames, and releases FCB handles upon frame departure.
The FCB manager is also responsible for enforcing buffer reservations and limits that will be used for QoS control
and source port flow control. The default values can be determined by referring to Section 7.6 on page 39. The
frame buffer is managed in a 128bytes block unit. During initialization, this block will link all the available blocks in a
free buffer list. When each port is ready to receive, this module hands the buffer handle to each requesting port.
The FCB manager will also link the released buffer back into the free buffer list.
The maximum buffer size can be increased from the standard 1518 bytes (1522 with VLAN tag) to up to 4 K bytes.
This is done using BUF_LIMIT, and is enabled on a per port basis via bit [1] in ECR3Pn. See Buffer Allocation
application note, ZLAN-47, for more information.
6.2.2
The Rx interface is mainly responsible for communicating with the RxMAC. It keeps track of the start and end of
frame and frame status (good or bad). Upon receiving an end of frame that is good, the Rx interface makes a switch
request.
Data packets received at port #0 are eligible to be sent to outgoing ports 1 and 2.
Data packets received at port #1 are eligible to be sent to outgoing ports 0 and 2.
Data packets received at port #2 are NOT eligible to be sent to ports 0 and 1.
Data Forwarding Summary
Frame Engine Details
Frame Engine
FCB Manager
Rx Interface
Zarlink Semiconductor Inc.
ZL50400
35
Data Sheet