xilinx xapp962, single-event upset mitigation for xilinx ...the scrubber interfaces have the same...

XAPP962 (v1.1) March 14, 2008 www.xilinx.com 1

© 2007–2008 Xilinx, Inc. All rights reserved. XILINX, the Xilinx logo, and other designated brands included herein are trademarks of Xilinx, Inc. All other trademarks are the property of their respective owners.

Summary Orbital, space-based, and extra-terrestrial applications are susceptible to the effects of high-energy charged particles. If of sufficient energy, these particles can cause single-event upsets (SEUs), possibly altering the logic state of any static memory element (latch, flip-flop, or RAM cell). Although these upsets are unavoidable, they are correctable.

This application note describes mitigation techniques using triple module redundancy (TMR) combined with configuration scrubbing for Xilinx-specific block RAMs in high-radiation environments (for details on selecting a mitigation technique, refer to [Ref 1]). Also included is a design example demonstrating these mitigation techniques.

It is essential for the reader to have a basic understanding of the Xilinx tool flow using TMR techniques, the Xilinx TMRTool, ISE™, and simulation. An understanding of Xilinx Platform Studio (XPS) is optional but critical if the user desires to replace the block RAM in a processor flow (see [Ref 2]). An in-depth review of [Ref 3] is also highly recommended.

Tools Needed to Complete the Example Design Flow

The following tools are required to complete the included example design flow:

• Xilinx ISE

http://www.xilinx.com/ise/logic_design_prod/foundation.htm

• Xilinx TMRTool

http://www.xilinx.com/ise/optional_prod/tmrtool.htm

• XPS (optional for processor designs)

http://www.xilinx.com/ise/embedded_design_prod/platform_studio.htm

• PlanAhead™ (optional) for viewing the netlists to ensure the design is mitigated as expected

• Mentor Graphics ModelSim™ (optional) for simulating the block RAM scrubber design

Introduction Xilinx FPGAs are an ideal fit for space applications in harsh environments due to the flexibility, size, and reliability these robust devices provide designers. By using a combination of TMR and configuration scrubbing, designers can mitigate the errors caused by single-event transients (SETs), and SEUs (refer to [Ref 4], [Ref 5], and [Ref 6], for more details).

In-orbit, space-based, and extra-terrestrial applications must consider the effects of high-energy charged particles (radiation) can have on electronic components. In particular, SEUs can alter the logic state of any static memory element (latch, flip-flop, or RAM cell). Since the user-programmed functionality of an FPGA depends on the data stored in millions of configuration latches within the device, an SEU in the configuration memory array can have adverse effects on the expected functionality.

Upsets in user block RAM can accumulate and must be monitored and corrected. Simple triplication of the block RAM is often not enough.Therefore, a scrubbing macro is needed to allow the FPGA to self correct the upsets that accumulate in block RAM.

Application Note: Virtex-II, and Virtex-4 FPGAs

XAPP962 (v1.1) March 14, 2008

Single-Event Upset Mitigation for Xilinx FPGA Block MemoriesAuthors: Greg Miller, Carl Carmichael, and Gary Swift

R

http://www.xilinx.com/ise/logic_design_prod/foundation.htm

http://www.xilinx.com/ise/optional_prod/tmrtool.htm

http://www.xilinx.com/ise/embedded_design_prod/platform_studio.htm

http://www.xilinx.com

Block RAM Correction Algorithm Overview


R

Note: Using the built-in error-correction circuitry (ECC) found in Virtex™-4 FPGAs is also not sufficient for correcting these upsets for three reasons:

♦ It cannot correct the actual content (errors can accumulate)

♦ The ECC blocks themselves are not protected

♦ The ECC is limited to 512 x 64 vertically adjacent block RAMs

This application note describes the exact steps required to successfully design, implement, verify, and actively scrub single-port block RAMs in a design. The macro represented here exploits the dual-port nature of the Xilinx block RAMs; therefore, only single-port block RAMs can be replaced for scrubbing at this time because the second port of the block RAM is used by the scrubbing engine.

Block RAM Correction Algorithm Overview

