Innihald fela sig
1 MICROCHIP KSZ9477 Ethernet Switch
2 INNGANGUR
3 ALMENNAR UPPLÝSINGAR
4 HSR SUPPORT
5 HARDWARE HSR
6 HSR SYSTEM IMPLEMENTATION
7 Örflöguupplýsingar
8 Algengar spurningar
9 Skjöl / auðlindir
9.1 Heimildir

Örmerki-LOGO

MICROCHIP KSZ9477 Ethernet Switch

MICROCHIP-KSZ9477-Ethernet-Switch-PRODUCTINNGANGUR

  • This application note introduces the concept of High-availability Seamless Redundancy (HSR), explains how it works, and aims to offer guidance and reference on how to implement it with the KSZ9477 Ethernet switch. This document is intended for users familiar with the HSR protocol and Microchip KSZ9477. It mainly focuses on a single-ring network scenario and does not cover connected-ring scenarios.
  • The performance measurement data shown in this application note is based on:
    • a) EVB-KSZ9477 where an external processor, SAMA5D3, manages the switch
    • b) KSZ9477 EDS2 Daughter Card with SAMA7D65 Curiosity

Köflum

This application note covers the following sections:

Heimildir
Refer to the following documents when using this application note:

  • KSZ9477S 7-Port Gigabit Ethernet Switch with Ring Redundancy, SGMII and RGMII/MII/RMII Interfaces Data Sheet
  • EVB-KSZ9477 Gigabit Ethernet Switch Evaluation Board User’s Guide
  • KSZ9477 EDS2 Daughter Card User Guide
  • SAMA7D65-Curiosity Kit User Guide
  • IEC 62439-3 Clause 5

ALMENNAR UPPLÝSINGAR

Offramboðsvalkostir

  • To protect against communication failure, some Layer 2 redundancy protocols, such as STP/RSTP, Link Aggregation, and DLR, etc. have been developed. All these protocols are normally second/sub-second recovery and do not provide zero-packet loss during switchover.

HSR Overview

  • High-availability Seamless Redundancy is a standard defined in IEC 62439-3 Clause 5, targeting applications that require short reaction time and high availability.
    The typical HSR topology is a ring. The source node duplicates all the frames it wants to send. It sends the frames using two different paths to their destination. In case of one network component failure, such as a link or a node failure, the frames will still reach their destination.
  • Frames forwarding in the ring carry the HSR tag inserted by the source node, which contains a sequence number. The doublet of source MAC address and sequence number uniquely identifies copies of the same frame. See Figure 1.MICROCHIP-KSZ9477-Ethernet-Switch-FIG (1)

HSR Advantages

  • HSR is a low-cost, zero-recovery redundancy protocol. This feature makes it highly suitable for real-time and mission-critical applications. See Table 1.
  • TABLE 1: REDUNDANCY PROTOCOLS COMPARISON
Bókun Switch-Over Time Athugasemdir
Hlekkjasöfnun Minna en 50 ms Only for link failure protection
Spannandi tré Nokkrar sekúndur Commonly used, but has the largest fail-over time (Athugasemd 1)
Hringur tækisstigs Minna en 50 ms Use beacon packets to detect failure.
Parallel Redundancy Protocol Núll Double the switch, cable, and data. This is mostly used in a star topology.
HSR Núll Double data. No single point of failure. This is mostly used in ring topology.
  • Note 1: Do not enable Spanning Tree Protocol (STP) on the HSR ring ports.

HSR SUPPORT

Software HSR Implementation

  • In the software-based HSR implementation, the HSR tag needs to be inserted in every frame sent out. These frames are also duplicated and sent to two ports. When the frame is received, the software needs to check duplicates and drop them. Because of this, the software has to maintain a database for received frames within a certain time.

Hardware HSR Implementation

  • In contrast with pure software implementation, hardware-based HSR implementation allows offloading of some CPU work, such as HSR frame duplication, hardware frame forwarding, and HSR sequence number checking, among others.

Switches that can implement Hardware HSR

  • The Microchip KSZ9477 is a highly recommended Ethernet switch for developing the hardware-based HSR.

