We have used an industrial board based on a pentium laptop CPU with lots of SEU voodoo
around as the main controller. That was not deep space but ISS.
Then there were PicoBlazes in the FPGA. I wrote the configuration memory scrubber
for the FPGA and a nice triple module redundant library that looked much like VHDL
std_logic... / signed/unsigned with the redundancy under the hood and barely visible.
I also modified the PicoBlaze because it uses block rams for registers etc. and these
are really part of the configuration memory. Re-juvenating the configuration ram
kills the register contents. That caused some grief for the software lady.

I don't think that American CPUs have a place in future space projects in the rest
of the world. Watch current American politics wrt TSMC just as an example.
No one with a brain will surrender himself into captivity if there is any other option.
I did not get the Xilinx TMR toolbox, so I wrote my own solution, which I feel is
better anyway (more fine grained). We ended up with bronze time FPGAs, we
could not even get the solder requirements for contemporary ones. And that for
a project intended for the ISS. Yes, one might have escalated that to the CEO
level and above, but I think the idea is just to create delays.
And that was pre-Donald. Just normal ITAR.
Others seem to have had the same problem. These are the results:
<
https://www.esa.int/Enabling_Support/Space_Engineering_Technology/Shaping_the_Future/High_Density_European_Rad-Hard_SRAM-Based_FPGA-_First_Validated_Prototypes_BRAVE >
<
https://www.edn.com/brave-new-itar-ear-free-space-grade-fpgas/ >
Xilinx won't like that.
Cheers,
Gerhard