Rant about the quality of embedded SW support from FPGA manfacturers

[Daixiwen]

I generally don't have a lot of problems with the hardware part of FPGA projects. I have almost always found the information I needed from the documentation and the quality is globally good. Of course the tools need some getting used to but this can be the subject of another rant.
Ever since the FPGAs have been big enough for soft core CPUs, and now that some have some hard core CPU included, the manufacturers also need to provide support for the embedded software developers. And the quality on that side is not really on par with the hardware side, to put it mildly...
Critical information is often missing from the documentation, and the software examples provided often look like they were written by an underpaid trainee with no experience in embedded software development, that stopped working on the code as soon as it was good enough to run for 5 minutes without crashing.

I've had problems with Altera before, and i have recently struggled with Microsemi while helping our software team to get a LwIP network stack working bearbones on a Smartfusion2 development kit.
So to begin with the driver provided by Microsemi doesn't include the polling function required when you don't use an operating system. Not a big problem, this is not very difficult to implement myself. But then I had to correct two bugs in the driver, including a race condition bug that would in some conditions completely stop all incoming traffic until the next reset or power cycle. Those conditions are more likely when running without OS, but even in their example application with FreeRTOS it is likely to happen under heavy traffic. The code has been out there for at least 6 years and I'm surprised it has never been fixed. And before you tell me that this is just example code and shouldn't be taken as is, Microsemi explicitly say in their datasheet that they recommend to use those drivers in production.

And then going through the rest of their LwIP port I stumbled upon this gem:

Code: [Select]

u32_t sys_arch_random(void)
{
  return 0x42414523u;
}
They probably got this from xkcd!
This function is called by the LwIP stack each time it needs a random number. I don't get this. It's not laziness, the nano libc provided with the tools have the rand() function, and even if it's not that good it can't be worse than a constant. And while I'm not a security expert, I know that at least the TCP/IP algorithm uses random values to mitigate spoofing attacks, making it difficult for the attacker to predict IDs used in TCP packets. so my guess is that any product using this code is vulnerable to TCP/IP spoofing attacks. Fortunately I don't think there are a lot of Microsemi components in consumer products....

But worse, now that I have seen that, it means that we will need to do a review of all their driver code before we can decide to use them in our projects. I wonder what other interesting quirks I will find....

[OwO]

I simply don't use the provided SDK or driver code. If I want to run Linux, I'll use a stock debian image and build the kernel. If you are doing bare metal, just do it from scratch and only implement drivers for things you are going to use. For something that uses a network stack, I highly recommend against going bare metal because "embedded" network stacks are always low quality and never get security updates.

[ralphrmartin]

Agreed, at least as far as Xilinx devices go. As an FPGA novice using a Zybo board, I was surprised how easy it was to build a Linux kernel with support for AXI GPIO, and then use that kernel with a stock Debian image. It's also pretty straightforward to then use uio to connect to the peripheral from userspace (with interrupts if needed) to drive your FPGA hardware, and standard linux calls for everything else.