Functions - 3.1 English

The system-level example design can be divided into two general functional groups:

• Support layer (<component_name>_support )
• Example layer (<component_name>_example_design )

The support layer and its sub-layers, contains all the integral logic of the total Soft Error Mitigation solution. This includes, the instantiations of the following logic:

• The helper blocks required to connect the IP to external devices:
• The UART helper block, a bridge between controllers and a standard RS-232 port. The resulting interface can be used to exchange commands and status with controllers. This interface is designed for connection to processors.
• The SPI flash master helper block, a bridge between controllers and a standard SPI bus. The resulting interface can be used to fetch data by controllers. This helper block is only present when the classification feature is enabled and is designed for connection to standard SPI flash.
• Configuration system primitives instantiation required by the IP.
• Clocking primitive used to distribute the core system clock.

The verification of the SEM controller IP includes these blocks and integrating of this logic into a design is recommended and is fully supported.

The example layer contains instantiation of the support layer and several VIO cores that eases the ability to visually inspect the IP status and dynamically drive inputs to the IP that do not require connection to external devices.

Additionally, this example layer also provides logic to illustrate how you can monitor the Status Interface to ensure that the IP is behaving as expected. The following status error signals are provided:

heartbeat_timeout

This signal asserts when the heartbeat stops toggling for more than 1 second when the SEM controller is in the expected states.

heartbeat_timeout_sticky

This is a sticky version of the heartbeat_timeout signal. After assertion, it stays asserted the rest of the time until the design is reconfigured.

status_irregular_sticky

This is a sticky signal that asserts if more than one status signal is asserted in the same clock cycle.

status_halt

This is a signal that asserts when the IP is halted due to a fatal error (all status signals are asserted).

The monitoring of the status signals is described further in the Systems.

For monolithic devices, there are four VIO IP cores instantiated:

<component_name>_vio_si14

Displays SEM controller Status Interface and status error signals.

<component_name>_vio_so32

Defines the fetch_tbladdr input for the Fetch Interface. Only available when error classification is enabled.

<component_name>_vio_si1_so5

Displays output and defines input for the ICAP Arbitration and Auxiliary Interfaces.

<component_name>_vio_si1_so41 or so45

Displays output and defines input for the Command Interface.

For UltraScale SSI devices, there is a VIO core for each SLR and another VIO core to drive inputs that are shared by all SLRs:

<component_name>_vio_slr_si16_so2

Displays all outputs and defines inputs for the Status and ICAP Arbitration Interfaces for a single SLR.

<component_name>_vio_generic_so44 or so76

Drives shared SLR inputs for Auxiliary, Command, and Fetch Interfaces. Inputs for the Fetch Interface is only available when error classification is enabled and it increases the number of output probes from 44 to 76.

For UltraScale+ SSI devices, there are four VIO IP cores instantiated:

<component_name>_vio_si17 or si20 or si23

Displays SEM controller Status Interface and status error signals.

<component_name>_vio_so32

Defines the fetch_tbladdr input for the Fetch Interface. Only available when error classification is enabled.

<component_name>)_vio_si1_so5

Displays output and defines input for the ICAP Arbitration and Auxiliary Interfaces.

<component_name>_sio_si1_so45

Displays output and defines input for the Command Interface.

Combined, the support and example layer provides a complete SEU mitigation solution for you to evaluate. The system-level design example is also provided as RTL source code unlike the controller itself to allow flexibility in system-level interfacing.

The following figure shows a block diagram of the system-level design example for non-SSI devices. The blocks drawn in gray only exist in certain configurations.

The following figure shows a block diagram of the system-level design example for UltraScale SSI devices. The blocks drawn in gray only exist in certain configurations.

The following figure shows a block diagram of the system-level design example for UltraScale+ SSI devices. The blocks drawn in gray only exist in certain configurations.