The block RAM self-correction algorithm is based on a custom macro replacing a group of block RAM primitives. This custom macro contains the block RAM scrubber engine and associated block RAMs described in VHDL.The size and dimensions of the block RAM group depend on the HDL code implementation. In the mitigation scheme detailed here, not every FPGA block RAM primitive has an individual scrubber as many block RAM primitives can be replaced with a single scrubber macro.

The block RAM scrubber (Figure 1) functions as follows:

1. An address count is presented at address port B of the block RAMs.

2. Data at address B is presented on port Data_outB.

3. Data is then voted and presented as corrected data on Din_B.

4. If an error is detected, WEB (Write enable B) is activated and corrected and data is written into Din_B Data port Input B. The address counter for all three domains is halted.

5. After correction, the counter is enabled.

6. The address counter is incremented and the process is repeated.X-Ref Target - Figure 1

Figure 1: Block RAM Scrubber Block Diagram

Din_B

AB

Web

Data_OutB0

BRAM_Block0

VD

ERRORData_Voter0

Voted_Data0

Din_B

AB

Web

Data_OutB1

BRAM_Block1

VD

ERRORData_Voter1

Voted_Data1

Din_B

AB

Web

Data_OutB2

BRAM_Block2

VD

ERRORData_Voter2

Voted_Data2

Data_Out[0|1|2]

Address_CNTR

EN[0|1|2]

Address_B[0|1|2]

Error_indication[0|1|2]

CNT_TR[0|1|2]

COMPARATOR

ENB[0|1|2]

WEB[0|1|2]

•

CEN_BSCNTR_TMR[0|1|2]CEN_BSCNT_TMR[0|1|2]

BRAM ENB for Address Compare

ADDRA_[0|1|2] + WEA[0|1|2]

X962_01_080707


The Block RAM Self-Scrubbing Macro


R

The Block RAM Self-Scrubbing Macro

A hand-triplicated replacement macro is the heart of the block RAM scrubbing engine. Depending on the design, the wrapper of the replacement macro might require modification. In the case of this application note, a stand-alone version of the scrubber is used. The stand-alone version is used in a design utilizing block RAMs independent of an embedded processor design. Other scrubbers, for example, can be replacements for block RAMs hanging off of an processor local bus (PLB) or on-chip peripheral bus (OPB). All the scrubber interfaces have the same engine, but the interface is altered slightly to match the top-level design.

Figure 2 is an example of a design using a single RAM block (consisting of many block RAM primitives) in a 14 × 64 configuration. During triplication, TMRTool replaces the RAM block with the block RAM scrubber macro. When triplicated, this sample design utilizes all the block RAMs available in an XC2VP40 device.

Note: Although this application note is specific to Virtex-II FPGAs, the techniques described here can be used to mitigate Virtex-4 FPGA block RAM designs as well. The same engine can be used but the user does not have to extract half latches or replace SRL16s.

Figure 3 illustrates part of the TMRTool flow. The block RAM (BRAM) component is replaced with the custom TMR type. X-Ref Target - Figure 2

Figure 2: Simple Stand-Alone Scrubber

X-Ref Target - Figure 3

Figure 3: Replacement Macro with Set XTMR Types Window

X962_02_091206

Replace Block RAM with

Scrubber Macro

X962_03_091206

Macro Replacement


Design Flow Walk-Through and Reference Design Example


R

Building the Block RAM Scrubbing Macro Overview

The triplicated block RAM replacement macro is built based on the size of the block RAMs being replaced. The VHDL code for the scrubber macro can be altered to accommodate different RAM sizes by changing the following VHDL files:

bram_scrubber_pkg.vhd (package file that specifies constants)

bram_scrubber_bram_inst_bitw.vhd (instantiated block RAMs)

Block RAM Scrubbing Macro Design Flow

The block RAM scrubber macro uses the following overall design flow:

1. Set constants in package file, ..\bram_scrubber_pkg.vhd, to define data width, address width and byte enables.

2. Synthesize a netlist of the address counter.

3. Use Xilinx TMRTool to triplicate the counter.

4. Create the block RAM scrubber netlist (.ngc) for import into TMRTool.

