logicore™ ip soft error mitigation controller v309/21/10 1.0 initial xilinx release. 12/14/10 2.0...

LogiCORE™ IP Soft Error Mitigation Controller v3.1User Guide

UG764 October 19, 2011

Soft Error Mitigation Controller www.xilinx.com UG764 October 19, 2011

The information disclosed to you hereunder (the “Materials”) is provided solely for the selection and use of Xilinx products. To the maximum extent permitted by applicable law: (1) Materials are made available “AS IS” and with all faults, Xilinx hereby DISCLAIMS ALL WARRANTIES AND CONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE; and (2) Xilinx shall not be liable (whether in contract or tort, including negligence, or under any other theory of liability) for any loss or damage of any kind or nature related to, arising under, or in connection with, the Materials (including your use of the Materials), including for any direct, indirect, special, incidental, or consequential loss or damage (including loss of data, profits, goodwill, or any type of loss or damage suffered as a result of any action brought by a third party) even if such damage or loss was reasonably foreseeable or Xilinx had been advised of the possibility of the same. Xilinx assumes no obligation to correct any errors contained in the Materials or to notify you of updates to the Materials or to product specifications. You may not reproduce, modify, distribute, or publicly display the Materials without prior written consent. Certain products are subject to the terms and conditions of the Limited Warranties which can be viewed at http://www.xilinx.com/warranty.htm; IP cores may be subject to warranty and support terms contained in a license issued to you by Xilinx. Xilinx products are not designed or intended to be fail-safe or for use in any application requiring fail-safe performance; you assume sole risk and liability for use of Xilinx products in Critical Applications: http://www.xilinx.com/warranty.htm#critapps.

© 2010–2011 Xilinx, Inc. Xilinx, the Xilinx logo, Artix, ISE, Kintex, Spartan, Virtex, Zynq, and other designated brands included herein are trademarks of Xilinx in the United States and other countries. All other trademarks are the property of their respective owners.

Revision HistoryThe following table shows the revision history for this document.

Date Version Revision

09/21/10 1.0 Initial Xilinx release.

12/14/10 2.0 Updated core to v1.2 and ISE to v12.4.

03/01/11 3.0 Updated core to v1.3 and ISE to v13.1.

06/22/11 4.0 Updated core to v2.1 and ISE Design Suite to v13.2. Added support for Spartan-6 devices.

10/19/11 5.0 Updated core to v3.1 and ISE Design Suite to v13.3. Added support for Kintex-7 and Virtex-7 (excluding SSI) devices.

http://www.xilinx.com/warranty.htmhttp://www.xilinx.com/warranty.htm#critappshttp://www.xilinx.com

Soft Error Mitigation Controller www.xilinx.com 3UG764 October 19, 2011

Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Schedule of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Schedule of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Preface: About This GuideGuide Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Typographical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Online Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 1: IntroductionAbout the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Recommended Design Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Additional Core Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Technical Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Feedback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

SEM Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Chapter 2: Soft Error OverviewOverview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Reliability Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Strategies for Mitigating Soft Errors in Configuration Memory . . . . . . . . . . . . . . 21Scheduled Maintenance Strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Emergency Maintenance Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Running Repairs Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Combined Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Chapter 3: Core OverviewOverview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Controller Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

ICAP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26FRAME_ECC Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Status Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Error Injection Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Table of Contents

http://www.xilinx.com

4 www.xilinx.com Soft Error Mitigation ControllerUG764 October 19, 2011

Monitor Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Fetch Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Chapter 4: Example Design OverviewOverview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Example Design Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Status Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Clock Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Monitor Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34External Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Error Injection Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Additional Information for I/O Pin Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Chapter 5: Generating the SolutionCreating a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Configuring the Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Component Name and Symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Controller Options: Enable Error Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Controller Options: Enable Error Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Controller Options: Error Correction Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Controller Options: Enable Error Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Controller Options: Controller Clock Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Example Design Options: Error Injection Shim. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Example Design Options: Data Retrieval Shim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Reviewing the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Generating the Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Reviewing the Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43/doc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44/example design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44/implement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45/implement/results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45/implement/synplify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45/implement/xst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Generating ChipScope Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 Series Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Virtex-6 and Spartan-6 Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Using ChipScope Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Chapter 6: Building the SolutionImplementing the Example Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Creating the External Memory Programming File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Chapter 7: Design ConstraintsContents of the User Constraints File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Device Selection Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Controller Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51



Example Design Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Chapter 8: Applying the SolutionInterface Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Clock Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Status Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Monitor Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60External Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

SPI Bus Clock Waveform and Timing Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63SPI Bus Transmit Waveform and Timing Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65SPI Bus Receive Waveform and Timing Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66SPI Bus Timing Budget Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Error Injection Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Behavior Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Controller Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Classification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Idle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Fatal Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Error Injection Interface Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Directed State Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Error Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Monitor Interface Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Directed State Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Status Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Error Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Monitor Interface Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Initialization Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Command Prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81State Change Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Flag Change Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Status Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Error Detection Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Error Correction Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Error Classification Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

System Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Solution Reliability Estimates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Estimation Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Sample 7 Series Reliability Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Sample Virtex-6 Reliability Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Sample Spartan-6 Reliability Estimation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Solution Latency Estimates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Estimation Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Start-Up Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Error Detection Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Error Correction Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Error Classification Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Sources of Additional Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Sample Latency Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93



Supervisory Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Chapter 9: Customizing the SolutionHID Shim Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95MON Shim Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Increase Bit Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Increase Buffer Depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Replace with Alternate Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

EXT Shim Customizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Replace with Alternate Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Chapter 10: Additional ConsiderationsUnsupported Features and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101No Controller Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Master Clock Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Data Consistency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Configuration Memory Masking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

7 Series FPGAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Virtex-6 FPGAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Spartan-6 FPGAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104



Chapter 1: Introduction

Chapter 2: Soft Error Overview

Chapter 3: Core OverviewFigure 3-1: SEM Controller Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Chapter 4: Example Design OverviewFigure 4-1: Example Design Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Figure 4-2: Example Design Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Chapter 5: Generating the SolutionFigure 5-1: Solution Configuration Dialog Box Page 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Figure 5-2: Solution Configuration Dialog Box Page 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Chapter 6: Building the Solution

Chapter 7: Design Constraints

