ADIN3310BBCZ datasheet(58/86 Pages) AD

58 / 86 page

Data Sheet

ADIN3310/ADIN6310

TSN FUNCTIONALITY

analog.com

Rev. A | 58 of 86

priority traffic to transit a network can vary from a minimum of the

sum of the bridge and cable delays in the path to a maximum of

the previous sum plus a maximum sized frame delay at each hop

(for example, at 1 Gbit with a 1528 byte maximum transmission

unit (MTU), this is a variance of more than 12 μs per hop). With

preemption, this variance is reduced from 1528 byte interfering

frames to 128 byte interfering fragments, or 12+ μs to less than 1.2

μs per hop, or an arrival time jitter reduction of 90%.

Another use for frame preemption is when frames are scheduled

(scheduled traffic is enabled). Typically, guard bands are used to

prevent large frames from interfering with the prompt start of a time

protected channel. When there are large frames in the network,

guard banding can be an inefficient use of network bandwidth

because the guard band size needs to cater to the maximum frame

size. Because frame preemption can fragment large frames into

smaller pieces, it is possible to have much smaller guard bands

and optimize network bandwidth. The preemptable traffic can start

egressing before the start of the smaller guard band and get inter-

rupted to ensure the critical traffic transits on time, with remaining

fragments being allowed to finish their transmissions after the time

window passes.

Traffic—Standard and Express Frames

Standard or express Ethernet frames have a preamble that ends

with SFD or SMD-E, which denotes the beginning of frame data.

The frame ends with a 32-bit CRC.

Traffic—Preemptable Ethernet Frames

Frames to which preemption may be applied have a start fragment

where the preamble ends with an SMD-S denoting the start of

frame. The frame ends with an mCRC. If the mCRC is equal to

the expected CRC, then this is the only fragment (the frame has

not been preempted). If the mCRC is equal to the expected CRC

with the lower 16 bits XOR'ed, this fragment does not finish the

frame, and additional fragments will follow, which tells the receiving

MAC that the frame has been fragmented, and it can expect a

continuation fragment to follow.

The switch receiving MAC always accepts frames with SMD-S and

SMD-C, frames to which preemption has been applied, because the

receive side always has preemption enabled.

The switch transmitting MAC only sends frames with an SMD-S and

SMD-C, frames to which preemption may be or has been applied,

after it has been established that the link partner supports preemp-

tion, and the switch has been instructed to enable preemption for

this link.

Enabling Frame Preemption with Verification

The process of discovering support for preemption is done through

the exchange of additional Ethernet capability type length value

(TLV). When preemption is enabled in the switch, the TLVs adver-

tising preemption capability and status can be observed in the Link

Layer Discovery Protocol (LLDP) frames originating from that port.

Initially, the switch sends an LLDP frame with the TLV, indicating

support of preemption; however, preemption is not enabled or

active at that point in time.

If the switch does not receive an LLDP frame from the link partner

with a TLV indicating support of preemption, the switch does not

enable or activate preemption with the link partner.

If the switch receives an LLDP frame from the link partner with

a TLV indicating support of preemption, then if verification is ena-

bled, the switch changes the LLDP TLV to indicate supported and

enabled but not active, and sends out a verify mPacket (SMD-V

= 0x07). If the link partner sends a response mPacket (SMD-R =

0x19), the switch changes the LLDP TLV to indicate supported,

enabled, and active, and starts to transmit frames from the selected

queues with SMD-S and/or SMD-C.

In the event there was no response frame received, after a timeout,

the switch sends another verify frame, after three fails (no response

from link partner), it stops sending verifies and changes its LLDP

TLV to indicate support only.

The verification process previously described is the expected nor-

mal operation and how the switch is intended to be configured.

There are debug options that allow users to force preemption to

enable, skipping the verification process. In this case, the switch

changes its LLDP TLV to indicate support, enabled, and active, and

sends preemptable traffic from the defined queues. Skipping using

verification should only be done as a debug mode because if the

link partner does not support preemption, the preempted frames

may get dropped as the receiving side may not understand the

SMD values.

The switch supports programmable minimum nonfinal fragment

sizes of 64 bytes, 128 bytes, 192 bytes, and 256 bytes. The APIs

to configure frame preemption are included in SES_preemption.h

header file, which is available as part of the software drivers from

the ADIN6310 product page.

Preemption Statistics

When using frame preemption, the transmit and receive MACs

capture a number of statistics related to operation. All registers

clear on read, and when full, stay at the maximum value and do not

overflow.

Table 32. Per Port Frame Preemption Statistics (Transmit and Receive)

Parameter

Description

Frame Assembly Error Count

Number of frame reassembled with errors

Frame SMD Error Count

Number of frames with SMD errors

Frame Assembly OK Count

Number of frames reassembled successfully

Fragment Count Receive

Number of valid continuation fragments re-

ceived

Fragment Count Transmit

Number of fragments transmitted

ADIN3310BBCZ bảng dữ liệu(PDF) 58 Page - Analog Devices

ADIN3310BBCZ bảng dữ liệu(HTML) 58 Page - Analog Devices

Html Pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86

bảng dữ liệu tải về

Link URL