HARDWARE HSR

HSR Principle
Below are the two node types used in HSR:

  1. Doubly Attached Node for HSR (DANH): A DANH has two Ethernet ports to connect to one HSR ring. When
    Sending frames, the ANH-node sends a duplicate of each frame into the network, one to each of the directions inthe ring. When receiving, it accepts the first copy and discards the second, thus eliminating the duplicate.
  2. Redundancy Box (RedBox): RedBox is an entity that has three Ethernet ports. Two ports are connected to an HSR ring, and one port is a traditional Ethernet port. RedBoxes are used to connect non-HSR nodes and non-HSR network segments (Single Attached Nodes or SAN) to HSR networks. RedBoxes forwards the frames over
    The ring-like DANH nodes act as proxies for all SANs that access them.

Frame Forwarding In HSR Network
UNICAST FRAME FORWARDING DECISION

  • When a unicast packet reaches the destination node, it is consumed by the receiver and not forwarded. If a unicast frame does not match any node in the ring, it will be dropped and will not be forwarded by one middle-node with the duplicate frame discard function enabled. In case it is forwarded back to the originating node, it is going to be dropped because the source MAC address matches the node address. See Figure 2.
  • FIGURE 2: UNICAST FRAME FORWARDING DECISIONMICROCHIP-KSZ9477-Ethernet-Switch-FIG (2)
  •  MULTICAST/BROADCAST FRAME FORWARDING DECISION: A multicast/broadcast packet is forwarded by each node because there could be multiple potential receivers. Usually, a multicast/broadcast packet is dropped and stopped being forwarded by a middle-node with duplicate frame discard function enabled. If a multicast frame is forwarded back to the originating node, it is dropped because the source MAC address matches the node address. See Figure 3.MICROCHIP-KSZ9477-Ethernet-Switch-FIG (3)
  • KSZ9477 Implementation Algorithm and Programming Figure 4 shows how HSR is implemented with KSZ9477. In this process, the CPU software is required to attach the HSR tag to a packet and send it to both A and B ports with the tail tag mechanism. The KSZ9477 hardware forwards the packet to both port A and port B based on the egress tail tag port map (tail tag will be removed and will not be sent out on the wire). While receiving, KSZ9477 provides the hardware with a duplicate discard functionality
  • FIGURE 4: OVERVIEW OF THE KSZ9477 HSR IMPLEMENTATIONMICROCHIP-KSZ9477-Ethernet-Switch-FIG (4)
  • SELECTING TWO PORTS TO PARTICIPATE IN THE HSR RING. Any two ports of the KSZ9477 may be used as ports for participation in the HSR ring. In a related registers setting, HSR ports are selected by setting two bits, as appropriate, in the HSR Port Map register. For instance, to select port 1 and port 2, bit[6:0] should be set as 0x3.
  • The HSR Port Map register is required to be set once, regardless of its default value.
  • TX PACKET DUPLICATION FROM HOST TO SWITCH. All frames in an HSR network are generated by the CPU software, including the HSR tag and sequence numbers. Tailtagging must be utilized for the CPU to indicate the two destination ports for each generated frame. It is a method that communicates ingress and egress port information between the CPU and the switch. Tail tagging is useful for spanning tree protocol, IGMP/MLD snooping, IEEE 1588, and other applications. The tail tag is inserted at the end of the packet, between the payload and the 4-byte CRC/FCS.
  • To enable tail tagging in a related registers setting, set the Tail Tag Enable bit in a Port Operation Control 0 register at address 0xN020 for port “N”. When this bit is set for one port, that port is referred to as the “host” port. Note that tail tagging applies only to the host port and never to any other ports of the switch. Then, in the two tail tag bytes (which refer to Transmit Tail Tag Format in the KSZ9477S Data Sheet), the host processor adds to each packet and determines the egress ports with bits [6:0]. The Lookup bit 10 should not be set.
  • RX PACKET DUPLICATION DISCARDING
    Hardware-assisted duplicate frame discard is implemented in KSZ9477 by utilizing a two-way set-associative on-chip memory with 512 entries for storing and managing variables relating to received frames. Entries are indexed by a combination of the source and destination addresses, as reduced by a hash function. Tracking is performed independently for each of the two ring ports. For each received frame, the HSR sequence number is extracted and compared to values in the table. If a matching frame has already been received on the other port, the frame is dropped. If not, then standard forwarding rules apply.
    In a related register setting, duplicate discard function is enabled by setting bit 7 in the Global HSR AME Control
    register (0x0644). Meanwhile, bit 6 in the Global HSR AME Control 0 register needs to be turned off.
  •  PREVENTING PACKET LOOP IN THE RING BY SELF-ADDRESS FILTERING. Self-address filtering is used to ensure that frames cannot traverse the ring more than once. When this feature is enabled, the source address of all received frames is compared to the node’s own MAC address. If there is a match, the frame will not be forwarded and will be discarded. In a related register setting, self-address filtering can be enabled for all ports by setting bit 6 in the Switch Lookup Engine Control 1 register. Alternatively, it can be enabled on a per-port basis by setting bit 3 in the Port Control 2 register. Both this port enable bit and the global enable bit must be set to activate self-address filtering. The local MAC address is programmed in the Global Switch MAC Address registers (Switch MAC Address 0 register through Switch MAC Address 5 register).

