Processor SDK HSR PRP

Starting in v4.3, Processor SDK documentation is no longer hosted on processors wiki.

Please bookmark the new links:

• Linux, RT-Linux: http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/index.html
• RTOS: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index.html
• Android: http://software-dl.ti.com/processor-sdk-android/esd/docs/latest/android/index.html

Overview

HSR stands for High Availability Seamless Redundancy. This is a protocol used to support redundant networks needed for industrial applications such as factory automation, substation automation etc. The standard is defined in IEC 62439-3 clause 5. HSR Ethernet frames are not compatible with standard Ethernet frames. HSR frames are identified uniquely by the HSR tag. So only HSR frames are possible in the network which is not identifiable by a standard Ethernet device. Factory or field devices are connected to a Double Attached Node HSR (DANH). Typically these nodes are connected in a Ring topology and only DANH compliant nodes can be connected to the HSR network. Other standard Ethernet devices (Singly Attached Nodes, SANs) needs to be connected through a Redundancy Box (RedBox) to work with HSR networks. HSR tag is used to manage redundancy in HSR network.

A DANH node has two ports operated in parallel. A source DANH prefixes a frame passed from its upper layers with an HSR tag to identify frame duplicates and sends the frame over each port.

A destination DANH receives, in the fault-free state, two identical frames (one from each port) within a certain interval. It removes the HSR tag of the first frame before passing it to its upper layers and discards any duplicate. The nodes support the IEEE 802.1D bridge functionality and forward frames from one port to the other, except if they already sent the same frame in that same direction. In particular, the node will not forward a frame that it injected into the ring. A destination node of a unicast frame does not forward a frame for which it is the only destination, except for testing. Frames circulating in the ring carry the HSR tag inserted by the source, which contains a sequence number. The doublet {source MAC address, sequence number} uniquely identifies copies of the same frame.

Figure below shows the structure of a DANH node.

Insert File for DANH Here

PRP stands for Parallel Redundancy Protocol which is another redundancy protocol defined by IEC 62439-3 clause 4. Standard Ethernet devices such as bridges and switches can be connected (SANs) to a PRP network. The PRP frames uses a trailer called RCT (Redundancy Control Trailer) which is treated like a pad by standard network devices. A Double Attached Node PRP (DANP) appends a RCT trailer to the frame to manage redundancy.

A DANP node has two ports that operate in parallel and that are attached to the same upper layers of the communication stack through the Link Redundancy Entity (LRE), as the figure below shows. For the basic communication, the LRE presents toward its upper layers the same interface as a non-redundant network adapter, so the upper layers are unaware of redundancy. The LRE has two tasks: handling of duplicates and management of redundancy. When receiving a frame from the node’s upper layers, the LRE appends a Redundancy Check Trailer (RCT) containing a sequence number to the frame and sends the frame through both ports at nearly the same time. The two frames are nearly identical except for the LAN identifier (and the checksum). The two frames transit through the two LANs with different delays, ideally they arrive at nearly the same time at the destination node. When receiving frames from the network, the LRE forwards the first received frame of a pair to its node’s upper layers and discards the duplicate frame (if it arrives). It removes the RCT if required.

Insert file for DANP here

ICSS PRU firmware for HSR/PRP/PTP

A common firmware is used across TI RTOS and Linux implementations of HSR/PRP. This section describes the firmware details.

Duplicate algorithm and table

Handling duplicate frames is one of the main tasks in HSR and PRP. The LRE must not provide the duplicate of a frame to its upper layer in order to offload the processor. The algorithm for discarding duplicates is not specified in IEC 62439-3. However, the standard mandates that the algorithm must be designed such that it never rejects a legitimate frame, while occasional acceptance of a duplicate can be tolerated.

In HSR, additionally to discarding duplicates destined to the host, a discard operation should also be used to prevent frames from looping in the network. A looping frame is a frame that is never discarded in any node of the network and therefore it keeps looping indefinitely. Normally, such a frame should be dropped by its source node. The function handles the case when a defective HSR device does not filter correctly according to source/destination address. This operation is less critical than the host duplicate discard. It is also specified that any duplicate discard method shall be able to forget an entry identified by the source MAC address and the sequence number after a time EntryForgetTime (default 400ms).

