MCU or SoftCORE? - Page 1
Forum section: electronics / general

author: martinribelotta
author_rank: Regular Contributor
timestamp: February 14, 2021, 08:32:05 pm
content: Hi everyone, I'm starting an reliable design of fligh control central processing unit for some clients... This design must work in hard envorinment (high altitude atmosphere) but I cannot use aerospace grade hardware (due to commertial focus of the project).In fact, the SBC will be very simple because te avionic is not so hard to do but require hard real time control and reliable work (this is not so hard to do into atmosphere -yea, in LEO sattelite is more heavy)But the client put as a "must-be requirement" the resuability of the hardware for an other avionic system. In other projects, my ellection was a dedicated cortex-r4 MCU or flash-based FPGA (like microsemi lines) with redundant softcore, but concidering the reusability requeriment, the CPU must be the most generic design than I can...In this context, wath is your preferences?FPGA with softcore: Really flexible but in last instance, highest cost and low performance (all softcores have an order of magnitude less performance than the hardcore processors at the same technology)TI's dual lockstep processors: Really cheap in the low end but very limited in interface and memory (the biggest part with large RAM is very expensive near 50usd)Other MCU in secure configuration? Anyone work with TriCore???Combination of not so great MCU and little FPGA with interface softcore?

author: JohnnyMalaria
author_rank: Super Contributor
timestamp: February 14, 2021, 08:39:53 pm
content: How about a Xilinx Zynq 7000 SoC - two ARM Cortex A9 processors and an FPGA in one package.https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html

author: gnuarm
author_rank: Super Contributor
timestamp: February 14, 2021, 08:48:09 pm
content: Not sure why you are asking us. You know your requirements better than we do. You mention softcores, but say they are slow. Do they need to be faster than fast enough???You mention reusability, but what does that mean exactly? Would a Cortex M1 be reusable enough? A microblaze CPU reusable enough? A J1 stack processor runs at 100 MIPS, uses about 600 LUTs, but you need to learn a new language. I'm thinking that is not "reusable" enough.When they made reusability a "must be" requirement, how will it be tested? Every requirement must be testable.

author: martinribelotta
author_rank: Regular Contributor
timestamp: February 14, 2021, 10:17:47 pm
content: QuoteIn other circumstances this will be a good option. Other interesting option in this range of processors (BGA, full MPU capable, high integrated) is the PolarFire SOC+FPGA from Actel/Microsemi/Microchip (f*ck off the company selling)https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpgaUnfortunately, the tecnology required by the client involes only QFP and the BGA packages is pribited due the posibility of thermal dilatation (the BGA without bumpers handle really bad the termal dilatation with the board)

author: brucehoult
author_rank: Super Contributor
timestamp: February 14, 2021, 10:24:51 pm
content: I'd suggest MicroChip "PolarFire SoC" FPGAs with embedded 5x 64 bit RISC-V cores running at 600 or 667 MHz, I've only seen one configuration off the shelf at Mouser so far with 250k element FPGA and 667 MHz speed for $340 qty 1 (part number MPFS250T-FCG1152EES)I believe MicroSemi FPGAs are often used in aerospace applications.

author: martinribelotta
author_rank: Regular Contributor
timestamp: February 14, 2021, 10:26:53 pm
content: QuoteI'm founding personal experiences on softcores vs MCU in whatever cases... Yes, the requirements is clean for me, but the chalenge is about "reusability" (explain me more below)QuoteThe resuability is in therms of board. The client seeks to have a development that they can reuse in future projects.. In my view is extremely difficult to take into account the future missions but the first approach is "more big CPU, more big memory, more flexible interfaces"QuoteThe client did not know the unit tests before hiring me... I'm fingthing for obtain a continuous integration system with hardware in the loop and a formar specification of the system... Your desire of testability is really far in my road...