HSR SYSTEM IMPLEMENTATION

This application note describes the following two sets of KSZ9477 evaluation boards:

Note 1: According to Section 3.1, Software HSR Implementation and Section 3.2, Hardware HSR Implementation,

  1. the bottleneck of HSR highly depends on the CPU’s computing power rather than the KSZ9477 switch. Therefore, the newly designed KSZ9477 EDS2 Daughter Card with SAMA7D65 Curiosity is more recommended.
  2. In the following chapters, “KSZ9477’s EVB” is used to refer to either EVB-KSZ9477 or KSZ9477 EDS2 Daughter Card with SAMA7D65-Curiosity.
  3. Different kernels have different network performance. Higher versions do not always deliver better performance. The CPU’s capability is the most critical factor affecting performance. Which Linux Kernel version customer would select correlates with their production environment configuration.

DANH-Node or RedBox

  • The KSZ9477’s EVB can operate as both a DANH-node and a RedBox in a typical HSR ring topology. Below is an HSR performance report of the EVB-KSZ9477’s EVB.

THE KSZ9477’S EVB OPERATING AS DANH-NODE
Test Topology

  • The operation of EVB-KSZ9477’s EVB as a DANH-NODE in a ring topology is illustrated in Figure 5.
  • FIGURE 5: EVB-KSZ9477’S EVB AS DANH-NODE TEST TOPOLOGYMICROCHIP-KSZ9477-Ethernet-Switch-FIG (5)

Stilling tækis

  • All devices have almost the same configuration, except for IP address/MAC address. On each device, run the commands in Figure 6 for the U-boot prompt:
  • FIGURE 6: COMMANDS FOR UBOOT PROMPT
    • //Note: N=board number
    • setenv ipaddr 192.0.2.10N
    • setenv -f ethaddr 00:10:A1:12:34:0N
    • setenv multi_dev 0
    • setenv eth1_ports 3
    • setenv eth1_proto hsr
    • setenv eth1_vlan 0x7e

