Document ID: FLXU057

Flexibilis Redundant Switch

(FRS)

Manual
This document could contain technical inaccuracies or typographical errors. Flexibilis Oy may
make changes in the product described in this document at any time.

Please, email comments about this document to [email protected].

Copyright Flexibilis Oy 2002-2013. All rights reserved.

Trademarks

All trademarks are the property of their respective owners.

FRS

Contents
1 About this Document ............................................................................................................7
2 General Overview ..................................................................................................................9
2.1 FRS Features ................................................................................................................9
2.1.1 Interface between MAC and PHY ................................................................ 10
2.1.2 Host System Interface .................................................................................. 10
3 Introduction to Ethernet and Switching ........................................................................... 11
3.1 Ethernet Media Access Control (MAC) ...................................................................... 11
3.1.1 Preamble and Start Frame Delimiter (SFD) ................................................. 11
3.1.2 Header .......................................................................................................... 12
3.1.3 CRC .............................................................................................................. 12
3.1.4 Media Independent Interface (MII/GMII) ...................................................... 12
3.2 Media Access Control (MAC) Bridge ......................................................................... 12
3.2.1 MAC Address Table ..................................................................................... 13
3.2.2 Shared Media versus Dedicated Media ....................................................... 13
3.2.3 Cut-through versus Store-and-Forward Operation ...................................... 13
3.2.4 Spanning Tree Protocol................................................................................ 14
3.3 Precision Time Protocol ............................................................................................. 14
3.3.1 Transparent Clock ........................................................................................ 14
3.4 HSR (High-availability Seamless Redundancy) ........................................................ 15
3.4.1 HSR Node Types ......................................................................................... 17
3.5 Parallel Redundancy Protocol (PRP)......................................................................... 18
3.5.1 PRP Node Types .......................................................................................... 19
4 Functional Description ....................................................................................................... 20
4.1 Inbound Processing ................................................................................................... 23
4.1.1 RX MII........................................................................................................... 23
4.1.2 Timestamp .................................................................................................... 24
4.1.3 RX Pre-process ............................................................................................ 24
4.1.4 Forwarding Decision ..................................................................................... 24
4.1.5 Inbound Policy .............................................................................................. 24
4.1.5.1 Priority-setting ............................................................................. 25
4.1.6 Precision Time Protocol ............................................................................... 25
4.1.6.1 End-to-end Transparent Clock Functionality .............................. 25
4.1.6.2 Peer-to-Peer Transparent Clock Support ................................... 25
4.1.7 Management Trailer ..................................................................................... 25
4.1.8 MAC Address Table ..................................................................................... 26
4.1.8.1 Address Table Entry ................................................................... 27
4.1.8.2 Address Learning ........................................................................ 27
4.1.8.3 Address Aging ............................................................................. 29
4.1.8.4 MAC Address and Forward Decision .......................................... 30
4.1.8.5 Port-based VLAN ........................................................................ 31
4.1.8.6 Forward Portmask ....................................................................... 32
4.2 Outbound Processing ................................................................................................ 33
4.2.1 TX Post-process ........................................................................................... 34
4.2.2 TX MII ........................................................................................................... 34
4.2.3 Timestamp .................................................................................................... 34
4.2.4 PTP Overwrite .............................................................................................. 34
4.3 Forwarding Core ........................................................................................................ 34
4.3.1 Memory Controller ........................................................................................ 34
4.3.2 Priority Queues ............................................................................................. 35
4.3.3 Core RX ........................................................................................................ 35
4.3.4 Core TX ........................................................................................................ 36
4.3.5 Frame Early Drop ......................................................................................... 36
4.4 HSR (High-availability Seamless Redundancy) ........................................................ 38
4.4.1 Forwarding of HSR Frames ......................................................................... 38

Manual 3 (68) Version 2.10

FRS

4.4.2 HSR Port Modes .......................................................................................... 40

4.5 PRP (Parallel Redundancy Protocol)......................................................................... 40
4.5.1 Forwarding of PRP Frames .......................................................................... 40
4.6 MDIO Controller ......................................................................................................... 41
4.6.1 PHY Initialization .......................................................................................... 43
4.7 IP License Authentication .......................................................................................... 43
4.8 Reset .......................................................................................................................... 43
4.8.1 Software Reset ............................................................................................. 43
4.8.2 Hardware Reset ........................................................................................... 43
5 Configuration Registers ..................................................................................................... 44
5.1 Indirect Register Access ............................................................................................ 45
5.2 FRS MDIO Registers ................................................................................................. 45
5.3 FRS Configuration Registers ..................................................................................... 46
5.3.1 FRS Switch Configuration Registers ............................................................ 47
5.3.1.1 General Switch Configuration Registers ..................................... 47
5.3.2 FRS Port Configuration Registers ................................................................ 51
5.3.2.1 General Configuration and State Registers ................................ 51
5.3.2.2 HSR/PRP Registers .................................................................... 52
5.3.2.3 PTP Registers ............................................................................. 53
5.3.2.4 Inbound Policy Registers ............................................................ 54
6 External Signals .................................................................................................................. 56
6.1 Generics ..................................................................................................................... 57
6.2 General Signals ......................................................................................................... 57
6.3 Time Interface Signals ............................................................................................... 58
6.4 Authentication Interface Signals ................................................................................ 59
6.5 MII/GMII Signals ........................................................................................................ 60
6.6 MDIO Interface........................................................................................................... 61
6.7 Transmit Clock Multiplexer ........................................................................................ 65
6.7.1 Interfacing to CPU with MII/GMII .................................................................. 65
7 Glossary .............................................................................................................................. 67
8 References .......................................................................................................................... 68

Figures
Figure 1. Bit and Byte Order ...................................................................................................... 7
Figure 2. FRS Overview ............................................................................................................ 9
Figure 3. Ethernet Frame Formats .......................................................................................... 11
Figure 4. HSR Ring Example with Unicast Message .............................................................. 15
Figure 5. HSR Ring Example with Multicast Message ............................................................ 16
Figure 6. HSR Tagged frame .................................................................................................. 17
Figure 7. QuadBox .................................................................................................................. 17
Figure 8. PRP Double LAN ...................................................................................................... 18
Figure 9. PRP Frame ............................................................................................................... 19
Figure 10. FRS Block Diagram ................................................................................................ 20
Figure 11. FRS Forwarding Path ............................................................................................. 21
Figure 12. FRS Inbound and Outbound Processing Blocks .................................................... 22
Figure 13. Ethernet Frame Timestamp Point .......................................................................... 23
Figure 14. Ethernet Frame with Management Trailer.............................................................. 26
Figure 15. MAC Address Entry ................................................................................................ 27
Figure 16. Address Learning ................................................................................................... 28
Figure 17. Address Aging ........................................................................................................ 29
Figure 18. Address Search (+ Port Based VLAN) ................................................................... 31
Figure 19. Address Search (+ Forward Portmask) .................................................................. 33
Figure 20. Priority Queues (only three ports shown) ............................................................... 35
Figure 21. Frame Early Drop Algorithm ................................................................................... 37

Manual 4 (68) Version 2.10

FRS

Figure 22. HSR Ring Port Forwarding Logic ........................................................................... 39

Figure 23. PRP Port Forwarding Logic .................................................................................... 41
Figure 24. MDIO Controller ..................................................................................................... 42
Figure 25. PHY Access from CPU through FRS ..................................................................... 42
Figure 26. MDIO Register Access ........................................................................................... 44
Figure 27. Indirect Read .......................................................................................................... 45
Figure 28. Indirect Write .......................................................................................................... 45
Figure 29. External Signals of FRS ......................................................................................... 56
Figure 30. (G)MII signal timing for signal port ......................................................................... 60
Figure 31. MDIO MMD Signal Timing Diagram ....................................................................... 63
Figure 32. MDIO STA Signal Timing Diagram ........................................................................ 64
Figure 33. External Transmit Clock Multiplexer ....................................................................... 65
Figure 34. Host Interface Connection ...................................................................................... 66

Tables
Table 1. FRS MDIO Registers ................................................................................................. 46
Table 2. FRS Switch Configuration Register Groups .............................................................. 47
Table 3. General Switch Configuration Registers ................................................................... 49
Table 4. FRS Port Configuration Register Groups .................................................................. 51
Table 5. General Configuration and State Registers ............................................................... 52
Table 6. HSR Registers ........................................................................................................... 53
Table 7. PTP Registers ........................................................................................................... 53
Table 8. Inbound Policy Registers ........................................................................................... 55
Table 9. FRS Generics ............................................................................................................ 57
Table 10. General Signals ....................................................................................................... 58
Table 11. Time Interface Signals ............................................................................................. 59
Table 12. MII/GMII Signals ...................................................................................................... 61
Table 13. MDIO Station Management Signals ........................................................................ 62
Table 14. MDIO Manageable Device Signals ......................................................................... 62
Table 15. MII/GMII Clock Mux Configuration .......................................................................... 66

Manual 5 (68) Version 2.10

FRS

Revision History
Rev Date Description
1.0 13.6.2011 First release.
1.1 14.10.2011 Minor improvements.
1.2 14.3.2012 - HSR configuration register modified
- Configuration pins defined to give system clock frequency
- PRP added
- HSR updates
2.0 23.3.2012 Approved
2.1 1.6.2012 HSR_CFG register clarifications (Table 6)
2.2 11.6.2012 Added IEEE 1588 Layer 2 functionality and Peer-to-peer transparent clock
2.3 13.6.2012 Support for link local traffic without HSR tag or PRP trailer
HSR_CFG register updates (Table 6)
2.4 28.6.2012 HSR_CFG register correction (Table 6)
2.5 29.6.2012 Changed PTP mode bits
2.6 15.8.2012 Minor changes
2.7 25.9.2012 Clock interface changed.
2.8 14.12.2012 Inbound Policy (IPO) registers changed.
2.9 29.1.2013 FES-HSR renamed to FRS
2.10 7.2.2013 IP License Authentication added

Manual 6 (68) Version 2.10

FRS

1 About this Document

This document describes Flexibilis Redundant Switch (FRS). FRS is an Ethernet switch
Intellectual Property (IP) core targeted at programmable hardware platforms. It is also
possible to integrate FRS into an ASIC. FRS is written in VHDL language.
This document is targeted for current and potential users of FRS. This includes those who are
designing software employing the functions of FRS, and those who are evaluating the
usability of FRS in their system or project. This documentation is not targeted at those who
want to make changes in the implementation of FRS, and therefore this document does not
cover detailed information about the internal implementation of FRS. The internal
implementation details are documented in Flexibilis Ethernet Switch/Router Specification [1].
FPGA tools and their usage is also out of the scope of this document.
Chapter 2 gives a general overview of FRS: what it is, what can be done with it, and what are
the main features of it. Chapter 3 contains a short introduction to Ethernet and switching in
general and chapter 4 describes FRS functionality in more detail. Chapter 5 defines the
register map of FRS and Chapter 6 defines the external signals. Chapter 7 contains a
glossary and chapter 8 contains the references.
Register descriptions in this document follow the following rules: unless otherwise stated, all
bits that activate or enable something are active when their value is 1 and inactive when their
value is 0. The explanation of the bit types is the following:
 RO = Read Capable Only. The bits marked with RO can be read. Writing to these bits is
allowed unless otherwise stated. If writing is allowed, it does not affect the value of the bit.
 R/W = Read and Write capable. The bits can be read and written. Writing 1 to the bit
makes its value 1. Writing 0 to the bit makes its value 0.
 R/C = Read and Clear capable. The bits can be read and cleared. Writing 0 to the bit
makes its value 0. Writing 1 does nothing.
 R/SC = Read, Write and Self Clear. The bits can be read and written. Writing 0 to the bit
does nothing. Writing 1 to the bit makes its value 1 for a while, but after that the value
automatically returns back to 0.
The bits marked as Reserved should not be written anything but 0, even if they are marked as
read capable only, because their function may change in future versions.
Bit and byte order used for 16, 32 and 64 registers is depicted in Figure 1.

Bit 15 8 7 0
16bit Bus
or Byte 1 Byte 0
Register:
MSB LSB

Bit 31 24 23 16 15 8 7 0
32bit Bus
or Byte 3 Byte 2 Byte 1 Byte 0
Register:
MSB LSB

Bit 63 56 55 48 47 40 39 32 31 24 23 16 15 8 7 0
64bit Bus
or Byte 7 Byte 6 Byte 5 Byte 4 Byte 3 Byte 2 Byte 1 Byte 0
Register:
MSB LSB

Figure 1. Bit and Byte Order

Signal names are written in this document in signal_name style. Block names are written
with Capital first letter. Pseudo code is written in PseudoCode style and command line

Manual 7 (68) Version 2.10

FRS

commands are written in CommandLine style. References are marked in the document in
[brackets].

Manual 8 (68) Version 2.10

FRS

2 General Overview
FRS is an Ethernet switch IP block designed to be used in programmable System on Chip
(SoC) environments. FRS includes multiple Ethernet Media Access Controller (MAC)
functional entities and provides MII/GMII interfaces for Ethernet PHY devices and optionally
for a host system CPU (see Figure 2). FRS also supports MDIO interfaces for the host CPU
to be able access the registers of FRS and for FRS to poll the status of the connected PHY
devices.

Off-Chip On-Chip Host system

HSR ring ports

10/100/1000 Mbps
Ethernet Medium

MII/GMII
PHY MAC Registers

MDIO STA MMD MDIO

10/100/1000 Mbps
Ethernet Medium

MII/GMII
MII/GMII
PHY MAC MAC CPU
FRS

Interlink/
maintenance
port
10/100/1000 Mbps
Ethernet Medium

MII/GMII
PHY MAC

Figure 2. FRS Overview

2.1 FRS Features

FRS standard features include:
 10/100/1000 Mbit/s Full-Duplex Ethernet interfaces (IEEE 802.3x [2])
 Compatible with IEEE standard 802.1D Media Access Control (MAC) Bridges [3]
 Media Independent Interfaces (MII) and Gigabit Media Independent Interfaces (GMII)
for attaching to external Physical Layer devices (PHY) and host system CPU(s)
 Management Data Input/Output (MDIO) controller for PHY and switch management,
automatic polling of connected PHY devices
 Register interface for accessing control and status registers
 Ethernet packet forwarding at wire-speed, non-blocking
 PTPv2 end-to-end one-step transparent clock [4] processing at hardware