author: martinribelotta
author_rank: Regular Contributor
timestamp: February 14, 2021, 10:34:37 pm
content: QuoteBGA pacakges... I'm limited to 4-layer non-bga designs in this project...QuoteI have syntetize a little LEON3 from Gaisler grlib in ProASIC3 A3P600 but the performance was really low (10MIPS at 24MHz) using external parallel async flash (I had no place for a cache).With a bigger FPGA (A3P1K) I could add a 4K+4K I+D cache and SDRAM controller but the performance was still poor (12MIPS at 30MHz)

author: brucehoult
author_rank: Super Contributor
timestamp: February 15, 2021, 12:30:27 am
content: Can you use an off-the-shelf daughter board with an FPGA on it? Do you have physical size constraints? Do you have cost constraints? Will project cost be dominated by your engineering time, or by the hardware? WIll it be mass-produced, or just one or a handful of copies?

author: gnuarm
author_rank: Super Contributor
timestamp: February 15, 2021, 01:39:14 am
content: Quote from: martinribelotta on February 14, 2021, 10:34:37 pmI seem to recall from looking at a soft cpu comparison by Brakefield the LEON processor was rather slow / large by most metrics. Some processors are quite good achieving performance/size metrics similar to commercial products. An AVR clone is near the top of the list! James Bowman's J1 reaches almost 400 KIPS/LUT. The LUT counts can vary a bit in that some devices have 4 input LUTs and others have 6 input LUTs. The benchmarks are typically done in 6 input LUTs, but some are notated with an 'A' which is unclear to me, others a 4 which should mean 4 input LUT.https://opencores.org/projects/up_core_list/downloads

author: brucehoult
author_rank: Super Contributor
timestamp: February 15, 2021, 09:41:22 am
content: Olof Kindgren's "SERV" implements RV32I in (currently) 188 LUT4 (or 135 LUT6) and 178 FF. The default build assumes 32 MHz but I think it will run a lot faster than that. It does use 32 clock cycles for most instructions though, and 64 for some (branches and shifts for example), so that 32 MHz clock rate implies around 5 KIPS/LUT. It's going for minimum resources, not efficiency.Update: I checked with Olof. He says SERV ran at 220 MHz on artix7 and 60 MHz on ice40 last time he checked.So that's 50 KIPS/LUT on artix7 and 10 KIPS/LUT on ice40.On 32 bit data, so that's worth more than the same KIPS on an AVR.

author: Bassman59
author_rank: Super Contributor
timestamp: February 15, 2021, 05:39:51 pm
content: Well, I've done the thing where the micro is a soft core embedded in the FPGA -- both Xilinx Microblaze (in a Virtex-4, to give you an idea of when I did it) and an Actel (now Microchip) ProASIC-3L with an 8051 in it (was gonna do their Cortex-M1 core, too) -- and I've glued an FPGA to a separate microcontroller, I have some opinions. I have not done Zynq (yet).The first question: are you limited in board area? Given that you can't use BGA, my guess is "not really."The next question: what part of the design is handled by FPGA logic, and what part is handled by a processor?The third question: how tightly-coupled are the two parts? That is, do you need a fast path between the FPGA and the micro or not?If the communication between the micro and the FPGA doesn't require much speed, you can use SPI (or quad-SPI) as your link. Or even I2C! If you need to go faster, you could use a parallel external memory interface (or just crank up the clock speed of the SPI). At some point, you will reach a limit, and that's when having the micro and the FPGA in the same package, either with the micro as a soft core or a hard core, will start to make sense.If the processor is separate from the FPGA (or is a hard core separate from FPGA logic like Zynq), you can use the former to configure the latter. That opens the possibility of having more than one FPGA firmware image that can be used to configure the FPGA on the fly.Now depending on the complexity of what the micro needs to handle, that could blow up the size of your FPGA if it's implemented in a soft core. It may just be cheaper to have a $10 ARM Cortex-M4 sitting next to a $10 FPGA, rather than having to use a $50 FPGA to fit the processor.There's another consideration, which is debug, and that's a separate topic.