Test Design

  • In this scenario, all frames originate from the SAMA5D3/SAMA7D65 processor. Use the iperf3 tool to simulate the TX/RX process of real application traffic. For example, run the iperf3 tool in destination node KSZ9477’s EVB #3 to operate as a server, and run the iperf3 tool in source node KSZ9477’s EVB #1 to operate as a client. UDP is used as a traffic type to measure the bandwidth. In Tests 1 to 6 (shown in Table 2 and Table 3), the difference is the packet length specified by “iperf3 -l.”
    TABLE 2: TEST RESULTS OF EVB-KSZ9477 (WITH SAMA5D63) OPERATING AS DANH-NODE (LINUX® KERNEL 6.6)
    Running iperf3 on Three-piece EVB-KSZ9477 as DANH Bandbreidd Tap/heildardagurtaghrútar
       

    Próf 1

    		 KSZ9477’s EVB #1: iperf3 -c 192.0.2.103 -u -l 16 -t 10 -b 1000M 746 Kbit/sek 0/58247 (0%)
    KSZ9477’s EVB #3: nice -n -20 iperf3 -s 736 Kbit/sek 656/58191 (1.1%)
      Próf 2 KSZ9477’s EVB #1: iperf3 -c 192.0.2.103 -u -l 80 -t 10 -b 1000M 3.81 Mbit/sek 0/59512 (0%)
     

    Mynd

    		 KSZ9477’s EVB #3: nice -n -20 iperf3 -s 3.06 Mbit/sek 11601/59424 (20%)
     

    Próf 3

    		 KSZ9477’s EVB #1: iperf3 -c 192.0.2.103 -u -l 208 -t 10 -b 1000M 9.75 Mbit/sek 0/58596 (0%)
    með
    KSZ9477’s EVB #3: nice -n -20 iperf3 -s 7.37 Mbit/sek 14222/58501 (24%)
    Linux®
    Próf 4 KSZ9477’s EVB #1: iperf3 -c 192.0.2.103 -u -l 464 -t 10 -b 1000M 21.0 Mbit/sek 0/56573 (0%)
    kjarna
    KSZ9477’s EVB #3: nice -n -20 iperf3 -s 17.5 Mbit/sek 9272/56486 (16%)
    6.6
    Próf 5 KSZ9477’s EVB #1: iperf3 -c 192.0.2.103 -u -l 976 -t 10 -b 1000M 42.9 Mbit/sek 0/54894 (0%)
    KSZ9477’s EVB #3: nice -n -20 iperf3 -s 34.3 Mbit/sek 10810/54803 (20%)
     

    Próf 6

    		 KSZ9477’s EVB #1: iperf3 -c 192.0.2.103 -u -l 1464 -t 10 -b 1000M 63.3 Mbit/sek 0/54074 (0%)
    KSZ9477’s EVB #3: nice -n -20 iperf3 -s 46.8 Mbit/sek 14012/53976 (26%)
  • TABLE 3: TEST RESULTS OF KSZ9477S EDS2 DAUGHTER CARD WITH SAMA7D65 CURIOSITY OPERATING AS DANH-NODE (LINUX® KERNEL 6.6)
    Running iperf3 on Three-piece KSZ9477-EDS2 Daughter Card + SA- MA7D65 as DANH Bandbreidd Lost/Total Data- grams
     

     

     

     

     

    Image with

    Linux® kernel 6.6

    		 Próf 1 KSZ9477’s EVB #1: iperf3 -c 192.0.2.103 -u -l16-t 10-b 1000M 3.50 Mbit/sek 0/273332 (0%)
    KSZ9477’s EVB #3: nice -n -20 iperf3 -s 3.50 Mbit/sek 0/273332 (0%)
    Próf 2 KSZ9477’s EVB #1: iperf3 -c 192.0.2.103 -u-l80-t10-b1000M 17.6 Mbit/sek 0/275562 (0%)
    KSZ9477’s EVB #3: nice -n -20 iperf3 -s 17.6 Mbit/sek 0/275562 (0%)
    Próf 3 KSZ9477’s EVB #1: iperf3-c192.0.2.103-u-l208-t10-b1000M 44.2 Mbit/sek 0/265574 (0%)
    KSZ9477’s EVB #3: nice -n -20 iperf3 -s 44.2 Mbit/sek 0/265574 (0%)
    Próf 4 KSZ9477’s EVB #1: iperf3-c192.0.2.103-u-l464-t10-b1000M 97.7 Mbit/sek 0/263146 (0%)
    KSZ9477’s EVB #3: nice -n -20 iperf3 -s 97.7 Mbit/sek 0/263146 (0%)
    Próf 5 KSZ9477’s EVB #1: iperf3-c192.0.2.103-u-l976-t10-b1000M 195 Mbit/sek 0/250293 (0%)
    KSZ9477’s EVB #3: nice -n -20 iperf3 -s 195 Mbit/sek 0/250293 (0%)
    Próf 6 KSZ9477’s EVB #1: iperf3-c192.0.2.103-u-l1464-t10-b1000M 279 Mbit/sek 0/243555 (0%)
    KSZ9477’s EVB #3: nice -n -20 iperf3 -s 279 Mbit/sek 4853/243471 (0%)
  • Table 4 details the iperf3 parameters.
  •  

    TABLE 4: IPERF3 PARAMETERS

    Parameter Skilgreining
    -s Run in Server mode
    -c <host> Run in Client mode, connecting to <host>
    -u Use UDP rather than TCP
    -l Length of buffer to read or write
    -t Time in sections to transmit for
    -b Target bandwidth in bits/sec (0 for unlimited)
  • Table 5 details the iperf3 versions in each setup.
    Uppsetning iperf3 Version
    EVB-KSZ9477 iperf 3.1.3
    KSZ9477 EDS2 Daughter Card with SAMA7D65 Curiosity iperf 3.14 (cJSON 1.7.15)
    PC1 & PC2 (Linux® Ubuntu 22.04) iperf 3.9 (cJSON 1.7.13)