Manual 9 (68) Version 2.10

FRS

 PTPv2 peer-to-peer transparent clock [4] support functions

 Ethernet packet filter and prioritization on each of the ports
 Compatible with IEC 62439-3 ”High-availability Seamless Redundancy (HSR)”
 Compatible with IEC 62439-3 ”Parallel Redundancy Protocol (PRP)”

2.1.1 Interface between MAC and PHY

FRS supports Media Independent Interface (MII) and Gigabit Media Independent Interface
(GMII). GMII is used only when an Ethernet port is in 1000 Mbps operating mode; In 10 Mbps
and 100 Mbps operating modes FRS uses MII interface.
GMII interface contains more signals than MII interface, for example receive and transmit data
paths are four bits wider. The signals that exist in both GMII interface and MII interface share
the same signals in FRS.
Reduced pin count interfaces (RMII and RGMII) are supported by using external (to FRS) MII-
to-RMII and GMII-to-RGMII adapter blocks at the FPGA. Serial SGMII interfaces are
supported with GMII-to-SGMII adapters.

2.1.2 Host System Interface

FRS has one special Ethernet interface that can be connected to a host system CPU. This
interface of FRS is called a management port. The management port has, along with MII and
GMII interfaces, an MDIO interface that can be used to configure FRS and the connected
PHY devices by accessing their MDIO registers.
By using the management port it is also possible to send/receive packets to/from any other
port independent from the MAC address table and other configurations.

Manual 10 (68) Version 2.10

FRS

3 Introduction to Ethernet and Switching

This chapter contains an introduction to the functionality provided by FES, including Ethernet,
Ethernet switching, Precision Time Protocol (IEEE 1588v2) and High-availability Seamless
Redundancy (HSR).

3.1 Ethernet Media Access Control (MAC)

The Media Access Control (MAC) protocol is used to provide the data link layer of Ethernet
protocol. The MAC protocol encapsulates data by adding a 14 byte header before the payload
and a 32 bit Cyclic Redundancy Check (CRC) checksum after the payload. In addition to this,
there is a 7 byte preamble and a 1 byte Start Frame Delimiter (SFD) before the header, see
Figure 3.
In case of Virtual LAN (VLAN) tagging being used, the header is 4 bytes longer because of an
additional type field and a VLAN tag. This also increases the Ethernet frame‟s maximum
length from 1518 bytes to 1522 bytes (without preamble and SFD). This means that an
Ethernet Bridge should support forwarding of a maximum length of 1522 byte frames.
14 bytes
1
7 bytes 6 bytes 6 bytes 2B 46-1500 bytes 4B
B

S
destination source
802.3 preamble F type data payload CRC
address address
D

64-1518 bytes

14 bytes
1
7 bytes 6 bytes 6 bytes 2B 2B 46-1500 bytes 4B
B

S
destination source VLAN
802.1Q preamble F TCI data payload CRC
address address TPID
D

68-1522 bytes

C
priority F VLAN identifier
I

1
3 bits 12 bits
b

Figure 3. Ethernet Frame Formats

3.1.1 Preamble and Start Frame Delimiter (SFD)

Between every frame, there is a small idle time called an Interframe Gap. The length of the
Interframe Gap is 96 bits. After an Interframe Gap a node starts its transmission by sending a
preamble sequence consisting of 56 alternating 1's and 0's. The purpose of the preamble
sequence is to synchronize the receiver(s) before the actual data arrives. After the preamble
comes a Start Frame Delimiter (“0x5D”) that indicates the starting point of the actual frame
(the header).

Manual 11 (68) Version 2.10

FRS

3.1.2 Header
MAC header consists of three parts:
 Destination Address field (6 bytes)
The Destination Address specifies whether the recipient is a single node (unicast), a
group of nodes (multicast), or all the nodes at the medium (broadcast). If the first bit is
zero, then the recipient is a single node and this field contains the physical address of
the receiver‟s interface.
 Source address field (6 bytes)
The physical address of the interface that originated the frame.
 Type/Length field (2 bytes)
The type field indicates the protocol being carried. In the case of IEEE 802.3 LLC, this
field can also be used to indicate the length of the data. If the value of the field is less
than or equal to 1500, then it is indicating the length of the frame.
Ethernet nodes are usually capable of choosing whether they want to receive only frames
sent to their own Ethernet address and the broadcast address, or also frames sent to some,
or all of the multicast addresses. The nodes may also choose to receive all the frames,
including those destined for other nodes. This is called promiscuous mode.

3.1.3 CRC
The 32-bit cyclic redundancy check (CRC) checksum at the end of the frame provides an
error detection mechanism. The CRC checksum is calculated and added to the frame when
the frame is sent, and it is checked when the frame is received at the opposite end. Frames
received with an invalid CRC checksum contain an error and should be discarded by the
receiver.

3.1.4 Media Independent Interface (MII/GMII)

Media Independent Interface (MII) is a standardized interface between MAC and PHY. MII
interface can exist in different forms, it can for example be a physical connector between two
devices or it can be just signals between two devices on a circuit board. It is also possible that
a MII interface exists inside a single chip, between two functional blocks. The idea of the MII
interface is that it is independent of the physical medium. In practise this means that the same
Ethernet MAC can be used with various kinds of Ethernet media. The MII interface standard
supports both 10 Mbps and 100 Mbps transfer rates. For gigabit media there is GMII (Gigabit
Medium Independent Interface).

3.2 Media Access Control (MAC) Bridge

MAC Bridges allow communications between end stations attached to separate LANs
(network segments). A bridge has an own separate MAC for each LAN it connects to and it is
able to bridge traffic between the LANs transparent to logical link control (LLC) and network
layer protocols, just as if the stations were attached to the same LAN. MAC Bridges with more
than two ports are commonly called as switching hubs or Ethernet switches.
Functional entities of an Ethernet switch can be divided roughly into three parts: Forwarding
Process, Address Learning Process and MAC address table (forwarding database). The
Forwarding Process forwards Ethernet frames between the ports according to MAC address
table updated by the Address Learning Process. The Address Learning Process observes all
the received frames and learns which stations are in which network segments by storing their
MAC addresses into the MAC address table.
Ethernet frames whose destination is known by the switch to be in the network segment
behind another port are forwarded into that port. If the destination is known to be behind the
same port where from the frame was received, the switch discards the frame. Ethernet frames
whose destination is unknown (the address is not yet stored into the MAC address table, or
the address information is deleted from the MAC address table because of being too old) are
forwarded to every other port than the source port. Also frames with broadcast (and multicast)

Manual 12 (68) Version 2.10

FRS

destination addresses are forwarded by switches to every other port that the source port as
they are supposed to reach every station in the network.

3.2.1 MAC Address Table

The operations on the MAC address table can be broke down to three different processes; a
learning process, a lookup process and an aging process.
The learning process compares the source addresses of the received frames to the
addresses in the MAC address table. If the entry is found to be already in the table, the port
mapping information is updated if it has changed (the network topology has changed), and
the entry is refreshed so that the aging process does not remove it prematurely. If the address
entry cannot be found from the table, it is added there. If the table is already full it may be
necessary to remove some other entry from the table. Note that if the network topology
changes and nodes are moved from a switch port to another, the switch will not have correct
information on the whereabouts of the node until it transmits something or the aging process
removes the entry. Until then frames destined to the node will be forwarded to wrong port and
they will never reach their destination.
The lookup process compares the destination addresses of the received frames to the
addresses in the MAC address table. According to this information the forwarding process
either discards the frame or forwards it to another or to all other ports. Note that frames are
never forwarded to the port where from they were received, as that would cause duplicate
frames to the network.
The aging process removes entries from the MAC address table. The entries are removed
when they have not been refreshed by the learning process for some time. In many switches
this aging time is configurable, but not always, in which case the default value of 5 minutes is
typically used. The aging process helps to keep the MAC address table small, which may in
some cases affect the time taken by address lookup (depends on the search algorithm used).
The other reason for aging process to exist is to be able to react to network topology changes
in case there are nodes that do not transmit too often or nodes that do not initiate any
communication by themselves.

3.2.2 Shared Media versus Dedicated Media

“There are no shared-medium implementations of Ethernet at data rates above 10Mb/s.” [5]
Unfortunately still today many Ethernet tutorials present Ethernet as a shared medium despite
the fact that typical Ethernet network has not been a shared medium for a decade. Shared
Ethernet, where technologies like Carrier Sense Multiple Access (CSMA) and Collision
Detection (CD) are used in gaining access to the physical medium, is today legacy
technology. Today‟s Ethernet is switched, which means that every end node has a dedicated
port in an Ethernet switch. In switched Ethernet there are only two devices on the LAN; every
network segment consists of an end-node, an Ethernet switch and a point-to-point link
between them.
Switched Ethernet has many advantages over a shared media:
 Full-Duplex links offer double the capacity of a Half-Duplex link at the same nominal
speed
 Different nodes are able to operate with different data rates
 Network capacity is used more efficiently and latency minimized as all the frames are not
forwarded to all the nodes and links
 Full-Duplex operation allows links to be longer in distance because CSMA/CD protocol
does not limit the maximum length. Today fiber optic Ethernet links can have range of
over 100 kilometres.

3.2.3 Cut-through versus Store-and-Forward Operation

According to the IEEE standard 802.1D “Media Access (MAC) Bridges” [3] every port of the
MAC bridge has an individual MAC entity examining all the frames transmitted to the medium
by the other node(s). The CRC checksums of the received frames are checked by calculating

Manual 13 (68) Version 2.10

FRS

CRC of the received frames and comparing it to the CRC checksum at the end of the frame.
Frames with erroneous CRC checksums should be silently discarded.
The so called cut-through switches that start to forward the frame before it is fully received, do
not conform with the standard in this respect, because they are not able to discard the
received frames if they have an erroneous CRC checksum. The opposite of cut-through
operation is store-and-forward operation, in which case frames are fully received and their
CRC checksums are checked before they are forwarded. This is standard compliant method
of operation.

3.2.4 Spanning Tree Protocol

Spanning Tree Protocol (STP) is a protocol that automatically removes loops from a switched
Ethernet network. A loop-free topology is achieved by disabling some of the network links, to
form a tree topology from the mesh topology. Loop-free topology is needed, because if there
was a loop in the network Ethernet frames would circulate in the loop for infinite time.
According to the standard (IEEE 802.1D) the Spanning Tree Protocol configures full, simple,
and symmetric connectivity throughout a Bridged Local Area Network that comprises
individual LANs interconnected by Bridges. The Spanning Tree Protocol (STP) configures the
Port State of each Bridge Port in the Bridged Local Area Network. STP ensures that the
stable connectivity provided by each Bridge between its Ports and by the individual LANs to
which those Ports attach is predictable, manageable, full, simple, and symmetric. STP further
ensures that temporary loops in the active topology do not occur if the network has to
reconfigure in response to the failure, removal, or addition of a network component, and that
erroneous station location information is removed from the Filtering Database after
reconfiguration.[3]
STP and its improved version Rapid Spanning Tree Protocol (RSTP)[6] use configuration
messages sent to a specific multicast MAC address to create and maintain the network
topology. In addition to the STP protocol stack, support for STP requires the Bridge to support
certain port states (Disabled, Learning and Forwarding) and capture the STP configuration
messages for the STP protocol stack.

3.3 Precision Time Protocol

Precision Time Protocol (PTP), defined in IEEE standard 1588 [4], is a protocol enabling
precise synchronization of device clocks in packet based networks, for example Ethernet.
Devices running PTP are automatically synchronized to the most accurate clock in the
network. The protocol supports system wide synchronization accuracy in sub microsecond
range with minimal network and local clock computing resources. It is used for example by
test and measurement, power-line management, industrial automation and telecom
applications.
PTP accuracy is based on an assumption that the delay in Ethernet is approximately constant
and symmetric. Because of the packet based traffic in Ethernet, Ethernet switches in the path
of the packets cause variable delay for packet throughput, thus degrading PTP
synchronization accuracy. Transparent PTP clock functionality removes these problems and
enables precise synchronization of clocks in switched Ethernet.

3.3.1 Transparent Clock

Transparent Clock timestamps PTP event frames in receive and in transmission ports and
calculates the delay caused by the switch by subtracting the receive timestamp from the
transmission timestamp. In PTP end-to-end transparent one step switch, the calculated delay
is added to the correction field of the PTP event frame. A PTP slave that receives the PTP
event message corrects the delay calculation by removing the effect of the PTP transparent
clocks by subtracting the correction field value from the calculated total packet transmission
delay. PTP peer-to-peer transparent clock measures the delay of the ingress path and
includes that also in the correction field value.

Manual 14 (68) Version 2.10

FRS

3.4 HSR (High-availability Seamless Redundancy)

Standard IEC62439-3 [7] deals with redundancy in Ethernet networks. The HSR concept
introduces network ring(s), where each possible source and destination pair is always
connected via two routes. In case of a fault, the ring breaks, but still provides connection
between source and destination(s) via second path, as shown in Figure 4 and Figure 5. HSR
can also be used with double LAN topology as depicted in Figure 8 (if SANs are attached
directly to LAN_A or LAN_B, they need to have HSR support). The standard is developed for
demanding and critical applications such as substation automation.

Interlink
End-node End-node
Redbox

End-node End-node End-node

Figure 4. HSR Ring Example with Unicast Message

Manual 15 (68) Version 2.10

FRS

End-node End-node Redbox

End-node End-node End-node

Figure 5. HSR Ring Example with Multicast Message

A frame in a ring is always HSR tagged. HSR tag in an Ethernet frame is presented in Figure
6. Tags are added / removed by the nodes connected to ring and ring exterior. Such nodes
are called Redundancy Boxes (RedBox). Source nodes send always two copies (red and
green arrows in Figure 5 and Figure 6) of the original frame (blue arrow) to the ring. The
intermediate nodes in the ring forward the frames and the destination node discards the
duplicate (the frame that arrives later). The duplicate frames are identified by having the same
source MAC address and sequence number. In case the frame travels full round (in case of
unicast this happens when destination is not found, in case of multicast this happens always),
the source node takes care of removing the frame from ring (X-marking in Figure 5).

Manual 16 (68) Version 2.10

FRS

