MCU or SoftCORE?

[martinribelotta]

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?

[JohnnyMalaria]

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

[gnuarm]

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.

[martinribelotta]

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

In 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-fpga

Unfortunately, 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)

[brucehoult]

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.

[martinribelotta]

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???

I'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)

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.

The 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"

When they made reusability a "must be" requirement, how will it be tested?  Every requirement must be testable.

The 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...

[martinribelotta]

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)

BGA pacakges... I'm limited to 4-layer non-bga designs in this project...

I believe MicroSemi FPGAs are often used in aerospace space applications.

I 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)

[brucehoult]

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?

[gnuarm]

I 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)

I 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

[brucehoult]

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.

[Bassman59]

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.

[NorthGuy]

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.

[brucehoult]

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.

Nah. 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.

[SiliconWizard]

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.

[brucehoult]

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.

[martinribelotta]

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 [1] 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)

[1] Banana dose: https://en.wikipedia.org/wiki/Banana_equivalent_dose

PD: I really wanted to use the PolarFIRE-SOC

PD2: Thanks to all and remember: "all engineer problems can be solved using banans"

[Silenos]

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.

[tszaboo]

• Other MCU in secure configuration? Anyone work with TriCore???

Its an Infineon microcontroller, burn it with fire.
That's all I wanted to say.

[viperidae]

Sounds like someone is trying to build an ICBM.
100km altitude and radiation exposure?

[uer166]

Or just a sounding rocket for science! A couple students broke the Karman line more than once.

[Berni]

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.

[uer166]

At least three cheap commercial MCUs with an FPGA output arbiter?

Essentially a DIY TriCore.

This 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.

[uer166]

This 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.

You can get very cheap and fairly rad hard (for commercial product) FPGAs (Microsemi ProASIC3), they are slow to run soft cores productively, but enough to run IO arbitration.

If the FPGA is rad-hard and verifiably more reliable than the MCUs, that makes 100% sense, thank you.

[Berni]

At least three cheap commercial MCUs with an FPGA output arbiter?

Essentially a DIY TriCore.

This 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.

I 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.

[gnuarm]

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.

I 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. 

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.

Very big bucks.  That's why space hardware uses the same tested items for decades.

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.

Or just rebooting periodically. 

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.

Error tolerance is not easy.  It's also hard to verify.  How do you prove it is tolerant of every type of failure?