Microchip announces PolarFireSOC FPGA with penta core RISC-V - Page 1
Forum section: electronics / general

author: brucehoult
author_rank: Super Contributor
timestamp: December 05, 2018, 02:08:40 am
content: Details:https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpgaPress gumpf:https://www.sifive.com/press/industrys-first-risc-v-soc-fpga-architecture-brings

author: brucehoult
author_rank: Super Contributor
timestamp: December 05, 2018, 02:54:15 am
content: Found the Microchip/MicroSemi press release now:https://investor.microsemi.com/2018-12-04-Industrys-First-RISC-V-SoC-FPGA-Architecture-Brings-Real-Time-to-Linux-Giving-Developers-the-Freedom-to-Innovate-in-Low-Power-Secure-and-Reliable-Designs

author: daqq
author_rank: Super Contributor
timestamp: December 05, 2018, 07:00:41 am
content: Looks nice! It's nice to see someone stirring up the FPGA market.

author: filssavi
author_rank: Frequent Contributor
timestamp: December 05, 2018, 07:14:32 am
content: I will wait the pricing before saying anything about this product because is doesn’t look cheap

author: brucehoult
author_rank: Super Contributor
timestamp: December 05, 2018, 08:07:42 am
content: Quote from: filssavi on December 05, 2018, 07:14:32 amYes. I have no idea on pricing. I *hope* it will be competitive with Zynq, but who knows?They also don't seem to have said anything about MHz. The FU-540 coreplex runs at up to 1.5 GHz in 28nm on the HiFive Unleashed, but it may be quite different in an FPGA-compatible process.I guess you could think of the HiFive Unleashed plus MicroSemi HiFive Unleashed Expansion board (which is based on a PolarFire FPGA) as a kind of prototype for this, but we're going to need to see prices a lot lower than the $1k plus $2k for that combination!

author: brucehoult
author_rank: Super Contributor
timestamp: December 05, 2018, 12:14:16 pm
content: Looks like it's going to be a while before these are available."The Microsemi division of Microchip will describe a five-core complex that it will embed in its PolarFire FPGAs by early 2020. The chip marks its first step in a plan to standardize on use of RISC-V."https://www.eetimes.com/document.asp?doc_id=1334032

author: coppice
author_rank: Super Contributor
timestamp: December 05, 2018, 12:53:19 pm
content: I think we'll believe it when we see it, but its interesting to see even an early announcement of work in progress with a RISC-V core by one of the mainstream silicon vendors.

author: JPortici
author_rank: Super Contributor
timestamp: December 05, 2018, 02:17:56 pm
content: i saw this announcement a couple of weeks ago.. didn't even know microchip got microsemiPIC32RZ when?

author: brucehoult
author_rank: Super Contributor
timestamp: December 05, 2018, 03:18:46 pm
content: Quote from: coppice on December 05, 2018, 12:53:19 pmNXP also just announced a chip (RV32M1) with a Cortex M0+, an M4F, and two RISC-V cores from the PULP project at ETH Zurich: a Zero-RISCY paired with the M0+, and a RI5CY paired with the M4F. It also has a ton of peripherals including Bluetooth LE 5.0, USB 2.0, uSDHC, RTC, ADC, CRC/AES/DES/SHA/RSA/ECC accelerator.https://github.com/open-isa-org/open-isa.org/blob/master/Reference%20Manual%20and%20Data%20Sheet/RV32M1DS_Rev.1.1.pdfPlus there is a board with this chip that you can order for free (as far as I can tell NXP themselves are absorbing the cost), and they were giving away a lot of them today at the RISC-V Summithttp://open-isa.org/order/

author: JPortici
author_rank: Super Contributor
timestamp: December 05, 2018, 03:37:58 pm
content: Quote from: brucehoult on December 05, 2018, 03:18:46 pmUS Only

author: kfnight
author_rank: Regular Contributor
timestamp: December 05, 2018, 06:17:03 pm
content: The cheapskate in me wants to pick one up. Who doesn't like free stuff? But I'm not sure what I'd use it for.

author: westfw
author_rank: Super Contributor
timestamp: December 05, 2018, 10:16:59 pm
content: QuoteI don't quite understand what that is supposed to accomplish - aren't the ARM and RISCV CPUs sort-of similar in capabilities? Why pair them together?

author: coppice
author_rank: Super Contributor
timestamp: December 05, 2018, 10:20:21 pm
content: Quote from: westfw on December 05, 2018, 10:16:59 pmIt sounds like a device just to test the waters, and gauge the reaction. Also, when some ideologue idiot says "does it us an ARM core" the honest answer is "yes".

