SEU avoidance

krishnasun — Tue, 25 Sep 2007 07:28:13 +0000

Whenever an application specific chip is required, the general tendency is to go for field programmable gate array based design. FPGA based design has a ton of advantages that include minimum NRE, reconfigurability and relatively good performance. But there is still one area where pure FPGA still struggles to reign. It is when it comes to SEU avoidance.

As most of you are aware, SEU means Single Event Upset. It’s a change of state in microprocessors due to a high energy particle stricking on sensitive nodes. This problem is usually faced in fields which experience radioactivity, like avionics, nuclear labs. Although SEU won’t result in a permanant transistorial damage, the state change may result in wrong output and wrong decision. (Note that cosmic radiation can potentially damage the transistors permanently, but it is not classified under SEU).

The effect of SEU is more in a SRAM based FPGA, since the functionality is defined in an SRAM FPGA as configuration bits. SEU may adulterate the configuration bits in the memory and corrupt the chip. It may modify the chip logic and makes it very difficult to detect and identify the causality.

There are different solutions to mitigate the effect of SEU like employing a VPR based placement and routing algorithm. But as of now, the best way to avoid SEU is to go for a structured ASIC design. The initial design can be done as FPGA and all the MUX based feedback loops can be replaced by specific design. Altera proposes a customization which promises to increase the feedback strength and isolating master slave configuration to mitigate SEU.

No solution so far is considered to be the best and thumb rule. It is yet to evolve. Also SEU is not the only problem a cosmic storm can cause to an integrate circuit. It is just one of them. It is crutial in terms of changing the IC’s logic completely with no trace. There are many that may damage transistors and the IC as a whole.

Multics Security

krishnasun — Fri, 21 Sep 2007 11:33:16 +0000

Multics is an early time sharing mainframe operating system. Its development work started in 1964. It was developed by MIT, GE, and Bell Labs. It was not a successful commercial product, but an astounding fact was that some of the security features of Multics was far ahead of many of the current day operating systems.

Long back a vulnerability analysis was done on Multics, which revealed some significant vulnerabilities. There has been a paper submitted on this analysis which may be treated as a security checklist for any open system developed these days. Most of the vulnerabilities mentioned in this paper are valid for many of the existing systems. The bottomline conclusion of this paper is that any system that requires frequent restructuring may need a verifiable security kernal since there are professional exploiters attacking subsequent versions of a system. Here is the link for that paper.

Logically speaking

SEU avoidance

Multics Security