Chapter 8: Applying the SolutionFigure 8-1: Status Interface State Signals Switching Characteristics . . . . . . . . . . . . . . . . . 58Figure 8-2: Status Interface Uncorrectable Flag Switching Characteristics . . . . . . . . . . . 59Figure 8-3: Status Interface Essential Flag Switching Characteristics . . . . . . . . . . . . . . . . 59Figure 8-4: Status Interface Heartbeat Switching Characteristics. . . . . . . . . . . . . . . . . . . . 59Figure 8-5: Monitor Interface Switching Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Figure 8-6: SPI Flash Device Connection, Including Level Translators . . . . . . . . . . . . . . 63Figure 8-7: SPI Flash Device Input Clock Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Figure 8-8: SPI Flash Device Input Data Capture Requirements . . . . . . . . . . . . . . . . . . . . 65Figure 8-9: Input Data Capture Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Figure 8-10: SPI Flash Device Output Data Switching Characteristics . . . . . . . . . . . . . . . 66Figure 8-11: Output Data Capture Timing (Hold Analysis) . . . . . . . . . . . . . . . . . . . . . . . . 67Figure 8-12: Output Data Capture Timing (Setup Analysis) . . . . . . . . . . . . . . . . . . . . . . . . 68Figure 8-13: Error Injection Interface Timing Requirements . . . . . . . . . . . . . . . . . . . . . . . 74Figure 8-14: 7 Series Enter Idle State Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Figure 8-15: 7 Series Enter Observation State Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Figure 8-16: Virtex-6 and Spartan-6 Enter Idle State Command . . . . . . . . . . . . . . . . . . . . . 77Figure 8-17: Virtex-6 and Spartan-6 Enter Observation State Command . . . . . . . . . . . . . 77Figure 8-18: 7 Series Error Injection Command (Linear Frame Address) . . . . . . . . . . . . . 78

Schedule of Figures



Figure 8-19: Virtex-6 Error Injection Command (Linear Frame Address) . . . . . . . . . . . . . 78Figure 8-20: Spartan-6 Error Injection Command (Linear Frame Address) . . . . . . . . . . . 78Figure 8-21: 7 Series Error Injection Command (Physical Frame Address) . . . . . . . . . . . 78Figure 8-22: Virtex-6 Error Injection Command (Physical Frame Address) . . . . . . . . . . . 79Figure 8-23: Spartan-6 Error Injection Command (Physical Frame Address) . . . . . . . . . . 79

Chapter 9: Customizing the SolutionFigure 9-1: Monitor Interface Transmit Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Figure 9-2: Monitor Interface Receive Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Figure 9-3: Fetch Interface Transmit Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Figure 9-4: Fetch Interface Receive Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Chapter 10: Additional Considerations





Chapter 3: Core OverviewTable 3-1: ICAP Interface Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Table 3-2: FRAME_ECC Interface Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Table 3-3: Status Interface Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Table 3-4: Error Injection Interface Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Table 3-5: Monitor Interface Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Table 3-6: Fetch Interface Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Chapter 4: Example Design OverviewTable 4-1: Clock Interface Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Table 4-2: Monitor Interface Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Table 4-3: External Interface Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Table 4-4: SEM Controller I/O Pin Interface Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Chapter 5: Generating the SolutionTable 5-1: Project Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Table 5-2: Component Name Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Table 5-3: Doc Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Table 5-4: Example Design Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Table 5-5: Implement Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Chapter 6: Building the Solution

Chapter 7: Design Constraints

Chapter 8: Applying the SolutionTable 8-1: External Storage Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Table 8-2: State Change Report Decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Table 8-3: Flag Change Report Decoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Table 8-4: Example Device FIT Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Table 8-5: Configuration Bits Per Device Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Table 8-6: Start-Up Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Table 8-7: Device Scan Times at ICAP Maximum Frequency . . . . . . . . . . . . . . . . . . . . . . . 89Table 8-8: Typical Error Correction Latency, No Throttling on Monitor Interface . . . . . 91

Schedule of Tables



Table 8-9: Typical Error Classification Latency, No Throttling on Monitor Interface . . 92

Chapter 9: Customizing the Solution

Chapter 10: Additional Considerations



Preface

About This Guide

The LogiCORE™ IP Soft Error Mitigation Controller User Guide provides information about the Soft Error Mitigation (SEM) Controller. This guide describes how to design with the core by outlining the key interfaces, detailing its behaviors, and providing an operational overview.

Guide ContentsThis manual contains the following chapters:

• Chapter 1, Introduction describes the core and related information, including licensing, recommended design experience, additional resources, technical support, and submitting feedback to Xilinx.

• Chapter 2, Soft Error Overview describes soft errors, surveys the reliability issues associated with them, and proposes techniques for mitigating them.

• Chapter 3, Core Overview overviews the function of the SEM Controller and the interfaces it exposes.

• Chapter 4, Example Design Overview overviews the function of the SEM Controller system-level design example and the interfaces it exposes.

• Chapter 5, Generating the Solution provides instructions for generating the SEM Controller solution.

• Chapter 6, Building the Solution provides details on building the SEM Controller solution.

• Chapter 7, Design Constraints describes the user constraints file provided with the SEM Controller.

• Chapter 8, Applying the Solution provides insight into the SEM Controller solution and how to apply it from three different levels, using a bottom-up approach.

• Chapter 9, Customizing the Solution provides details about customizing the SEM Controller.

• Chapter 10, Additional Considerations provides information critical to successful application of the SEM Controller in a complete design.

Additional ResourcesTo find additional documentation, see the Xilinx website at:

www.xilinx.com/support/documentation/index.htm.

To search the Answer Database of silicon, software, and IP questions and answers, or to create a technical support WebCase, see the Xilinx website at:

http://www.xilinx.comhttp://www.xilinx.com/support/documentation/index.htm


Preface: About This Guide

www.xilinx.com/support/mysupport.htm.

ConventionsThis document uses the following conventions. An example illustrates each convention.

TypographicalThe following typographical conventions are used in this document:

Convention Meaning or Use Example

Courier fontMessages, prompts, and program files that the system displays

speed grade: - 100

Courier boldLiteral commands that you enter in a syntactical statement

ngdbuild design_name

Helvetica bold

Commands that you select from a menu

File → Open

Keyboard shortcuts Ctrl+C

Italic font

Variables in a syntax statement for which you must supply values

ngdbuild design_name

References to other manuals See the User Guide for more information.

Emphasis in textIf a wire is drawn so that it overlaps the pin of a symbol, the two nets are not connected.

Dark ShadingItems that are not supported or reserved

This feature is not supported

Square brackets [ ]

An optional entry or parameter. However, in bus specifications, such as bus[7:0], they are required.

ngdbuild [option_name] design_name

Braces { } A list of items from which you must choose one or more

lowpwr ={on|off}

Vertical bar | Separates items in a list of choices

lowpwr ={on|off}

Angle brackets < >User-defined variable or in code samples

Vertical ellipsis...

Repetitive material that has been omitted

IOB #1: Name = QOUT’ IOB #2: Name = CLKIN’...

Horizontal ellipsis . . .Repetitive material that has been omitted

allow block block_name loc1 loc2 ... locn;

http://www.xilinx.com/support/mysupport.htmhttp://www.xilinx.com


Conventions

Online DocumentThe following conventions are used in this document:

Notations