14 bytes
1
7 bytes 6 bytes 6 bytes 2B 4B 2B 4B
B

HSR S
destination source HSR
frame preamble F HSR PT data payload CRC
address address PT
D

path LSDU size Sequence number

4 bits 12 bits 16 bits

Figure 6. HSR Tagged frame

3.4.1 HSR Node Types

Normal nodes that connect only to one ring and therefore have only two ports are called HSR
End-nodes. Also name Double Attached Node Implementing HSR (DANH) is used [7].
RedBox is a device that connects non-HSR node(s) or subnetwork(s) to the ring (see Figure
5). Two HSR rings can be connected together using a device named QuadBox. To prevent
single point of failure, two QuadBoxes are needed as presented in Figure 7. With these
building blocks also more complex network topologies, such as rings of rings etc., can be
built.

End-node End-node QuadBox End-node End-node

End-node End-node QuadBox End-node End-node

Figure 7. QuadBox

FRS can be used as a part of HSR RedBox and HSR QuadBox design as well as HSR End-
node.

Manual 17 (68) Version 2.10

FRS

3.5 Parallel Redundancy Protocol (PRP)

In addition to HSR standard IEC62439-3 [7] defines also PRP redundancy method. The PRP
concept introduces double LAN networks, where each possible source and destination pair is
always connected via two routes. In case of a single fault, the network still provides
connection between source and destination(s) via second path, as shown in Figure 8. The
standard is developed for demanding and critical applications such as substation automation.

VDAN

SAN
DANP DANP
Redbox

SAN

SAN
LAN_A LAN_B

switch switch

DANP DANP

Figure 8. PRP Double LAN

Each PRP frame contains a PRP trailer as depicted in Figure 9. Trailers are added / removed
by the PRP nodes connected to a PRP network. Normal non-PRP Ethernet switches can be
used to form PRP LAN_A and LAN_B network segments. Redundancy Box (RedBox) can be
used to connect non-PRP (SAN) devices to a PRP network. In PRP protocol the source node
sends always two copies of the original frame, one for both network segments (LAN_A and
LAN_B), and the destination node(s) discards the duplicate (the frame that arrives later). The
duplicate frames are identified by having the same source MAC address and sequence
number. Non-PRP (SAN) devices are also allowed to connect to LAN_A and LAN_B directly
without a RedBox. In that case SANs do not benefit from the redundancy.

Manual 18 (68) Version 2.10

FRS

14 bytes
1
7 bytes 6 bytes 6 bytes 2B 6B 4B
B

PRP S
destination source PRP
frame preamble F PT data payload CRC
address address trailer
D

Sequence number LanId LSDU size PRP suffix

16 bits 4bits 12bits 16 bits

Figure 9. PRP Frame

3.5.1 PRP Node Types

Normal nodes that connect to PRP network are called PRP End-nodes. Also name Double
Attached Node Implementing PRP (DANP) is used [7]. RedBox is a device that connects non-
PRP node(s) or subnetwork(s) to the PRP network (seeFigure 8).
FRS can be used as a part of a PRP RedBox design as well as PRP End-node.

Manual 19 (68) Version 2.10

FRS

4 Functional Description
The functional blocks of FRS are presented in Figure 10. The functionality of FRS can be
controlled via configuration registers accessed using MDIO interface. The configuration
registers are defined in Chapter 5.

FRS
MDIO

Forwarding core

Buffer manager MMD

Memory Cnfiguration MDIO
Control Buffer
Buffer
Buffer
Buffer
Buffer
Buffer
Buffer
Registers controller

STA
queues

queues

queues

queues
Priority

Priority

Priority

Priority
Outbound

Outbound

Outbound

Outbound
Inbound

Inbound

Inbound

Inbound

MDIO

...
MAC MAC MAC MAC

GMII/ GMII/ GMII/ GMII/

MII MII MII MII

Figure 10. FRS Block Diagram

FRS consists of four main blocks: Forwarding Core, Inbound and Outbound processing and
MDIO controller. The inbound and outbound processing include Ethernet Media Access
Control (MAC).
The Forwarding core is responsible for managing the frames inside the switch. The
forwarding core is common for all the ports and it does the actual forwarding of frames
between ports. As frames may need to spend time inside the switch, they are stored in into a
buffer memory. The forwarding core does the memory management for the buffer memory
and it is also responsible for queuing of the frames.
Every port has its own MAC and inbound and outbound processing. The inbound and
outbound processing of a port is independent from the other ports. The only exception to this
is that the inbound processing entities share the same MAC address table.
MDIO Controller block is used for accessing registers of FRS and the connected external
PHY devices. The PHY devices are connected to STA port of the MDIO controller. A
management CPU can be connected to the MMD port of the MDIO Controller. The CPU can
then access all the configuration registers of FRS and also the registers of the attached PHY
devices through FRS. FRS itself uses the MDIO controller to poll the status of the connected
PHY devices to determine their auto negotiation results.

Manual 20 (68) Version 2.10

FRS

Inbound processing

HW time MAC Table

stamping

Frame analyse and

MAC modification, forwarding
decision

Forwarding core

Memory
Inbound RX control Buffer TX Outbound
Buffer
Buffer
processing processing Buffer processing processing

CTRL info
CTRL info
Inbound RX CTRL info TX Outbound
Buffer
Buffer
processing processing Buffer
Buffer processing processing

Buffer
Buffer
Buffer
Buffer
Inbound RX TX Outbound
processing processing processing processing

Outbound processing

Frame modification MAC

HW time
stamping

Figure 11. FRS Forwarding Path

Figure 11 presents the processing path of a forwarded frame inside FRS. The path contains
Inbound processing, Outbound processing and Forwarding core functions.
Inbound processing contains Ethernet MAC and data processing blocks that are able to
analyze and modify the frame. Every port has its own Inbound processing functionality, that
uses MAC address table common to all ports.
The Forwarding core contains RX and TX processing blocks for controlling Inbound and
Outbound processing blocks. Memory controller block manages the memory used for storing
frames and their control information. Storing of frames is needed, because there can be more
frames forwarded to an output port that what its capacity is. Frame data is stored into a buffer
memory, and the state of the frame is managed via a CTRL info data structure. Every frame is
associated with one CTRL info structure. CTRL info data structure contains all the needed

Manual 21 (68) Version 2.10

FRS

information about the state of the frame, including the destination port and the whereabouts of
the memory buffers where the frame data is stored. Frames are stored into the buffer memory
in chunks of 512 Bytes. This means that every stored frame consumes N * 512 B of buffer
memory, where N=1…3. When frames are stored into the buffer memory waiting to be
transmitted from an output port, they are in an output priority queue of the output port. The
output priority queues contain pointers to the frames; no actual frame data is moved from
place to another when queuing the frames.
The main function of Outbound processing is to send frames from buffer memory to Ethernet.
It contains functionality for retrieving data from the buffer memory, time stamping functions for
PTP use and Ethernet MAC functionality for sending data to the medium. Every port has its
own individual Outbound processing entity.

Master CLK
FRS

To Forwarding Core From Forwarding Core

Inbound Outbound
Control
Data
Construct Port mask &
priority info

PTP
Modify Forwarding Control
(port 0 only)
decision Data
Extract
PTP
Detect
HSR Tag
Add
HSR&PRP&V
LAN&Manag MAC
ement Address MGMT
header/trailer
Remove Table Trailer
Add

Inbound
HSR, VLAN,
MAC Address
Policy PTP
info Extract Overwrite

RX pre- TX post-
process MAC process
Clock domain
Time interface

Time interface

border Time- Time-

stamp stamp

RX MII TX MII
RX MII TX MII
CLK CLK
GMII/MII

GMII/MII

Figure 12. FRS Inbound and Outbound Processing Blocks

FRS Inbound and Outbound processing paths are depicted in Figure 12. The Inbound
processing and Outbound processing functionality are completely independent of each other.
The Inbound processing and Outbound processing data paths are designed so that it is
relatively easy to add more processing blocks to them. Such blocks could collect information
from the frames, modify them and/or affect their forwarding decision. It is also possible to
forward the data path outside of FES, to allow adding of customer‟s own Inbound and
Outbound processing blocks.

Manual 22 (68) Version 2.10

FRS

4.1 Inbound Processing

Inbound processing receives frames from Ethernet and transfers them to the buffer memory
(see Figure 12). The functionality of inbound processing blocks are described in sub-
paragraphs in this chapter.
During reception, Inbound processing does:
 Detect frame errors
 Timestamp frames
 Filter and recognize frames
 Determine the destination port for every frame
 Perform MAC address learning
 Modify frames

4.1.1 RX MII
The RX MII receives frames from the Ethernet PHY. When RX MII is operational and frames
arrive from the network, it writes the frames received from the network to the RX pre-process
block. While the frame is being received, RX MII calculates CRC over the frame. After the
reception of the frame is completed it indicates the status of the CRC calculation. Frames with
invalid CRC are discarded by the forwarding core and MAC RX error counter is incremented.
RX MII block indicates the start of the frame to Timestamp block via Time interface. The
timestamp point for a frame is defined in Figure 13.

S
preamble F
D
dst address ...

timestamp
point

Figure 13. Ethernet Frame Timestamp Point

There are four kinds of errors that can occur while RX MII is receiving a frame. These are:
Size Error, CRC Error, Octet Error and Line Error.
Size Error indicates that the received frame is over 1532 bytes long (without
preamble, SFD and CRC). In that case the frame is truncated to 1532 bytes, and Size
Error is generated incrementing MAC RX Error Counter.
CRC Error signals that the CRC checksum in the received frame was not the same
as the one that was calculated while receiving the frame. This is a result of an error in
the data of the received frame and an indication that the frame should be discarded.
Size Error, Octet Error and Line Error usually cause also a CRC error to the received
frame.
Octet Error occurs when the received frame contains an uneven number of half bytes
(nibbles). This kind of a frame is not valid.

Manual 23 (68) Version 2.10

FRS

Line Error indicates that while receiving the Frame the PHY reported RX MII of an
error.
All the frames received with an error are dropped by the Forwarding Core and the MAC RX
error counter is incremented (see Table 5). Frames whose size is less than 64 bytes are
silently discarded.

4.1.2 Timestamp
The Timestamp block uses the start-of-frame indication from RX MII block to determine the
exact value of the reception time. The reception time of the frame is then given to the RX pre-
process block.
The Timestamp block is external to FRS. FRS communicates with the Timestamp block using
Time interface. Time interface uses time presentation that has accuracy of 2^-16
nanoseconds and timestamp length of 96 bits. The actual accuracy depends on the system
clock frequency used, and the type of clock. Time interface is presented in Chapter 6.3.
Timestamp block is external to FRS because it is quite hardware dependent. The
implementation of the Timestamp block depends on the FPGA family used, available FPGA
resources (PLLs for example) and the timing related hardware external to FPGA; different
kinds of boards have different kinds of clocks, with different accuracies and different
frequencies, fixed and adjustable.

4.1.3 RX Pre-process
The RX pre-process block provides the received frames to the rest of the Inbound processing
blocks. The Inbound processing blocks are chained in a row between the RX pre-process and
the Forwarding core. The inbound processing blocks are connected to each other with a
standard interface called EIF (Extended Interface). The RX pre-process is the source of the
EIF bus and it generates EIF-cycles for each frame it receives from the RX MII.

4.1.4 Forwarding Decision

A Forwarding decision in FRS is made based on information from the following sources:
 MAC address table (Chapter 4.1.8.4)
 Management Trailer (Chapter 4.1.7)
 Inbound Policy (Chapter 4.1.5)
 VLAN configuration (Chapter 4.1.8.5)
 Port state (Port State Register, Table 5)
 HSR tag (Chapter 4.4)
 PRP trailer (Chapter 4.5)

Regardless of a frame being dropped or not, it is always received to the buffer memory of the
forwarding core, which means that it goes through the whole inbound processing chain. If the
frame is to be dropped the memory resources allocated by the frame are freed right after the
reception.

4.1.5 Inbound Policy

Inbound policy checks the destination MAC addresses of all the received frames. The user
can configure through the register interface what kind of a treatment should frames with
certain MAC addresses get. The alternatives for individual MAC addresses are the following:
 Drop
 Forward according to MAC address table
 Forward to certain ports

Manual 24 (68) Version 2.10

FRS

 Forward without adding HSR tag or PRP trailer

It is also possible to enable or disable:

 All unicast frames
 All multicast frames
 All broadcast frames

4.1.5.1 Priority-setting
In inbound policy block the received frames get their priority according to the destination MAC
address.
Inbound policy sets the priorities for the frames according to the priority set in Inbound Policy
Configuration Register (Table 8). The priority is used by the Forwarding core to place the
frames into correct transmit priority queues. Default priority for frames whose priority is not
modified by the Inbound Policy block is 0, which is the lowest priority.

4.1.6 Precision Time Protocol

FRS supports PTP message transportation directly over Ethernet (IEEE 1588-2008 [4] Annex
F) and over User Datagram Protocol (UDP) over Internet Protocol version 4 (IEEE 1588-2008
[4] Annex D). PTP Mode setting in General Register (see Table 3) selects which one of the
two modes is selected.
Inbound processing always timestamps every incoming Ethernet frame. PTP Detect block
recognizes PTP version 2 event messages, determines the type of the event message (Sync,
Delay_Req, Pdelay_Req and Pdelay_Resp) and calculates the offsets of the message fields
in the frame, see Figure 12.

4.1.6.1 End-to-end Transparent Clock Functionality

FRS implements PTP version 2 end-to-end transparent clock functionality in one-step mode
with pure hardware. In Inbound processing chain PTP Detect block recognizes IEEE 1588
PTP version 2 [4] event messages that need to have special processing inside Ethernet
switches providing PTP transparent clock functionality. In practice what is done to the
recognized frames is that FRS adds the frame residence time inside the switch to the PTPv2
event message correctionField. The correctionField is modified in Outbound processing, in
PTP Overwrite block. The modified message types include Sync, Delay_Req, Pdelay_Req
and Pdelay_Resp messages.

4.1.6.2 Peer-to-Peer Transparent Clock Support

