seeking insights for potential reconfigurable computing application platforms

Anne,

Email me directly to discuss the US Air Force program for a Soft error Immune Radiation-hardened FPGA (SIRF).

I will email you back my phone number.

Austin

I would pick two or three historical or made-up applications for the purpose of refining the idea. Sometimes the only way to get input is with a quick jump from general to specific. Also if my grand plan fails to accommodate the simplest of examples, I know I am on the wrong path. Good luck.

-- Mike Treseler

Historically, anti-fuse technology was the major player in RHESE applications but can't offer in-field reconfigurability. It might be worthwhile to check out the very recent FLASH-based FPGAs from Actel. Though significantly sparser than their SRAM counterparts (no built-in special function ASIC blocks e.g. DSP MACs), if you'r willing to compromise on this by having a reconfigurable DSP loosely coupled with FLASH FPGA accelerator, you might be able to pull off a decent match to what you seek. Still this means that you guys have to develop the whole reconfigurable platform with its supporting tools; a non-trivial task I reckon.

Hi Anne, Here's a thought. Imagine you make a bunch of identical thingies which can be either a dsp, a uP, whatever. Cool, you've reduced the parts inventory. You set off on your mission to Mars, and one of these things go wrong. However, it turns out this is not a random failure, but a systemic failure due to a design fault. (Perhaps the sub-contract designer mixed up imperial and metric units?!) This means, because all your replacements are identical, they'll all have the same fault. Kinda like the reason that some people think GM crops are bad, because a single disease can wipe out an entire harvest of a monoculture plant. Maybe there's an argument to have a couple (or maybe more) different designs of replacement. It's a long trip to Fry's from the red planet! Cheers, Syms.

Are you aware of the Reconfigurable Scalable Computing (RSC) project being run out of NASA Langley?

A few web references below, but feel free to contact me directly if you'd like more info.

Regards,

John

In news: snipped-for-privacy@y80g2000hsf.googlegroups.com timestamped 16 May 2007 08:59:17 -0700, Anne L. Atkinson posted: "I am currently working on a NASA program focused on the development of Radiation-Hardened Electronics for Space Environments (RHESE). One portion of the sub-project I am working in support of is aimed at developing reconfigurable modular spare electronic parts for avionics systems.

An ultimate goal of this sub-project is to reduce the total number of spare parts that must be flown on a mission by having spares that are reconfigurable such that, for example, they could function as a DSP or microprocessor or microcontroller at any given time (just one specific application at any given time)."

When I had originally read the second paragraph it had not seemed to me that the type of spare items (e.g. "a DSP or microprocessor or microcontroller") are to be so restricted as to be only MicroBlazes; PicoBlazes; and some as yet undecided DSPs listed further down in news: snipped-for-privacy@y80g2000hsf.googlegroups.com for Path

1. Though you mentioned spare copies of what are already planned for a spacecraft, I suspect that this could be a narrower view than necessary: e.g. gyroscopes or other parts can eventually become noisy (or even completely useless) so some leftover unused logic could conceivably be used to apply extra filtering (or extra computational power for a more advanced control law) instead of simply providing a replacement of part of the originally designed electronics. Of course, we could spend forever thinking of every possible alternative way to exploit something.

If you plan to reduce the number of spare devices on board by using reconfigurable spare devices, you run the risk that you will need more physical spares than you actually launched. Of course, this could also happen without reconfigurable spare devices.

" (And one obvious question here is -- exactly what specific functionality is desired from the microprocessor, microcontroller, or DSP that this part will implement?

- that does not seem to be entirely clear yet on this project - when I pose those questions, I don't get answers. That's a bit frustrating (to me anyhow), but for now, that is just how it is!)

[..]

Also, since "path 1" will require a lot more time and effort for in- house design / development to implement the desired functionalities, I am thinking that "path 2" may provide for a good initial demonstration of capabilities (in general, since at current there do not seem to be specifics with regard to the desired capabilities!), with the hopes that "path 1" can be pursued over a longer period of time with a greater degree of focus on the _specific_ capabilities and characteristics that are ultimately decided upon.

[..]

I wish I could provide more specifics on exactly what specific functionality is desired from the microprocessor, microcontroller, or DSP that this part will implement... As I said, that is currently a frustration of mine, and I know that makes it tough to provide insight on the best development path. I am hoping that as the process of specifying appropriate development platforms progresses, the performance and other characteristics of the platforms specified will help the folks here work towards more clarity on the specifics of what they need."

I empathize with discontentment arising from questions being unanswered. E.g. on April 13th, 2007 and May 15th, 2007 I asked the main tutor for my Ph.D. would we be able to obtain papers such as T. Vladimirova and D. Zheng, "Reconfigurable System-on-a-Chip Based Computing Platform for Small Satellites", "Proceedings of the 1st Annual ESA Workshop on Spacecraft Data Systems and Software", SDSS

2005, ESTEC, Noordwijk, The Netherlands, 17-20 October 2005 and others listed on and T. Vladimirova, P. Davies, M. Sweeting, "Reconfigurable Computing for Micro-Satellites", DASIA 2006 listed on and I am unfortunately still waiting.