The prefix ‘0x’ or the suffix ‘h’ indicate hexadecimal notation

A read of address 0x00112975 returned 45524943h.

An ‘_n’ means the signal is active low

usr_teof_n is active low.



Blue textCross-reference link to a location in the current document

See the section “Additional Resources” for details.

Refer to “Title Formats” in Chapter 1 for details.

Blue, underlined text Hyperlink to a website (URL)Go to www.xilinx.com for the latest speed files.



Preface: About This Guide



Chapter 1

Introduction

This chapter introduces the Soft Error Mitigation (SEM) Controller core and provides related information, including recommended design experience, additional resources, technical support, and submitting feedback to Xilinx. The SEM Controller is designed to support both Verilog and VHDL design environments.

Soft error mitigation is an emerging concern for commercial FPGA devices although it has been a long-time consideration for aerospace and high-reliability/high-availability applications. This guide covers the implementation and use of the SEM Controller.

About the CoreThe SEM Controller is a Xilinx CORE Generator™ IP core, included in the latest IP update on the Xilinx IP Center. For detailed information about the core, see:

www.xilinx.com/products/intellectual-property/SEM.htm

The SEM Controller can detect, correct, and classify soft errors in the Configuration Memory of an FPGA device. The solution does not prevent soft errors in Configuration Memory; rather, it provides designers with a method to better manage the system-level effects of these events. Careful management of these events increases system reliability and availability.

LicensingThe SEM Controller core is a free solution. No license key is required to generate the core through CORE Generator.

System RequirementsThe SEM Controller core is not used in isolation, and is intended for integration into a larger design. The system requirements are therefore set by the nature of the larger design.

When the SEM Controller is configured to use the optional error classification function or the optional correction by replace function, the controller requires externally stored data created by the Xilinx implementation tools. The application that creates this data requires a large amount of system RAM. Xilinx recommends the use of a 64-bit operating system with 16 Gb or more of system RAM.

Recommended Design ExperienceThe SEM Controller operates at a relatively low frequency. The implementation of the controller in Xilinx FPGA devices is not challenging. However, evaluation of the suitability

http://www.xilinx.com/products/intellectual-property/SEM.htmhttp://www.xilinx.com



of this solution for use in a system and proper application of the solution requires careful analysis and detailed understanding of the system requirements. These considerations are design specific and outside the scope of this document.

Contact your local Xilinx representative for a closer review of your specific requirements.

Additional Core ResourcesFor detailed information and updates about the SEM Controller, see the following documents, located on the SEM Controller product page at:

www.xilinx.com/products/ipcenter/SEM.htm

• LogiCORE IP Soft Error Mitigation Controller Data Sheet

• LogiCORE IP Soft Error Mitigation Controller Release Notes

Technical SupportFor technical support, go to www.xilinx.com/support. Questions are routed to a team with expertise using the SEM Controller.

Xilinx will provide technical support for use of this product as described in the Soft Error Mitigation Controller User Guide. Xilinx cannot guarantee timing, functionality, or support of this product for designs that do not follow these guidelines.

FeedbackXilinx welcomes comments and suggestions about the SEM Controller and the accompanying documentation.

SEM ControllerFor comments or suggestions about the SEM Controller, please submit a WebCase from www.xilinx.com/support/clearexpress/websupport.htm. Be sure to include the following information:

• Product name

• Core version number

• Explanation of your comments

DocumentationFor comments or suggestions about the SEM Controller documentation, please submit a WebCase from www.xilinx.com/support/clearexpress/websupport.htm. Be sure to include the following information:

• Document title

• Document number

• Page number(s) to which your comments refer

• Explanation of your comments

http://www.xilinx.comhttp://www.xilinx.com/products/ipcenter/SEM.htmwww.xilinx.com/supporthttp://www.xilinx.com/support/clearexpress/websupport.htmhttp://www.xilinx.com/support/clearexpress/websupport.htm


References

References1. UG470, 7 Series FPGAs Configuration User Guide

2. UG360, Xilinx Virtex-6 FPGA Configuration User Guide

3. UG380, Xilinx Spartan-6 FPGA Configuration User Guide

4. UG116, Xilinx Device Reliability Report

5. WP286, Continuing Experiments of Atmospheric Neutron Effects on Deep Submicron Integrated Circuits

6. XAPP962, Single-Event Upset Mitigation for Xilinx FPGA Block Memories



Chapter 2

Soft Error Overview

This chapter describes soft errors, surveys the reliability issues associated with them, and proposes techniques for mitigating them. A variety of solutions are possible, and the selection of the best solution is highly application dependent. The SEM Controller is the best solution for highly demanding commercial applications. However, most applications are well served using the integrated silicon soft error mitigation features alone. Xilinx recommends careful consideration of system-level requirements in the decision to use and selection of soft error mitigation solutions.

OverviewIonizing radiation is capable of inducing undesired effects in most silicon devices. Broadly, an undesired effect resulting from a single event is called a single event effect (SEE). In most cases, these events do not permanently damage the silicon device; SEEs that result in no permanent damage to the device are called soft errors. However, soft errors have the potential to reduce reliability.

Xilinx devices are designed to have an inherently low susceptibility to soft errors. However, Xilinx also recognizes that soft errors are unavoidable within commercial and practical constraints. As a result, Xilinx has integrated soft error detection and correction capability into many device families.

In many applications, soft errors can simply be ignored. In applications where higher reliability is desired, the integrated soft error detection and correction capability is usually sufficient. In demanding applications, the SEM Controller can ensure an even higher level of reliability.

If a soft error occurs, one or more memory bits are corrupted. The memory bits affected may be in the device configuration memory (which determines the behavior of the design), or may be in design memory elements (which determine the state of the design). The following four memory categories represent a majority of the memory in a device:

• Configuration Memory. Storage elements used to configure the function of the design loaded into the device. This includes function block behavior and function block connectivity. This memory is physically distributed across the entire device and represents the largest number of bits. Only a fraction of the bits are essential to the proper operation of any specific design loaded into the device.

• Block Memory. High capacity storage elements used to store design state. As the name implies, the bits are clustered into a physical block, with a number of blocks distributed across the entire device. Block Memory represents the second largest number of bits.

• Distributed Memory. Medium capacity storage elements used to store design state. This type of memory is present in certain configurable logic blocks (CLBs) and is




distributed across the entire device. Distributed Memory represents the third largest number of bits.

• Flip Flops. Low capacity storage elements used to store design state. This type of memory is present in all configurable logic blocks (CLBs) and is distributed across the entire device. Flip Flops represent the fourth largest number of bits.

