RISC-V and Microsemi Polarfire on Fedora 27
Introduction
Microsemi is one of many vendors that are cozying up to RISC-V… SiFive’s next dev board for their 64-bit silicon, which is eagerly awaited, marries an engineering sample 64-bit physical chip with a Microsemi Polarfire FPGA.
Interestingly - tellingly - you can find mention of RISC-V soft-core right on the landing page above, but you have to download the overview PDF
Polarfire product overview PDF
…before there is mention of an Arm Cortex M3 “system controller” on the FPGA die. Having some kind of “system controller” in there makes a lot of sense, it’s not such a main presence as on Zynq or Altera / Intel variants with more powerful Arm chips on the die and integrated to the DDR controller and other buses, but then it’s not so expensive. Still, the fact it is left off the headline features altogether in favour of soft RISC-V, is an interesting straw in the wind.
SiFive “Unleashed” platform
I attended a Japanese “RISC-V day” in December, which a friend was helping to run. There Jack Kang, the Si-Five CEO showed slides about this forthcoming “unleashed” board… it’s not secret; here is the PR
… and here is a little more information via Microsemi…
The concept is hard silicon 64-bit RISC-V with a PCIe type link to the FPGA; the Polarfire is blessed with very high speed differential IO. So with this dev board, it will become possible to implement FPGA HDL peripherals that appear direct on the CPU bus.
Although RISC-V cores are standardized, and some acceleration infrastructure, their direct interest ends at the ISA. So unlike Arm’s strategy with many generic “Primecell” IPs you can also rent from them, which are standardized and have Linux drivers already, RISC-V do not provide “house versions” of anything other than the core, not even a serial port IP. This will inevitably lead to greater fragmentation than found even in the Arm ecosystem, for no benefit. Unfunded FOSS hackers who want to throw together soft IPs inside an FPGA will also meet a brick wall, as discussed later.
Update 2018-02-04: there’s a public release of the board now
But no mention of the FPGA / Companion board.
RISC-V seems to have made its case
There have been many news articles the last year or so about RISC-V I won’t bother regurgitating. From a FOSS perspective though, there have not been any significant contributions outside the core itself being permissively licensed. News that companies like WDC are, wisely, dropping Arm and rolling their own is clearly important (especially to Arm) but these chips are entirely proprietary and the change helps only WDC save money. It has no visible implication for FOSS users since they use all their chips internally.
Likewise there are presumably going to be customers for Si-Five’s “supported and characterized” 64-bit HDL, but existing locked-down devices simply moving from Arm to RISC-V to save the vendor money also does nothing for the FOSS commons.
Celerity
Celerity:
have a cool use for RISC-V basically making a GPU-type architecture with vast numbers (496 in the first iteration) of generic 32-bit RISV-V nodes inside and five 64-bit RISC-V nodes to act as controllers.
This is a contribution to the FOSS commons
and the design is FOSS.
RISC-V with OoO and competitive performance
The canonical RISC-V designs have a 4-stage fixed pipeline scheme, ie, no OoO / speculation putting the 64-bit design on a par with an RPi3 performance- wise (of course it depends on process). However Esperanto (IP vendor) showed a slide on an OoO 64-bit RISC-V design for use “at the top end”, ie, a modern Armv8 competitor:
ET-Maxion RISC-V Processor
- ET-Maxion will be the highest single thread performance 64-bit RISC-V
processor
- Allow RISC-V to be positioned alongside highest performance processors.
- Enable companies to go RISC-V from top to bottom.
- Reduces threat of retaliation by eliminating need to go to another
architecture at high end.
- Provide a viable high-end alternative for companies wanting to make the
transition to RISC-V.
Performance goals:
- Single thread integer performance comparable to the best IP cores
available from market leaders.
- Great Linux performance to run OS and applications.
Technical features:
- 64-bit RISC-V RV64GC instruction set
- Starting from BOOM v2, but expect substantial changes
- Out-of-order pipeline
- Multiple levels of cache
- Multiprocessor support
- Optimized for 7nm CMOS
- Will be used in Esperanto's products and made available as a licensable core.
Esperanto ET-Maxion, see p8
“Reduces threat of retaliation by eliminating need to go to another architecture at high end” eh… whatever can they mean :-)
These are proprietary implementations of the permissively-licensed RISC-V design, so they are not for free. However, since they are based on free stuff, they are going to be a lot cheaper than Arm’s proprietary-only designs.
This OoO design is perhaps the reason for the slightly careful phrasing during RISC-V’s ritual humiliation of Arm and Intel over Spectre, they could only say “no announced RISC-V silicon” suffers from Spectre. I guess Esperanto were all over their design when they learned about the generic vulnerability.
The general feeling at the meeting was RISC-V was here and has made its case. There were two Westerners sitting together way at the back arms folded, looking miserable.
Certainly it’s an uphill battle for Arm to continue asking for money - per-chip money as well as upfront - when there is a permissively-licensed solution in production by their customers' competitors. Again the main problem for RISC-V is you can go to Arm and rent almost all the related IPs that are guaranteed to play well together, including GPU, but RISC-V just has the CPU part of the puzzle.
Libero for PolarFire on Fedora 27
I wrote to SiFive while sitting in the audience to register to get a preview Unleashed board, and was added to the list. These are supposed to be coming around March, so after completing a consultancy job I thought it was time to check out the Microsemi FPGA toolchain, since installing these binary-only crapfests are usually several nightmares chained together.
Effect of free but non-Free IP on FOSS projects
I talked to Ted Speers from Microsemi during the lunch Q&A there, about a problem specific to FOSS FPGA designs, that the IPs provided with the FPGA toolchain are restrictively licensed and nonredistributable. He gave a generic “I don’t know what you are talking about but I will look into it” answer and I heard no more.
This is a serious problem when you want to provide full sources, because, eg, on the HDMI analyzer project I have written about before, it uses a source-level instantiation of the Xilinx IP DMAC as part of itself… this is free to instantiate but under a nonredistributable license. You don’t care if you are producing a proprietary product, because the source is never distributed. But this actually stops you making FOSS projects using Zynq.
I don’t hold out much hope for this with Microsemi’s toolchain because the Synopsys stuff wants to download its IPs into a “vault”. But I did not get far enough yet to find out the licensing situation for FOSS for their pieces or even what pieces they have.
Download and install
I registered and downloaded a 6.3GB (!) toolchain tarball from their website, it unpacked into two zipfiles (2 and 4 GB respectively), a Java installer and a README.
The Java app insisted I scroll down to the bottom of the license, but that was not entirely successful under openjdk…
It worked OK after that to install… it took about 15 minutes spent at 4% then 100% and done. It didn’t install any DE / GUI link to start the thing that Gnome knew, and the README that was unpacked didn’t give any clue either.
Motif library problem 1
Trying ./Libero_PolarFire_v2.0/Libero/bin/libero got me
Error: Could not locate the Motif library in LD_LIBRARY_PATH
and exit. Googling the error message found this… guys why not point to it in the README dropped by the installer?
132361-how-to-set-up-your-linux-environment-for-libero pdf
Licensing problem 1
So before looking at the immediate error, this informs me “Step 1—Download License Daemons, License File, and Set Up Licensing on License Server”… this again. It’s again (as the Lattice tools) a network-MAC locked license, free as in beer for the $0 toolchain, but not free as in blood pressure. Of course with Linux you can force your MAC to whatever, so pointless. Clearly Synopsys are to blame since they are forcing all the vendors into that madness.
The setup is really messy… you have to download a “license server daemon” for your platform. In the download are 8 binaries, no docs
$ ls -l Linux_Licensing_Daemon/
total 13944
-rwxrwxr-x. 1 agreen agreen 1190636 Sep 17 2016 actlmgrd
-rwxrwxr-x. 1 agreen agreen 1221728 Sep 17 2016 lmgrd
-rwxrwxr-x. 1 agreen agreen 1065316 Sep 17 2016 lmhostid
-rwxrwxr-x. 1 agreen agreen 1065316 Sep 17 2016 lmutil
-rwxrwxr-x. 1 agreen agreen 1203448 Apr 23 2016 mgcld
-rwxrwxr-x. 1 agreen agreen 6662892 Apr 23 2016 snpslmd
-rwxrwxr-x. 1 agreen agreen 402432 Apr 23 2016 syncad
-rwxrwxr-x. 1 agreen agreen 1448880 Apr 23 2016 synplctyd
It doesn’t say how to run them. The next step is get a license code for your MAC …which one, this laptop has both USB ethernet and WLAN… it turned out to be better than the Lattice license stuff though, since it worked with a network device named something other than eth%d.
Broken survey on Microsemi site
But the site felt it was all going too smoothly, and wanted me to fill out a mandatory survey.
Please take a moment to take a very brief 3 question survey. Upon completion, you can obtain or register for a license. Thank You. Click the button below.
An empty popup appeared when I clicked the button, Firefox reports
Attempt to set a forbidden header was denied: Connection prototype.js:683
Okay… break out Chrome, go to microsemi.com and try to login… not known. soc.microsemi.com… not known. Exact same URL as in firefox:
Back up to http://soc.microsemi.com/Portal… it will let me log in.
In Chrome the same error in their JS for the survey is seen
Refused to set unsafe header "Connection"
but it doesn’t regard it as fatal, so the survey appears. Lesson here, you can only get a license with Chrome due to bugs on their site.
In the survey, they ask what FPGA family you will use, but do not list PolarFire.
Unclear license choices, max 1 year
After the buggy survey, the following mysterious choices appear
851 - PolarFire Seminar Node Locked License for Windows PC
796 - Libero 60 days Evaluation Floating License for Windows or Linux Server
760 - Libero 60 days Evaluation Node Locked License for Windows
Free 1 Year Licenses
798 - Libero Silver 1 Year Floating License for Windows/Linux
799 - Libero Silver 1 Year Node-lock License for Windows
644 - Synopsys Synphony Model Compiler ME. Requires MATLAB/Simulink from Mathworks.
So… I could choose a 60-day license for a 1 year license? There is only one 1-year option for Linux mercifully. Then it wanted the MAC address… I pasted it in but it was truncated, the web designer had limited the input field to 12 chars, no matter that MACs are reported by all OSes with : delimiters.
Then it told me my license will arrive by email within 45 minutes. Well… the PDF says “Download the license file to the HOME directory of the user who will be installing and administering licensing for Libero” so I will try that when it comes.
Motif library problem 2
Back to the motif thing… so it turns out the 6.3GB of stuff is all 32-bit. So I assumed its problem is simply I did not have the i686 motif package installed. However… from the PDF…
Libero Linux tools expect to see the libXm.so.3 package
of the Motif Library. Different versions of OPEN
Motif could potentially install libXm.so.4 or others
that are not compatible with Libero.
…so they only support outdated libXm… on Fedora 27…
$ rpm -ql motif.i686 | grep Xm
/usr/lib/libXm.so.4
/usr/lib/libXm.so.4.0.4
Motif library workaround and libz problem
Well, sometimes actually it doesn’t really care if it doesn’t use any api that changed with the SONAME bump. So to see what happened next:
$ sudo ln -sf /usr/lib/libXm.so.4 /usr/lib/libXm.so.3
$ Libero_PolarFire_v2.0/Libero/bin/libero
/projects/polarfire/Libero_PolarFire_v2.0/Libero/bin/libero_bin: /projects/polarfire/Libero_PolarFire_v2.0/Libero/lib/libz.so.1: no version information available (required by /usr/lib/libpng16.so.16)
/projects/polarfire/Libero_PolarFire_v2.0/Libero/bin/libero_bin: /projects/polarfire/Libero_PolarFire_v2.0/Libero/lib/libz.so.1: no version information available (required by /usr/lib/libpng16.so.16)
/projects/polarfire/Libero_PolarFire_v2.0/Libero/bin/libero_bin: relocation error: /usr/lib/libpng16.so.16: symbol inflateReset2, version ZLIB_1.2.3.4 not defined in file libz.so.1 with link time reference
So in other words Fedora libpng wants to confirm the version of libz it is being bound to is the one it expects, there’s no version info in the one from this app.
libz workaround
I replaced the stock libz in the app with a symlink to F27 i686 libz, after backing it up
$ cp Libero_PolarFire_v2.0/Libero/lib/libz.so.1 .
$ ln -sf /lib/libz.so.1 Libero_PolarFire_v2.0/Libero/lib/libz.so.1
That gets me
$ Libero_PolarFire_v2.0/Libero/bin/libero
License Checkout Error: Microsemi License Error [-1,359]: Cannot locate license file.
Use LM_LICENSE_FILE to specify a different license file.
Well… that is expected. In the meanwhile the license file arrived.
License file clash
So the license is an attachment in the email called “License.dat” that should go in my home dir. But thanks to every FPGA vendor having been infected with this license madness by their upstream tools vendor, I already have a license.dat there for the Lattice tools.
I renamed it and saved the Microsemi one there. Just to make sure I tried the libero app again to see if it would pick it up, but it gives the same error. It turns out later it should actually go in ./flexlm according to the docs.
Problems with documenation outdated for license process
The PDF says “unzip License.dat”… but it is not a zip file, it is a text file in there actually as it arrived in the email. I guess at one point they sent them zipped (without a .zip suffix?)… let’s pretend that never happened.
Then you must edit this text file to put what seems to be license server coodinates at the top of it, localhost port 1702 it seems, and then really crazily must give paths to these “linux license daemon” binaries downloaded before, not one path but three, for “actlmgrd”, “mgcld”, and “snpslmd”.
Then it says “Replace the
Problems with binary license daemon loader
Next is “/home/
bash: ./Linux_Licensing_Daemon/lmgrd: No such file or directory
But it is really there.
$ file Linux_Licensing_Daemon/lmgrd
Linux_Licensing_Daemon/lmgrd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-lsb.so.3, for GNU/Linux 2.6.9, stripped
It has a nonstandard loader told in the ELF file… I forced a symlink to the normal 32-bit loader
$ sudo ln -sf /lib/ld-linux.so.2 /lib/ld-lsb.so.3
Misleading error
Now it starts and spews a load of things related to its purpose in life licensing things, which is another way to say, stopping things from working. Amongst them:
02/01/2018 13:51:50 (snpslmd) Error: Incompatible vendor daemon found.The vendor daemon <actlmgrd> is not supported in <SCL_11.11.1> version.
Error: Please upgrade to the latest SCL version. Go to http://www.synopsys.com/licensing for more information.
02/01/2018 13:51:50 (snpslmd) Error: Incompatible vendor daemon found.The vendor daemon <mgcld> is not supported in <SCL_11.11.1> version.
Error: Please upgrade to the latest SCL version. Go to http://www.synopsys.com/licensing for more information.
What this error actually means is “you did not hack these env vars in the shell you are trying to start libero from”:
$ export LM_LICENSE_FILE=1702@localhost:$LM_LICENSE_FILE
$ export SNPSLMD_LICENSE_FILE=1702@localhost:$SNPSLMD_LICENSE_FILE
Success
Finally it can start up on Fedora 27, at least as far as its “hello” page
What did we learn this time?
| Cause | Hack |
|---|---|
| openjdk incompatibility | Scroll installer license page with scrollbar, not mouse scrollwheel |
| outdated motif library | $ sudo ln -sf /usr/lib/libXm.so.4 /usr/lib/libXm.so.3 |
| weirdo libz in app incompatible with Fedora libpng |
$ cp Libero_PolarFire_v2.0/Libero/lib/libz.so.1 . $ ln -sf /lib/libz.so.1 Libero_PolarFire_v2.0/Libero/lib/libz.so.1 |
| License daemons linked against weirdo loader |
$ sudo ln -sf /lib/ld-linux.so.2 /lib/ld-lsb.so.3 |
| outdated docs | Ignore License.dat supposedly being a zip file |
| outdated docs | Ignore need to put MAC in License.dat |
| Buggy website script | Use Chrome to fetch license |