From FRS point of view Peer-to-peer transparent clock support differs from End-to-end
transparent clock support by only a little: In Peer-to-peer transparent clock also the line delay
associated with the ingress path is added to the correction field. For this purpose there are
registers (PTP_DELAY_SUBNS, PTP_DELAY_NS_LOW, PTP_DELAY_NS_HIGH) for the
link delay (see Chapter 5.3.2.3). For End-to-end transparent clock value zero is written into
these registers. For Peer-to-peer transparent clock there has to be software that determines
the link delay and writes it into these registers, after which FRS is able to make the
corrections automatically.

4.1.7 Management Trailer

The FRS port 0 is a management port that includes an MDIO interface and can be configured
to a special management mode. In management mode the management port supports the
following features:

Manual 25 (68) Version 2.10

FRS

 Inbound Policy is able to force the forwarding of the selected frames from any other port
to the management port (see Table 8).
 From the management port, it is possible to send Ethernet frames to any other port
independent from other configurations (MAC table etc.).
Management mode configuration includes three steps:
1. Configure the Management port to management mode (see Table 5).
2. Configure the Management port HW mode and speed (see Table 5).
3. Configure which frames to forward to Management port from other ports (see Table
8).
When in management mode, every frame sent and received via a management port is
equipped with a management trailer. FRS inserts a management trailer to a frame when it
sends the frame to a management port and FRS expects every frame received from a
management port to contain one. The management trailer contains information about the
input/output port: from which port has the frame been received or to which port(s) is it to be
sent. An Ethernet frame containing the management trailer is depicted in Figure 14.

Management
Ethernet header Data CRC
Trailer

Port Port Port

Reserved ... 2 1 0

Bit 7 2 1 0

Figure 14. Ethernet Frame with Management Trailer

The length of the Management Trailer is one byte. Every bit in the trailer corresponds to one
port, starting from port number 0 in the least significant bit. Unused trailer bits are reserved
and they are always set to 0 by FRS and they should be written 0 by the user of the
Management Port.
When the host CPU sends a frame via management port to port number 1, it adds a
management trailer to the frame with the bit corresponding to „Port 1‟ set to one and the other
bits in the management trailer set to zero. The host CPU can send a frame to multiple FRS
ports by setting multiple bits in the management trailer. By setting all management trailer bits
to zero, the host CPU lets FRS make the forwarding decision.
When FRS sends a frame to host CPU to the management port (and the management port is
in management mode), it adds a management trailer to the frame always with one of the bits
set. The bit corresponds to the port from which the frame was received.

4.1.8 MAC Address Table

Forwarding decisions of FRS are typically made by an address search to the MAC Address
Table. Note that Inbound policy, Management trailer or VLAN settings may override the
decision made by the MAC Address Table search algorithm.

Manual 26 (68) Version 2.10

FRS

4.1.8.1 Address Table Entry

The structure of a MAC Address Table entry in FRS MAC Address Table is depicted in Figure
15.
U
S Expiration
MAC address (48 bits) Port (8 bits)
E Time (7 bits)
D

Figure 15. MAC Address Entry

The MAC address entry contains a USED bit, the actual MAC Address, Expiration time and a
Port number. USED bit set to „1‟ indicates that the entry is currently in use. The port where the
frame was received from is stored into the Port field.
The MAC address aging time is set to Expiration time field. There is an internal counter that
keeps track of the current time, and when the expiration time is updated a value of current
time + address lifetime is written to the Expiration time field. The address lifetime is user
configurable in the register map (see Table 3). The Expiration time value is stored in multiples
of 16 seconds.

4.1.8.2 Address Learning

FRS updates the MAC address table automatically according to the source MAC address
information in the received Ethernet frames. The Address learning process updates the MAC
Address Table when the receive port of the frame is in Forwarding or Learning state (See port
state in Table 5). After learning the source MAC address from a frame received from a port
that is in Learning state, the frame is dropped by the Forwarding core. If a port is in Disabled
state, the MAC Address Table is not updated.
The address learning process for the source address of a received Ethernet frame is depicted
in Figure 16.

Manual 27 (68) Version 2.10

FRS

Source
address is NO
unicast?

YES

Search address
from table

Update
Address
YES Timestamp and
found?
Port field

NO

Search entry with

USED=0

Select one from

Found? NO
the used entries

YES

Copy MAC
address, set
Timestamp and
Port field

Set USED=1

Figure 16. Address Learning

The Address learning process of FRS is the following:

1. Check that the source address is a unicast Ethernet address.
2. Search for the address in the table
3. If the address is found, update Expiration time and port fields with expiration time and
source port and exit.
4. If the address is not found, search for an address entry with USED bit set to „0‟.

Manual 28 (68) Version 2.10

FRS

5. If unused entry is not found, select one of the already used entries.
6. Copy MAC address and Port fields to the selected entry. Set Expiration time to
expiration time field and set USED bit to „1‟.

4.1.8.3 Address Aging

Address aging processes for the MAC address table removes entries that are found to be
expired. The Address aging process is depicted in Figure 17.

Process all address table entries

Get next

Whole table
Wait 16s YES
processed?

NO

If USED = 1 NO

YES

Expiration Time
NO
= current time?

YES

Set USED = 0

Figure 17. Address Aging

The Address Aging process goes through all the MAC Address Table entries every 16
seconds. All the expired entries are removed, in other words, their USED bit is set to „0‟.
Expiration is detected from the Expiration time field of the MAC Address entry: If the
Expiration time is the same as the current time, the entry is to be removed. The address entry
expiration time is updated by the Address Learning process, so only the entries that have not
been refreshed for a certain time (Address lifetime) are removed by the Address Aging
process.

Manual 29 (68) Version 2.10

FRS

4.1.8.4 MAC Address and Forward Decision

The Address Search process searches MAC address(es) from the MAC Address table.
Destination MAC address is extracted from every received frame and a search is made to the
MAC address table with the address. If the address is found in the MAC Address table, it
means that it is known behind which port the destination node is, and the frame can be
forwarded to that port. Note that Inbound policy, Management trailer or VLAN settings may
override the decision made by the MAC Address Table search algorithm.
The Address search and forwarding process is the following:
 Check if the destination address is unicast, multicast or broadcast address
 If the destination address is a broadcast address, forward the frame to every other port
than the source port belonging to the same VLAN as the receive port.
 If the destination address is a multicast address, forward the frame to every other port
than the source port belonging to the same VLAN as the receive port.
 If the destination address is a unicast address, search address from the MAC address
table.
 If a match is found in the address table and the output port is not the receive port and
VLAN configuration accepts the port as a destination, forward frame to the port.
 If a match is not found in the address table, forward the frame to every other port defined
by the VLAN configuration, except the receive port.
The MAC Address based forwarding decision is depicted in Figure 18.

Manual 30 (68) Version 2.10

FRS

Check destination
address

Unicast? NO

YES

Search address
from table

Address
NO
found?

YES

Use Port specified

in Address entry
as dst port

dst port =
YES receive port

NO

Forward frame to
dst port
every other port
valid in VLAN NO
valid in VLAN
conf.
configuration

YES

Drop frame Forward frame to

dst port

Figure 18. Address Search (+ Port Based VLAN)

4.1.8.5 Port-based VLAN

FRS supports port-based Virtual LANs (VLANs). By using port-based VLANs the switch can
be virtually divided into two or more virtual switches; frames from a port cannot be forwarded
into a port that is configured to be in another VLAN. VLANs for the ports can be configured
using port configuration registers (see Table 5). See Figure 18 on how VLAN configuration
affects the address search and forwarding decision.

Manual 31 (68) Version 2.10

FRS

4.1.8.6 Forward Portmask

Forward portmask is another way to control how frames can be forwarded between ports.
Everything that can be done with port-based VLAN can be done also with Forward portmask,
but not the other way around. So, Forward portmask is more versatile tool than Port-based
VLAN; Port-based VLAN basically exists for compatibility reasons. The user should not
restrict the forwarding between ports using both Port-based VLAN and Forward Portmask at
the same time as there should be no reason to do so.
Forward portmask configuration is made via port configuration registers (see Table 5). With
Forward portmask the user defines to which ports it is possible to forward frames from the
port. Note that the forwarding can be configured to be different in different directions. The
Forward portmask can be useful for example in systems where one of the ports is connected
to a CPU; Forward portmask can be used to force the forwarding of frames from other ports to
the CPU port only.
See Figure 19 on how Forward Portmask affects the address search and forwarding decision.

Manual 32 (68) Version 2.10

FRS

Check destination
address

Unicast? NO

YES

Search address
from table

Address
NO
found?

YES

Use Port specified

in Address entry
as dst port

dst port =
YES receive port

NO

Forward frame to
Allowed by
every other port
Forward NO
Forward portmask
Portmask
allows

YES

Drop frame Forward frame to

dst port

Figure 19. Address Search (+ Forward Portmask)

4.2 Outbound Processing

Outbound processing block transfers frames from forwarding core (buffer memory) to
Ethernet medium (refer to Figure 12). Every port has its own individual Outbound processing
entity. During transmitting the Outbound processing does the following:
 Timestamp frames
 Modify frames

Manual 33 (68) Version 2.10

FRS

4.2.1 TX Post-process
The Outbound processing blocks are chained in a row between the Forwarding core and the
TX post-process. The Outbound processing blocks are connected to each other with a
standard interface called EIF (Extended Interface). TX MII controls the rate at which the data
flows through the Outbound processing path and the Forwarding core feeds the data at that
rate. TX post-process transfers data to TX MII block for sending.

4.2.2 TX MII
TX MII block automatically calculates and inserts correct CRC checksums to transmitted
frames. Also the preamble and the Start Frame Delimiter (SFD) are automatically inserted. TX
MII block indicates the start of the frame to Timestamp block via Time interface (see Figure
12). The timestamp point of a frame is defined in Figure 13.

4.2.3 Timestamp
The Timestamp block uses the start-of-frame indication from TX MII block to determine the
exact value of the transmit time. The transmit time is then given to the PTP overwrite block.
The Time-stamp block is external to FRS. FRS communicates with the Time-stamp block
using Time interface. The timestamp block and Time interface at Outbound processing are
similar to the Timestamp block and Time interface at Inbound processing. See more
information at Chapter 4.1.2.

4.2.4 PTP Overwrite

Outbound processing timestamps every Ethernet frame and the difference between the
outbound and the inbound time stamps (the time the frame spent inside the switch) is added
to the correctionField of the PTP event message headers together with the link delay of the
ingress port. Event messages are recognized already at Inbound processing as specified in
Chapter 4.1.6.
The time the frame spent inside the switch is calculated by subtracting the RX timestamp of
the frame from the TX timestamp. The accuracy of the calculation is 2^-16 nanoseconds.

4.3 Forwarding Core

The Forwarding core is responsible for forwarding frames between ports; that is from the
inbound processing path of a port to the outbound processing path of another. The forwarding
core is common to all ports. The Forwarding core includes memory management, four
transmit priority queues per port and management of the inbound and the outbound
processing paths. The Forwarding core also drops frames during high load situations, when
running out of buffer memory space.

4.3.1 Memory Controller

Memory controller block (see Figure 10) is responsible for the memory management of the
buffer memory used for buffering the frames. The buffer memory is common to all the ports
and there is no fixed buffer space reserved per port. Instead, a port is able to buffer more
frames when other ports have shorter queues.
The Ethernet frames to be forwarded are stored into the buffer memory in one to three
fragments depending on the length of the frame. The size of each fragment is 512 Bytes. This
is also the size of the unit in which Memory controller manages the buffer memory. Every
output port has enough bandwidth to the buffer memory to achieve wire-speed operation.
Memory controller provides an indication to the Frame Early Drop algorithm (see Chapter
4.3.5) in situations where the buffer memory is so crowded that some of the already stored
frames have to be dropped to make space for new ones.

Manual 34 (68) Version 2.10

FRS

4.3.2 Priority Queues

FRS has four priority queues for every output interface. When a frame is received, the priority
of the frame and the destination port(s) are determined during Inbound processing. When the
Inbound processing passes the frame for the Forwarding core, the Forwarding core places
the frame into the priority queue that matches its priority. The priority queues are FIFO type
and they actually contain only a pointer to the data of the frame (see Figure 20). The data of
the frame is not moved, when the pointer moves forward in the queue.
The queues are emptied in priority order so that frames from higher priority queues are sent
before any frames from any of the lower priority queues of the port.
All the priority queues have fixed length of 32 frames. If the destination priority queue is full,
the frame is dropped. In case of frames that are forwarded to multiple ports, the frame is
dropped only from queue(s) that are full. When a frame is dropped because the priority queue
is full, the corresponding error counter is incremented (see Table 5).

Data_memory
... Fragment Fragment Fragment Fragment ...

Control_memory
... CTRL_info CTRL_info CTRL_info CTRL_info ...

Data
Data

TX queues for Port 0:

Priority 0

Priority 1
Inbound Outbound
Core RX Core TX
processing processing
Priority 2
Control
Memory
Pointers Priority 3

TX queues for Port 1:

Priority 0

Priority 1
Inbound Outbound
Core RX Core TX
processing processing
Priority 2

Priority 3
Control
Memory TX queues for Port 2:
Pointers
Priority 0

Priority 1
Inbound Outbound
Core RX Core TX
processing processing
Priority 2

Priority 3

Figure 20. Priority Queues (only three ports shown)

4.3.3 Core RX
Core RX blocks terminate the Inbound processing paths (EIF buses, see Chapter 4.1.3). The
RX Core blocks reserve a CTLR_info structures for the frames from the Control memory and
handle the writing of the frame data to the Data memory. A CTLR_info structure contains the

Manual 35 (68) Version 2.10

FRS

information on where the data fragments are located in the Data memory. The Core RX block
places a pointer to the CTRL_info struct into correct priority queue of the correct output port(s)
based on the information from Inbound processing. If the queue is full the frame is not
forwarded to that port at all. Note that it is not allowed to place the frame into a priority queue
with lower or higher priority, because the frames belonging to the same data stream in
Ethernet have to preserve their order.
If a frame cannot be forwarded to any destination port because their TX queues are full, the
frame is dropped. The frame is dropped also in case Control memory is full (out of CTRL_info
structures) or Data memory is full. In case Inbound processing indicates that there was an
error in the frame, Core RX block drops the frame and increments the corresponding error
counter. When frames are dropped by Core RX, both the CTRL_info stucture and the
reserved Data_memory are deallocated.

