One of the toaster controllers I designed has an MCU and an FPGA. The FPGA handles the hard real-time functions, while the MCU does supervisory stuff, and controls and monitors the FPGA via an SPI sidecar interface.
As the same hardware is used for several models of toasters, with very different operating parameters and requirements, and I dislike maintaining multiple versions of the FPGA code, there are rather a lot of configuration registers defined, so that the same FPGA code may be used for all the different toasters.
As the requirements have grown, so has the FPGA code evolved, sprouting ever more configuration options.
Now, here's a bit of a puzzlement: I'd noted in the past that, if I loaded outdated FPGA code, the MCU code would exhibit strange behavior.
Inspiration struck on today's morning walkies. The part of the sidecar interface where I handle register writes? There's a big case statement, on the register address.
I didn't include a default case. So: in effect, I told the compiler, "In the event that someone throws us an address I didn't list here, I don't care what happens."
So, the compiler optimized for CLB usage and timing... and when new MCU code writes to old FPGA logic that doesn't support a control register, the write can end up clobbering some other register. This may result in status registers returning insane values, causing the MCU firmware to become confused.
So now I know what causes that problem... and I'm confident that it won't cause trouble in the field, because all production releases check the FPGA's revision code, and down-rev logic causes the unit to lock up with a self-test fault.
Comments