An extremely small number of additional memory bits exist as internal device control registers and state elements. Soft errors occurring in these areas may result in regional or device-wide interference that is referred to as a single-event functional interrupt (SEFI). Due to the small number of these memory bits, the frequency of SEFI events is considered negligible in this discussion, and these infrequent events are not addressed by the SEM Controller.

Soft error mitigation for the design state in Block Memory, Distributed Memory, and Flip Flops can be performed in the design itself, by applying standard techniques such as error detection and correction codes or redundancy. Soft errors in unused storage elements (those physically present in the device, but unused by the design) are simply ignored. Designers concerned about reliability must assess risk areas in the design and incorporate mitigation techniques for the design state as warranted.

Soft error mitigation for the design function in Configuration Memory is performed using error detection and correction codes.

Configuration Memory is organized as an array of frames, much like a wide static RAM. In many device families, each frame is protected by ECC, with the entire array of frames protected by CRC in all device families. The two techniques are complementary; CRC is incredibly robust for error detection, while ECC provides high resolution of error location.

The SEM Controller builds upon the robust capability of the integrated logic by adding optional capability to classify Configuration Memory errors as either “essential” or “non-essential.” This leverages the fact that only a fraction of the Configuration Memory bits are essential to the proper operation of any specific design.

Without error classification, all Configuration Memory errors must be considered “essential.” With error classification, most errors will be assessed “non-essential” which eliminates false alarms and reduces the frequency errors that require a potentially disruptive system-level mitigation response.

Additionally, the SEM Controller extends the built-in correction capability to accelerate error detection and provides the capability to handle multi-bit errors.

If the extended features offered by the SEM Controller like error injection, error classification, correction by enhanced repair, and correction by replace are not required, the integrated soft error detection and correction capability in the silicon should be sufficient for SEU mitigation. See UG470, 7 Series FPGAs Configuration User Guide, UG360, Virtex-6 FPGA Configuration User Guide and UG380, Spartan-6 FPGA Configuration User Guide for information on how to use the built-in error detection and correction capability.

Reliability EstimationAs a starting point, a designer’s specification for system reliability should highlight critical sections of the system design and provide a value for the required reliability of each sub-section. Reliability requirements are typically expressed as failures in time (FIT), which is the number of design failures that can be expected in 109 hours (approximately 114,155 years).

When more than one instance of a design is deployed, the probability of a soft error affecting any one of them increases proportionately. For example, if the design is shipped



Strategies for Mitigating Soft Errors in Configuration Memory

in 1,000 units of product, the nominal FIT across all deployed units is 1,000 times greater. This is an important consideration because the nominal FIT of the total deployment can grow large and may represent a service or maintenance burden.

The nominal FIT is different from the probability of an individual unit being affected. Also, the probability of a specific unit incurring a second soft error is determined by the FIT of the individual design and not the deployment. This is an important consideration when assessing suitable soft error mitigation strategies for an application.

The FIT associated with soft errors must not be confused with that of product life expectancy, which considers the replacement or physical repair of some part of a system.

Xilinx device FIT data is reported in UG116, Device Reliability Report. To render an estimate, the device FIT data must be combined with additional design-specific data that indicates how many bits of each memory type are used.

ObservationsThe data in UG116, Device Reliability Report, reveals the overall infrequency of soft errors in devices. Although some memory types clearly contribute more than others, it is important to note that the failure rates involved are so small that most designs need not include any form of soft error mitigation.

The contribution to FIT from Flip Flops is negligible based on the Flip Flop’s very low FIT/Mbit and small quantity. However, this does not discount the importance of protecting the design state stored in Flip Flops. If any state stored in Flip Flops is highly important to design operation, the design must contain logic to detect, correct, and recover from soft errors in a manner appropriate to the application.

The contribution to FIT from Distributed Memory and Block Memory can be large in designs where these resources are highly utilized. As previously noted, the FIT contribution can be substantially decreased by using soft error mitigation techniques in the design. For example, Block Memory resources include built-in error detection and correction circuits that can be used in certain Block Memory configurations. For all Block Memory and Distributed Memory configurations, soft error mitigation techniques may be applied using programmable logic resources.

The contribution to FIT from Configuration Memory is large. Without using an error classification technique, all soft errors in Configuration Memory must be considered “essential,” and the resulting contribution to FIT will eclipse all other sources combined. Use of error classification reduces the contribution to FIT by no longer considering most soft errors as failures; if a soft error has no effect, it can be corrected without any disruption.

In designs requiring the highest level of reliability, classification of soft errors in Configuration Memory is essential. This capability is provided by the SEM Controller.

Strategies for Mitigating Soft Errors in Configuration MemoryA soft error in Configuration Memory has the potential to significantly change the design, and unlike design state, the Configuration Memory is not periodically overwritten by a new value. The strategies in this section focus on mitigating the effects of soft errors in Configuration Memory. The strategies discussed are:

• Scheduled Maintenance Strategy, page 22

• Emergency Maintenance Strategy, page 22




• Running Repairs Strategy, page 23

• Combined Strategy, page 24

Based on the infrequent occurrence of soft errors, designers must carefully consider the disadvantages and costs of adopting a particular strategy as well as its advantages.

Scheduled Maintenance StrategyWhen there is a soft error in a Configuration Memory bit, the effect on the design can be instantaneous or irregularities might not be noticed for a significant time. For example, an error affecting clocks or resets can have an effect almost immediately, but a change to a circuit used to display the hours on a clock might not become apparent for hours.

Some parts of an application are more important than others; it is the important parts to which precautions are applied. It is useful to assess the time a soft error takes to affect a function and to consider the consequences that a failure can have. An important question to ask is if the system is required to maintain operation after a soft error, or is it only required to fail safely? The answer determines the appropriate precautions to take.

When a device is reconfigured, all Configuration Memory bits are written, regardless of the previous state. As a result, previously existing soft errors are removed. Although there are some applications that operate continuously for very long periods of time, very few are required to operate continuously without interruption for the entire product lifetime.

Most applications experience relatively frequent power cycles or periods of inactivity when maintenance can be performed. The scheduled maintenance strategy is intended to fully exploit these opportunities. The best use of the scheduled maintenance strategy exploits every available opportunity to reconfigure the device during normal operation, and reconfigure when it is not playing an active role in the system. No attempt is made to determine if a soft error has occurred; the reconfiguration simply repairs any corruption, if it exists. This is the same concept as performing regular maintenance on a vehicle, where certain parts are replaced at regular intervals even if they appear to be perfectly serviceable.

Even if all errors are corrected by the next scheduled reconfiguration, what happens for the period of time between a soft error and the next reconfiguration? This is when precautions must either maintain service or fail safely as the application requires.

Scheduled reconfiguration corrects any errors that have occurred, and if a design contains precautions to cope with soft errors, this scheme can be acceptable in many applications.