5. Use the Xilinx TMRTool to create a pre-XTMR netlist in the .ds format (from the .ngc file in step 4).

6. Synthesize the top-level design containing the block RAMs to be replaced.

7. Use Xilinx TMRTool to triplicate the user design and replace the block RAM macro.

8. Place and route the final triplicated design.

9. Simulate the block RAM scrubber top-level design and perform a smoke test.

Note: In a smoke test, one of the clock domains or resets is disabled and the design is tested for proper functionality.

Using TMRTool to Replace BRAM with the Self-Scrubbing Macro

The hand-triplicated replacement macro is the heart of the block RAM scrubbing engine. Depending on the design, the user can modify the replacement wrapper to match the design. In the case of this application note, a stand-alone version of the scrubber is used. Other block RAM scrubbers, for example, can be replacement BRAMs that hang off of an PLB/OPB bus. All the scrubber interfaces have the same engine, but the interface is changed slightly to match the top-level design.

Figure 2 is an example of a design using a single block RAM (composed of many actual BRAMs) in a 14 × 64 configuration. This example uses (when triplicated) all the BRAMs in an XC2VP40 device, or 192 of 336 BRAMs in an XC4VLX200. It is this level that is triplicated (by the TMRTool), and the block RAM is replaced by the BRAM scrubber macro.


This section contains a walk-through of a fully mitigated simple block RAM design. This example uses an XC2VP40, but can be easily applied to a Virtex-4 device.The reference design uses a large, 14 × 64 single-port block RAM composed of individual primitives. This block RAM is not only triplicated but replaced with the block RAM scrubber macro, containing triplicated block RAMs. The block RAM is 64-data bits wide, and a MUX selects the word read based on the address. Test data is created by using the address bus and is composed of the first 14 bits of address with bits 1 and 0 of the address bits representing the upper two data bits, for example:

Data[15:0] = A[1] & A[0] & A[13:0]

The rest of the data is repeated in this manner for the other three 16-bit data words, making a total of 16 × 4 = 64 data bits (Figure 2).

The reference design files for this application note (xapp962.zip) provide an example of the stand-alone block RAM scrubber replacement macro. The files contain complete code, allowing the user to implement a block RAM scrubber macro. The reference design files including the block RAM scrubber source code are available on the Xilinx FTP site at:

http://www.xilinx.com/support/documentation/application_notes/xapp962.zip


http://www.xilinx.com/support/documentation/application_notes/xapp962.zip



R

Note: For this example, the process of building a scrubber example is done with the ISE GUI but can be accomplished via command-line entry for design-flow simplification. In addition, this walk-through is based upon software versions available at the time of publication.

Example Design Directory Structure

This example requires an organized directory structure (Table 1). The user can implement any structure desired, but it is highly recommended that the individual tool projects are organized into separate directories, allowing projects to be easily re-run at any point during the implementation phase. All directories are relative to where the user unpacks the example design.

Table 1: Recommended Directory Structure(1)

Directory Comments

\installed_example_dir\

\Doc\ Contains readme.txt (describes test)

\ISE\ For ISE designs, pre-TMR. This directory can also include 'export to ISE from EDK designs'

\9.2iSP4 Version and SP

\design_name1 Top or sub designs as needed


\ISE_TMR For ISE designs, post TMR

\9.2iSP4 Version and SP



\Sim Third-party simulation project directory, pre-TMR

\golden_designname1 Golden simulation .wlf generated separately for test comparisons

\MSSE_6.1b Simulator type and version, for example, ModelSim SE Version 6.1b

\design_name1 Design simulation MS project

\Sim_TMR Third-party simulation project directory, post-TMR

\golden_designname1 Golden simulation .wlf generated separately for test comparisons

\MSSE_6.1b Simulator type and version,

\design_name1 Design simulation MS project

\source All the source code for the project, separated by type

\coregen Core generated files from CORE Generator™ tool

\Macros Macros from TMRTool (.ds files)

\Netlists .edf or other netlists

\TB Testbench VHDL files

\VHDL All pertinent VHDL source (non-testbench, synthesizable) code