author: NorthGuy
author_rank: Super Contributor
timestamp: February 16, 2021, 12:08:50 am
content: I never worked with flight control, but I suspect you need very fast real-time number crunching, which you probably would do in FPGA fabric without involving CPU. Hence, the CPU core doesn't need to be very powerful, if at all needed, so the softcore would do just fine.On the other hand, you admit you could do it in CPU, which implies you don't really need fast real-time processing. Then, it is not clear why you need an FPGA.In short, if you know everything about your project, but still cannot make a decision, it's silly to expect any help from the forum people thousands miles away who don't really know what you need.

author: brucehoult
author_rank: Super Contributor
timestamp: February 16, 2021, 01:13:18 am
content: Quote from: NorthGuy on February 16, 2021, 12:08:50 amNah. Quadcopters and other RC models are far more twitchy than full-sized aircraft (even fighters) and got by fine with AVR autopilots until M0/M3/M4 chips got cheap.If nothing else, you can't physically move the control surfaces (ailerons, elevator etc) at even 10 Hz.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 16, 2021, 01:36:56 am
content: Agreed, but it's true we don't know the OP's requirements and what exactly his unit is supposed to do.Assuming they take care of the requirements properly, the question of which approach would be more "reusable" is interesting but hard to answer in a very general way.First, you need to exactly define (of have your customer define) what reusable means in this context. Should your design be usable in other contexts? Should it be easy to modify if extra features are needed? Should the customer be able to do this on their own once you've delivered the project? What amount of documentation are you ready to produce and give away?Does reusable here mean longevity? So should your selection of components ensure that they will be available long-term? If so, how many years from now (minimum)? Does that alternatively mean that your design should be easy to port to different parts (especially the "CPU")? Does that mean that this porting would have to be minimal AND doable by the customer years from now and without your help?Selecting a soft core on FPGA rather than a MCU is a tough choice to make for achieving the above goal. A soft core-solution may look like it's better because you have control over the processor itself instead of being tied to a specific vendor, but it looks that way on the surface only. In many cases, a real-life implementation of a soft core on some FPGA will require specific resources of the FPGA you select and thus the porting effort to another FPGA down the line may not be as easy as it seems. Then there's the question of the architecture of the soft core itself. If you're going for a vendor-provided soft core with an odd ISA, you're tying yourself to this vendor. OK some vendor soft cores are open and you can reuse them on other FPGAs (but that may take effort), some are not... Then you need to consider if an odd architecture will not make your design actually more difficult to reuse than using an off-the-shelf MCU with a well-known and well supported architecture.Then you need to consider validation. I don't know what your customer expects, but in avionics, regulations are stringent. You need to follow strict standards. Validating avionics software is hard as it is, but if you have to validate a soft core on top of that (including its particular implementation on the particular FPGA you select), that's a lot of work.Again I don't know all your constraints, but if you're using a MCU with a pretty standard architecture (say ARM), write decently portable code, properly isolate all the hardware-related code (drivers, etc), and/or use a well-known and well supported RTOS, this should be straightforward to port to a different MCU later on if the need should arise.A lot of considerations, but choosing a soft core, even though it may look like you have full control over every part of your design, is not necessarily the wisest choice here. And with all that said, you should definitely consider discussing that with your customer in details, exposing the pros and cons of various approaches, taking the regulatory aspects into account, and let them decide based on your technical inputs. Just my 2 cents.

author: brucehoult
author_rank: Super Contributor
timestamp: February 16, 2021, 03:59:03 am
content: That seems like an argument for starting with a commercial verified soft core (if current performance requirements permit -- 50 MHz on a 32 bit or 64 bit core with FPU is quite a lot of performance) from a vendor that can also provide the exact same core in a stand-alone SoC, or as a hard core inside an FPGA.Seems as if ARM Cortex A9 almost fits that bill, as it is available in SoC or embedded in Zynq. But I don't think it's available as a soft core.SiFive S51 or U54 would fit all three.