THE KSZ9477’S EVB OPERATING AS REDBOX

Test Topology

  • The operation of KSZ9477’s EVB as a RedBox in a ring topology is shown in Figure 7.
  • FIGURE 7: KSZ9477’S EVB AS REDBOX TEST TOPOLOGYMICROCHIP-KSZ9477-Ethernet-Switch-FIG (6)
  • Stilling tækis
  • All devices have almost the same configuration, except for IP address/MAC address. On each device, run the following commands on the U-Boot prompt. See Figure 8.
  • FIGURE 8: DEVICE CONFIGURATION COMMANDS
    • //N=board number
    • setenv ipaddr 192.0.2.10N
    • setenv -f ethaddr 00:10:A1:12:34:0N
    • setenv multi_dev 1
    • setenv eth1_ports 3
    • setenv eth1_proto hsr
    • setenv eth1_vlan 0x7e
    • setenv eth2_proto redbox
    • setenv eth2_vlan 0x7f

Test Design

  • In this scenario, iperf3 running on PCs is used to simulate SANs (Singly Attached Nodes), which rely on RedBox to work with HSR networks. We use “iperf3 -b” in Test cases 1 to 6 (shown Table 6 and Table 7) to specify the maximum bandwidth for different packet lengths in order to guarantee no packet loss with RedBox operation.
  • TABLE 6: TEST RESULTS OF EVB-KSZ9477 (WITH SAMA5D63) OPERATING AS REDBOX (LINUX® KERNEL 6.6)
    Running iperf3 on Three-piece EVB-KSZ9477 as RedBox Bandbreidd Tap/heildardagurtaghrútar Pakkastærð (bæti) Hámarks afköst
       

    Próf 1

    		 PC1 – iperf3 client iperf3 -c 192.0.2.4 -u -l 64 -t 10 -b 10.5M 10.5 Mbit/sek 0/205064 (0%)  

    64 bæti

    		  

    10.5 Mbps
    PC2 – iperf3 server nice -n -20 iperf3 -s 10.5 Mbit/sek 0/205064 (0%)
       

    Próf 2

    		 PC1 – iperf3 client iperf3 -c 192.0.2.4 -u -l 128 -t 10 -b 25.8M 25.8 Mbit/sek 0/251933 (0%)  

    128 bæti

    		  

    25.6 Mbps
    PC2 – iperf3 server nice -n -20 iperf3 -s 25.6 Mbit/sek 0/251933 (0%)
    Image with  

    Próf 3

    		 PC1 – iperf3 client iperf3 -c 192.0.2.4 -u -l 256 -t 10 -b 51.5M 51.5 Mbit/sek 0/251448 (0%)  

    256 bæti

    		  

    51.3 Mbps
    PC2 – iperf3 server nice -n -20 iperf3 -s 51.3 Mbit/sek 0/251448 (0%)
    Linux®      
      PC1 – iperf3 client iperf3 -c 192.0.2.4 -u -l 512 -t 10 -b 101M 101 Mbit/sek 0/247785 (0%)    
    kernel 6.6 Próf 4 512 bæti 101 Mbps
    PC2 – iperf3 server nice -n -20 iperf3 -s 101 Mbit/sek 0/247785 (0%)
       

    Próf 5

    		 PC1 – iperf3 client iperf3 -c 192.0.2.4 -u -l 1024 -t 10 -b 197M 197 Mbit/sek 0/240462 (0%)  

    1024 bæti

    		  

    196 Mbps
    PC2 – iperf3 server nice -n -20 iperf3 -s 196 Mbit/sek 0/240462 (0%)
       

    Próf 6

    		 PC1 – iperf3 client iperf3 -c 192.0.2.4 -u -l 1448 -t 10 -b 275M 275 Mbit/sek 0/237382 (0%)  

    1464 bæti

    		  

    274 Mbps
    PC2 – iperf3 server nice -n -20 iperf3 -s 274 Mbit/sek 0/237382 (0%)
  • TABLE 7: TEST RESULTS OF KSZ9477S EDS2 DAUGHTER CARD WITH SAMA7D65 CURIOSITY OPERATING AS REDBOX (LINUX® KERNEL 6.6)
    Running iperf3 on Three-piece KSZ9477S EDS2 Daughter Card+ SAMA7D65 as RedBox Bandbreidd Tap/heildardagurtaghrútar Pakkastærð (bæti) Hámarks afköst
       

    Próf 1

    		 PC1 – iperf3 client iperf3 -c 192.0.2.4-u -l 64-t 10-b 36M 36.0 Mbit/sek 0/703102 (0%)  

    64

    		  

    35.9 Mbps
    PC2 – iperf3 server nice -n -20 iperf3 -s 35. Mbits/sec9 0/703102 (0%)
       

    Próf 2

    		 PC1 – iperf3 client iperf3 -c 192.0.2.4 -u-l 128-t 10-b 84M 84. Mbits/sec0 0/820259 (0%)  

    128

    		  

    83.7 Mbps
    PC2 – iperf3 server nice -n -20 iperf3 -s 83. Mbits/sec7 0/820259 (0%)
    Image with  

    Próf 3

    		 PC1 – iperf3 client iperf3-c192.0.2.4-u-l 256-t 10-b 185M 185 Mbit/sek 0/903265 (0%)  

    256

    		  

    184 Mbps
    PC2 – iperf3 server nice -n -20 iperf3 -s 184 Mbit/sek 0/903265 (0%)
    Linux®      
      PC1 – iperf3 client iperf3-c192.0.2.4-u-l 512-t 10-b 367M 367 Mbit/sek 0/895934 (0%)    
    kernel 6.6 Próf 4 512 366 Mbps
    PC2 – iperf3 server nice -n -20 iperf3 -s 366 Mbit/sek 0/895934 (0%)
       

    Próf 5

    		 PC1 – iperf3 client iperf3-c192.0.2.4-u-l 1024-t 10-b 842M 842 Mbit/sek 0/1027771 (0%)  

    1024

    		  

    839 Mbps
    PC2 – iperf3 server nice -n -20 iperf3 -s 839 Mbit/sek 0/1027771 (0%)
       

    Próf 6

    		 PC1 – iperf3 client iperf3-c192.0.2.4-u-l 1448-t 10-b 945M 945 Mbit/sek 0/815730 (0%)  

    1464

    		  

    941 Mbps
    PC2 – iperf3 server nice -n -20 iperf3 -s 941 Mbit/sek 0/815730 (0%)