4.3.4 Core TX
Core TX blocks source the Outbound processing paths (EIF buses). A Core TX block gets
information of which frame to transfer to the Outbound processing path from the TX queues of
the corresponding port. The Core TX block then transfers the data from the Data_memory to
the Outbound processing path at the rate the Outbound processing path is able to handle.
This rate depends on the speed setting of the output interface (10/100/1000 Mbit/s).
After transferring the frame to the Outbound processing, it is checked if the frame has to be
transferred to Outbound processing of other ports as well. If this was the last port to forward
to, both the CTRL_info stucture and the reserved Data memory are freed.

4.3.5 Frame Early Drop

Frame Early Drop (FED) algorithm deallocates buffer memory when FRS encounters heavy
load and buffer memory is about to cease. An indication that the memory is going to be fully
used soon is got from Memory controller block.
One reason for using FED algorithm is to ensure that frames buffered for some output ports
do not block traffic for the other ports. Buffering too much frames for some ports would in
worst case cause all the incoming frames to be dropped. This is because the buffer memory
is common to all ports. So the Memory controller block triggers the Frame Early Drop
algorithm early and frequently enough to ensure that there will always be enough buffer
memory to be able to receive all the incoming frames.
The FED algorithm used also guarantees that lower priority frames for a port are dropped
before higher priority ones for the port. Another effect is that when buffer memory
consumption is high, frames are dropped early enough to slow down TCP connections
(selective dropping for oldest frames) to prevent total congestion.

Manual 36 (68) Version 2.10

FRS

Memory low

Select port that

has most frames
queued (all priority
levels combined)

Select lowest
priority queue P = queue priority (0 is lowest)
(P = 0)

Check number of
frames in the
queue

Select queue with

Highest priority
Number of frames NO NO next priority
queue selected
>0 (P = P+1)

YES YES

Memory cannot be
Free oldest frame low (this should
from selected never happen)
queue

Figure 21. Frame Early Drop Algorithm

The Frame Early Drop algorithm is presented in Figure 21. The algorithm is run when buffer
memory resources are running low. The algorithm selects one frame to be dropped and drops
it.
The Frame Early Drop algorithm selects first the output port that has the most frames queued.
Then it selects the lowest priority queue of that port that has queued frames it, and removes
the oldest frame from that queue. After dropping the frame, the appropriate error counter (see
Table 5) is incremented.

Manual 37 (68) Version 2.10

FRS

4.4 HSR (High-availability Seamless Redundancy)

HSR specific features of FRS include:
 Automatic insertion of HSR tag
 Automatic removal of HSR tag
 Automatic duplicate generation for HSR redundant ports
 Automatic duplicate detection and removal for HSR redundant ports
In inbound processing after making the forwarding decision for a frame the HSR tag (see
Figure 6) is always removed if the port is in HSR mode. In outbound processing a HSR tag is
added if the output port is in HSR mode.
The HSR mode for a port and the other HSR specific setting are configured using HSR/PRP
registers (see Table 6). To enable HSR, two ports must be configured as HSR enabled
redundant ports and they must be with the same ring ID value.

4.4.1 Forwarding of HSR Frames

When forwarding frames in HSR-enabled switch there are basically two different cases: the
frame is either coming in from a HSR redundant port or it is coming in from an interlink port.
If the frame comes in from an interlink port it is forwarded normally (as in non-HSR case, see
Chapter 4.1.4), except if it is to be forwarded to HSR-redundant port, in which case the frame
is duplicated and sent out from the both redundant ports.
The forwarding logic for frames coming in from a redundant port is more complicated,
because of duplicate detection and removal. The forwarding logic for frames coming from
HSR redundant port is presented in Figure 22.

Manual 38 (68) Version 2.10

FRS

SRC = source MAC address

DST = destination MAC address
non-HSR port = port where HSR is not
HSR frame received from HSR ring
enabled (not ring or HSR Interlink)

SRC found
from MAC tbl?

YES

SRC is
in Interlink YES DROP
port?

NO
Duplicate
detection

NO
Already
Add/update entry
DROP YES relayed by
and store seq
same port?

NO

Already
relayed by the
YES
other ring port
?

NO

Add/update entry Add/update entry

and store seq and store seq

Forward to DST,
according to the
Unicast FWD chain
DST is in decision
remove non-HSR port?
from ring

YES NO
FWD

DROP Forward to HSR

ring port only

FWD

Figure 22. HSR Ring Port Forwarding Logic

For HSR frames received from a HSR port, it is first checked if the source MAC address
exists in the MAC address table and if the source node is located in non-redundant (interlink)
port. The duplicate detection is then done by looking at the MAC address entry‟s stored HSR
sequence numbers for the other HSR redundant port: if it matches with the incoming frame‟s
HSR Tag‟s sequence number, we have a duplicate. Additionally, it is checked whether a
frame with this same sequence number and source MAC address, coming in from this same
port has already been forwarded, in which case the frame is circulating in the ring/network
and has to be deleted. If the frame is neither duplicate nor circulating, it is forwarded towards
its destination(s) and the corresponding entry is updated.

Manual 39 (68) Version 2.10

FRS

Multicast and broadcast frames (see Figure 5) always circulate the whole ring. The duplicate
detection for multicast and broadcast frames is made in two phases: by first looking if the
frame has already been forwarded into this direction. If the answer is yes, the frame already
circulated the whole ring and it is dropped (note that checking whether the source address is
behind a non-HSR port probably drops the frame earlier). The next step is to see whether the
frame was already received from the other redundant port and has therefore already been
forwarded to the interlink ports. If not, the frame is forwarded to all the other ports (except the
input port). Otherwise the frame is forwarded only to the other redundant port.

4.4.2 HSR Port Modes

HSR standard defines one mandatory operation mode and four optional modes. The default
mode is called mode M, which is normal HSR tagged forwarding.
In the optional mode N, traffic is not forwarded between HSR redundant ports. The mode N
can be configured using PORT_FWD_MASK register (see Table 6) by disabling forwarding
between HSR redundant ports.
The configuration procedure is the following:
1. Disable both redundant ports (Table 5, PORT_STATE register)
2. Change mode (Table 6, HSR_CFG register) for both redundant ports
3. Configure PORT_FWD_MASK (Table 5, PORT_FWD_MASK register)
4. Enable both configured ports (Table 5, PORT_STATE register)

4.5 PRP (Parallel Redundancy Protocol)

PRP specific features of FRS include:
 Automatic insertion of PRP trailer
 Automatic removal of PRP trailer
 Automatic duplicate generation for PRP ports
 Automatic duplicate detection and removal for PRP ports
In inbound processing after making the forwarding decision for a frame the PRP trailer is
removed if the port is in PRP mode and the frame has one. In outbound processing a PRP
trailer is added if the output port is in PRP mode. Frames coming in from a PRP enabled port
that do not have a PRP trailer are accepted, because they can be from a SAN (Singly
Attached Node).
The PRP mode for a port and the other PRP specific settings are configured using HSR/PRP
registers (see Table 6). To enable PRP functionality, two ports must be configured as PRP
redundant. Also PORT_FWD_MASK must be configured to prevent forwarding between PRP
redundant ports.
The configuration procedure is the following:
1. Disable both redundant ports (Table 5, PORT_STATE register)
2. Change mode (Table 6, HSR_CFG register) for both redundant ports
3. Configure PORT_FWD_MASK to prevent forwarding between PRP ports (Table 5,
PORT_FWD_MASK register)
4. Enable both configured ports (Table 5, PORT_STATE register)

4.5.1 Forwarding of PRP Frames

When a frame (either PRP frame of non-PRP frame) comes in from an interlink port it is
forwarded normally (as in non-PRP case, see Chapter 4.1.4), except if it is to be forwarded to
a PRP redundant port, in which case the frame is duplicated and sent out from the both PRP
redundant ports.
The forwarding logic for frames coming in from a PRP redundant port is more complicated,
because of duplicate detection and removal. The forwarding logic for frames coming in from a
PRP port is presented in Figure 23.

Manual 40 (68) Version 2.10

FRS

SRC = source MAC address

DST = destination MAC address

Valid PRP frame received from PRP interface

SRC found
from MAC tbl?

YES

Duplicate
detection

NO
Already
Add/update entry
DROP YES relayed by
and store seq
same port?

NO

Already
relayed by the
YES
other PRP port
?

NO

Add/update entry
and store seq

Forward to DST,
according to the
FWD chain
decision

FWD

Figure 23. PRP Port Forwarding Logic

For PRP frames received from a PRP port, it is first checked if the source MAC address exists
in the MAC address table. The duplicate detection is then done by looking at the MAC
address entry‟s stored PRP sequence numbers for the other PRP port: if it matches with the
incoming frame‟s PRP trailer‟s sequence number, we have a duplicate. Additionally, it is
checked whether a frame with this same sequence number and source MAC address, coming
in from this same port has already been forwarded. If the frame is not duplicate it is forwarded
towards its destination(s) and the corresponding entry is updated.

4.6 MDIO Controller

In FRS MDIO is used for two purposes: for the optional CPU to access registers of FRS and
for the FRS to poll the status of the connected PHYsical layer devices. If the CPU disables
the polling feature, it is also possible for the CPU to access registers of the PHY devices
through FRS.

Manual 41 (68) Version 2.10

FRS

The MDIO Controller has two ports: a station management entity (STA) port and an MDIO
Manageable Device (MMD) port. All the Ethernet PHYs are connected to the STA port and
the optional host CPU can be connected to the MMD port (see Figure 24).

CPU

MDIO MDC

MMD

MDIO Controller

STA

MDC
MDIO

PHY PHY PHY

Figure 24. MDIO Controller

By default, MDIO Controller block polls the registers of the PHYs periodically and configures
its interfaces according to their current status. The polled configuration includes Link State,
Speed Selection and Duplex Mode.
If the host CPU wants to access the PHY registers, it has to temporarily disable the polling of
the PHY registers (see Table 3). After disabling the polling feature, the CPU has to check that
the polling is disabled before accessing the PHYs, as it may take a while to disable it. After
accessing the PHY registers, the CPU must enable polling again to allow FRS to access to
the PHY registers. MDIO PHY access from the CPU through FRS is depicted in Figure 25.

CPU MDIO Control PHY

disable MDIO polling

Wait until
check MDIO
polling state
polling state
is disabled

read/write MDIO

enable MDIO polling

Figure 25. PHY Access from CPU through FRS

Manual 42 (68) Version 2.10

FRS

4.6.1 PHY Initialization

Normally PHY devices are fully functional after power-up, which means that initialization of
the PHY is not necessarily needed at all. In some situations however, depending on the PHY
device model used and the way it has been connected in the hardware, some initialization
may be required before the PHY is fully functional.
The PHY registers are used, for example, for setting auto-negotiation capabilities and link
modes. For further information about the register set see IEEE Std. 802.3 [8] and the
datasheet of the PHY device you are using.

4.7 IP License Authentication

To prevent unauthorized use of the IP block, FRS includes an Authentication Interface (see
Authentication Interface signals in Figure 29). An external Security Chip is connected to the
Interface. FRS sends authentication requests approximately once a second to the connected
Security Chip and examines the replies it gets. Valid replies from the Security Chip indicate to
FRS that the user has a valid license to use the IP.
If FRS does not get valid replies to its requests, for example when there is no Security Chip
connected, FRS will operate for approximately 2 hours and 15 minutes from reset, after which
it stops. This behavior makes it possible for customers to evaluate FRS IP core without
purchasing Security Chips.
The register map (see Table 3, AUTH_STATUS register) includes an Authentication failure
counter that counts failed and succeeded authentication requests. From this register the user
can see whether the IP license authentication is working or not, which can be useful for
example in product development phase and in production tester environment.

4.8 Reset
4.8.1 Software Reset
Software reset is made by writing value “1” to the Software reset bit (see Table 3) in General
Register. After reset command FRS cancels all of its current operations and waits until all of
its state machines have returned to their reset states. After the reset has completed, FRS
clears the Software reset bit in the register. After software reset FRS is in the same state as
after hardware reset.

4.8.2 Hardware Reset

Hardware reset is made by setting the global asynchronous reset input signal to its active
state. All of the flip-flops of FRS are immediately returned to their reset states and internal
memories are initialized. The state after hardware reset is equivalent to power-up condition.

Manual 43 (68) Version 2.10

FRS

5 Configuration Registers
Functionality of FRS is controlled through registers. The configuration registers of FRS are
accessed using MDIO. Each MDIO access has two addresses: PHY address and Register
address. Both the PHY address and the Register address are 5 bits in length.
When accessing registers of external PHY devices, the PHY address selects the PHY device
to be accessed and the Register address selects the Address inside the selected PHY device.
When accessing registers of FRS, the PHY address selects whether the access goes to FRS
Switch configuration registers or to FRS Port configuration registers (see Figure 26). If
accessing FRS port configuration registers, the PHY Address also defines which port‟s port
configuration registers are accessed.
FRS Configuration registers (FRS Port configuration registers and FRS Switch configuration
registers) are accessed indirectly through FRS MDIO registers as shown in Figure 26. The
FRS MDIO registers include registers PRA (Port Register Address) and PRD (Port Register
Data) into which address and data of FRS Configuration registers (FRS Port configuration
registers and FRS Switch configuration registers) are written when using the indirect access.
PHY Addresses of external PHY devices and FRS ports are configured using external signals
of FRS, see Table 10. Note that the same PHY addresses are used:
 when CPU accesses external PHY devices
 when CPU accesses FRS Port configuration registers
 when FRS accesses external PHY devices
In addition to this there is a separate PHY address the CPU uses when accessing FRS
Switch configuration registers (see Figure 26 and Table 10).

PHY Address (5bit),

Reg. Address (5bit),
Reg. Data (16bit)

FRS
MDIO
PHY Addr = PHY Addr = PHY Addr =
PORT 0 PHY PORT 1 PHY PORT n PHY
If PHY ADDR ADDR ADDR
MMD polling
enabled

If PHY PHY Addr =

polling FES-HSR PHY
disabled ADDR
indirect indirect indirect indirect
FES-HSR
access using access using access using access using
MDIO
registers PRA registers PRA registers PRA registers PRA
registers
and PRD and PRD and PRD and PRD

FES-HSR FES-HSR FES-HSR FES-HSR

Switch Port Port Port FES-HSR