author: martinribelotta
author_rank: Regular Contributor
timestamp: February 16, 2021, 04:32:22 pm
content: My final approach: Inphographics with bannana-dose equivalences.Explanation:The vehicle is a some type of small misil flying at 100Km of altitude. The team of the client was worried by the radiation to these altitude (100Km) and the possible SEU or total dose accumulation. This is the only reazon to do the design with a space cualificable hardware like rad tolerant samv71 or some kind of FRAM processors (like MSP430) apart from concidering the usage of ProASIC3 FPGA (the industrial parts is the same die than the space grade parts but without cualification process)The cost of vehicle will be extremelly low because is not reusable and ship some scientific instruments (with really low cost hardware) as a payload. In the first approach, the desired BOM should be less than 250 USD per CPU board and capable of being mounted manually.My approach is do it with commertial electronics due to cost restrictions but the client team argued that in these altitude the radiation and SEUs will be very problematic, but an annalisis of the real dose of radiations shows that the dose at 100Km is equivalent to 1uSv. The uSv is not a familiar unit for most business people on my country. Due this, I translate the 1uSv to banana dose  and explain the context as: "the electronic receive the equivalent of radiation emmited of then banana per seconds, or, in international system notation 10BED (banana equivalent dose)" (insert LOLs in the room)This does not remove the SEUs fails or other equivalent errors but the mitigation is more easy than the real orbital travel. My approach is use a ProASIC3 (600Klut) with two VexRISC minimal cores in lockstep mode (sytetized at 35MHz with 0.75DMIPS/MHz) and use the rest of FPGA to implement the required interfaces (many SPI, two i2c, two QSPI with memory mapped to PSRAM/FLASH and other extrages encoder interfaces) Banana dose:https://en.wikipedia.org/wiki/Banana_equivalent_dosePD: I really wanted to use the PolarFIRE-SOCPD2: Thanks to all and remember: "all engineer problems can be solved using banans"

author: Silenos
author_rank: Regular Contributor
timestamp: February 16, 2021, 06:53:12 pm
content: I can tell you that even stm32f1 can eat more full siverts inside the ++1 MeV gamma flux than a human can.Although I'm no expert in "aerospace", I wouldn't worry that much about radiation doses in your usecase. Unless your cpu register structure ate 300 TeV proton farted off by a galaxy which has already redshifted into oblivion, imo nothing would happen. The Sun has started moving towards maximum and pumping its magnetosphere, so such cosmic rays are significantly will be less and less propable to occur for next 10 years.Dunno if your client told you explicit radiation doses and risks, or has more experience, but I advice you to try testing your finished device in some radiation laboratory. Just few hours of ram/rom memory integrity testing program in front of cobalt source, fast neutrons, maybe beta too, it shoudn't be expensive. And you would have hard results on paper. Banana uSv radiation is nothing. Yes, detectable, above the background, but still nothing.Assuming your device will last max tens of minutes on 100 km altitude and is expendable, I would drop the lockstepped cpus, fpgas and other bs, and stick to completely normal, commercial things done with redundancy in mind (double mcu). Mind you still will have other ICs onboad. And still, the software engineering will be the major contribution in the your project cost.But that's just my opinion based on whatever brutal radiation mutilations I have commited on some electronic parts.Personally I think, that rocket acceleration and vibrations could be much more of issue than radiation. Afaik semiconductors don't like it. Against temperature I would just pack the board inside the thin heated enclosure and forget the issue with already some radiation attenuation granted for free. Just throwing ideas around.

author: tszaboo
author_rank: Super Contributor
timestamp: February 16, 2021, 11:20:27 pm
content: Quote from: martinribelotta on February 14, 2021, 08:32:05 pmIts an Infineon microcontroller, burn it with fire.That's all I wanted to say.