KSZ9477 CHIP LIMITATIONS

  • Software is required to implement the duplicate discard function when the number of nodes is even and the HW-based duplicate discard is enabled in the switch. The switch has to know that a packet has come before it can determine that a duplicate happened the next time the same packet arrives again. The arrival of the first packet is recognized at the end of its transmission, while the second packet is looked up just after the VLAN tag is received. For instance, the duplicate packet arrives before the first packet is completely received (so the recognition of the first packet has not happened yet). Given this situation, the switch does not have the record to remove the duplicated packet. This only happens when these two packets overlap inside the switch. Therefore, the difference between the arrival times of the two packets would probably be either in ns or μs. For example, a 64-byte packet has the packet receiving time of (8 + 64) x 80 ns = 5.76 μs for a 100 Mbps port. The first packet arrived. If the first 24 bytes of the duplicate packet arrive before the previous packet is completely received, the first packet cannot be discarded. In this case, the second packet needs to arrive at least (8 + 64 – 24) x 80 ns = 3.84 μs later than the first packet’s arrival. There is a shorter time required in the Gigabit port (1/10 of it), but this depends on the length of the packet.
    This scenario happens when both the original packet and the duplicate packet enter the switch at about the same
    moment (with only ns-to-μs level difference), so the device cannot handle it. It should not happen frequently in network rings of more than 2 nodes. With the duplicate discard function enabled in the switch, it will remove most of the
    duplicate packets, and the software just needs to handle the rest of the packets.
  • Some MAC controllers do not understand the HSR tag, so hardware checksum generation may fail, and the function has to be disabled. This affects the network performance for UDP and especially TCP packets when running on Linux.