A table holds entries representing frames that have been registered in the LRE, each entry is represented bya frame signature. The signature consists of the source MAC address and the 16 bit sequence number. The sequence number value is incremented by 1 when a frame and its duplicate are sent by a source in an HSR network. This signature allows identifying a frame uniquely. When a frame is received, the list is searched by comparing the frame signature with all entries in the table. If such an entry is found, the frame is a duplicate and shall be discarded. If no entry exists, the frame is the first one received and needs to be forwarded to the application and/or – in case of HSR - to the other port. With a successful forwarding process (frame received with no error), a new entry with the signature of that frame is created in the table.

A linear lookup process is too time consuming; thus Hash algorithms are used to decrease the search time.

Port to Host Duplicate Table

It is used to prevent sending duplicate frames to the upper layers. This table is common for both PRUs. Resource sharing implies that collision (two PRUs accessing the same data) must be handled. Since the table is common to both PRUs, the host duplicate rejection must be done after the EOF is detected in order to avoid rejecting legitimate frames.

Port to Port Duplicate Table

A PRU forwards the frames received from one HSR port to the other HSR port, unless the frame was sent already. Each PRU has its own port duplicate table. A search operation can start before the EOF is detected since the table is not shared between the PRU and is not subject to any modification during the reception of a frame. In order to minimize the load of the PRU after EOF reception, the search operation in the port duplicate table is executed during frame reception. Moreover, this allows to quickly detecting if the frame should be discarded early in the reception process. An insertion in the table is still made only after the EOF is detected, but the operation is much faster since the result of the search operation can used.

Node Table

The node table is a central element of the HSR/PRP mechanism although the standard declares node tables optional. This firmware implements node tables for HSR and PRP. Node table handling is implemented in the PRU and comprises of registering incoming supervision and non-supervision-frames as well as ageing and deleting of old entries. The standard requires updating the node table when a supervision frame is received. Accessing the node table is thus not critical since supervision frames are sent only every 2 seconds. For HSR, to maintain statistics for each source node of the network and to facilitate debugging, the implementation updates the node table for each frame received by the host from a source that has previously sent a supervision frame. A further advantage of this approach is having a similar implementation for HSR and PRP. Indeed, the PRP Standard requires updating the node table, if implemented, for all the incoming frames in order to keep track of the traffic contented to each redundant LAN. The node table is accessible by the host for management purposes. Update- and register operations in the table should be done when the frame is completely received in order to avoid registering erroneous frames.

The node table search/update operation is very critical since it is resource/time consuming (maximum NODE_TABLE_SIZE is 256 entries). In the worst case scenario (node table full), a linear lookup operation in the receiving task could load the PRU too much and in consequence could cause Rx overflow or TX underflow. Moreover the node table is common to both PRUs and since it is accessed often, the resource-sharing management has additional impact on the latency. Optimized linear tables were considered, but the timing remained too critical in the worst case scenario. Hash tables are not considered because it is not allowed to lose entries due to collisions. The implemented solution is a sorted table with a two layer table structure. This allows to significantly optimize the lookup time especially when the table has lots of valid entries.

It is important to notice that in a normal HSR case scenario there are - in average - significantly more successful lookup operations (MAC address found in the table) than insertion and deletion operations. Indeed, insertion operations are only made with a supervision frame. This assumption cannot be made for PRP since all frames can create an entry in the node table. The design is therefore optimized according to this assumption.

Frame duplication from the host

Frames sent by the host must be duplicated and should be sent to both ports nearly at the same time for HSR and PRP. In a simple approach, the host stores the frame in the queue of one PRU, the PRU then waits until both ports are available and finally sends the frame at the same time via both ports. However, this solution is not resource efficient and it increases the latency of one PRU when waiting for the PORT to be ready. Therefore, a solution that off-loads the PRU from the duplication task is implemented: the host driver duplicates the frames and puts a copy to each PRU queue.

The implementation is however not straightforward:

Since the frames are not “linked” to each other, there is no guarantee that the frames are sent by both PRUs within a short interval. The host could control the queue status and only push the frames in the highest priority queue of both PRU when the queues are free. This would force each PRU to send the frame and its duplicate next. Nevertheless, for HSR this solution removes the prioritization of the frame circulating in the HSR ring as a PRU could buffer a high priority frame from the ring due to a lower priority frame sent by the host. Frames circulating in the ring are to be treated with higher priority than frames sent by the host. There is a compromise to be found.