author: viperidae
author_rank: Frequent Contributor
timestamp: February 17, 2021, 06:09:47 am
content: Sounds like someone is trying to build an ICBM.100km altitude and radiation exposure?

author: uer166
author_rank: Super Contributor
timestamp: February 17, 2021, 06:22:02 am
content: Or just a sounding rocket for science! A couple students broke the Karman line more than once.

author: Berni
author_rank: Super Contributor
timestamp: February 17, 2021, 06:23:57 am
content: I don't see how going for a softcore would be more reliable in radiation. If anything a FPGA is more fragile due to the possibility of radiation not only corrupting bits in memory but also corrupting the distributed switch fabric memory that holds the FPGA configuration state while it is running.Id say go for any of the automotive offerings that have multiple CPU cores running in lockstep. They are cheep and easily available while being plenty robust, as the only step up is to go for proper radhard chips that cost big bucks.Also being resistant to radiation doesn't just mean that it keeps running despite high energy particles bombarding its bits. Its also about detecting that something went wrong and quickly rebooting the processor before it has a chance to do something stupid and doom the mission. The software is designed to quickly pick itself back up and continue running. A short outage of the system is still better than a glitch causing permanent damage to something or even god forbid endangering lives.If you do need flexibility to do weird IO and such you can still use a MCU+FPGA combo on a board, giving you the freedom to chose any MCU and any FPGA you like. Letting the MCU do the processory tasks while the FPGA handles any of the weird IO that the MCU might not be capable of. But then it is also your job to design the FPGA logic in a redundant way that self tests itself for errors, so that the FPGA can be quickly reset to recover it.

author: uer166
author_rank: Super Contributor
timestamp: February 17, 2021, 06:24:20 am
content: Quote from: blueskull on February 17, 2021, 06:21:19 amThis always confused me, who arbitrates the arbiter?? I can visualize that a mechanical combiner/voting logic much like in some fighter jets (F22 IIRC?, also commercial aileron controls) increases reliability, but using an FPGA seems counter-productive, much like using a 4th MCU of the same kind as voting logic.

author: uer166
author_rank: Super Contributor
timestamp: February 17, 2021, 06:28:06 am
content: Quote from: blueskull on February 17, 2021, 06:26:57 amIf the FPGA is rad-hard and verifiably more reliable than the MCUs, that makes 100% sense, thank you.

author: Berni
author_rank: Super Contributor
timestamp: February 17, 2021, 06:42:55 am
content: Quote from: uer166 on February 17, 2021, 06:24:20 amI did something similar before in a design as a fallback in case of CPU failure.I put all the critical control signals under the command of a CPLD chip. The CPU would then ask the CPLD to toggle those lines as needed, but it also had to constantly update a watchdog register. The CPU calls the clear watchdog function once if all the internal code paths have hit there own mini watchdog. If the CPU fails to do that then it is cut off from control and the CPLD falls back to some simple internal control logic that takes care of the most critical functions. Same happens if an external emergency signal is received. You could short the MCUs Vcc line and all that would do is blow the MCUs power supply fuse while the system continues running in the limping safemode.So the CPLD is considered as the final gate keeper that decides who gets control of the system. But the source code for the CPLD is so small that it is just a single HDL file that fits on a few A4 pages. The whole idea being that the gate keeper is so simple and dumb that there is a very very small chance for something to go wrong inside it.If the requirement was to also keep the CPU functions operational despite a single component failure then the CPUs would indeed have to be in triplicate and the CPLD would have to run the voting system in pure combinational logic.

author: gnuarm
author_rank: Super Contributor
timestamp: February 17, 2021, 07:41:37 am
content: Quote from: Berni on February 17, 2021, 06:23:57 amI worked with a guy from NASA once and they dealt with soft errors by reconfiguring the FPGA periodically. I didn't get the details, but soft errors would not impact the system long enough to cause any real damage.QuoteVery big bucks. That's why space hardware uses the same tested items for decades.QuoteOr just rebooting periodically.QuoteError tolerance is not easy. It's also hard to verify. How do you prove it is tolerant of every type of failure?