author: rstofer
author_rank: Super Contributor
timestamp: December 06, 2018, 12:57:11 am
content: Quote from: kfnight on December 05, 2018, 06:17:03 pmAnd what toolchain do I need for the FPGA and, say, C for the RISC-V? Are the tools already available?

author: PCB.Wiz
author_rank: Super Contributor
timestamp: December 06, 2018, 01:10:57 am
content: Quote from: westfw on December 05, 2018, 10:16:59 pmAs mentioned above, this is marketing, plus a good way to keep ARM license fees honestIf NXP have a proven RISC-V in silicon, you can see how the next license negotiations will pan out.

author: brucehoult
author_rank: Super Contributor
timestamp: December 06, 2018, 02:54:54 am
content: Quote from: rstofer on December 06, 2018, 12:57:11 amThere has been RISC-V gcc and so forth for a few years already, and it all got upstreamed into standard binutils, gcc, glibc, newlib about a year ago, though improvements are still being made rapidly.If you want the latest, and don't mind building things yourself (takes about 20 min on a quad core i7) then go tohttps://github.com/riscv/riscv-gnu-toolchainand follow the instructions.There's also a lot of information athttps://wiki.debian.org/RISC-Vincluding instructions for getting pre-built toolchains.Most recent distros should just be able to apt-get or yum or whatever by now.

author: brucehoult
author_rank: Super Contributor
timestamp: December 06, 2018, 03:41:04 am
content: There's some quite good information in this articlehttp://linuxgizmos.com/worlds-first-risc-v-based-fpga-soc-runs-linux/

author: oPossum
author_rank: Super Contributor
timestamp: December 06, 2018, 06:30:33 am
content: LTT @ SiFive HQ

author: brucehoult
author_rank: Super Contributor
timestamp: December 06, 2018, 08:36:17 am
content: Slightly off the thread, but Qualcomm announced today at the RISC-V Summit that they'll be shipping a "high performance" RISC-V device in 2019.

author: ezalys
author_rank: Frequent Contributor
timestamp: December 06, 2018, 03:10:32 pm
content: I feel like higher end chips are named by spinning two big jeopardy style wheels with names on them. One says "Polar" "Cold" "Dragon" and the next "Fire", etc. "Dragonball" "Coldfire" "polarfire." Really cool.

author: legacy
author_rank: Super Contributor
timestamp: December 06, 2018, 03:57:30 pm
content: Quote from: rstofer on December 06, 2018, 12:57:11 amNo commercial tools, unfortunately. Only GNU GCC and LLVM.

author: legacy
author_rank: Super Contributor
timestamp: December 06, 2018, 04:11:44 pm
content: Quote from: brucehoult on December 06, 2018, 02:54:54 amOn DTB we have just created a special "catalyst" for this; on Host=HPPA2, Target=RISCV, where HPPA2=C8900,4cores@1.1Ghz, it took 6 days 24h/24 to build all this stuff from stage1 to stage4.Given a bootstrapper (which is the real problem when you are not on x86 host), a GCC-toolchain can be (re)built in 1 day.That's funny since our Arise-v2 HL compiler compiles and builds in just 10 minutes on the same machine. Ok, it's not a C compiler, and it's not GCC, but hey? 10 minutes makes people nice and very happy!GCC is definitively a bloated amount of code, and GNU/BSD/whatever is used for the userland of our Linux and BSD systems is no different: excessively bloated due to the bad assumption that people have Ghz computing power, with hundreds of cores, and Terabyte of rame.g. can't norm people assume that I need 64bit (>>4Gbyte) for the stack just to compile a browser

author: legacy
author_rank: Super Contributor
timestamp: December 06, 2018, 04:15:02 pm
content: Porting Ada to HPPA2 has recently been a bloody experience. I really hope Ada (GNAT) will go on RISCV with less suffering.

author: Ice-Tea
author_rank: Super Contributor
timestamp: December 06, 2018, 04:17:31 pm
content: So... microsemi now belongs to microchip?

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 06, 2018, 04:38:16 pm
content: Quote from: Ice-Tea on December 06, 2018, 04:17:31 pmIndeed:https://www.microchip.com/investor/Pressrelease/MCHP%20to%20Acquire%20Microsemi%20Corporation.030118.pdf

author: brucehoult
author_rank: Super Contributor
timestamp: December 06, 2018, 07:31:34 pm
content: Quote from: legacy on December 06, 2018, 03:57:30 pmIAR is on it's way. Earlier in the year they were saying beta by the end of 2018, now they're saying delivery mid-2019. Well .. those are not mutually exclusive.https://www.sifive.com/press/iar-systems-and-sifive-partner-to-meet-customers-demands"IAR Embedded Workbench® for RISC-V will be available mid-2019. The toolchain will offer leading code quality, size and speed as well as extensive debug functionality with a fully integrated debugger with simulator and hardware debugging support. The significant development milestones will be showcased at the SiFive booth (#202) at the RISC-V Summit on December 4th and 5th."So I guess it's working, even if not quite ready to ship.