The solution is the following: The host driver duplicates the frame and puts the duplicates in the queues of each PRU. The queue is selected based on the priority of the frame. Each PRU handles the frame independently and we only have the assurance that each frame will be sent out within an unknown interval. The drawback of this solution is the lack of control on when each frame will be sent out. The interval can be bigger than one maximum sized Ethernet frame in this case.

Supervision Frame

Incoming supervision frames are received and processed by the PRU. On reception of a frame, the PRU updates the node table and the statistic counters. For HSR, if the received supervision frame originates from the receiver (i.e. it traversed the whole ring) it is discarded. Otherwise it is sent to the next node in store and forward mode. The reason for using store and forward mode is the following: A supervision frame might trigger the creation of an entry in the node table and this task is time consuming. By sending the frame in store and forward mode, more time is available for this operation while receiving the frame. Each device in an HSR/PRP network sends supervision frames at a constant time interval. Outgoing supervision frames are composed and sent by the host CPU.

Cut-Through for HSR

Cut through happens when switch firmware bypasses the transmit queues and directly copies data from Rx FIFO to Tx FIFO. The concept is explained here

The concept of forwarding frames from HSR port to HSR port when operating in cut-through mode deserves more explanation since the following boundary conditions require a carefully balanced implementation: •Cut-through of a frame shall start as early as possible in order to minimize the propagation delay in each node. The ICSS switch supports starting the cut-through operation after a configurable amount of bytes received. Theoretically, for HSR the minimum number of bytes required is 22 (12 bytes Source-/Destination MAC, 4 bytes VLAN Tag, 6 bytes HSR Tag) in order to have all the necessary data to take the routing decision. The receiving process is optimized to allow cut through as soon as possible depending on the type of the frame ( see start receiving process in 3.2.2 Micro Scheduler). •Duplicates shall not be cut through (i.e. the detection of a duplicate shall be finished before the next node in the ring starts processing the frame) •Detection of duplicates (computing the hash index and scanning a bin in the hash table) is time consuming

Waiting for the duplicate detection before taking the cut through decision would delay the frame too much. Starting to cut-through a frame without port duplicate rejection minimizes the delay and allows starting the receiving process after 14 bytes. Once the cut through of a frame has started, the port duplication rejection process starts. If the frame is identified as duplicate or corrupted, the transmission of the frame is aborted by asserting the TX_RESET which will reset the transmit FIFO and clear all its contents and therefore corrupt the frame being cut-though.

Memory Map

Shared RAM Memory Map

Shared RAM Memory Map

Name of Offset	Description Refer to hsr_prp_firmware.h	Offset in Shared RAM	Size (in bytes)
LRE_Interface_Stats_and_Monitoring	HSR/PRP Firmware Stats - See Table below	0x140	124
INDEX_ARRAY	Index entry for Node Table	0x1E0	144
NODE_TABLE	Node Table for the DANH/DANP	0x1FCO	4132

LRE Interface Stats