author: iMo
author_rank: Super Contributor
timestamp: February 17, 2021, 08:18:39 am
content: Quote from: martinribelotta on February 14, 2021, 08:32:05 pmBy asking here how to make your design for your clients you also indicate you do not have enough experience in that area.. If I were you I would not commit myself to any deliveries of that kind..

author: gnuarm
author_rank: Super Contributor
timestamp: February 17, 2021, 08:56:34 am
content: Quote from: imo on February 17, 2021, 08:18:39 amHe is not asking anyone to make his decisions. He is just looking to bounce ideas around. Brainstorming. Potentially very useful, but hard to do when you work alone.I thought that was one of the reasons for this group existing? I know that's why I come here, to share ideas and experience, not to get others to do my work.

author: NorthGuy
author_rank: Super Contributor
timestamp: February 17, 2021, 03:03:27 pm
content: Quote from: gnuarm on February 17, 2021, 07:41:37 amXilinx FPGA configuration blocks have Humming codes. You can configure the FPGA to constantly check the Humming codes and if a code fails you get a signal. I don't remember if it can correct on its own or not.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 17, 2021, 03:51:14 pm
content: Quote from: Berni on February 17, 2021, 06:23:57 amI'd agree with that in general, but I guess the OP chose that path not just because it's a soft core on any random FPGA, but because Actel/Microsemi/now Microchip offers Proasic3 FPGAs that are radiation-tolerant:https://www.microsemi.com/product-directory/rad-tolerant-fpgas/1696-rt-proasic3I don't know if the OP really intends on using those though - they talked about Proasic3, and the non-RT ones are not specified for radiation tolerance (although I've indeed heard they tended to behave better under radiation than many other FPGAs, the vendor doesn't guarantee that.) I have no clue how expensive the "RT Proasic3" are.I would probably have considered radiation-hardened MCUs instead though. As I said earlier, validating a whole custom SOC on FPGA is no easy task, and I don't think we were talking about a hobby project here... so validation doesn't look optional IMHO.Microchip also has this radiation-hardened MCU:https://www.microchip.com/wwwproducts/en/SAMRH71(in typical packaging for this), a beefy MCU on top of that. Probably not cheap.As I think we understood cost was a consideration (because the device would end up being lost if I got it right?), then going for a design with vanilla parts and redundancy may look like a better option, but it still requires care. If your components are sensitive to radiation, you could put 10 redundant systems in parallel and they could very well all fail...

author: gnuarm
author_rank: Super Contributor
timestamp: February 17, 2021, 05:18:23 pm
content: Quote from: NorthGuy on February 17, 2021, 03:03:27 pmI think you mean Hamming codes, no? I found info on this, FRAME_ECCE2, and it says the primitive must be instantiated and that it does not automatically correct errors. That must be done in user code. I'm pretty sure only single bit errors can be corrected. Since multiple bit errors can be detected, but not all, it is unlikely this would suffice for high reliability systems. Double bit errors can be detected 100%, but more than two bit errors and even the detection is not certain.Even if this approach is adequately reliable, it is essentially a sequential process that takes time to detect and find an error. For other than single bit errors, resolution of the error requires reconfiguration. So the details of timing may change, but this is essentially not different from simply reloading the entire configuration periodically.

author: tggzzz
author_rank: Super Contributor
timestamp: February 17, 2021, 05:28:34 pm
content: Quote from: martinribelotta on February 14, 2021, 08:32:05 pmI suggest your starting point is to determine what will be in the acceptance criteria and acceptance tests.As a hypothetical example, you may find you have to prove/demonstrate that the implementation of a softcore matches the specification. If so, what happens when there is a change which causes an FPGA implementation to be placed and routed differently?