author: brucehoult
author_rank: Super Contributor
timestamp: December 06, 2018, 07:35:42 pm
content: Quote from: legacy on December 06, 2018, 04:15:02 pmSomeone did that back in mid-2017. It looks like it's even easy now:https://blog.adacore.com/ada-on-the-first-risc-v-microcontroller

author: brucehoult
author_rank: Super Contributor
timestamp: December 06, 2018, 07:43:27 pm
content: Quote from: brucehoult on December 06, 2018, 08:36:17 amI saw speculation on twitter that what Qualcomm is referring to might be a helper core inside the Snapdragon 855:https://twitter.com/jangray/status/1070695117504180225

author: legacy
author_rank: Super Contributor
timestamp: December 06, 2018, 08:54:53 pm
content: Quote from: brucehoult on December 06, 2018, 07:31:34 pmexcellent news

author: westfw
author_rank: Super Contributor
timestamp: December 06, 2018, 10:28:52 pm
content: QuoteIndeed++ - it's the subject of half-a-dozen shareholder class-action lawsuits, because apparently Microsemi's financials weren't in nearly as good a shape as they looked:QuoteNot that there aren't lawfirms that will jump on any change in stock price or admission of mistakes, but... the sheer number of separate firms involved is pretty impressive...And (But?) also !!:QuoteExciting times!

author: brucehoult
author_rank: Super Contributor
timestamp: December 07, 2018, 01:02:46 am
content: More interesting details, especially regarding (selective) deterministic execution and security.https://www.electronicdesign.com/industrial-automation/hard-core-risc-v-cores-mate-fpga

author: NorthGuy
author_rank: Super Contributor
timestamp: December 07, 2018, 03:47:37 am
content: Very strange design. I would expect that the FPGA core would provide any realtimelyness you can possibly want, while the CPU cores would provide fast parallel data processing. But for some reason the key design feature is the ability to put (some of) the CPUs into deterministic mode running entirely from cache.

author: brucehoult
author_rank: Super Contributor
timestamp: December 07, 2018, 04:19:45 am
content: Yes, I don't know how many people will want or need the determinism off turning off the branch predictor (at the expense of speed, obviously). It seems to be a popular feature of cores at the Cortex M0 and SiFive E20 level. Certainly it's very cheap to provide, and there are plenty of other cores available here still able to run at full speed.Locking part of the cache to provide scratchpad is of course a standard feature -- ARM has had it since at least the ARM940T in 1998 (was that their first chip with cache?).

author: NorthGuy
author_rank: Super Contributor
timestamp: December 07, 2018, 05:30:03 am
content: Quote from: brucehoult on December 07, 2018, 04:19:45 amIt makes sense if you have a single CPU. If you want to use bit-bang something you need predictable instruction times. Or if you want to meet tight timing, it's better to work with something deterministic.But FPGA is much better for bit-banging - you can read/generate quite complex signals with relatively small amount of logic.Will be interesting to see more details when the datasheets comes out. Hopefully, Microchip will eventually destroy the existing Microsemi system of restricted access to the documentation.

author: mac.6
author_rank: Regular Contributor
timestamp: December 07, 2018, 02:30:42 pm
content: You want determinism if you want security (ie no data leak ala Spectre). This is where risc-v shines as you can't do very much when integrating arm core that can't be modified.Security is the "next big thing" for some market, like automotive.