Name of Offset	Description Refer to hsr_prp_firmware.h	Offset in Shared RAM (base : 0x140)
LRE_CNT_TX_A	Number of frames successfully sent over port A that are HSR/PRP tagged	4
LRE_CNT_TX_B	Same for Port B	8
LRE_CNT_TX_C	Number of frames successfully sent to Host that are HSR/PRP tagged	12
LRE_CNT_ERRWRONGLAN_A	number of frames with the wrong LAN identifier received on LRE port A	16
LRE_CNT_ERRWRONGLAN_B	Same for Port B	20
LRE_CNT_ERRWRONGLAN_C	Same for Host	24
LRE_CNT_RX_A	number of frames received successfully with HSR or PRP TAG on a LRE port A	28
LRE_CNT_RX_B	Same for Port B	32
LRE_CNT_RX_C	Same for Host	36
LRE_CNT_ERRORS_A	number of frames with errors received on this LRE port A	40
LRE_CNT_ERRORS_B	Same for Port B	44
LRE_CNT_ERRORS_C	Same for Host	48
LRE_CNT_NODES	Number of active nodes in the node table	52
LRE_CNT_PROXY_NODES	Number of active proxy nodes in the node table	56
LRE_CNT_UNIQUE_RX_A	Number of entries in the duplicate detection mechanism on port A for which no duplicate was received	60
LRE_CNT_UNIQUE_RX_B	Same for Port B	64
LRE_CNT_UNIQUE_RX_C	Same for Host	68
LRE_CNT_DUPLICATE_RX_A	Number of entries in the duplicate detection mechanism on port A for which one single duplicate was received	72
LRE_CNT_DUPLICATE_RX_B	Same for Port B	76
LRE_CNT_DUPLICATE_RX_C	Same for Host	80
LRE_CNT_MULTIPLE_RX_A	Number of entries in the duplicate detection mechanism on port A for which more than one duplicate was received	84
LRE_CNT_MULTIPLE_RX_B	Same for Port B	88
LRE_CNT_MULTIPLE_RX_C	Same for Port C	92
LRE_CNT_OWN_RX_A	Number of entries on port A received from device itself	96
LRE_CNT_OWN_RX_B	Same for Port B	100
LRE_DUPLICATE_DISCARD	Number of frame retreive by the host	104
LRE_TRANSPARENT_RECEPTION	Number of frame received without PRP RCT	108
LRE_NODE_TABLE_LOOKUP_ERROR_A	Number of instances where node table look up failed for Port A	112
LRE_NODE_TABLE_LOOKUP_ERROR_B	Same for Port B	116
LRE_NODE_TABLE_FULL	If Node Table is full, this value is incremented	120

PRU0 RAM Memory Map

Name of Offset	Description Refer to hsr_prp_firmware.h	Offset in PRU0 DRAM	Size (in bytes)
DUPLICATE_HOST_TABLE	Duplicate detection table for Host	0x200	6136
NEXT_FREE_ADDRESS_NT_QUEUE	Offset of the queue of the free address for the node table	0x1B00	132
POINTERS_FREE_ADDR_NODETABLE	Offset of the read and write pointer of the free address of the node table(read.w0,write.w2)	0x1B84	4

PRU1 RAM Memory Map

Name of Offset	Description Refer to hsr_prp_firmware.h	Offset in PRU1 DRAM	Size (in bytes)
DUPLICATE_PORT_TABLE_PRU0	Offset of port duplicate table for PRU0 (HSR Only)	0x200	3064
DUPLICATE_PORT_TABLE_PRU1	Offset of port duplicate table for PRU1 (HSR Only)	0xE00	3064
NODE_TABLE_SIZE	Size of the node table [0..128]	0x1C00	4
NODE_TABLE_ARBITRATION	Busy slave flag and busy master flag for 3 lock used to protect the node table	0x1C04	4
DUPLICATE_HOST_TABLE_SIZE	Size and setup (N and M) of duplicate host table	0x1C08	4
DUPLICATE_PORT_TABLE_SIZE	Size and setup (N and M) of duplicate port table	0x1C1C	4
NODE_FORGET_TIME	Time after which a node entry is cleared (10ms resolution)	0x1C20	4
DUPLI_FORGET_TIME	Time after which an entry is removed from the duplicate table (10ms resolution)	0x1C24	4
PATH_BROKEN_NB_FRAM_DIFF	Supervision frame Counter minimum difference to detect a broken path	0x1C28	4
DUPLI_PORT_CHECK_RESO	Time interval to check the port duplicate table	0x1C2C	4
DUPLI_HOST_CHECK_RESO	Time interval to check the host duplicate table	0x1C30	4
NODETABLE_CHECK_RESO	Time interval to check the node duplicate table	0x1C34	4
HOST_TIMER_CHECK_FLAGS	Host | Port	0x1C38	4
HOST_DUPLICATE_ARBITRATION	Arbitration flag for the host duplicate task	0x1C3C	4
ICSS_FIRMWARE_RELEASE	Time counter to trigger the host duplicate table check task	0x1C40	4
RED_FIRMWARE_RELEASE	Time counter to trigger the Node Table check task in firmware	0x1C44	4
SUP_ADDR	Supervision address in HSR	0x1C48	4

TI RTOS

TI RTOS specific details are available at [[1]]

Linux

Linux specific details are available at [[2]]