ECP5 Dual Ring Wrapper ====================== This module is a higher-level wrapper around the :doc:`ecp5_quad_wrapper `, providing a simplified interface to access a preconfigured HotRIO Dual Ring slave. HotRIO Dual Ring is a network configuration in which nodes are connected by two fiber optic daisy-chains (called rings) transmitting redundant HotRIO data in opposite directions. This architecture guarantees that the master will receive data from all functional slave nodes even in the case of a fault in one node or fiber. To achieve this, the datapaths of the two rings are multiplexed at each node so that in the absence of RX data on one ring, that ring's transmitter becomes connected to the TX stream of the other ring. Another advantage of Dual Ring is the possibility to compute the network latency between the master and each slave node on each ring, by means of the Delay Measurement Protocol (DMP). This protocol performs the calculation by observing the difference between the arrival times of HotRIO timing flags on the two rings and comparing it with the total delay of such flags when passing through a full ring from the master TX to the master RX. The ECP5 Dual Ring Wrapper provides all necessary modules to instantiate a minimal Dual Ring slave node: - **ECP5 Quad Wrapper**: four-channel 8b/10b transceiver, preconfigured to support bidirectional HotRIO communications on channels *ch0* and *ch2*, while admitting manual configuration on channels *ch1* and *ch3*. - **HotRIO slaves**: two instances of the :doc:`hotrio_slave ` module, handling reception and transmission of HotRIO frames from/to the transceiver. - **DMP module**: one instance of :doc:`dmp_module `, used to calculate the network latency of the node with respect to the master on each ring. .. note:: As specified above, ``ecp5_dual_ring_wrapper`` is meant to implement a HotRIO Dual Ring **slave**. It shall not be used to instantiate a Dual Ring **master**; for this purpose, use an ``ecp5_quad_wrapper`` connected to :doc:`hotrio_master_tx ` and :doc:`hotrio_master_rx ` on both *ch0* and *ch2*. The ``ecp5_quad_wrapper`` documentation linked at the beginning of this page contains instructions on the instantiation of the module. Detailed portlist ----------------- .. vhdlentity:: :file: ../Firmware/Source/ip_cores/ecp5_quad_wrapper/hdl/ecp5_dual_ring_wrapper.vhd :entity: ecp5_dual_ring_wrapper Configuring the Dual Ring Wrapper --------------------------------- This section provides guidance in the instantiation of the ``ecp5_dual_ring_wrapper`` module and in the selection of the appropriate options for the application. Several settings, both in the generic map and in the port map, are equal to those of the ``ecp5_quad_wrapper`` module, and they are explained in its document. These include: - Generics to **invert channels**. - Generics to change the size of SerDes/PCS **reset counters**. - Ports to **power up/down the channels** *not involved in Dual Ring* (*ch1* and *ch3*), and to control their **running disparity** and **Built-in Self Test** (BIST). Here onwards, only the parts of module configuration that differ from the ``ecp5_quad_wrapper`` will be discussed. Fixed options ~~~~~~~~~~~~~ With respect to the Quad Wrapper, this module is partially preconfigured. As a result, some options that were selectable in the Quad Wrapper cannot be changed in the Dual Ring Wrapper. These include the following: - **Both Duals** of the 8b/10b transceiver are **always instantiated**, as they are needed to provide access to channels *ch0* and *ch2* for Dual Ring. As such, the ``hdinp`` and ``hdinn`` ports always have width 4 in the Dual Ring Wrapper, even if *ch1* and *ch3* are unused. - **Line rates** for the two Duals cannot be changed and they are set to **125 MHz**, the HotRIO transmission frequency. - **Direct link mode** cannot be enabled for any Dual. Internally, the TX reference clock of the Duals are both connected to the same clock net, provided by the user on the ``clk_i`` port. Clocking ~~~~~~~~ While the Quad Wrapper has a clock input for each Dual, the Dual Ring Wrapper only has **one clock input**, *shared by both Duals*. All data inputs to the Dual Ring Wrapper, including TX data for all channels, the module's reset, and configuration ports, should be provided synchronously with this clock input, *clk_i*. *clk_i* must be a **stable 125 MHz clock** and *must not be derived from a clock output of the module itself*. Enabling and disabling channels ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Channels involved in Dual Ring (*ch0* and *ch2*) cannot be permanently disabled in the generic map. The two auxiliary channels (*ch1* and *ch3*) can be freely configured, as they are general-purpose Quad Wrapper channels. By default they are enabled, but if they are not needed by the application they can be disabled by setting the corresponding **chN_rx_enable_g** and/or **chN_tx_enable_g** generics to *false*. This will cause the channel-specific logic to be omitted inside the Dual Ring Wrapper, resulting in lower resource utilization and potentially easier timing closure. Enabled auxiliary channels can still be powered up or down at runtime using the **chN_rx_pwrup_i** and **chN_tx_pwrup_i** ports. Dual Ring channels can also be powered up or down, but they are always both in the same powerup status, controlled by the **dual_ring_pwrup_i** port. HotRIO slave options ~~~~~~~~~~~~~~~~~~~~ The Dual Ring Wrapper includes HotRIO slave settings both in the generic list and in the port list. These options always take effect in both HotRIO slave instances in the Dual Ring symmetrically. - The generics can be used to set the **number of addresses** belonging to the node, the **delay** between receiving an address in the node's range and sampling the TX payload to be sent as a reply, and whether a **reply** should have the MSB of the address set to 1 or left unchanged. - In the port list, the **first of** the consecutive **addresses belonging to this node** can be selected at runtime through the ``dual_ring_start_address_i`` port. This setting should not be modified while one of the HotRIO slaves of this module is actively replying to a HotRIO packet that belongs to the current address range. Enabling and disabling BIST on Dual Ring channels ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Built-In Self Test is provided for all channels of the Quad. However, Dual Ring channels *cannot be independently set to BIST mode*. BIST can be **enabled in both rings** simultaneously by asserting ``dual_ring_bist_en_i``. When BIST is enabled, the *HotRIO slaves are bypassed* and their flags and counters should be ignored. Both Dual Ring channels will send BIST data on their transmitters, and their receivers will be directly connected to the BIST checker. The two usual BIST flags, "active" and "err", are taken from each checker and combined to produce a single set of flags according to the following rules: - ``dual_ring_bist_active_o`` is high if both "active" flags are high (AND gate) - ``dual_ring_bist_err_o`` is high if any "err" flag is high (OR gate) The Built-In Self Test can be considered passed only if ``dual_ring_bist_active_o`` is steady high and ``dual_ring_bist_err_o`` is steady low. Exchanging data with Dual Ring channels ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ While auxiliary channels have *8-bit data ports* for RX and TX, Dual Ring channels are designed to exchange HotRIO packets. As such, they have **80-bit payload** TX and RX ports and an **8-bit RX address** port, as well as the full set of **flags** and **diagnostic counters** of the ``hotrio_slave`` module. There are also two additional outputs providing timing information to the node: - ``rN_time_o`` provides the 64-bit timestamp sent by the master node. - ``rN_delay_o`` provides the network latency calculated by the DMP, measured in 125 MHz clock periods. Configuring DMP ~~~~~~~~~~~~~~~ As mentioned in the introduction of this document, the HotRIO Delay Measurement Protocol requires information on the **total delay** of a full ring to be able to calculate the delay between the master and the current node. This information can be provided in several ways. The suggested approach is to provide it *through the register tree via sideband communication*. When the register dedicated to the total ring delay is written by the STM32-G0, its *update flag* can be connected to ``ring_delay_valid_i`` to notify the presence of new valid data on ``total_ring_delay_i``. DMP delays will be recalculated every time a new total ring delay is provided to the aforementioned ports.