PROCESSOR SELECTION

  • When a device such as EVB-KSZ9477 operates as DANH in the TX direction, all application traffic originates from the CPU. The CPU is also expected to add an HSR tag on all application traffic. In the RX direction, the CPU is responsible for stripping the HSR tag before delivering traffic back tothe  application layer.
  • When a device like EVB-KSZ9477 operates as RedBox, the CPU plays a traffic relay role between the Non-HSR network and the HSR network. In particular, the CPU relays traffic in a software bridging manner. The CPU also handles the work of adding and removing the HSR tag. Therefore, both conditions above show that the HSR bandwidth performance is limited to the capabilities of the CPU processor, so choosing the most suitable processor is crucial to achieving optimum results.
  • APPENDIX A: APPLICATION NOTE REVISION HISTORY
  • TAFLA A-1: ​​ENDURSKOÐARSAGA
    Endurskoðunarstig og dagsetning Hluti/mynd/færsla Leiðrétting
    DS00003474B (09-25-2025) Kafli 1.0, Inngangur Added KSZ9477S EDS2-related information
    Section 1.2, References Added KSZ9477S EDS2 and SAMA7D65 Curiosity- related reference documents
    Section 5.0, HSR System Framkvæmd Added KSZ9477S EDS2 and SAMA7D65 Curiosity- related information
    Section 5.1, DANH-Node or Rauðkassinn Redesigned the test case based on a new setup and topology
    Allt Made minor formatting updates
    DS00003474A (05-20-2020) Upphafleg útgáfa