author: gnuarm
author_rank: Super Contributor
timestamp: February 17, 2021, 08:37:46 pm
content: Quote from: tggzzz on February 17, 2021, 05:28:34 pmI don't think that particular example is difficult to manage unless you are talking about some level of verification that is far beyond what is done for FPGA designs.Timing constraints are used to establish that the routing meets timing requirements. A particular job may require a validation suite of test vectors be run to verify functionality. In theory that can be run against the source code to validate the design, but a very cautious project may require the routed design be validated to assure the synthesis was done correctly.Beyond that you would be validating the design process rather than the design. While that is not an unreasonable thing to do, I think it is beyond what needs to be considered for the initial evaluation of a project the OP is doing.

author: tggzzz
author_rank: Super Contributor
timestamp: February 17, 2021, 09:43:08 pm
content: Aerospace systems typically have stringent requirements concerning the design process. What we might think is (un)reasonable is unimportant.Such considerations can be "the tail that wags the dog". The OP should determine the key factors in this case; we cannot.

author: Bassman59
author_rank: Super Contributor
timestamp: February 18, 2021, 12:08:38 am
content: Quote from: SiliconWizard on February 17, 2021, 03:51:14 pmThe RT ProASIC-3 devices have the same dice as the equivalent commercial devices. The difference is that they ship in hermetically-sealed column-grid-array packages (with the same footprint as the commercial BGA devices), and they come with the paperwork indicating their pedigree. (They're also a LOT more expensive.)The flash-based configuration is immune to upsets, even from heavy neutrons, and they do not latch up.Now don't confuse the configuration with the logic: you can still flip logic bits because of radiation. Enable TMR in synthesis on the whole design, or on critical parts. The version of Synplify Pro they provide does this for free. It will, of course, have an adverse affect on timing.The ProASIC3 fabric is shitty.Microsemichip also have the follow-on PolarFire devices, which have a better fabric on the same sort of flash configuration. There's an RT variant, too.There's also the RTG4, which is giant.And if you're serious, there's the RTAX space-flight grade parts, one-time programmable, with all registers TMR.

author: brucehoult
author_rank: Super Contributor
timestamp: February 19, 2021, 10:02:16 am
content: https://twitter.com/ColeJ71909899/status/1362458612266917893The "Ingenuity" helicopter on the #Mars2020 mission has a fault-tolerant computer system designed around an off-the-shelf FPGA model (ProASIC3L.) The FPGA does the usual things an FPGA would do but also takes care of the other components when they fail due to radiation. The FPGA ensures its own fault tolerance by running below the max speed grade and using Triple Modular Redundancy in parts of the design. (1 gate -> 3 gates that vote)Visual processing is done by a Snapdragon 801 running Linux.

author: Berni
author_rank: Super Contributor
timestamp: February 19, 2021, 10:17:06 am
content: That is a rather nice writeup of the mars helicopter project too. Its short at 18 pages but contains all the nice juicy technical details of how it works and reasons why it is designed the way it is.

author: NorthGuy
author_rank: Super Contributor
timestamp: February 19, 2021, 04:20:44 pm
content: Quote from: gnuarm on February 17, 2021, 05:18:23 pmExcept that you don't need to re-configure if there's no errors. Thus, instead of reloading periodically, you do it very rarely, most likely never.

author: gnuarm
author_rank: Super Contributor
timestamp: February 19, 2021, 04:55:28 pm
content: Quote from: NorthGuy on February 19, 2021, 04:20:44 pmIf you have to allow for the device to be reconfigured, there's no advantage to not reconfiguring.When I first heard of doing this I thought it must be something very strange to be able to work most of the time, but not all of the time. But it seems space craft have components that are not used 100% of the time. The hard part is verifying the rest of the system is not impacted when one component is not functional. I seem to recall reading about a mission failure caused by a lack of consideration for some mode of use of an Actel part. I think they have a white paper about it, but I recall zero of the details.

author: NorthGuy
author_rank: Super Contributor
timestamp: February 19, 2021, 06:57:13 pm
content: Quote from: gnuarm on February 19, 2021, 04:55:28 pmIf something fails in your PC it will reboot (hopefully). If you truly believe what you just said, configure your PC to reboot every five minutes and see how it goes.

author: gnuarm
author_rank: Super Contributor
timestamp: February 19, 2021, 07:31:52 pm
content: Quote from: NorthGuy on February 19, 2021, 06:57:13 pmPlease don't make silly arguments. If you are designing a space craft to sustain soft errors in the FPGA by reconfiguring, obviously it has to have zero impact on the craft.Do you really not understand that?

author: NorthGuy
author_rank: Super Contributor
timestamp: February 19, 2021, 08:08:37 pm
content: Quote from: gnuarm on February 19, 2021, 07:31:52 pmThis is not an argument. It's an example which makes it easier to see how silly your proposition is.Quote from: gnuarm on February 19, 2021, 07:31:52 pmAny device, no matter how hard you try to make it safe, can fail. You can only reduce probability of the failure, but you cannot 100% prevent it. Doing something very rarely - such as reconfiguring FPGA due to spurious configuration errors which statistically occurs once every 1000 years, is not the same as deliberately doing this every second, and will have different impact on the probability of the system failure. Moreover, reconfiguration itself poses risks, such as reliance on the integrity of the configuration source (e.g. flash or EEPROM). If the configuration source gets corrupted, it may become impossible to configure the FPGA at all, so your "periodic reconfiguration" will kill the system instead of healing it.

author: gnuarm
author_rank: Super Contributor
timestamp: February 19, 2021, 08:39:01 pm
content: North, I don't know what conversation you are having. The context I was discussing was recovery from soft errors in a high radiation environment such as space flight where the MTBF for such soft errors in configuration bits is much less than 1,000 years.If you wish to discuss that matter, I'm all ears. You seem to want to take the conversation in other directions where it makes no sense to even consider such errors.

author: NorthGuy
author_rank: Super Contributor
timestamp: February 19, 2021, 09:41:57 pm
content: Quote from: gnuarm on February 19, 2021, 08:39:01 pmYou said that checking ECC codes in FPGA to verify the integrity of the configurationQuote from: gnuarm on February 17, 2021, 05:18:23 pmI am trying to explain you why this is not the same.Quote from: gnuarm on February 19, 2021, 08:39:01 pmIf you're referring to the environment where MTBF for spurious configuration errors is similar (or even comparable) to the time required to check the configuration ECC, I can assure you that FPGAs are completely unusable in such environment. End even if they were , re-configuring every second would make them unusable.

author: gnuarm
author_rank: Super Contributor
timestamp: February 19, 2021, 10:50:06 pm
content: This is very simple... I'm talking about what NASA does to use Xilinx FPGAs in space according to the guy who was running the testing on the devices at NASA. If you would like to ask him questions I can look up his email address.

author: Bassman59
author_rank: Super Contributor
timestamp: February 20, 2021, 06:19:11 pm
content: Quote from: brucehoult on February 19, 2021, 10:02:16 amWell, to be fair, the design runs below the maximum rating for the speed grade because when you enable TMR, it greatly reduces the maximum clock frequency because of all of the routing required to get signals to three times the number of flip-flops and the voting gates. ProASIC3L does TMR in the fabric with synthesis, there's nothing special about the fabric itself. But ... it does work. I've used these parts in a rad-tolerant design.But regarding the clock frequency: what determines the clock frequency of any given design? Usually there's a throughput requirement, or there's some external device that has a frequency spec. In absence of either, you run at a moderate frequency. Lower frequency means less power consumption (important for a space vehicle!). So they likely picked a clock frequency that guaranteed TMR timing while also ensuring that you can talk to other things in the design.