...
STA configuration configuration configuration Configuration
configuration
registers registers for registers for registers for registers
Port 0 Port 1 Port n
MDIO

PHY PHY ... PHY

PHY
MDIO
Chip 0 Chip 1 Chip n
registers

Figure 26. MDIO Register Access

Manual 44 (68) Version 2.10

FRS

5.1 Indirect Register Access

Indirect access is needed to be able access FRS Configuration registers. The FRS
configuration registers consists of FRS Switch configuration registers and FRS port
configuration registers, as can be seen in Figure 26.
Indirect access to FRS configuration registers is made using FRS MDIO registers named
PRA and PRD. Indirect read access is presented in Figure 27. In indirect read access the
address of the FRS Configuration register is written to FRS MDIO register named PRA. After
this the value of the FRS Configuration register is read from the FRS MDIO register named
PRD.

FRS MDIO FRS Configuration

CPU registers register

Write PRA
(address & read enable)

Read register
(address)

(data)

Read PRD
(data)

Figure 27. Indirect Read

Indirect write access to FRS Configuration register (FRS Switch configuration register or FRS
Port configuration register) is presented in Figure 28. In indirect write access the address of
the FRS Configuration register is written to FRS MDIO register named PRA and the value for
the FRS Configuration register is written to the FRS MDIO register named PRD. FRS then
immediately writes the value to the FRS Configuration register.
FRS MDIO FRS Configuration
CPU registers register
Write PRD
(data)

Write PRA
(address & write enable)

write register (address, data)

Figure 28. Indirect Write

Note that accessing FRS Port configuration registers is possible only when PHY polling
feature of FRS is enabled. When PHY polling feature is disabled, MDIO access goes to
external PHY devices as presented in Figure 26.

5.2 FRS MDIO Registers

FRS MDIO registers are used for two purposes, for identifying FRS version (PHYIDR1 and 2)
and for indirect access to FRS Configuration registers (PRA and PRD). FRS reacts to MDIO
accesses made with two kinds of PHY addresses:

Manual 45 (68) Version 2.10

FRS

 FRS PHY Address (configured with signal cfg_fes_addr(4:0), see Table 10)
 Port PHY Addresses (configured with signal cfg_port_addr(n:0)(4:0), see Table 10)
FRS does not respond to accesses with any other PHY addresses. To Port PHY Addresses it
responds only when PHY polling feature is enabled. When doing indirect access using FRS
MDIO registers PRA and PRD, the PHY Address of the MDIO access defines whether the
access goes to FRS Switch configuration register or one of the FRS Port configuration
registers.

MDIO Register Register Description

Address
0x0…0x1 Reserved Reserved
0x02 PHYIDR1 PHY Identifier Register #1
- Reset: 0 x XX XX XX XX
- PHY Identifier 1. Configured via configuration parameters, The value in this
register is the lowest bits of FES_PHY_ID presented in Table 10.
Bits 15-0 : RO FES_PHY_ID, bits 15-0
0x03 PHYIDR2 PHY Identifier Register #2
- Reset: 0 x XX XX XX XX
- PHY Identifier 2. Configured via configuration parameters, The value in this
register is the highest bits of FES_PHY_ID presented in Table 10.
Bits 15-0 : RO FES_PHY_ID, bits 31-16
0x4…0x1D Reserved Reserved
0x1E PRA Port Register Address
- Reset: 0 x 00 00 00 00
- Address for the FRS Port configuration register or FRS Switch configuration
register. Requested action (Read/Write) is performed immediately after
writing in this register.
Bits 14-0 : R/W Register Address
Address of the register where to data is written or where
from data is read.
Bit 15 : R/W Read/Write
0 = Read. Data is available on next read from PRD.
1 = Write. Data in PRD is written to register.
0x1F PRD Port Register Data
- Reset: 0 x 00 00 00 00
- Data for the FRS Port configuration register or FRS Switch configuration
register.
Bits 15-0 : R/W Register data
If write command is given to PRA, contents of this
register are written to the register whose address is
written in PRA. If read command is given, contents of the
register in the address specified in PRA are read to this
register.
0x20… Reserved Reserved

Table 1. FRS MDIO Registers

PHYIDR1 and PHYIDR2 registers are used to identify FRS. For more information about using
these registers, see IEEE std. 802.3 [8].

5.3 FRS Configuration Registers

FRS configuration registers consist of two sets of registers: FRS Switch configuration
registers (Chapter 5.3.1) and FRS Port configuration registers (Chapter 5.3.2). The FRS
Switch configuration registers are used to configure the operation of the FRS switch core. The
FRS Port configuration registers are used to configure the operation of the input/output ports
of FRS. There is a separate set of FRS Port configuration registers for every Ethernet port
(see Figure 26).

Manual 46 (68) Version 2.10

FRS

5.3.1 FRS Switch Configuration Registers

Table 2 presents the FRS switch configuration register groups. These registers are accessible
using indirect register access (Chapter 5.1) with FRS PHY address as PHY Address in the
MDIO access to PRA and PRD registers.

Address Offset Acronym Register group description Section Table

0x0000 SWITCH General switch configuration registers 5.3.1.1 Table 3

Table 2. FRS Switch Configuration Register Groups

5.3.1.1 General Switch Configuration Registers

The General switch configuration registers are presented in Table 3.

Manual 47 (68) Version 2.10

FRS

Address Register Description

SWITCH+ ID0 IP Core ID 0
0x0000 - Reset: 0 x 00 00
- IP core identification register 0.
Bits 15-0 : RO Device ID bits 23 to 8.
Device ID of FES and FRS is 0x40.
SWITCH+ ID1 IP Core ID 1
0x0001 - Reset: 0 x 40 00
- IP core identification register 1.
Bits 7-0 : RO Reserved
Bits 15-8 : RO Device id bits 7 to 0.
Device ID of FES and FRS is 0x40.
SWITCH+ FES_SVN_ID1 FES SVN ID1
0x0002 - Reset: 0 x XX XX
Bits 15-0 : RO FES configuration ID.
FES configuration ID for FRS is defined in release
note.
SWITCH+ FES_SVN_ID2 FES SVN ID2
0x0003 - Reset: 0 x XX XX
Bits 15-0 : RO FES configuration SVN ID.
Revision number from Flexibilis version control
system.
SWITCH+ FES_SVN_ID3 FES SVN ID3
0x0004 - Reset: 0 x XX XX
Bits 15-0 : RO FES body SVN ID.
Revision number from Flexibilis version control
system.
SWITCH+ Reserved Reserved
0x0005 …
SWITCH+
0x0007
SWITCH+ GENERAL General register
0x0008 - Reset: 0 x 00 00
- General control bits for FES.
Bit 0 : R/W Disable MDIO polling
Writing ‘1’ to this bit disables MDIO polling. When
polling is disabled CPU may access registers of
connected PHY devices.
Bit 1 : RO MDIO polling state
MDIO polling state. After CPU writes ‘1’ to Disable
MDIO polling -bit, it should wait until this bit is ‘0’
before accessing the external PHY devices.
‘0’ = disabled
‘1’ = enabled
Bits 9-2 : RO Reserved
Bits 12-10 : R/W PTP Mode
‘00’ = PTP over UDP/IPv4
‘01’ = reserved
‘10’ = PTP over Ethernet
‘11’ = reserved
Bit 13 : RO Reserved
Bit 14 : R/SC Clear MAC address table
Writing ‘1’ to this bit clears the whole MAC address
table. FRS clears this bit when done.
Bit 15 : R/SC Software reset
Writing ‘1’ to this bit starts a software reset. FRS clears
the bit when reset is completed.
SWITCH+ Reserved Reserved
0x0009
SWITCH+ CMEM_FILL_LEVEL Control Memory Fill Level
0x000A - Reset: 0 x xxxx
Bits N-0 : RO Number of available frame pointers
N depends on the size of Control Memory. Each port
keeps one frame pointer reserved.
Bits 15-M : RO Reserved

SWITCH+ DMEM_FILL_LEVEL Data Memory Fill Level

0x000B - Reset: 0 x xxxx
Bits N-0 : RO Number of available fragment pointers
N depends on the size of data memory. Each port
keeps two fragment pointers reserved.
Bits 15-M : RO Reserved

Manual 48 (68) Version 2.10

FRS

SWITCH+ SEQ_MEM_FILL_ HSR Sequence Number Memory Fill Level

0x000C LEVEL - After reset: 0 x 00FB
Bits 7-0 : RO HSR sequence number memory pointers available
Note that each port keeps one pointer reserved all the
time.
Bits 15-8 : RO Reserved
SWITCH+ ADDRESS_AGING MAC Address Aging Configuration
0x0010 - Reset: 0 x 00 12
- Configuration register for address aging functionality of the MAC Address
table.
Bits 6-0 : R/W Address LifeTime. (ProxyNodeTableForgetTime in HSR)
Lifetime of automatically learned addresses. The
value is interpreted as multiples of 16 seconds
(when using default Aging Base Time). Valid values
1…127 (16s…2032s), 0=reserved.
Bit 7 : RO Reserved
Bits 9-8 : R/W HSR EntryForgetTime
Timer value for HSR duplicate discard algorithm,
see HSR specification[7]. The value is interpreted as
2^n * Aging base Time milliseconds, where n is the
value in these bits. (0=10ms, 1=20ms,
2=40ms,3=80ms when using default Aging Base
Time)
Bits 15-10 : RO Reserved
SWITCH+ AGING_BASE_ Aging Base Time Value LO
0x0011 TIME_LO - After reset: 0 x A11F
Bits 15-0 : R/W Aging base time value bits(15:0).
Defines Aging Base Time in number of system clock
cycles. Default value gives 4 milliseconds with 125
MHz system clock frequency.
SWITCH+ AGING_BASE_ Aging Base Time Value HI
0x0012 TIME_HI - After reset: 0 x 0007
Bits 7-0 : R/W Aging base time value bits (23:16).
Defines Aging Base Time in number of system clock
cycles.
Bits 15-8 : RO Reserved
SWITCH+ AUTH_STATUS IP License Authentication Status Counter
0x0013 - After reset: 0 x 0000
Bits 12-0 : RO Authentication failure counter
The value of this counter is incremented by one when
IP license authentication request fails; the value is
decremented by one when authentication succeeds.
Saturates to 8191 (0x1FFF) and to 0. Authentication
requests are done approximately once per second. In
case value 8191 is reached FRS stops operating.
Bits 15-13 : RO Reserved

Table 3. General Switch Configuration Registers

The exact formula for the minimum and maximum of the duplicate aging time is the following:
Duplicate aging time (min) = 2 * (AGING_BASE_TIME * Tclk) * (2 ^
HSR_ENTRY_FORGET_TIME);
Duplicate aging time (max) = 3 * (AGING_BASE_TIME * Tclk) * (2 ^
HSR_ENTRY_FORGET_TIME);
, where AGING_BASE_TIME is the Aging Base Time in registers AGING_BASE_TIME_LO
and AGIGNG_BASE_TIME_HI, HSR_ENTRY_FORGET_TIME is the value in HSR
EntryForgetTime bits in ADDRESS_AGING register and Tclk is the period of the Main Clock
(clk).

The exact formula for the minimum and maximum of the MAC entry aging time is the
following:
MAC entry aging time (min) = 6 * (AGING_BASE_TIME * Tclk) * 600 *
ADDRESS_LIFETIME;

Manual 49 (68) Version 2.10

FRS

MAC entry aging time (max) = 7 * (AGING_BASE_TIME * Tclk) * 600 *

ADDRESS_LIFETIME;
, where AGING_BASE_TIME is the Aging Base Time in registers AGING_BASE_TIME_LO
and AGIGNG_BASE_TIME_HI, ADDRESS_LIFETIME is the value in Address Lifetime bits in
ADDRESS_AGING register and Tclk is the period of the Main Clock (clk).

Manual 50 (68) Version 2.10

FRS

5.3.2 FRS Port Configuration Registers

Table 4 presents the FRS port configuration register groups. These registers are accessible
using indirect register access (Chapter 5.1) with Port PHY address as PHY Address in the
MDIO access to PRA and PRD registers. Note that these registers are accessible only when
PHY polling feature is enabled. When it is disabled, the access goes to an external PHY
device.
FRS port configuration registers are used to configure port-specific features of the FRS. The
FRS Port configuration register groups are listed in Table 4.

Address Offset Acronym Register group description Section Table

0x0000 GEN General configuration and state 5.3.2.1 Table 5
registers
0x1000 HSR HSR configuration registers 5.3.2.2 Table 6
0x2000 PTP PTP configuration registers 5.3.2.3 Table 7
0x4000 IPO Inbound policy registers 5.3.2.4 Table 8

Table 4. FRS Port Configuration Register Groups

5.3.2.1 General Configuration and State Registers

General configuration and state registers are presented in Table 5.

Address Register Description

GEN+ PORT_STATE Port State Register
0x0000 - Reset: 0 x 10 20
Bits 1-0 : R/W Port state.
00 = Forwarding. Port learns MAC addresses and
forwards data.
01 = Learning. Port learns MAC addresses, but does
not forward data.
10 = Disabled. Port neither learns MAC addresses nor
forwards data.
11 = Reserved
Bits 3-2 : R/W Port management status.
00 = Normal mode
01 = Management mode. Only frames with a
management trailer can be sent to this port and it
sends all frames with a management trailer. Note that
only the first port can be configured as a management
port.
10 = Reserved
11 = Reserved
Bits 5-4 : R/W Port HW mode
00 = MII
01 = Reserved
10 = GMII
11 = Reserved
Bits 7-6 : RO Reserved
Bits 9-8 : R/W Speed select
Bit9 Bit8
0 0 = Automatic
0 1 = 1000 Mb/s
1 0 = 100 Mb/s
1 1 = 10 Mb/s
Bit 11-10 : RO Current speed
Updated only when MDIO Polling is enabled.
Bit11 Bit10
0 0 = Disabled
0 1 = 1000 Mb/s
1 0 = 100 Mb/s
1 1 = 10 Mb/s
Bits 15-12 : RO Reserved

Manual 51 (68) Version 2.10

FRS

GEN+ 0x1 Reserved Reserved

