Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > Controls/MCUs
?
?
Controls/MCUs??

Managing single event upsets with C-slow retiming

Posted: 19 May 2015 ?? ?Print Version ?Bookmark and Share

Keywords:pipelining? C-slow retiming? single event upsets? processors? FPGA?

In my previous article, I covered some aspects of C-slow retiming. In this article, we consider how this technique can be used to create a time-redundant system to detect single event upsets (SEUs) in digital designs.

Recalling C-Slow Retiming (CSR)
Figure 1(a) shows the basic structure of a sequential circuit with its combinatorial logic (CL), inputs (I), outputs (O), and original register (OR). In figure 1(b), the CL is sliced into three (C=3) parts, and each original path now has two (C-1) additional registers.

Figure 1: a) Simplified design. b) Applying the CSR technique.

This is the basic idea behind CSR. It results in C functionally independent design copies which use the logic in a time-sliced fashion. It shows how different parts of the logic are used during different cycles. It now takes three micro-cycles to achieve the same result as in one original cycle (a "macro-cycle"). In figure 1, the inputs and outputs are valid at the same time slice. The implemented register sets are called "C-Slow Retiming Registers" or CRs. They are placed at different C-levels. Figure 1(b) illustrated one basic rule of CSRthere are paths only between consecutive CRs, and from the last CR to the original register, and from the original register to the first CR.

CSR and SEU detection circuit
One way to detect a single event upset (SEU) is to replicate parts of a design (thereby adding redundancy) and to compare key registers and/or outputs. When an SEU occurs, at least one instantiation of the design will run different to the others and, once this is detected, further actions can be taken. CSR supports this feature when executing a group of identical threads. In figure 2, all threads execute the same algorithm (or program) and use the logic in a time-shared fashion. Therefore, only a limited number of threads are affected when an SEU occurs.

Figure 2: Comparing signal values at key registers to detect an SEU.

Multiple identical threads are most likely affected differently because each one of them is in a different design state. When this difference affects the state of key registers, it can be detected by support logic that compares the states of consecutive threads. A mismatch indicates that threads run differently. The SEU detection circuit need only be applied on key registers (e.g., program counter, and bus write data).

Handling memories at the system/board-level
The method proposed here is is not limited to processors only. All kinds of digital designs and sub-systemsincluding the system bus, peripherals, accelerators, etc.can be targets of CSR modifications. Although the simplification in figure 1 is still valid, it is obvious that memories are usually duplicated in CSR-ed designs. A processor's register file will have a C-times larger memory space than the one in the original design. The thread identifier is then added as most-significant bits (MSBs) to the memory address bus. When applicable, larger external data or program memories can also be duplicated, and each C-copy of the design gets exclusive access to its specific sections. In the case of running identical threads, the thread identifier can also be added as least-significant bits (LSBs) to the address bus in order to support potential memory burst features.

Figure 3: Detecting faulty memory content with (interleaved) memory access to identical data at different memory locations.


1???2?Next Page?Last Page



Article Comments - Managing single event upsets with C-...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top