Emergency Maintenance StrategyThe concept behind the emergency maintenance strategy is the same as a vehicle’s “check engine” indicator, which offers notification that a serious issue may exist. The appropriate response is to investigate the problem immediately, rather than wait until the next scheduled maintenance. This means advancing the next reconfiguration of the device when a soft error is detected in Configuration Memory.

The key to the emergency maintenance strategy is detecting if a soft error has occurred in the Configuration Memory. Recent Xilinx devices provide an integrated soft error detection capability for this purpose. When this is used for detection only, it facilitates simple implementation of an emergency maintenance strategy using a CRC-based error detection signal. A description of this feature and how to use it is provided in UG470, 7 Series FPGAs Configuration User Guide, UG360, Virtex-6 FPGA Configuration User Guide and UG380, Spartan-6 FPGA Configuration User Guide.



Strategies for Mitigating Soft Errors in Configuration Memory

The time to detect the presence of a soft error in Configuration Memory with a CRC-based method depends on the rate at which the integrated soft error detection circuit scans the memory array, as well as the location of the soft error with respect to the scanning process. While the best case represents a fairly immediate detection, the worst case may require nearly two full device scans, with the average time to detection being one device scan. If the maximum detection time can be tolerated before a reconfiguration of the device is initiated, then emergency maintenance using the integrated soft error detection avoids the requirement for any special circuitry. However, shorter detection times are possible.

The SEM Controller uses a detection scheme based on both CRC and ECC. It can be used in a detection only mode. With this scheme, almost all soft errors are detected within one device scan because the ECC checks are performed with much finer granularity than the CRC check. The average detection time is half of a full device scan.

Error detection performed by either solution indicates a change in the Configuration Memory and does not (and cannot) indicate a change to design state. If parts of the design contain important state information, these parts still need precautionary circuits of their own.

In general, use the emergency maintenance strategy when the system can tolerate a configuration fault in the design for the duration of the soft error detection time, until reconfiguration is initiated. The system must also be tolerant of the device down time during reconfiguration.

Running Repairs StrategyThe running repairs strategy is useful in applications where it is desirable to maintain operation following a soft error, while carrying out localized repair of Configuration Memory content rather than performing a full device reconfiguration.

Given the high probability that a soft error will have no immediate effect on a particular design, this strategy avoids the interruption of service associated with the emergency maintenance strategy.

The integrated soft error detection capability of some Xilinx devices also includes soft error correction capability. When enabled, this feature allows the device to not only detect errors, but also correct the most common type, which are single-bit errors. A description of this feature and how to use it is provided in UG470, 7 Series FPGAs Configuration User Guide, UG360, Virtex-6 FPGA Configuration User Guide, and UG380, Spartan-6 FPGA Configuration User Guide.

The SEM Controller expands on the error correction capability in Xilinx devices. The controller can repair single-bit errors using the same method as the integrated function. The controller can repair two-bit adjacent errors using a CRC-based enhanced repair algorithm. Or, the core can be configured to replace Configuration Memory content instead of repair it, enabling correction of soft errors of arbitrary size as long as the location of the errors can be identified. This provides extensive correction capability.

Although the running repairs strategy can detect and repair soft errors while the design is active, any soft errors that occur will exist for a short period of time until their correction. A simple, yet very conservative approach is to assume that all soft errors can affect the proper operation of the design. One potential solution is to issue a reset to all important circuits upon detection of an error and then remove the reset after the error has been corrected. Although this interrupts normal operation, it will be of significantly shorter duration than the time required for a full reconfiguration of the device and does not require the additional resource usage associated with design redundancy.




To further minimize interruption of normal operation, the SEM Controller offers an optional soft error classification capability. When this capability is enabled and a soft error is corrected, the core performs a look up to determine if the bit(s) affected by the soft error were essential to the proper operation of the design. If the correction involved any essential bits, then the error is considered “essential” and may warrant additional action. If the error is “non-essential,” the soft error will have no effect on the design operation, and the error can be corrected while the design continues to operate normally.

Combined StrategySystems requiring the very highest reliability benefit from using a combination of scheduled maintenance, emergency maintenance, and running repairs strategies. This multi-layered approach continues the redundancy concept by using each strategy to provide cover for the next.

When considering the most beneficial combinations for a system, the operation of an aircraft is a useful analogy when reliability is paramount. Once in service, regular maintenance of the aircraft includes the replacement of parts even if there is no visible evidence of a problem. This prevents failures due to wear over time as well as fixing defects missed during in situ inspections. Reconfiguring a device at regular intervals offers similar advantages by correcting possible unseen errors (however remote a possibility) and ensuring a clean start for each period of operation.

Before each flight, checks are made to ensure all important systems on the aircraft are working properly. If the check reveals a fault, the aircraft is grounded until the fault is corrected. Using the built-in error detection to continuously check the Configuration Memory performs a similar function. If a system is in a standby mode and an error is detected, an emergency reconfiguration can be invoked to repair the fault. This avoids the potential of accumulating errors over time and ensures the device is in perfect condition when it enters an operational mode.

Once an aircraft is in flight, any failure is undesirable. An active warning light alerts the crew to the nature of the fault so that they can take appropriate actions. These actions vary depending on the severity and location of the failure. It might be possible to contain the problem and continue to the planned destination, or a diversion and an emergency landing might be required. The most challenging scenario is when the plane must maintain flight because there is no suitable landing site, for example, in the middle of the ocean. In all cases, once the plane has landed, the aircraft is removed from service and repaired before being flown again. This applies even if the fault was considered to be temporary and resolved by the crew during the flight.

In a Xilinx device, the warning is provided when the error detection logic identifies a soft error. In most cases, the soft error does not affect the operation of the design. However, the cases that do impact operation require that appropriate action is taken. If the device can be safely reconfigured immediately, this is the obvious response to the warning. If continuous operation must be maintained, then redundancy and localized repairs (using capability of the SEM Controller) will be required.



Chapter 3

Core Overview

This chapter overviews the function of the SEM Controller and the interfaces it exposes. The controller is highly flexible and may be designed into a variety of applications.

The SEM Controller provides users with a method to better manage the system-level effects of soft errors in Configuration Memory. Intelligent management of these events increases reliability and availability and reduces maintenance and downtime costs. The controller has been designed to directly support the “running repairs” strategy although using it to implement other strategies is clearly possible.

As the term “mitigation” implies, the SEM Controller does not prevent soft errors. The controller does not operate on soft errors in Block Memory, Distributed Memory, or Flip Flops. Soft error mitigation in these resources must be addressed by inclusion of precautionary measures in the design such as redundancy or error detection and correction codes.