…
GEN+ 0x7
GEN+ PORT_VLAN_ID Port VLAN ID Configuration Register
0x0008 - Reset: 0 x 00 00
- Contains VLAN configuration for the port.
Bits 11-0 : R/W Port VLAN number.
Bits 15-12 : RO Reserved
GEN+ 0x9 Reserved Reserved

GEN+ PORT_FWD_MASK Forward Portmask Configuration Register

0x000A - Reset: 0 x 00 00
- Contains Forward portmask for the port.
Bits 15-0 : R/W Port forward mask.
Bit 0 corresponds to port 0, bit 1 corresponds to port 1,
etc.
‘0’ = enable forwarding to the port
‘1’ = disable forwarding to the port
GEN+ 0xB Reserved Reserved
…
GEN+ 0xF
GEN+ ERROR_RX MAC RX Error Counter
0x0010 - Reset: 0 x 00 00
- Contains the number of MAC RX errors for the port. Wraps around after
overflow.
Bits 15-0 : RO Number of RX errors.
GEN+ ERROR_TX MAC TX Error Counter
0x0011 - Reset: 0 x 00 00
- Contains the number of MAC TX errors for the port. Wraps around after
overflow.
Bits 15-0 : RO Number of TX errors.
GEN+ PRIQ_DROP Priority Queue Drop Counter
0x0012 - Reset: 0 x 00 00
- Contains the number frames dropped because a priority queue was full.
Wraps around after overflow.
Bits 15-0 : RO Number of priority queue drops.
GEN+ EARLY_DROP Number of Early Frame Drops
0x0013 - Reset: 0 x 00 00
- Contains the number of frames dropped by Frame Early Drop. Wraps
around after overflow.
Bits 15-0 : RO Number of frames dropped.
GEN+ RX_STATUS_CNT0 Number of RX Frames Forwarded
0x0014 - Reset: 0 x 00 00
Bits 15-0 : RO Number of frames
Number of frames received and forwarded. Wraps
around after overflow.
GEN+ 0x15 Reserved Reserved
…
GEN+ 0x1B
GEN+ TX_STATUS_CNT0 Number of Frames Transmitted
0x001C - Reset: 0 x 00 00
Bits 15-0 : RO Number of frames transmitted. Wraps around after overflow.

Table 5. General Configuration and State Registers

5.3.2.2 HSR/PRP Registers

HSR/PRP registers are presented in Table 6.

Manual 52 (68) Version 2.10

FRS

Address Register Description

HSR+ HSR_CFG HSR/PRP Configuration Register
0x0000 - Reset: 0 x 00 00
- Register can be updated only when port is disabled via PORT_STATE
(Table 5) register. Configuration change procedure:
o Disable both redundant ports (Table 5, PORT_STATE)
o Change mode (HSR_CFG) for both redundant ports
o Enable both configured ports (PORT_STATE)
Bits 0 : R/W Port Mode.
0 = HSR/PRP disabled for the port
1 = HSR/PRP enabled for the port
Bits 3-1 : RO Reserved
Bits 7-4 : R/W HSR Ring ID
Bit 8 : R/W HSR/PRP mode select.
0 = Port is in HSR mode
1 = Port is in PRP mode
Bit 9 : RO Reserved
Bit 10 : R/W Mode A/B select
0 = Port is HSR/PRP port A
1 = Port is HSR/PRP port B
The selection is valid only when HSR/PRP is enabled
(bit0=1)
Bits 15-11 : RO Reserved
HSR+ DUPLICATE_DROP HSR Duplicate drop counter
0x0001 _CNT - Reset: 0 x 00 00
Bits 15-0: RO Number of duplicates
Number of duplicate frames dropped after reception.
Wraps around after overflow.

Table 6. HSR Registers

5.3.2.3 PTP Registers

PTP registers are presented in Table 7.

Address Register Description

PTP+ PTP_DELAY_SUBN PTP Link Delay Register, subnanoseconds
0x0000 S - Reset: 0 x 00 00
- Contains the subnanoseconds part of the link delay for peer-to-peer
transparent clock. Must be set to 0x0 for end-to-end transparent clock.
- The value in this register is taken into use after writing to register
PTP_DELAY_NS_LOW
Bits 15-0 : R/W Link delay, subnanoseconds
Presented in 2^16 parts of a nanosecond
PTP+ PTP_DELAY_NS_L PTP Link Delay Register, nanoseconds lowest part
0x0001 OW - Reset: 0 x 00 00
- Contains the lowest 16 bits of the nanoseconds part of the link delay for
peer-to-peer transparent clock. Must be set to 0x0 for end-to-end
transparent clock.
- Write access to this registers takes into use the values in registers
PTP_DELAY_SUBNS and PTP_DELAY_NS_HIGH
Bits 15-0 : R/W Link delay, nanoseconds
PTP+ PTP_DELAY_NS_HI PTP Link Delay Register, nanoseconds highest part
0x0002 GH - Reset: 0 x 00 00
- Contains the highest 8 bits of the nanoseconds part of the link delay for
peer-to-peer transparent clock. Must be set to 0x0 for end-to-end
transparent clock.
- The value in this register is taken into use after writing to register
PTP_DELAY_NS_LOW
Bits 7-0 : R/W Link delay, nanoseconds
Bits 15-8 : RO Reserved

Table 7. PTP Registers

Manual 53 (68) Version 2.10

FRS

5.3.2.4 Inbound Policy Registers

Inbound policy registers are presented in Table 8.

Manual 54 (68) Version 2.10

FRS

Address Register Description

IPO + ETH_ADDR0_CFG Ethernet address 0 filter configuration
0x0000 - Reset: 0 x 00 00
- Configuration for Ethernet address 0 (ETH_ADDR0) of inbound policy
filter.
Bit 0 : R/W Enable
Enable this entry. The other bits in this register are
functional only when this is set to ‘1’.
Bit 1 : RO Reserved
Bits 7-2 : R/W Compared Length
Defines how many bits from the start of the MAC
addresses of the incoming frames are compared to the
value in registers ETH_ADDR0_0...2. If the value is 48
the whole MAC address is compared. With value 1
only the unicast/multicast bit is compared. With value 0
every frame matches. Values over 48 are reserved.
Bits 9-8 : RO Reserved
Bit 10 : R/W No HSR-tag
Do not add a HSR-tag to the frame even when output
from HSR enabled port.
Bit 11 : R/W No PRP-trailer
Do not add a PRP-trailer to the frame even when
output from PRP enabled port.
Bits 13-12 : R/W Priority
Set priority of the frame to this value. Overrides other
priority settings.
Bits 15-14 : RO Reserved
IPO + ETH_ADDR0_FWD Ethernet address 0 allow forwarding
0x0001 _ALLOW - Reset: 0 x 00 00
- Defines into which ports the matching frame is allowed to be forwarded
Bits 15-0 : R/W Forward enable mask
Bit 0 corresponds to port 0, bit 1 corresponds to port
1, etc.
‘0’ = Forwarding is not allowed to this port
‘1’ = Forwarding is allowed to this port
IPO + ETH_ADDR0_FWD Ethernet address 0 mirror port
0x0002 _MIRROR - Reset: 0 x 00 00
- Defines into which ports the matching frames are mirrored to
Bits 15-0 : R/W Forward mirror mask
Bit 0 corresponds to port 0, bit 1 corresponds to port
1, etc.
‘0’ = Frame is not mirrored to this port
‘1’ = Frame is mirrored to this port. If the value of
this bit is ‘1’, the corresponding bit in
ETH_ADDR0_FWD_ALLOW register cannot be ‘0’
IPO+ Reserved Reserved
0x0003
IPO + ETH_ADDR0_0 Ethernet address 0 part 0
0x0004 - Reset: 0 x 00 00
- First part of the Ethernet address ETH_ADDR0.
Bits 7-0 : R/W 1st octet (XX:00:00:00:00:00)
Bits 15-8 : R/W 2nd octet (00:XX:00:00:00:00)
IPO + ETH_ADDR0_1 Ethernet address 0 part 1
0x0005 - Reset: 0 x 00 00
- Second part of the Ethernet address ETH_ADDR0.
Bits 7-0 : R/W 3rd octet (00:00:XX:00:00:00)
Bits 15-8 : R/W 4th octet (00:00:00:XX:00:00)
IPO + ETH_ADDR0_2 Ethernet address 0 part 2
0x0006 - Reset: 0 x 00 00
- Third part of the Ethernet address ETH_ADDR0.
Bits 7-0 : R/W 5th octet (00:00:00:00:XX:00)
Bits 15-8 : R/W 6th octet (00:00:00:00:00:XX)
IPO+ Reserved Reserved
0x0007…
IPO+
0x000F
IPO + ETH_ADDR1_CFG Ethernet address 1 filter configuration
0x0010 Description: See ETH_ADDR0_CFG
… … …
IPO + ETH_ADDR15_2 Ethernet address 15 part 2
0x00A6 Description: See ETH_ADDR0_2

Table 8. Inbound Policy Registers

Manual 55 (68) Version 2.10

FRS

6 External Signals
The external signals of FRS are presented in Figure 29. The external signals consist of
MII/GMII signals, MDIO signals, Time interface signals and General signals.

MII/GMII Rx Signals MII/GMII Tx Signals

rx_rst(n:0) rx_rst(n:0)
rx_clk(n:0) tx_clk(n:0)
rx_dv(n:0) tx_en(n:0)
rxd(n:0)(3:0) txd(n:0)(3:0)
rx_er(n:0) tx_er(n:0)
crs(n:0)
GMII Rx Signals col(n:0)
rxd(n:0)(7:4)
GMII Tx Signals
General Signals txd(n:0)(7:4)
rst gtx_clk_sel(n:0)
clk_1x
clk_nx
cfg_init_done
cfg_fes_addr(4:0)
cfg_port_addr(n:0)(4:0)
FRS
MDIO MDD Signals MDIO STA Signals
Tri-state Tri-state
buffer buffer
mdd_mdio_in sta_ mdio_in
mdio mmd_ mdio_out sta_ mdio_out mdio
mmd_ mdio_ena sta_ mdio_ena
mmd_ mdc sta_ mdc

Symbols alingment
tx_ alignment

RX Time Interface Signals TX Time Interface Signals

rx_time_ word(95:0) tx_time_ word(95:0)
rx_time_req tx_time_req
rx_ time_ack tx_ time_ack

Authentication Interface Signals

clk_shift
chal_valid
chal_data
resp_valid
resp_data

Figure 29. External Signals of FRS

Manual 56 (68) Version 2.10

FRS

The tri-state buffers for MDIO signals are external to FRS (see Figure 29), because tri-state
signals are normally not used inside an FPGA. The tri-state buffer is used only when the
MDIO signal is wired outside of the FPGA. It is not used if the signal is wired to another block
inside the FPGA.

6.1 Generics
The compile time configuration is presented in Table 9.
Generic name Default value Description
Active edge of reset signal. The allowed values are 0 (active
RST_ACTIVE 1
low) and 1 (active high).
PHY id of FES. Readable from registers PHYIDR1 and
FES_PHY_ID 0x 0000 0000
PHYIDR2 (see Table 1).
Clock divider length for sta_mdc clock. This is used for
sta_mdc clock when FRS is polling the PHYs.
MDC_DIV_MSB 5
Typical value: 5 => Fsta_mdc = Fclk/ 64
Allowed values: >2
Width of external time data bus. Common setting for Rx and
TIME_WORD_MSB 95
Tx. The only supported value is 95
Number of Ethernet ports minus one.
Allowed values: 2 to 7
3-port FRS: use 2
FES_PORT_HIGH 3
4-port FRS: use 3
5-port FRS: use 4
…
HSR_PORT_OPT 0 „0‟: All the ports have HSR/PRP capability
„1‟: Only two ports have HSR/PRP capability
When HSR_PORT_OPT=‟1‟, this defines which port is
HSR_PORT_A 1 HSR/PRP redundant port A. The value of HSR_PORT_A
cannot be the same as the value of HSR_PORT_B
When HSR_PORT_OPT=‟1‟, this defines which port is
HSR_PORT_B 2 HSR/PRP redundant port B. The value of HSR_PORT_B
cannot be the same as the value of HSR_PORT_A.
FPGA device family, for example “ECP3”, “Stratix II GX” or
DEVICE_FAMILY “”
“Spartan 6”

Table 9. FRS Generics

6.2 General Signals

The General Signals consist of global reset, clocks and configuration signals. The General
Signals are presented in Table 10.

Manual 57 (68) Version 2.10

FRS

Name Direction Description

Reset
rst This is a global asynchronous signal that resets all the flip-flops of
Input
FRS to their initial values. Active high or low depending on generic
RST_ACTIVE (see Table 9).
Main Clock
This signal is the FRS main clock and its frequency must be greater
than or equal to 125 MHz. Only the rising edge of the signal is used.
This signal should be connected to a low skew clock buffer. If there
clk Input
is a shortage of low skew clock buffers at the FPGA, this signal
should have priority over the rx_clk(n:0) and tx_clk(n:0) signals. If
FRS is going to be used only in 10/100 Mbit modes, the frequency
must be greater than or equal to 50 MHz.
Initialization Done
cfg_init_done Output When high, FRS initialization is done. Goes low only during HW and
SW reset.
FES Address Select
cfg_fes_addr(4:0) Input Selects the PHY address used for accessing FRS Switch
configuration registers. An address from 1 to 31 can be selected.
PHY Address Select
Configures the PHY addresses of the external PHY devices. The
cfg_port_addr(n:0)(4:0) same addresses are also used when accessing FRS Port
Input
configuration registers. Addresses from 1 to 31 can be selected.
None of the ports can have the same address as cfg_fes_addrr(4:0)
or another port.
Main Clock Frequency
Informs FES about main clock (clk) frequency used. This is given in
1 MHz increments as follows:
cfg_clk_freq(7:0) Input 0 = N/A
1 = 1 MHz
2 = 2 MHz
…
255= 255 MHz

Table 10. General Signals

6.3 Time Interface Signals

Time Interface consists of signals used for time information exchange between FRS and the
rest of the system. The handling of the time information is left outside of FRS because its
implementation may vary significantly depending on the hardware.
The clock time information is used in time stamping of the Ethernet frames received and
transmitted. An exact receive and transmit time information is essential for the IEEE 1588
Precision Time Protocol to achieve its best accuracy.

Manual 58 (68) Version 2.10

FRS

Name Direction Description

