Microchip Adds RISC-V Cores to PolarFire FPGAs | Hacker News Reader

Microchip Adds RISC-V Cores to PolarFire FPGAs

electronicsweekly.com

82 pointsunwind20 comments

> From existing PolarFire FPGAs, Risc-V versions are inheriting security functions including: DPA-resistant bit-stream programming, anti-tamper, a cryptographical bound supply chain assurance, a physically un-clonable function, a true random number generator and a side-channel resistant crypto-coprocessor.

> In addition according to Microchip the processors will have secure boot (128kbyte boot flash), physical memory protection and, on all memories: single-bit error correction and double-bit error detection. THe firm is also claiming Spectre and Meltdown immunity.

With all this buzzword bingo, you'd think the company formerly known as Actel was actively marketing to a defense industry with selective amnesia[1].

[1] https://doi.org/10.1007/978-3-642-33027-8_2

Microsemi is the company formerly known as Actel. Microchip is the company that makes (amongst other things) PICs and bought Atmel (AVRs etc)

edit: I see the article is the one in the wrong - it should have said Microsemi

The article isn't wrong; you're acquisition history is simply miscalibrated.

PolarFire is the operand signal...everything else is in the noise.

Ah yes - I missed an extra acquisition! Microchip acquired Microsemi (who acquired Actel)!

They are gobbling up everything now. FWIW - I quite like the Actel/Microsemi/Microchip FPGAs. Their ProASICs and Igloos have been solid for me.

Their software is utter crap, though – even by the standards of the EDA industry. Some of their tools (I'm looking at you, designer) are so old and unmaintained, that they still show the Actel logo.

Is there no Free Software alternative for those devices?

No. Unlike mainstream CPUs, for which sufficient information is publicly available to develop competitive compilers, FPGAs are closed systems. There is enough documentation to write the synthesis and map steps (which compile VHDL/Verilog/whatever to an architecture dependent netlist) and for the place step (which assigns instances from the netlist to blocks on the FPGA device). For the remaining steps (routing, static timing analysis, and bitstream generation), hardly any required documentation is available.

For a couple of small, outdated FPGAs, some of that information has been reverse-engineered and used for open source software, but I don't know how reliable, e.g., their static timing analysis is. I would never, ever use that for a non-hobby project.

Interesting move by Microchip. The previous generation of FPGA had two variants. Igloo2 and SmartFusion2. The latter had an ARM hard macro. When they announced PolarFire, the ARM was gone and no indication of it coming back. That was a surprise to some of us SF2 users. However they very soon started to promote RISC-V as a softcore. The hardcore followup is a natural progression.

I was an employee there till 2018. The pivot to RISC V was made sometime late in Dec 2016. However thanks to high attrition due to Microchip acquisiton , this has been delayed quite a bit.

Attrition... Layoffs? Or exodus?

Exodus. Particularly in Verification and post Silicon

It was already announced at the RISC-V summit in Santa Clara, December 2018.

I couldn't quite tell if the cache was turned off permanently or it is a configuration option.

Not sure if products are available yet or if this is just based on the announcement of an upcoming product.

I thought it was interesting since it's RISC-V in hardware from a classic/respected/well-established US-based company, which is not so common yet. Also it's "real" CPU cores even though they share a SoC with FPGA circuitry; this is not RISC-V cores being implemented on the FPGA fabric.

It's really "cores" and not "core", too: the SoC features one RV64IMAC core for monitoring (and probably hard real-time tasks) and a quad-core RV64GC for general computing/applications I guess. It uses DDR4 memory so it's quite beefy for an embedded target.

It’s an announcement of PolarFire SoC: https://www.microsemi.com/product-directory/soc-fpgas/5498-p...

Currently the processors are implemented as soft cores. One can start writing code, real processors will be available later.

Also interesting when speaking of real CPU core with attached FPGA, see the SmartFusion2. However, it is ARM-based CPU.

FPGA-based heterogenous compute has been around since at least early 2000s on Xilinx Virtex-II Pro[1] with PowerPC hard IP blocks.

[1] https://www.xilinx.com/support/documentation/data_sheets/ds0...

It's a subject I know very little about, would anyone care to enlighten me on some good use cases for this kind of hardware?

It's quite common to pair FPGAs with ARM processors. Xilinx Zynq (for example, there are many others) places a Cortex A-9 alongside Artix-7 FPGA fabric. In a sense Microchip are simply doing the same thing except with higher end cores and without paying ARM.

The use for this is simply where you need to couple some hardware bits with some software to control it, and you don't want to have a separate host computer (or your host computer is doing something else!). A simple example might be an experimental music synthesizer: You could generate sound envelopes "in hardware" (in the FPGA) because that requires tight timing and IO wired to the DAC, but control the notes and the song from the processor in software, because writing that in C or Python is way easier. The Zynq product page here has a few example applications: https://www.xilinx.com/products/silicon-devices/soc/zynq-700...

One use case I've actually seen is somewhat ironic: They were prototyping a RISC-V core on the FPGA fabric, and using the ARM core in the FPGA to serve memory and I/O cycles to the RISC-V core. (For this to make sense you have to know that prototyped FPGA cores run really slowly, eg. 50 MHz or less, so even a low-end ARM core can easily keep up)

thank you :)

It's tragic that the "B" Bitmanip extension isn't ready yet for crystallization into the custom hardware on these devices. I suppose one could implement the specific ops needed in the FPGA part of the device, but that's clumsy.

Reply on news.ycombinator.com