OverviewThe SEM Controller implements five main functions: initialization, error injection, error detection, error correction, and error classification. All functions, except initialization and detection, are optional; desired functions are selected during the IP core configuration and generation process in the Xilinx CORE Generator.

The controller initializes by bringing the integrated soft error detection capability of the FPGA into a known state after the FPGA enters user mode. After this initialization, the controller endlessly loops, observing the integrated soft error detection status. When an ECC or CRC error is detected, the controller evaluates the situation to identify the Configuration Memory location involved.

Once this is complete, the controller may optionally correct the soft error by repairing it or by replacing the affected bits. The repair methods are active partial reconfiguration to perform a localized correction of Configuration Memory using a read-modify-write scheme. These methods use algorithms to identify the error in need of correction. The replace method is also active partial reconfiguration with the same goal, but this method uses a write-only scheme to replace Configuration Memory with original data. This data is provided by the implementation tools and stored outside the controller.

The controller may optionally classify the soft error as essential or non-essential using a lookup table. The lookup table is stored outside the controller and is fetched as required during execution of error classification. This data is also provided by the implementation tools and stored outside the controller.

When the controller is idle, there is an option to accept input from the user to inject errors into Configuration Memory. This function is useful for testing the integration of the controller into a larger system design. Using the error injection capability, system



Chapter 3: Core Overview

verification and validation engineers may construct test cases to ensure the complete system responds to soft error events as expected.

Controller InterfacesThe SEM Controller is the kernel of the soft error mitigation solution. Figure 3-1 shows the SEM Controller ports. These ports are clustered into six groups. Shading indicates port groups that only exist in certain configurations.

The SEM Controller has no reset input or output. It automatically initializes itself with an internal synchronous reset derived from the de-assertion of the global GSR signal.

The controller is a fully synchronous design using icap_clk as the single clock. All state elements are synchronous to the rising edge of this clock. As a result, all interfaces are also synchronous to the rising edge of this clock.

ICAP InterfaceThe ICAP Interface is a point-to-point connection between the SEM Controller and the ICAP primitive. The ICAP primitive enables read and write access to the registers inside the FPGA configuration system. The ICAP primitive and the behavior of the signals on this interface are described in UG470, 7 Series FPGAs Configuration User Guide, UG360, Virtex-6

X-Ref Target - Figure 3-1

Figure 3-1: SEM Controller Ports



Controller Interfaces

FPGA Configuration User Guide, and UG380, Spartan®-6 FPGA Configuration User Guide. For 7 series devices, icap_busy is not part of the ICAP Interface.

FRAME_ECC InterfaceThe FRAME_ECC Interface is a point-to-point connection between the SEM Controller and the FRAME_ECC primitive. The FRAME_ECC primitive is an output-only primitive that provides a window into the soft error detection function in the FPGA configuration system. The FRAME_ECC primitive and the behavior of the signals on this interface are described in UG470, 7 Series FPGAs Configuration User Guide, and UG360, Virtex-6 FPGA Configuration User Guide.

For Spartan-6 devices, the FRAME_ECC primitive and the soft error detection functionality are implemented in soft logic within the SEM Controller. This logic implements the same capabilities as present in Virtex-6 FPGAs. As a result, no FRAME_ECC Interface exists on implementations of the SEM Controller for Spartan-6 devices.

Table 3-1: ICAP Interface Signals

Name Sense Direction Description

icap_busy HIGH IN Receives BUSY output of ICAP. For 7 series devices, icap_busy is not part of the ICAP Interface.

icap_o[icap_width-1:0] HIGH IN Receives O output of ICAP. The variable icap_width is equal to 32 for 7 series and Virtex-6 devices and 16 for Spartan-6 devices.

icap_csib / icap_csb LOW OUT Drives CSIB (7 series) / CSB (Virtex-6 and Spartan-6) input of ICAP.

icap_rdwrb LOW OUT Drives RDWRB input of ICAP.

icap_i[icap_width-1:0] HIGH OUT Drives I input of ICAP. The variable icap_width is equal to 32 for 7 series and Virtex-6 devices and 16 for Spartan-6 devices.

icap_clk EDGE IN Receives the clock for the design. This same clock also must be applied to the CLK input of ICAP. The clock frequency must comply with the ICAP input clock requirements as specified in the target device data sheet.

icap_request HIGH OUT This signal is reserved for future use. Leave this port OPEN.

icap_grant HIGH IN This signal is reserved for future use. Tie this port to VCC.

Table 3-2: FRAME_ECC Interface Signals


fecc_crcerr HIGH IN Receives CRCERROR output of FRAME_ECC.

fecc_eccerr HIGH IN Receives ECCERROR output of FRAME_ECC.




Status InterfaceThe Controller Status Interface provides a convenient set of decoded outputs that indicate, at a high level, what the controller is doing.

fecc_eccerrsingle HIGH IN Receives ECCERRORSINGLE output of FRAME_ECC.

fecc_syndromevalid HIGH IN Receives SYNDROMEVALID output of FRAME_ECC.

fecc_syndrome[12:0] HIGH IN Receives SYNDROME output of FRAME_ECC.

fecc_far[far_width-1:0] HIGH IN Receives FAR output of FRAME_ECC. The variable for far_width is 26 for 7 series devices and 24 for Virtex-6 devices.

fecc_synbit[4:0] HIGH IN Receives SYNBIT output of FRAME_ECC.

fecc_synword[6:0] HIGH IN Receives SYNWORD output of FRAME_ECC.

Table 3-2: FRAME_ECC Interface Signals (Cont’d)


Table 3-3: Status Interface Signals


status_heartbeat HIGH OUT The heartbeat signal is active while status_observation is true. This output will issue a single-cycle high pulse at least once every 128 clock cycles for 7 series and Virtex-6 devices, and at least once every 512 clock cycles for Spartan-6 devices. This signal may be used to implement an external watchdog timer to detect “controller stop” scenarios that may occur if the controller or clock distribution is perturbed by soft errors. When status_observation is false, the behavior of the heartbeat signal is unspecified.

status_initialization HIGH OUT The initialization signal is active during controller initialization, which occurs one time after the design begins operation.

status_observation HIGH OUT The observation signal is active during controller observation of error detection signals. This signal remains active after an error detection while the controller queries the hardware for information.

status_correction HIGH OUT The correction signal is active during controller correction of an error or during transition through this controller state if correction is disabled.

status_classification HIGH OUT The classification signal is active during controller classification of an error or during transition through this controller state if classification is disabled.

status_injection HIGH OUT The injection signal is active during controller injection of an error. When an error injection is complete, and the controller is ready to inject another error or return to observation, this signal returns inactive.



Controller Interfaces