"I've been tasked with evaluation of potential development platforms for these modular spares. This is a bit "out of the box" for me -- my background is primarily in system software development -- I'm not a hardware designer -- but, this has been very interesting and I'm trying to learn and do my best at it."

I wish success for the project. The longest of my degrees so far was for computer science. I am not exactly perfect myself, see e.g. news:f2hoij$v4e$ snipped-for-privacy@newsserver.cilea.it

"After spending some time trying to spin-up on reconfigurable hardware / systems through books (a colleague lent me a copy of The_Design_Warrior's_Guide_to_FPGAs_ by Clive "Max" Maxfield which has been a very good tutorial / reference - I recommend it!)"

I am not familiar with Clive Maxfield.

" papers, and google searches, my current thoughts are towards a "dual path" development plan:

Path 1: Use a cutting edge platform in the genre of what Clive "Max" Maxfield refers to as a "Field Programmable Node Array (FPNA)" in the above mentioned book in an attempt to get the most flexible end product from the standpoint of reconfigurability, power consumption, board/device size,"

I am unfamiliar with the term ""Field Programmable Node Array (FPNA)"".

" and a novel approach to provision of radiation tolerance."

If it would not be illegal copyright infringement to do so, could you please reveal what this approach is?

" Current plan here is to use a platform and associated development toolset provided by a small start-up company -- so relatively high risk, but good potential benefits if it all comes together well."

Do you have a particular "small start-up company" in mind, or do you simply associate new technology as outside the realm of established companies?

"Path 2: [..] which uses: 1) MicroBlaze soft core to implement microprocessor functionality 2) PicoBlaze soft core to implement microcontroller functionality 3) ??? some soft core provided through the above development tools (or from some other source?) to implement DSP functionality"

What if someone wanted to use a different instruction set processor? E.g. someone in NASA uses a Silicon Laude 8051 clone,

(Robert F. Jarnot, "Re: 8051 IP core with JTAG debugger for FPGA?", comp.arch.fpga, Thu, 23 Feb 2006 13:33:10 -0800, Message-ID: ), and someone else in NASA uses a completely different instruction set.

"Path 2: Target a Xilinx FPGA-based platform of some type - from what looking through information / references on the Xilinx web site, I'm thinking of possibly using a combination of Xilinx's ISE and EDK development tools to develop a reconfigurable platform [..]"

Xilinx is not the only manufacturer of FPGAs. In what way is using extremely buggy software (whether from Xilinx or another supplier of buggy software for FPGAs) not risky?

"[..]

So I have some questions / concerns, on which I hope some folks with more knowledge of this arena can help give me insight:

