
Microchip Adds RISC-V Cores to PolarFire FPGAs - unwind
https://www.electronicsweekly.com/open-source-engineering/risc-v-day-microchip-adds-risc-v-hard-ip-polarfire-fpgas-2019-10/
======
metaphor
> _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](https://doi.org/10.1007/978-3-642-33027-8_2)

~~~
asm_
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

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

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

~~~
asm_
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.

~~~
adwn
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.

~~~
ncmncm
Is there no Free Software alternative for those devices?

~~~
adwn
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.

------
diarmuidc
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.

~~~
WillSlim95
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.

~~~
ncmncm
Attrition... Layoffs? Or exodus?

~~~
WillSlim95
Exodus. Particularly in Verification and post Silicon

------
unwind
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.

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

~~~
metaphor
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...](https://www.xilinx.com/support/documentation/data_sheets/ds083.pdf)

------
tudorw
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?

~~~
rwmj
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...](https://www.xilinx.com/products/silicon-
devices/soc/zynq-7000.html)

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)

~~~
tudorw
thank you :)

------
ncmncm
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.