Örflöguupplýsingar

  • Trademarks The “Microchip” name and logo, the “M” logo, and other names, logos, and brands are registered and unregistered trademarks of Microchip Technology Incorporated or its affiliates and/or subsidiaries in the United States and/or other countries (“Microchip Trademarks”). Information regarding Microchip Trademarks can be found at https://www.microchip.com/en-us/about/legal-information/microchiptrademarks. ISBN: 979-8-3371-2056-0
    Lagatilkynning
  • Þessa útgáfu og upplýsingarnar hér má aðeins nota með vörum frá Microchip, þar á meðal til að hanna, prófa og samþætta vörur frá Microchip við forrit þitt. Notkun þessara upplýsinga á annan hátt brýtur gegn þessum skilmálum. Upplýsingar varðandi forrit tækja eru eingöngu veittar til þæginda fyrir þig og geta verið leystar af hólmi með uppfærslum. Það er þín ábyrgð að tryggja að forritið þitt uppfylli forskriftir þínar. Hafðu samband við söluskrifstofu Microchip á þínu svæði til að fá frekari aðstoð eða fáðu frekari aðstoð á www.microchip.com/en-us/support/design-help/client-support-services.
    THIS INFORMATION IS PROVIDED BY MICROCHIP “AS IS”. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND, WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ANY IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY, AND  FITNESS FOR A PARTICULAR PURPOSE, OR WARRANTIES RELATED TO ITS CONDITION, QUALITY, OR PERFORMANCE. IN NO EVENT WILL MICROCHIP BE LIABLE FOR ANY INDIRECT, SPECIAL, PUNITIVE, INCIDENTAL, OR CONSEQUENTIAL LOSS, DAMAGE, COST, OR EXPENSE OF ANY KIND WHATSOEVER RELATED TO THE INFORMATION OR ITS USE, HOWEVER CAUSED, EVEN IF MICROCHIP HAS BEEN ADVISED OF THE POSSIBILITY OF THE DAMAGES ARE FORESEEABLE. TO THE FULLEST EXTENT ALLOWED BY LAW, MICROCHIP’S TOTAL LIABILITY ON ALL CLAIMS IN ANY WAY RELATED TO THE INFORMATION OR ITS USE WILL NOT EXCEED THE AMOUNT OF FEES, IF ANY, THAT YOU HAVE PAID DIRECTLY TO MICROCHIP FOR THE INFORMATION.
    Use of Microchip devices in life support and/or safety applications is entirely at the buyer’s risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights unless otherwise stated. Microchip Devices Code Protection Feature
    Athugaðu eftirfarandi upplýsingar um kóðaverndareiginleikann á Microchip vörum:
    • Örflöguvörur uppfylla forskriftirnar í tilteknu örflögugagnablaði þeirra.
    • Microchip telur að vöruflokkur þess sé öruggur þegar þær eru notaðar á tilsettan hátt, innan rekstrarforskrifta og við venjulegar aðstæður.
    • Örflögu metur og verndar hugverkaréttindi sín ákaft. Tilraunir til að brjóta kóða verndareiginleika Microchip vara eru stranglega bannaðar og geta brotið gegn Digital Millennium Copyright Act.
    • Hvorki Microchip né nokkur annar hálfleiðaraframleiðandi getur ábyrgst öryggi kóðans. Kóðavernd þýðir ekki að við tryggjum að varan sé „óbrjótanleg“. Kóðavernd er í stöðugri þróun. Microchip hefur skuldbundið sig til að bæta stöðugt kóðaverndareiginleika vara okkar

Kóðaverndareiginleiki örflögutækja Athugaðu eftirfarandi upplýsingar um kóðaverndareiginleikann á örflöguvörum:

  • Örflöguvörur uppfylla forskriftirnar í tilteknu örflögugagnablaði þeirra.
  • Microchip telur að vöruflokkur þess sé öruggur þegar þær eru notaðar á tilsettan hátt, innan rekstrarforskrifta og við venjulegar aðstæður.
  • Örflögu metur og verndar hugverkaréttindi sín ákaft. Tilraunir til að brjóta kóða verndareiginleika Microchip vara eru stranglega bannaðar og geta brotið gegn Digital Millennium Copyright Act.
  • Hvorki Microchip né nokkur annar hálfleiðaraframleiðandi getur ábyrgst öryggi kóðans. Kóðavernd þýðir ekki að við tryggjum að varan sé „óbrjótanleg“. Kóðavernd er í stöðugri þróun. Microchip hefur skuldbundið sig til að bæta stöðugt kóðaverndareiginleika vara okkar.

Algengar spurningar

Q: What is the typical topology for HSR?

A: The typical HSR topology is a ring where source nodes duplicate frames and send them through two paths for redundancy.

Q: How does HSR compare to other redundancy protocols?

A: HSR offers zero switchover time and doubles data without single points of failure, making it ideal for ring topologies.

Skjöl / auðlindir

MICROCHIP KSZ9477 Ethernet Switch [pdfLeiðbeiningar
EVB-KSZ9477, KSZ9477, SAMA5D3, KSZ9477 Ethernet Switch, KSZ9477, Ethernet Switch, Switch

Heimildir

Skildu eftir athugasemd

Netfangið þitt verður ekki birt. Nauðsynlegir reitir eru merktir *