The status_heartbeat output provides an indication that the controller is active. Although the controller mitigates soft errors, it can also be disrupted by soft errors. For example, the controller clock may be disabled by a soft error. If the status_heartbeat signal stops, the user can take remedial action.

The status_initialization, status_observation, status_correction, status_classification, and status_injection outputs indicate the current controller state. The status_uncorrectable and status_essential outputs qualify the nature of detected errors.

Two additional controller state may be decoded from the five controller state outputs. If all five signals are low, the controller is idle (inactive but ready to resume). If all five signals are high, the controller is halted (inactive due to fatal error).

Error Injection InterfaceThe controller Error Injection Interface provides a convenient set of inputs to command the controller to inject a bit error into configuration memory.

The user must provide an error injection address and command on inject_address[inject_width-1:0] and assert inject_strobe to indicate an error injection.

In response, the controller will inject a bit error. The controller confirms receipt of the error injection command by asserting status_injection. When the injection command has completed, the controller de-asserts status_injection. To inject errors affecting multiple bits, a sequence of error injections can be performed.

For more information on error injection commands, see Error Injection Interface in Chapter 8.

status_essential HIGH OUT The essential signal is an error classification status signal. Prior to exiting the classification state, the controller will set this signal to reflect whether the error occurred on an essential bit(s). Then, the controller exits classification state.

status_uncorrectable HIGH OUT The uncorrectable signal is an error correction status signal. Prior to exiting the correction state, the controller will set this signal to reflect the correctability of the error. Then, the controller exits correction state.

Table 3-3: Status Interface Signals


Table 3-4: Error Injection Interface Signals


inject_strobe HIGH IN The error injection control is used to indicate an error injection request. The inject_strobe signal should be pulsed high for one cycle concurrent with the application of a valid address to the inject_address input. The error injection control must only be used when the controller is idle.

inject_address[inject_width-1:0]

HIGH IN The error injection address bus is used to specify the parameters for an error injection. The value on this bus is captured at the same time inject_strobe is sampled active. For 7 series devices, the variable inject_width is 40, and for Virtex-6 and Spartan-6 devices, the variable is 36.




Monitor InterfaceThe controller Monitor Interface provides a mechanism for the user to interact with the controller.

The controller is designed to read commands and write status information to this interface as ASCII strings. The status and command capability of the Monitor Interface is a superset of the Status Interface and the Error Injection Interface. The Monitor Interface is intended for use in processor based systems.

Fetch InterfaceThe controller Fetch Interface provides a mechanism for the controller to request data from an external source.

During error correction and error classification, the controller may need to fetch a frame of configuration data or a frame of essential bit data. The controller is designed to write a command describing the desired data to the Fetch Interface in binary. The external source must use the information to fetch the data and return it to the Fetch Interface.

Table 3-5: Monitor Interface Signals


monitor_txdata[7:0] HIGH OUT Parallel transmit data from controller.

monitor_txwrite HIGH OUT Write strobe, qualifies validity of parallel transmit data.

monitor_txfull HIGH IN This signal implements flow control on the transmit channel, from the shim (peripheral) to the controller.

monitor_rxdata[7:0] HIGH IN Parallel receive data from the shim (peripheral).

monitor_rxread HIGH OUT Read strobe, acknowledges receipt of parallel receive data.

monitor_rxempty HIGH IN This signal implements flow control on the receive channel, from the shim (peripheral) to the controller.

Table 3-6: Fetch Interface Signals


fetch_txdata[7:0] HIGH OUT Parallel transmit data from controller.

fetch_txwrite HIGH OUT Write strobe, qualifies validity of parallel transmit data.

fetch_txfull HIGH IN This signal implements flow control on the transmit channel, from the shim (peripheral) to the controller.

fetch_rxdata[7:0] HIGH IN Parallel receive data from the shim (peripheral).

fetch_rxread HIGH OUT Read strobe, acknowledges receipt of parallel receive data.

fetch_rxempty HIGH IN This signal implements flow control on the receive channel, from the shim (peripheral) to the controller.



Chapter 4

Example Design Overview

This chapter overviews the function of the SEM Controller system-level design example and the interfaces it exposes. The system-level design example encapsulates the controller and various shims that serve to interface the controller to other devices. These shims may include I/O Pins, ChipScope, I/O Interfaces, Memory Controllers, or application-specific system management interfaces.

As delivered, the system-level design example is not a reference design, but an integral part of the total solution and fully verified by Xilinx. While designers do have the flexibility to modify the system-level design example, the recommended approach is to use it as delivered.

OverviewIn addition to serving as an instantiation vehicle for the controller itself, the system-level design example incorporates five main functions:

• The FPGA configuration system primitives and their connection to the controller.

• The MON shim, a bridge between the controller and a standard RS-232 port. The resulting interface may be used to exchange commands and status with the controller. This interface is designed for connection to processors.

• The EXT shim, a bridge between the controller and a standard SPI bus. The resulting interface may be used to fetch data by the controller. This shim is only present in certain controller configurations and is designed for connection to standard SPI flash.

• The HID shim, a bridge between the controller and an interface device. The resulting interface may be used to exchange commands and status with the controller. This shim is only present in certain controller configurations.



Chapter 4: Example Design Overview

Figure 4-1 shows a block diagram of the system-level design example. The blocks drawn in gray only exist in certain configurations.

The system-level design example is provided to allow flexibility in system-level interfacing. To support this goal, the system-level design example is provided as RTL source code, unlike the controller itself.


Figure 4-1: Example Design Block Diagram

��

�

�

��

��

��

� �



Example Design Interfaces

Example Design InterfacesFigure 4-2 shows the example design ports. The ports are clustered into six groups. The groups shaded in gray only exist in certain configurations.

The system-level design example has no reset input or output. The controller automatically initializes itself. The controller then initializes the shims, as required.

The system-level design example is a fully synchronous design using clk as the single clock. All state elements are synchronous to the rising edge of this clock. As a result, the interfaces are generally synchronous to the rising edge of this clock.

Status InterfaceThe Status Interface is a direct pass-through of the controller Status Interface. See Chapter 3, Core Overview for a description of this interface.

Clock InterfaceThe Clock Interface is used to provide a clock to the system-level design example. Internally, the clock signal is distributed on a global clock buffer to all synchronous logic elements.


Figure 4-2: Example Design Ports

Table 4-1: Clock Interface Details


clk EDGE IN Receives the master clock for the system-level design example.




Monitor InterfaceThe Monitor Interface is always present. The MON shim in the system-level design example is a UART. This shim serializes status information generated by the controller (a byte stream of ASCII codes) for serial transmission. Similarly, the shim de-serializes command information presented to the controller (a bit stream of ASCII codes) for parallel presentation to the controller.