author: Bassman59
author_rank: Super Contributor
timestamp: December 07, 2018, 04:43:33 pm
content: Quote from: NorthGuy on December 07, 2018, 05:30:03 amHaving done enough designs that have both an FPGA and a processor, it all comes down to: what is best done in the FPGA and what is best done in the processor? Datapath from a sensor to multichannel ADCs through some sample-rate signal processing and out to a high-speed datapipe, as well as controller/sequencer logic for that sensor, are all best done in the FPGA fabric. Command parsing, system control (setting bias DACs, configuring other stuff, storing configurations) are much more easily done using a sequential-execution processor.Sure, you can write a command parser in VHDL and implement it in hardware. Sure, you can do your signal processing in a processor (that's fast enough). But gluing a standalone Cortex M3 to a smaller FPGA might just be the ticket. Hey, you need more SPI masters than your processor has? Implement them in the FPGA! This is engineering, you need to do the work to figure out which is "better" for your application.Is everyone who uses SoCs working with severe space constraints, so the processor and the FPGA need to be in the same PCB footprint?QuoteI haven't had much issue with restricted documentation ... i just signed up for the Microsemi website portal (hell, back when they were still Actel) and I guess I don't notice it. But their software licensing is bonkers and their tech-support sucks. I hope that Microchip can fix all of that. (Not holding my breath.)

author: legacy
author_rank: Super Contributor
timestamp: December 07, 2018, 05:35:42 pm
content: Quote from: mac.6 on December 07, 2018, 02:30:42 pmcan someone summarize what Spectre consists of? and what exactly causes it?thanks

author: mac.6
author_rank: Regular Contributor
timestamp: December 07, 2018, 08:42:35 pm
content: Spectre and meltdown are attack/exploitation of speculative execution:https://spectreattack.com/spectre.pdf

author: brucehoult
author_rank: Super Contributor
timestamp: December 08, 2018, 01:38:39 am
content: Quote from: legacy on December 07, 2018, 05:35:42 pmIt's simple. These problems are caused by speculative execution (for example, predicting the outcome of a conditional branch) that turns out to be incorrect AND THEN not 100% reversing changes made by the instructions that shouldn't have been executed.Obviously every CPU with branch prediction will correctly undo things such as changes to CPU registers or stores to memory. If they didn't then nothing would ever work.But there are more subtle things. For example if a load instruction is killed, it might have already caused a cache miss, and loaded that data into the cache, displacing some other data from the cache. If you carefully pre-load the cache with known data then run a load instruction after a branch, you can detect afterwards whether the branch was mispredicted by checking how long it takes to load data items that you know were in the cache.Similar things happen for branch predictors. A conditional branch that is itself speculatively executed might update the branch prediction flags for that branch, even if the branch itself ends up being undone.It's actually not very difficult to eliminate these things, using exactly the same kinds of techniques that are used for updating memory and registers: things like store queues or reorder buffers that don't update the real resource until the instruction is no longer speculative, and that are thrown away in the event of a misprediction. It's pretty easy and cheap to do this for loads into the cache, updated to branch predictors etc, with little or no performance penalty -- mostly it's just a small amount extra circuitry and so area&power, and maybe a couple of extra gate delays. I doubt whether it's even a 1% hit.The only hard thing is realising that you SHOULD do that.Preferably *before* you ship billions of processors where you didn't do that, like Intel and ARM have.That's where RISC-V has an opportunity. There is nothing inherent about RISC-V, it just happens to be lucky timing that no one shipped a RISC-V processor with speculative execution before designers became aware of Spectre and Meltdown. (BOOM doesn't count, since no one except Chris Celio has ever used it)Note: branch prediction by itself doesn't cause problems in an in-order processor because although incorrect instructions get fetched and decoded, they don't get to the execution or writeback pipe stage before the branch misprediction is discovered.

author: OwO
author_rank: Super Contributor
timestamp: December 08, 2018, 03:21:05 am
content: Quote from: Bassman59 on December 07, 2018, 04:43:33 pmThe number one reason to use an FPGA SoC is the high speed interconnect between the processor and fabric. You can easily implement accelerators (e.g. for DSP) that directly operate on data in DRAM. Plus the AXI memory mapped interface is a much nicer and cleaner way to implement a peripheral than designing your own SPI protocol. You also immediately have access to a large amount of memory from the FPGA side (otherwise you would have to waste resources on a DRAM controller or use more expensive SRAM). I've had many applications that call for both an FPGA and a MCU to coordinate things, and every time separate FPGA/MCU was ruled out because the SoC approach just simply gives you a far less messy design.

author: legacy
author_rank: Super Contributor
timestamp: December 08, 2018, 12:24:24 pm
content: @brucehoultthanks! Clear and neat explanation! I got it!

author: nctnico
author_rank: Super Contributor
timestamp: December 09, 2018, 04:07:28 pm
content: Quote from: OwO on December 08, 2018, 03:21:05 amYou can mitigate a lot of this by using PCIexpress between the processor and the FPGA. This should allow the FPGA and processor to push data into eachother's memories.

author: Bassman59
author_rank: Super Contributor
timestamp: December 09, 2018, 06:22:54 pm
content: Quote from: OwO on December 08, 2018, 03:21:05 amThat all assumes that you need a high-speed (and the definition of "high speed" is, of course, application-dependent) interconnect between the FPGA and the processor. The system design has to balance this all. What does the FPGA do, what does the processor do, how separate are these functions? For many applications, yes, the SoC is the answer. For many other applications, it's not. And for many applications, embedding a simple processor in the FPGA fabric is a good idea.