With this blog post I would like to present you my first views on the Polarfire FPGA Evaluation Kit. I was one of the few lucky participants selected to roadtest this invaluable FPGA board.
My take on this part would be to focus more on the software aspect (toolchains)/documentation as a frequent Xilinx Vivado user, but a first time Microchip Libero SoC user.
This board some has unique features when compared to boards from other vendors I used in the past, which I am excited to try in the near future:
- Non-volatile FPGA fabric
- Power monitoring circuitry
- Impressive selection of I/O ports
This part of the review is a bit critical at times, but I really believe in this platform and I hope my comments can be used to improve the software/support as well. For the next part, I plan to explore a more advanced use case like with a RISC-V softcore (Simodense), and how it benefits from the unique features mentioned above (e.g. use the power measurements optimise the softcore design for power, and many more).
Unboxing
I have recorded my unboxing experience in a timelapse video:
This is not a masterpiece of a video, but you can get a general idea of the size of the FPGA board, as well as the contents inside the box. An interesting thing is that there is no software license as someone would expect (more on this later), other than a quick start leaflet with a barcode.
Installing Libero SoC on Linux (in a VM)
Libero SoC is the toolchain provided by Microchip to assist all the software-related tasks such as synthesis, place-and-route and programming for this FPGA. Installing Libero SoC on Linux has not been very straightforward, but I would not say it is a dealbreaker for me. I have installed CentOS 8 inside VirtualBox, as this was one of the few Linux distributions that are officially supported by Microchip.
First, with respect to the license, I was supposed to request a one-year "free Silver license" after registering an account at the Microchip website. The documentation was a bit vague on the licensing details, such as about what license is required for Windows vs Linux, so I had to look for clues/smallprint (e.g. inside PDFs with FAQ). There is the "node-locked" license, which only works on Windows, because it reads the hard drive partition serial number and expects a certain number of digits, which is much lower than Linux's UUID. There is also the "floating" license, which expects you to run a license server process ("lmgrd") in the background. So, for installing Libero on Linux, I had to opt for the free "floating" Silver license via the portal inside the Microchip website. The Microchip website is not as polished either, as it "promised" to send an email with license within 24 hours, though I never received the email, but the license file was shortly available to download from the online portal.
The license server process ("lmgrd") is supposed to run in the background to provide (numerous) "handshakes" for the different Libero subprocesses, ensuring that the license is valid. One problem with "lmgrd" is that it forbids use in a VM, hence I had to run this natively on my Laptop (Thinkpad L14 AMD with Arch Linux). The official documentation obfuscates this information by saying virtual machines are not "supported". But after seeing lmgrd's log files, it is clear that there is a detection mechanism (logging "Running on Hypervisor: Not determined - treat as Physical"). A problem with lmgrd, other than its restrictive nature, is that it bases the license authorisation on the MAC address of the network interface of your computer, which you have to disclose before obtaining the license file. When the machine goes offline, lmgrd has to be restarted, otherwise important functions like place-and-route stop to work.
The Lmgrd binary is buried inside Libero's filesystem hierarchy, hence I used the "find" linux command to find it, though it can be downloaded separately from the website ("Linux_Licensing_Daemon"). This was then transferred to my host machine, and the VM's Libero accesses this through an IP address pointing to the host, as specified by my Virtualbox's port forwarding settings. The IP address for the license server has to also be declared in .bashrc (LM_LICENSE_FILE and SNPSLMD_LICENSE_FILE variables), otherwise Libero does not even start.
The first setup binary for Libero SoC is supposed to help with the licensing process, but it falls short quickly, as it only provides links to the website (no mention of lmgrd). Any license error messages inside Libero are not very descriptive, as in the best case you will find some error codes that will hopefully match a forum discussion after googling. For example, the problem with "lmgrd" forbidding VM use was discovered by such clues (I think from an unrelated Matlab or Wolfram forum if I recall correctly), rather getting an explicit message for the problem.
There were some other peculiarities relating to Linux use. For instance, Libero sometimes requests you to type certain commands in the linux terminal by hand. This was the case for the first installer, where it gave a long DNF (package maintainer for CentOS) command line to install all required libraries from CentOS's repository, though all this could be automated or integrated.
Similarly, for other steps you also need to search for other fineprint online if you run Libero on Linux. One of the last steps of my progress was to connect the FPGA using the USB port on the computer and flash the device, but I could not tell why it was reporting that "no programmer is detected". As it turned out, you need to run the "udev_install" script and take some additional steps, otherwise the tool would need to run with a superuser account to interact with USB.
Update: As mentioned below, appart from the license server, the programming software "FlashPRO Express" (downloaded separately (originally included in Libero SoC)) also need to run natively, otherwise the programming takes over 15 minutes and sometimes fails. After installation, the "udev_install" script produced an empty file for the udev rules, probably because my host machine is running Arch, which is unsupported. Luckily, the script generated for CentOS 8 was compatible with my Arch setup. This needs to be saved in the following path: "/etc/udev/rules.d/71-microsemi.rules".
SUBSYSTEM=="usb",ATTR{idProduct}=="2008",ATTR{idVendor}=="1514",MODE="0660",GROUP="1000",SYMLINK+="FlashPro5"
SUBSYSTEM=="usb",ATTR{idProduct}=="6001",ATTR{idVendor}=="0403",MODE="0660",GROUP="1000",SYMLINK+="FTDI232"
SUBSYSTEM=="usb",DRIVERS=="ftdi_sio",ATTRS{interface}=="FlashPro5",RUN+="/bin/sh -c 'echo %k > /sys/bus/usb/drivers/ftdi_sio/unbind'"
There are some other minor issues I have not managed to resolve yet, like getting a blank browser window for some help links inside Libero. An important question that I still have is what happens after my silver license expires after a year (can I renew it for free?).
Note that from my experience with installing tools from other vendors they were also a bit time consuming, but it would be nice to have a smoother first experience, and maybe use a more permissive license and licensing tools to simplify the process.
Libero SoC vs similar tools
When comparing Libero SoC itself, I would say there is not much difference to competing tools. I have experience mostly with Xilinx's Vivado, but I would say Libero SoC look and feels more like Vivado than Intel's Quartus.
There are some bugs here and there, but unfortunately this may be the norm for all FPGA tools.
I indicatively provide a screenshot showing an issue I found. The virtual machine's allocated RAM was not enough for this particular step, but there was no other detailed indication of what went wrong, other than the "Tool failed" tooltip. So I had to dig deeper into the project's files.
If we ignore these issues, I really appreciated the hierarchical view on the left. I personally found it more user friendly than Vivado, because the tools are more well interconnected here.
There is a more philosophical argument with respect to how integrated these tools will need be in the end. I would like to be able to run e.g. in "batch mode" to assist a design space exploration for example. I know Libero could support Tcl, but I am interested in a bit more than that. I understand that companies such as Xilinx attempt to automate a great part of the design process to increase user-friendliness. However, in the process some freedom is usually lost, such as with Xilinx's "FPGA manager" (FPGA manager was a kernel facility that enabled reconfiguration while Linux was already running in its Zynq devices). While there are similar/equivalent tools, I found out that the proportion of related/similar binary blobs has increased over the open source code (or more generally adhering to the Unix design principles), probably in the name of security as well, and are more limiting (another example for other Xilinx devices is that you are not supposed to do DMA transfers in user space). I may be wrong and miss some information, but I think this approach is prominent among FPGA vendors (also with the push for high-level synthesis) and eliminates some possibilities for research, as FPGAs should still be able to be used as development platforms for research. This comment is my high-level understanding of how tool integration looks and evolves at the moment, but I plan to revisit this section. I think this is where Microchip could shine, but I will let you know my experience when I move to a more complex design in Part 2.
Documentation and support
An issue with this board is the inconsistent support from Microchip, and I hope this can be resolved soon. While there is a support page for the board online, listing numerous documents, there are broken links relating to the Libero project files. I think this relates to the acquisition of Microsemi from Microchip. The following screenshots summarise the issue.
Luckily, there are Libero SoC projects available in Github that can be used as a baseline, but I really hope this is issue is resolved, especially for using more advanced features on the board.
Thus, for my first design I followed the excellent blog post of my fellow roadtester for the moment.
Update: The files seem to still exist in the website (the above example was here), therefore it would be a matter of updating the documents...
Another issue relates to the timeliness of the documentation. There seems to be a time gap between the hardware ("Rev. F") and the documentation ("Rev. D"), which resulted in some incoherent information. For example, even the board layout seemed to have changed in the meantime, but the documentation talks about pins from the past revision. See the image comparison below from one of the tutorials and my board (and do I also have to short the new J26 now?).
Other than these, I think the "inherited" material from Microsemi, as well as some online tutorials were much more helpful and direct than from other FPGA vendors. Therefore, I think it would be very valuable to fix these issues to create a coherent experience.
First design
My first design for this board is a modification of misaz' design, to count seconds in binary. A code snippet and a video follows.
module top (input wire clk, input wire rst, output [7:0] leds);
reg [31:0] counter;
assign leds[7:0] = counter[28:21];
always @(posedge clk) begin
if (!rst) begin
counter<=0;
end else begin
counter<=counter+1;
end
end
endmodule
A shortcoming is with the programming of the device, because it takes 15 minutes (Xilinx's Ultra96/ ZU3EG takes less than a second) and sometimes fails (with an unknown error code). But this may somehow relate to the virtual machine use, I can check out what happens natively at a later point.
Update: As mentioned in the documentation and from other users this should take less than a minute, so this could relate to the VM use or the J26 pin.
The occasional programming failure can be seen in the screenshot below (click to zoom in).
Update 2: This was fixed by programming the device natively instead of through the VM (see above for installation instructions for "FlashPRO Express"). The programming only takes a few minutes now. (click to zoom in)
First conclusions
I am very excited to try more advanced designs soon as this is a very capable and unique board. In general my overall impressions is that the hardware is very promising, but the toolchain and support need improvements to fully leverage the potential of this platform. I liked the clarity in the tools and I think they already have their own merits when compared to the tools of other vendors.
Disclaimer: I happy to fix any factual errors you find, or apply any other suggestions.