\Synthesis Third-party synthesis projects

\synplify_pro_8.2 Tool and version

\design_name1 Design name synthesis project

\TMR_Tool Contains the TMRTool projects)

\TMR_2.1.75 TMRTool version



Notes: 1. The tools used are the latest versions as of this writing. Tool versions change rapidly as they are updated.




R

Steps to Complete the Example Design

Step 1: Setting Constraints

Set constants in the package file ..\bram_scrubber_pkg.vhd to define data width, address width and byte enables:

28-----------------------------------------------------------------------2930 library IEEE;31 use IEEE.STD_LOGIC_1164.all;3233 package bram_scrubber_pkg is3435 -- Declare constraints36 -- This is where the user can change the size of the BRAMs37 constant data_width := 64;38 constant addr_width := 14;39 constant we_num := 1;4041 -- Components42 -- Port B address Counter Component43 component BSCNTR_XTMR44 port (45 internal_gnd_tr0 : in std_logic46 internal_gnd_tr1 : in std_logic

Note: The provided code only supports a single-bit-data version of the block RAM primitives. Depending on the design requirements (and on address/data size), this method might not be the most efficient implementation of a block RAM replacement. The design can be altered to accommodate multi-bit block RAM primitives but is beyond the scope of this application note (the file bram_scrubber_bram_inst_bitw.vhd in the source/VHDL directory is annotated to show where to make the appropriate changes).

Step 2: Synthesize the Address Counter

Create a new ISE project, BSCNTR, in ..\ISE\9.2i_SP4\. Add the source files BSCNTR.vhd and bram_scrubber_pkg.vhd from ..\source\VHDL and synthesize the counter with the defined package and source file, BSCNTR.vhd (Figure 4). From the Process Properties dialog box (Figure 5), deselect Add I/O buffers, and set Number of Clock Buffers to zero under the Xilinx Specific Options tab.

Note: Verify that Advanced properties are displayed.

Use the resultant file (.ngc) in step 3 to generate a triplicated macro.


Figure 4: ISE BRAM Counter Project ExampleX962_04_091907




R

Step 3: Use Xilinx TMRTool to Triplicate the Counter

Create a new project in TMRTool named BSCNTR under ..\TMR_Tool\TMR_2.1.75\. Add the file bscntr.ngc as the top-level source from step 2. Verify the process properties are set in both tabs as shown in Figure 6 and Figure 7.

Note: For Virtex-4 FPGA designs, it is not necessary to replace registers with half-latch flip-flops, nor is it required to replace SRL16s with flip-flops. If designing for Virtex-4 FPGAs, in the "Process Steps" tab, uncheck Replace Registers, and uncheck Extract Vcc/Gnd; and in "Process Settings" Tab, uncheck Replace Shift Register LUTs (SRL16) with Flip-Flops.

As a sub-module, create the triplicated counter .edif netlist and copy into the netlists directory. Double-click on Export Design (Figure 8) to triplicate the counter and create an .edif netlist design module. The user now has a triplicated counter module, BSCNTR_xtmr.edf, for use in the block RAM scrubber design. Copy the file BSCNTR_xtmr.edf to the ..\source\Netlists directory.


Figure 5: Process Properties


Figure 6: TMRTool Process Settings Example (for Address Counter Triplication)

X962_05_091907

X962_06_091907




R

Step 4: Create the Block RAM Scrubber Netlist for TMRTool Import

The next step is to create the block RAM scrubber netlist (.ngc) for import into TMRTool. First, create a new ISE project, bram_scrubber_wrapper_tmr, under ..\ISE\9.2i_SP4. Then add the following files from ..\source\VHDL to the project:

bram_scrubber_pkg.vhd (package file)

bram_scrubber_wrapper_tmr_bitw.vhd (block RAM scrubber engine [and top level in this step] replacement macro, consisting of two lower levels):

bram_scrubber_bram_inst_bitw.vhd (actual block RAM instantiation)

bram_scrubber_data_voter.vhd (data voting code)

Sources in the project should now appear similar to those shown in Figure 10.

Note: Deselecting the option in ISE that copies source files into the project directory allows for management of source files in one location.


Figure 7: TMRTool Process Steps Example (for Address Counter Triplication)


Figure 8: TMRTool Processes for Source flow

X962_07_091907

X962_08_091907




R

Under HDL options, deselect Shift Register Extraction (only for Virtex-II and Virtex-II Pro FPGAs: can remain selected for Virtex-4 FPGAs). Also, under Xilinx Specific Options (Figure 9), deselect Add I/O buffers, and set the number of clock buffers to zero.

Double-click on Synthesize - XST (Figure 10) to synthesize the block RAM scrubber macro to generate a .ngc netlist file. ISE reports several components as being black boxes including the block RAM scrubber counter (bscntr_xtmr). This netlist is pulled into the design at a later step.


Figure 9: Setting Xilinx Specific Options


Figure 10: HDL Source Structure in the ISE Environment

X962_09_091907

X962_10_091907




R

Step 5: Create a Pre-XTMR Netlist

This step uses the .ngc file from step 4 to create a pre-XTMR netlist in the .ds format with XTMRTool. Create a new project in TMRTool called bram_scrubber_wrapper_tmr under the ..\TMR_Tool\TMR_2.1.75\ directory. Once the user imports the file:

bram_scrubber_wrapper_tmr.ngc

the file:

bram_scrubber_wrapper_tmr_prextmr.ds

is created. Add the .ngc file to Sources in project in TMRTool. Double-click Import to create the pre-XTMR .ds file (Figure 11).

Copy the file bram_scrubber_wrapper_tmr_prextmr.ds to the XTMR_TOOL_Install>\macrolib\USER\ directory, located under the install directory of the TMRTool. Placing the netlist in this directory allows the macro to be seen as a replacement for the block RAM.

Step 6: Synthesize the Top-level Design

To synthesize the top-level design containing the block RAMs to be replaced, create a new design, bram_scrubber_standalone_top_test, using ISE under the ..\ISE\9.2i_SP4\.

Synthesize the two files from the ..\source\VHDL directory:

bram_scrubber_pkg.vhd

bram_scrubber_standalone_top_test.vhd

The file bram_scrubber_standalone_top_test.vhd is the top-level file containing the block RAM to be replaced by the macro. After this top-level file is synthesized, a .ngc file (bram_scrubber_standalone_top_test.ngc) is created for use by the Xilinx TMRTool.


Figure 11: Double-click Import to Create the Pre-XTMR .ds File

X962_11_091907




R

Step 7: Triplicate the User Design

To triplicate the user design with TMRTool and replace the block RAM macro, use the custom macro replacement flow (see the TMRTool User Guide) to replace the block RAM wrapper with the .ds macro created in step 5.

Create a new XTMR project under the ..\TMR_Tool\TMR_2.1.75 directory called bram_scrubber_standalone_top_test. Import the .ngc file created in step 6:

bram_scrubber_standalone_top_test.ngc

into TMRTool. Double-click on Edit XTMR Types to enable replacement of the macro in the Set XTMR Types box to the right (Figure 12).

Use the custom macro replacement flow to replace the block RAM with the .ds database file. If this file is not available as a selection, ensure that the .ds file was created properly and is located in the MACROLIB/USER directory under the XTMR install directory (Figure 13).

Note: TMRTool might need to be closed and restarted. TMRTool loads the .ds macros in the user directory on startup.


Figure 12: Edit XTMR Types


Figure 13: Custom Macro Block RAM Replacement

X962_12_091907

X962_13_091907




R

Implement XTMR and ensure the settings are as required (this example design uses the default settings as shown in Figure 14 and Figure 15).

Note: For Virtex-4 FPGA designs, it is not necessary to replace registers with half-latch flip-flops, nor is it required to replace SRL16s with flip-flops. If designing for Virtex-4 FPGAs, in the "Process Steps" tab, uncheck Replace Registers, and uncheck Extract Vcc/Gnd; and in "Process Settings" Tab, uncheck Replace Shift Register LUTs (SRL16) with Flip-Flops.

Close these dialog boxes and double-click on Export Design under the processes for source windows to create the .edf netlist file representing a triplicated version of the block RAM with the block RAM scrubber, ready for place and route:

bram_scrubber_standalone_top_test_xtmr.edf


Figure 14: Implement XTMR Process Steps Defaults


Figure 15: Implement XTMR Process Steps Defaults

X962_14_091907

X962_15_091907




R

Step 8: Place and Route the Final Triplicated Design

Create a new ISE project, bram_scrubber_standalone_top_test, under .\ISE_TMR\9.2i_SP4 and select the EDIF flow option under the Top-Level Module Type pull-down box (Figure 16).

Select the .edf file created in step 8 and deselect the option to copy the .edf file into the working directory. This action keeps ISE pointing to the original .edf generated by TMRTool. If changes are made, and a new, triplicated .edf file is created, then ISE uses the new .edf. When prompted to specify a device, select the device (Figure 17).

Note: This example uses the XC2VP40FF1152-6. The user could also select a Virtex-4 FPGA.


Figure 16: Creating a New ISE Project


Figure 17: New ISE Project Part Selection

X962_16_091907

X962_17_091907




R

After the project is set up, right-click on Translate to open the Process Properties dialog box (Figure 18). Under Macro search path option, type ..\..\..\source\Netlists.

Specifying this search path allows the final black box (the triplicated address counter) created in step 3 to be merged into the design. Double-click on Place and Route to run the translate, map, place, and route processes to build the final chip design. If errors are encountered, review the previous steps.

Note: This example design is for illustrative purposes only and does not contain any timing or pin location constraints.

Figure 19 shows the resource usage of the final design. Due to triplication, the example design uses all of the block RAM available in an XC2VP40 device.


Figure 18: Setting Macro Search Path


Figure 19: Resource Utilization Report

X962_18_091907

X962_19_091907




R

Step 9: Simulate the Block Ram Scrubber Design and Perform a Smoke Test.

Although there are several ways to simulate a post-place-and-route design, ModelSim is used for this example. Prior to simulation, be sure to build the necessary libraries by using the command compxlib or building within ISE for the appropriate device (refer to the on-line documentation for ISE and ModelSim for details).

Using the ISE project from step 8, create the post-place-and-route VHDL simulation model. For this example, the file is called:

bram_scrubber_standalone_top_test_xtmr_timesim.vhd

Note: The diagrams are shown without timing and represent function only.

After building the post-place-and-route simulation model, use this model in conjunction with the provided simulation testbench, bram_scrubber_standalone_top_test_tb.vhd, located in ..\ source\TB.

This simulation testbench checks two critical functions of the block RAM scrubber:

• Verifies that the scrubber functions when one clock is removed and then restored (smoke test).

• Verifies that if the block RAM contents are corrupted, that the block RAM scrubber self corrects.

Note: For the second simulation, several internal signals are needed to verify functionality and can be added to the waveform within ModelSim.

These steps perform a simple simulation, and the user is encouraged to add to the simulation testbench for further study.

Step 9a: Compile the Design Files

Add the files bram_scrubber_standalone_top_test_tb.vhd located in ..\source\TB and bram_scrubber_standalone_top_test_xtmr_timesim.vhd created above to ModelSim (Figure 20). Compile both files.

Note: The Xilinx libraries are needed to compile bram_scrubber_standalone_top_test_xtmr_timesim.vhd.X-Ref Target - Figure 20

Figure 20: ModelSim VHDL Simulation Files

X962_20_091907




R

Step 9b: Start Simulation and Open a Waveform

Start simulation and set bram_scrubber_standalone_top_test_tb as the simulation level (Figure 21).

After the simulation starts, create a new waveform and add all the signals from the top level. Also add the signals from the UUT list and any other signals desired. For easier readability, set the signals to display in hexadecimal format and display signal path to 1 (or user preference) in the waveform window.

Select the block RAM TR2 instance 5 and add the desired signals to observe the write correction when the address counter reaches 0x20h (Figure 22).

Suggested internal signals to add from bram_0_bram_scrubber_bram_tr2_bram_0_raminfr_inst_br_5_ram16_s1_s1_ins are:

addra (address port a)

addrb (address port b — where the address counter is observed)

clka/clkb (clocks to the block RAM)

dia/dib (data in ports A and B)

wea/web (write enables a and b; web is the signal were the correction is observed when the address counter hits 0x20h)

doa/dob (data out ports A and B)

Note: Instance names can vary.


Figure 21: Starting the Simulation


Figure 22: ModelSim Signal Selection

X962_21_091907

X962_22_091907




R

Step 9c: Simulate the Design

Simulate the design for 5000 ns (Figure 23).

As shown in the simulation, clock one is off for the first test. When the read address is presented (0x4), data_out_tr1 is 3-stated. This behavior is expected because the triplicated outputs are wire-ORed on the circuit board. The resulting output is correct as voted between the three. When the clock is restored, the output is restored.


Figure 23: Clock Removal Smoke TestX962_24_091206

Data_out_tr1 is 3-stated until clock 1

is restored

Simulate a fault on tr2 inst 5 block


Possible Additions


R

Figure 24 illustrates a write (WEB) to the block RAM. This write (at address 0x20h) happens to only one of the block RAMs to simulate a block RAM fault.

When the address counter (addrb) reaches 0x0020h, a compare occurs and WEB is activated causing a correction to the block RAM. Until that point, data_out_TR2 is held in 3-state. At address 0x0020h, the block RAM is corrected and the output is now expressed properly.

Possible Additions

There are some improvements/additions under consideration for future releases:

• Adding the ability to compensate for block RAMs other than one data-bit wide without code modifications (for example, as is done in the PLB version).

• Creating dual-port RAM replacements, instead of just single port.

• Separating the A and B clocks for designs needing higher performance.

References 1. XAPP987, Single-Event Upset Mitigation Selection Guide.

2. XAPP1004, Single-Event Upset Mitigation Design Flow for Xilinx FPGA PowerPC Systems.

3. UG156,TMRTool User Guide.

4. XAPP216, Correcting Single-Event Upsets Virtex Partial Configuration.

5. XAPP779, Correcting Single-Event Upsets in Virtex-II Platform FPGA Configuration Memory.

6. XAPP988, Correcting Single-Event Upsets in Virtex-4 Platform FPGA Configuration Memory.


Figure 24: Correcting Block RAM Content

X962_25_091206

Address Count

Block RAM Port B


http://direct.xilinx.com/support/documentation/application_notes/xapp779.pdf




http://www.xilinx.com/products/milaero/ug156.pdf


Conclusion


R

Conclusion Single-event upsets can alter the logic state of any static memory element (latch, flip-flop, or RAM cell). Although these upsets are unavoidable, they are correctable via the mitigation technique described in this application note. Using Xilinx TMRTool combined with proper mitigation techniques, configuration scrubbing, and block-RAM scrubbing (as in this application note) is a powerful way to mitigate SEUs and SETs in SRAM-based FPGA designs.

Revision History

The following table shows the revision history for this document.

Notice of Disclaimer

Xilinx is disclosing this Application Note to you “AS-IS” with no warranty of any kind. This Application Noteis one possible implementation of this feature, application, or standard, and is subject to change withoutfurther notice from Xilinx. You are responsible for obtaining any rights you may require in connection withyour use or implementation of this Application Note. XILINX MAKES NO REPRESENTATIONS ORWARRANTIES, WHETHER EXPRESS OR IMPLIED, STATUTORY OR OTHERWISE, INCLUDING,WITHOUT LIMITATION, IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, ORFITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT WILL XILINX BE LIABLE FOR ANY LOSS OFDATA, LOST PROFITS, OR FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR INDIRECTDAMAGES ARISING FROM YOUR USE OF THIS APPLICATION NOTE.

Date Version Revision

02/01/07 1.0 Initial Xilinx release.

03/14/08 1.1 • Updated template.• Added notes regarding Virtex-4 FPGA applicability.• Other minor edits and updates.


xilinx xapp962, single-event upset mitigation for xilinx ...the scrubber interfaces have the same...

Documents