The shim uses a standard serial communication protocol. The shim contains synchronization and over sampling logic to support asynchronous serial devices that operate at the same nominal baud rate. Refer to Chapter 8, Applying the Solution for additional information.

The resulting interface is directly compatible with a wide array of devices ranging from embedded microcontrollers to desktop computers. External level translators may be necessary depending on system requirements.

External InterfaceThe External Interface is present when the controller requires access to external data. When present, the EXT shim in the system-level design example is a fixed-function SPI bus master. This shim accepts commands from the controller that consist of an address and a byte count. The shim generates SPI bus transactions to fetch the requested data from an external SPI flash. The shim formats the returned data for the controller to pick up.

The shim uses standard SPI bus protocol, implementing the most common mode (CPOL = 0, CPHA = 0, often referred to as “Mode 0”). The SPI bus clock frequency is locked to one half of the master clock for the system-level design example. See Chapter 8, Applying the Solution for information on external timing budgets.

The resulting interface is directly compatible with a wide array of standard SPI flash. External level translators may be necessary depending on system requirements.

Error Injection InterfaceThe Error Injection Interface is present when the controller supports error injection and the HID shim is set to I/O Pins. This interface is a direct pass-through of the controller Error Injection Interface. See Chapter 3, Core Overview for a description of this interface.

Table 4-2: Monitor Interface Details


monitor_tx LOW OUT Serial transmit data from system-level design example.

monitor_rx LOW IN Serial receive data to system-level design example.

Table 4-3: External Interface Details


external_c EDGE OUT SPI bus clock for an external SPI flash.

external_d HIGH OUT SPI bus “master out, slave in” signal for an external SPI flash.

external_s_n LOW OUT SPI bus select signal for an external SPI flash.

external_q HIGH IN SPI bus “master in, slave out” signal for an external SPI flash.



Example Design Interfaces

When the controller supports error injection and the HID shim is set to ChipScope, or when error injection is disabled, this interface is absent.

Additional Information for I/O Pin InterfacesWhen the system-level design example is implemented as delivered, its interfaces are mapped to external I/O pins with specific electrical characteristics. These are summarized in Table 4-4.

Table 4-4: SEM Controller I/O Pin Interface Details

Name Driver Type Pull Load Supply Drive / Slew

Clock Interface

clk LVCMOS NONE N/A 2.5V/1.8V N/A

Status Interface

status_heartbeat LVCMOS NONE UNSPECIFIED 2.5V/1.8V 4 mA / SLOW

status_initialization LVCMOS NONE UNSPECIFIED 2.5V/1.8V 4 mA / SLOW

status_observation LVCMOS NONE UNSPECIFIED 2.5V/1.8V 4 mA / SLOW

status_correction LVCMOS NONE UNSPECIFIED 2.5V/1.8V 4 mA / SLOW

status_classification LVCMOS NONE UNSPECIFIED 2.5V/1.8V 4 mA / SLOW

status_injection LVCMOS NONE UNSPECIFIED 2.5V/1.8V 4 mA / SLOW

status_essential LVCMOS NONE UNSPECIFIED 2.5V/1.8V 4 mA / SLOW

status_uncorrectable LVCMOS NONE UNSPECIFIED 2.5V/1.8V 4 mA / SLOW

Monitor Interface

monitor_tx LVCMOS NONE 10 pF 2.5V/1.8V 4 mA / SLOW

monitor_rx LVCMOS NONE N/A 2.5V/1.8V N/A

External Interface (Optional)

external_c LVCMOS NONE 10 pF 2.5V/1.8V 8 mA / FAST

external_d LVCMOS NONE 10 pF 2.5V/1.8V 8 mA / FAST

external_s_n LVCMOS NONE 10 pF 2.5V/1.8V 8 mA / FAST

external_q LVCMOS NONE N/A 2.5V/1.8V N/A

Error Injection Interface (Optional)

inject_strobe LVCMOS NONE N/A 2.5V/1.8V N/A

inject_address[inject_width-1:0]

LVCMOS NONE N/A 2.5V/1.8V N/A



Chapter 5

Generating the Solution

This chapter provides instructions for generating the SEM Controller solution. The generation instructions are annotated with detailed information about each of the available options.

Creating a ProjectFirst, create a project using the Xilinx CORE Generator software. For detailed information on starting and using the CORE Generator software, see the Xilinx CORE Generator User Guide. Perform the following steps:

1. Start the CORE Generator software.

2. Choose File > New Project from the menu.

3. Using the file requestor dialog box:

a. Navigate to the desired project directory.

b. Modify the project file name, if desired.

c. Click Save.

4. Set the Part Options in the Project Options dialog box:

a. Select the target family, device, package, and speed grade.

Example: Kintex-7, xc7k325t-ffg900-1

Note: If an unsupported family is selected, the IP core will not appear in the IP Catalog.

b. Click Apply.

5. Set the Generation Options in the Project Options dialog box:

a. For Flow, select Design Entry in either VHDL or Verilog.

b. For Flow Settings, select either ISE (for XST) or Synplicity (for Synplify).

c. Click Okay.

After creating the project, the IP core will be available for selection in the IP Catalog, located at FPGA Features and Design > Soft Error Mitigation > Soft Error Mitigation.

Configuring the SolutionLocate the IP core in the IP Catalog and click it once to select it. Important information regarding the solution is displayed in the main window. Please review this information before proceeding.



Chapter 5: Generating the Solution

In the Actions section of the main window, click on the Customize and Generate link. This launches page one of the solution configuration dialog box, shown in Figure 5-1.

Review each of the available options, and modify them as desired so that the SEM Controller solution meets the requirements of the larger project into which it will be integrated. The following sub-sections discuss the options in detail to serve as a guide.

Component Name and SymbolThe name of the generated component is set by the Component Name field. The name “sem_v3_1” is used in this example.

The Component Symbol occupies the left half of the dialog box and provides a visual indication of the ports that will exist on the component, given the current option settings. Ports that will be generated are drawn in black. This diagram is automatically updated when the option settings are modified.

Controller Options: Enable Error InjectionThe Enable Error Injection checkbox is used to enable or disable the error injection feature. Error injection is a design verification function that provides a mechanism for users to create errors in Configuration Memory that model a soft error event. This is useful during integration or system level testing to verify that the controller has been properly interfaced with system supervisory logic and that the system responds as desired when a soft error event occurs.

If error injection is enabled, the Error Injection Interface is generated (as indicated by the Component Symbol) and the controller will perform error injections in response to commands from the user. These commands may be applied to the Error Injection Interface or to the Monitor Interface.

logicore™ ip soft error mitigation controller v309/21/10 1.0 initial xilinx release. 12/14/10 2.0...

Documents