Transmit Alignment Control
This signal can be used to adjust transmit start timing to achieve
optimal symbol alignment when using fiber connection. This signal
can be connected to tx alignment signal of an external SGMII
tx_alignment Input adapter block.
If used, this signal must toggle on each clock cycle.
If not used, this signal must be tied to „0‟.
This signal is synchronous to the MII/GMII interface transmit clock.
Receive Time Request
When a frame is received, at the moment when the Frame
rx_time_req Output Timestamp Point is in MII/GMII interface, this signal toggles.
This signal is synchronous to the MII/GMII interface receive clock.
If time interface is not used, this signal must be tied to rx_time_ack.
Receive Time Acknowledge
This signal should toggle to follow the rx_time_req signal when
rx_time_ack Input data is updated on the rx_time_word(95:0) signal.
This signal is synchronized to the clk clock.
If time interface is not used, this signal must be tied to rx_time_req.
Receive Time Word
This signal should be updated when the rx_time_req signal has
opposite state to the rx_time_ack signal.
The format is the following:
rx_time_word(15:0): subnanoseconds (2^16 parts of a
rx_time_word(95:0) Input nanosecond)
rx_time_word(45:16): nanoseconds
rx_time_word(47:46): reserved (=0)
rx_time_word(95:48): seconds
This signal is synchronous to the MII/GMII interface receive clock.
If time interface is not used, this bus must be tied to zero.
Transmit Time Request
This signal toggles to request up to date timestamp data.
tx_time_req Output
This signal is synchronous to the MII/GMII interface transmit clock.
If time interface is not used, this signal must be tied to tx_time_ack.
Transmit Time Acknowledge
This signal should toggle to follow the tx_time_req signal when
tx_time_ack Input data is updated on the tx_time_word(95:0) signal.
This signal is synchronized to the clkclock.
If time interface is not used, this signal must be tied to tx_time_req.
Transmit Time Word
This signal should be updated when the tx_time_req signal has
opposite state to the tx_time_ack signal.
rx_time_word(15:0): subnanoseconds (2^16 parts of a
nanosecond)
tx_time_word(95:0) Input
rx_time_word(45:16): nanoseconds
rx_time_word(47:46): reserved (=0)
rx_time_word(95:48): seconds
This signal is synchronous to the MII/GMII interface transmit clock.
If time interface is not used, this bus must be tied to zero.

Table 11. Time Interface Signals

6.4 Authentication Interface Signals

Authentication Interface Signals are connected to respective signals of external (to FPGA)
security chip, if such chip exists. If there is no security chip, input signals should be tied to „0‟
and output signals left unconnected.

Manual 59 (68) Version 2.10

FRS

6.5 MII/GMII Signals

The Media Independent Interface (MII) and the Gigabit Media Independent Interface (GMII)
signals of FRS MAC are presented in Table 12. The MII/GMII signals consist of the MII/GMII
RX and the MII/GMII TX signals. Every MAC entity of FRS has its own set of MII/GMII signals:
the MII/GMII signals are presented as vectors in Table 12, where n is the number of MAC
blocks in FRS minus one.
The MII/GMII RX signals are synchronous to rx_clk and the MII/GMII TX signals are
synchronous to tx_clk. Crs and col signals can be asynchronous with respect to tx_clk (and
rx_clk). For further information about the MII interface see IEEE Std 802.3 [8].
The MII/GMII signals are presented in Table 12. Note that in the table, unless otherwise
stated, all the signals that can activate or enable something are active when their state is high
and inactive when their state is low.

FRS registers rx_dv, rxd and rx_er on rising edge of rx_clk

T rx_clk
rx_rst

rx_clk

rx_dv

rxd(3:0)
x x
rxd(7:4)

rx_er

FRS creates tx_en, txd and tx_er on rising edge of tx_clk and
registers crs and col on rising edge of tx_clk
(NOTE: crs and col effective only in half-duplex mode) T tx_clk
tx_rst

tx_clk

tx_en

txd(3:0) x
txd(7:4)
tx_er

crs

col

Figure 30. (G)MII signal timing for signal port

Manual 60 (68) Version 2.10

FRS

Name Direction Description

MII/GMII Receive Reset
rx_rst(n:0) Input Resets the corresponding clock domain logic. Active high or active
low depending on generic RST_ACTIVE (see Table 9).
MII/GMII Receive Clock
The frequency is 2.5 MHz in the 10 Mbps mode, 25 MHz in the 100
rx_clk(n:0) Input Mbps mode and 125MHz in 1000 Mbps mode. It is allowed that the
clock is not running continuously. Discontinuous receive clock does
not cause malfunction in FRS MAC. This signal should be
connected to a low skew clock buffer.
MII/GMII Receive Data Valid
rx_dv(n:0) Input
Indicates when the data lines are carrying valid data from the PHY.
MII/GMII Receive Data
rxd(n:0)(3:0) Input
Data lines from the PHY.
GMII Receive Data
rxd(n:0) (7:4) Input
Data lines from the PHY.
MII/GMII Receive Error
rx_er(n:0) Input
Indicates that an error has been detected while receiving a frame.
MII/GMII Transmit Reset
tx_rst(n:0) Input Resets the corresponding clock domain logic. Active high or active
low depending on generic RST_ACTIVE (see Table 9).
MII/GMII Transmit Clock
The frequency is 2.5 MHz in the 10 Mbps mode, 25 MHz in the 100
tx_clk(n:0) Input Mbps mode and 125MHz in 1000 Mbps mode. It is allowed that the
clock is not running continuously. Discontinuous transmit clock does
not cause malfunction in FRS MAC. This signal should be
connected to a low skew clock buffer.
MII/GMII Transmit Enable
tx_en(n:0) Output
Indicates that the data lines are carrying valid data to the PHY.
MII/GMII Transmit Data
txd(n:0) (3:0) Output
Data lines to the PHY.
GMII Transmit Data
txd(n:0) (7:4) Output
Data lines to the PHY.
MII/GMII Transmit Error
tx_er(n:0) Output
Indicates that an error has occurred while transmitting the frame.
MII Carrier Sense
crs(n:0) Input
Indicates that the medium is busy.
MII Collision Detection
col(n:0) Input
Indicates that a collision is detected on the medium.
GMII Transmit Clock Select
gtx_clk_sel(n:0) Output Selects the transmit clock by controlling an external clock
multiplexer, see Figure 33.

Table 12. MII/GMII Signals

6.6 MDIO Interface

The MDIO Station Management signals are presented in Table 13 and MDIO Manageable
Device signals are presented in Table 14.

Manual 61 (68) Version 2.10

FRS

Name Direction Description

Management Data Input
sta_mdio_in Input
Serial data input.
Management Data Output
sta_mdio_out Output
Serial data output.
Management Data Output Enable
sta_mdio_ena Output This signal is a tri-state enable signal for the Management Data
Output signal. It is active high.
Management Data Clock
The frequency of this signal is configurable using generic
MDC_DIV_MSB, see Table 9. The default frequency is clk / 64. The
sta_mdc Output
IEEE Std 802.3 requires that the frequency must be lower than, or
equal to 2.5MHz.
The clock runs only when data is being transferred.

Table 13. MDIO Station Management Signals

Name Direction Description

Management Data Input
mmd_mdio_in Input
Serial data input.
Management Data Output
mmd_mdio_out Output
Serial data output.
Management Data Output Enable
mmd_mdio_ena Output This signal is a tri-state enable signal for the Management Data
Output signal. It is active high.
Management Data Clock
The frequency must be lower than or equal to clk / 8. Note that the
mmd_mdc Input IEEE Std 802.3 requires that the frequency must be lower than, or
equal to 2.5MHz.
The clock runs only when data is being transferred.

Table 14. MDIO Manageable Device Signals

MDIO timing is shown in Figure 31 and Figure 32.

Manual 62 (68) Version 2.10

 FRS

Manual
mmd_mdio write: FRS registers mmd_mdio_in signal on rising edge of mmd_mdc*

mmd_mdc

mmd_mdio_in 0 1 0 1 A4 A3 A0 R4 R3 R0 1 0 D15 D14 D1 D0

Preamble
Idle SFD OP code PHY address Register address Turn around Data Idle
(32 ‟1's)

* exact registering moment of mmd_mdio_in is 2-4 clk_1x cycles after rising edge of mmd_mdc due to synchronization to clk_1x domain
* mmd_mdio_ena stays logic ’0'

mmd_mdio read operation: FRS registers mmd_mdio_in signal on rising edge of mmd_mdc* and
generates mmd_mdio_out with rising edge of mmd_mdc

63 (68)
mmd_mdc

mmd_mdio_in 0 1 1 0 A4 A3 A0 R4 R3 R0 Z

Preamble Turn
Idle SFD OP code PHY address Register address Data Idle
(32 ‟1's) around

Figure 31. MDIO MMD Signal Timing Diagram

mmd_mdio_out 0 D15 D14 D1 D0 0

mmd_mdio_ena

* exact registering moment of mmd_mdio_in is 2-4 clk_1x cycles after rising edge of mmd_mdc due to synchronization to clk_1x domain

Version 2.10
 FRS

Manual
sta_mdio write operation: FRS generates sta_mdc and sta_mdio_out signal on rising edge of sta_mdc

sta_mdc

sta_mdio_out 0 1 0 0 A4 A3 A0 R4 R3 R0 1 0 D15 D14 D1 D0

Preamble
Idle SFD OP code PHY address Register address Turn around Data Idle
(32 ‟1's)

sta_mdio read operation:

FRS generates sta_mdc and sta_mdio_out with rising edge of clk_1x (sta_mdio_out changes when sta_mdc falling edge )
FRS registers sta_mdio_in signal on falling edge of sta_mdc

64 (68)
sta_mdc

sta_mdio_out 0 1 1 0 A4 A3 A0 R4 R3 R0 Z

Preamble Turn
Idle SFD OP code PHY address Register address Data Idle
(32 ‟1's) around

sta_mdio_ena

Figure 32. MDIO STA Signal Timing Diagram

* sta_mdc synchronized to clk_1x domain

sta_mdio_in 0 D15 D14 D1 D0 0

Version 2.10
FRS

6.7 Transmit Clock Multiplexer

In gigabit (GMII) mode the receive and the transmit clock speeds are higher, and the direction
of the transmit clock signal towards PHY is opposite than in 10 Mbps and 100 Mbps (MII)
modes. For this reason, and also because it is reasonable to generate the high-speed GMII
transmit clock (gtx_clk) outside of FRS, FRS MAC employs an external clock multiplexer. The
basic connection of the clock multiplexer (clk_mux) with FRS MAC is presented in Figure 33.
The clock multiplexer is not needed if FRS MAC is used only in 10/100 Mbps mode, or only in
1000 Mbps mode.

125MHz clk
generation

Same 125MHz frequency,

different phase

gtx_clk (GMII)
FRS MAC

tx_clk clk_
mux
tx_clk (MII)

PHY
gtx_clk_sel

rx_clk

Figure 33. External Transmit Clock Multiplexer

6.7.1 Interfacing to CPU with MII/GMII

Connecting MII/GMII between FRS and a CPU is illustrated in Figure 34.

Manual 65 (68) Version 2.10

FRS

25MHz clk 125MHz clk

generation generation

25MHz clk 125MHz clk

clk_mux

rx_clk gtx_clk_sel
tx_clk rx_clk
gtx_clk tx_clk

CPU rxd(7:0) txd(7:0) FRS MAC

rx_dv tx_en
rx_er tx_err
tx_en rx_dv
txd(7:0) rxd(7:0)
tx_err rx_er

Figure 34. Host Interface Connection

Table 15 presents functionality of clk_mux for MII/GMII clocks in MII and GMII modes.

Signal Source (MII, gtx_clk_sel=0) Source (GMII, gtx_clk_sel=1)

CPU rx_clk 25MHz clk 125MHz clk
CPU tx_clk 25MHz clk -
FRS rx_clk 25MHz clk CPU gtx_clk
FRS tx_clk 25MHz clk 125MHz clk

Table 15. MII/GMII Clock Mux Configuration

Manual 66 (68) Version 2.10

FRS

7 Glossary

ASIC Application Specific Integrated Circuit

CPU Central Processing Unit
CRC Cyclic Redundancy Check
DST Destination (Address)
FED Frame Early Drop
FES Flexibilis Ethernet Switch
FRS Flexibilis Redundant Switch
FIFO First In First Out
FPGA Field Programmable Gate Array
GMII Gigabit Media Independent Interface
HSR High-availability Seamless Redundancy
IEEE Institute of Electrical & Electronics Engineers, Inc
LAN Local Area Network
MAC Media Access Control
MDC Management Data Clock
MDIO Management Data Input/Output
MII Media Independent Interface
MMD MDIO Managed Device
MUX MUltipleXer
PHY Physical layer device
PTP Precision Time Protocol
RSTP Rapid Spanning Tree Protocol
RX Receive
SFD Start Frame Delimiter
SRC Source (Address)
STA Station Management Entity
STP Spanning Tree Protocol
TX Transmit
VHDL Very high speed integrated circuits Hardware Description Language
VLAN Virtual LAN

Manual 67 (68) Version 2.10

FRS

8 References
[1] “Flexibilis Ethernet Switch/Router Specification”, Flexibilis Oy, 2011
[2] IEEE Std 802.3x-1997, “Specification for 802.3 Full Duplex Operation and Physical
Layer Specification for 100 Mb/s Operation on Two Pairs of Category 3 Or Better
Balanced Twisted Pair Cable (100BASE-T2)”, 1997
[3] IEEE Std 802.1D, “Media Access Control (MAC) Bridges”, 2004.
[4] IEEE Std 1588-2008: IEEE Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems, 2008.
[5] Rich Seifert, “The Switch Book, The complete guide to LAN switching technology”,
John Wiley & Sons inc, 2000, page 299
[6] IEEE Std 802.1w-2001, “Media Access Control (MAC) Bridges: Amendment 2 –
Rapid Reconfiguration“, 2001
[7] IEC62439-3 , “Industrial communication networks - High availability automation
networks - Part 3: Parallel Redundancy Protocol (PRP) and High-availability
Seamless Redundancy (HSR)”, 2010, Clause 5
[8] IEEE Std 802.3-2008, “Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications”, 2008

Manual 68 (68) Version 2.10