• Am I going down reasonable paths to pursue the end goals here? I have a little wellspring of doubt about all my thoughts since hardware specs / design is not something in which I have experience (plus it's just kinda my nature to doubt and worry!!! ;) :) ). I'd appreciate any insight, positive or negative, on this point."

It is good to be skeptical.

"* I was going to try to contact a Xilinx field engineer to ask about the viability of a Xilinx-FPGA based platform, and if that is viable, to get recommendations on appropriate platforms / development boards / development tools / IP cores to work towards the desired end-goal functionality;"

Perhaps you are not skeptical. Which company do you suspect an employee of Xilinx would recommend?

" however, from looking through the Xilinx web site (which provides a lot of excellent reference information -- it's almost overwhelming to a newby in this arena like me!) "

Be wary of the information concerning GEO on Slide 27 of

[VII Testing - SEFI2

• MTBF calculations for POR+JCFG SEFI at different orbits . POR SEFI is worse case ; JTAG is better than SelectMAP Orbit Altitude Inclination Upset Rate MTBF (km) (degrees) (SEU/device/day) (Years/Event) LEO 400 51.6 2.33E-06 2,185 LEO 800 22.0 9.87E-06 277 Polar 833 98.7 5.44E-06 503 Const. 1,200 65.0 2.74E-05 100 GEO 36,000 0.0 2.00E-06 1,369] as GEO is actually not a relatively safe location for electronics (especially when it is not part of the Earth's magnetosphere during solar maximum!).

Slide 36 of

contains something which is plainly untrue: "TMR Overview

• Triplication Technique is called TMR (Triple Module Redundancy) . Logic is triplicated INSIDE the FPGA

• Don.t have to do this by hand anymore!!! TMRTool . Single Point Failures are eliminated . TMR analysis includes:

• Throughput Logic

• Feedback Logic w/ voters

• Output voting" as confessed on Slide 36: "[..]

• We can.t PREVENT SEUs and SETs...

• We can only MITIGATE their effects... [..]"

I.e. a single point failure is not eliminated: where the winning decision of a voting system is determined is a single point of failure. One approach (which is still not perfect) (which is not mentioned on that slide which is concerned with TMR inside one FPGA) is to use three FPGAs as voters and for the component which is to decide the winning value of the vote, to use a component in which greater confidence in its resistance to radiation is justified (e.g. a one time field programmable gate array), e.g. a checker of a safer technology is mentioned in e.g. Cheung Ed; William I. Clement; and Ray Bietry, "Reconfigurable Avionics for Hubble Servicing Missions", MAPLD 2003, Klabs.org/richcontent/MAPLDCon03/papers/p/p11_cheung_p.pdf and seems to be shown on Slide 57 of

(unfortunately the Cheung; Clement; and Bietry paper and another MAPLD paper did not contain anything positive about Single Event Transients (for which one might deliberately use clocks out of phase for voters as in the spatial voting scheme reviewed in Blum; Delgado-Frias; "Schemes for Eliminating Transient-Width Clock Overhead From SET-Tolerant Memory-Based Systems", "IEEE TRANSACTIONS ON NUCLEAR SCIENCE", VOL. 53, NO. 3, JUNE

2006) and I received no response to my complaints (but a strict subset of the email addresses I tried bounced)).

Prof. William H. Sanders boasted during a lecture (this webpage does not go into enough detail to show the boast:

) that many years ago he had convinced people of NASA's that some reliability problem could be satisfactorily tackled. In his solution, voters or similar checkers were used but at least in the lecture he had not addressed the issue of a failure in a checker so I raised this issue. He has responded in the lecture that of course the issue of who checks the checker is an unsolvable problem and so he would have much simpler (and hence hopefully less prone to obscure, complicated errors) logic as a checker than the logic it checks.

contains many more techniques, none of which is perfect as perfection is not possible if any arbitrary fault is possible.

Always be sceptical of the context in which something is claimed, e.g. from Slide 4 of both

and :"Rad-Tolerant vs Military

• Rad-Tolerant devices = Military Devices + . Epitaxial Substrate Wafer (2 microns)

• Used for latch-up immunity [..]" but from other slides such as Slide 65 of
  formatting link
  :"[..] Solution: Use of epitaxial substrate => Virtex II is immune to SEL upto LET > 160 Mev.cm2/mg"

I was surprised at home much attention is given to neutrons on

but by Slide 80 I remembered that that file is also relevant to aircraft.

In news: snipped-for-privacy@y80g2000hsf.googlegroups.com timestamped 16 May 2007 08:59:17 -0700, Anne L. Atkinson posted:

"[..] Where would I find good points of contact to ask questions and get advice on potential platforms / development tools, etc. to begin determining the best selections for a "path 2" platform?

[..]"

John Williams has already advised you in news: snipped-for-privacy@itee.uq.edu.au of NASA employee Richard B. Katz's website for MAPLD. I am sure that Richard B. Katz would love to help you. However, I am not convinced that everything which is accepted for MAPLD is of high quality.

Dr. Tanya Vladimirova is a pleasant person to speak to and might also be willing to help you.

I may be willing to help you, as part of my Ph.D., and quite possibly I will not need money from you as I already receive funding from a scholarship. However, I might not know what you need an assistant to know.

In news: snipped-for-privacy@u30g2000hsc.googlegroups.com timestamped 16 May 2007 12:01:51 -0700, Manny posted: "Historically, anti-fuse technology was the major player in RHESE applications but can't offer in-field reconfigurability."

Perhaps suitability for space should be more important than reconfigurability. Various factors affecting a reconfigurable FPGA such as temperature can not be expected to be the same on the engineering model as on the board on orbit so plenty of problems could result from delicate timing violations.

" It might be worthwhile to check out the very recent FLASH-based FPGAs from Actel."

Someone in the European Space Agency advised against Flash (much as one would be wary of EEPROM) but I do not know of what that person would recommend to use.

"Though significantly sparser than their SRAM counterparts (no built-in special function ASIC blocks e.g. DSP MACs), if you'r willing to compromise on this by having a reconfigurable DSP loosely coupled with FLASH FPGA accelerator, you might be able to pull off a decent match to what you seek. Still this means that you guys have to develop the whole reconfigurable platform with its supporting tools; a non-trivial task I reckon."

Maybe.

Regards, Nicholas Paul Collin Gloster

In news: snipped-for-privacy@itee.uq.edu.au timestamped Thu, 17 May 2007

09:27:33 +1000, John Williams posted: "[..]

Are you aware of the Reconfigurable Scalable Computing (RSC) project being run out of NASA Langley?

A few web references below, but feel free to contact me directly if you'd like more info.

Regards,

John"

Dear Dr. Williams,

I note that the term "Bus" appears twice on

hodson p.ppt#299,9,Reconfigurable Processing Module in contrast to the term "Scalable Network" on hodson p.ppt#268,4,Scalable Architecture

Is the cache mentioned on

hodson p.ppt#308,10,RPM Features suitable for realtime use?

"Xilinx logic is triplicated" on

hodson p.ppt#308,10,RPM Features is not detailed enough to show what risks your form of triplication is susceptible to and resilient to. On somervill p.ppt#281,10,Embedded Processing it is written: "Design mitigated with XTMR tool (or manually)". What drives your choice for the XTMR tool or manual error detection and correction? However, I note from Linux and RSC that your reconfigurable systems for NASA are not intended for spacecraft survivability, so protection against errors might not be very important for you.

On

Multiprocessing it is claimed "We can put about 8 CPUs in an FPGA" so what is the 33% utilization "of FIFO16/RAM16s" on for?

Thanks, Colin Paul Gloster