Microchip announces PolarFireSOC FPGA with penta core RISC-V

[brucehoult]

And what toolchain do I need for the FPGA and, say, C for the RISC-V?  Are the tools already available?

No commercial tools, unfortunately. Only GNU GCC and LLVM.

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

[brucehoult]

Porting Ada to HPPA2 has recently been a bloody experience. I really hope Ada (GNAT) will go on RISCV with less suffering.

Someone 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

[brucehoult]

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.

I 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

[legacy]

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

excellent news 

[westfw]

So... microsemi now belongs to microchip?

Indeed++ - 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:

On August 9, 2018, Microchip announced its financial and operating results for the fiscal quarter ended June 30, 2018. During a conference call following the Company's earnings announcement, Microchip's Chief Executive Officer ("CFO") acknowledged that the Company's due diligence on Microsemi prior to the acquisition had been inadequate, and that much of Microsemi's revenues reported prior to the merger were not supported by end-user demand, but rather were the result of excess distribution into the channel. Additionally, Microchip's CEO disclosed that "while excessive shipments into distribution and contract manufacturers has been the main issue at Microsemi, we also found a culture of excessive extravagance and high spending.
"Following these disclosures,shares of Microchip's common stock fell $10.67 per share, or over 10.8%, to close on August 10, 2018 at $87.41 per share.

Not 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 !!:

Ousted Microsemi Corp. Chief Executive James Peterson and three of his former executives are suing Microchip Technology Inc. and its executives for alleged slander, libel and unfair business practices.
   :The suit alleges that Sanghi blamed Microsemi executives for Microchip’s underperformance after the sale, and that Sanghi fabricated claims that Microsemi was performing poorly leading up to and after the sale.

Exciting times!

[brucehoult]

More interesting details, especially regarding (selective) deterministic execution and security.

https://www.electronicdesign.com/industrial-automation/hard-core-risc-v-cores-mate-fpga

[NorthGuy]

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.

[brucehoult]

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?).

[NorthGuy]

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.

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

[mac.6]

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.

[Bassman59]

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.

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

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

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.

I 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.)

[legacy]

Spectre

can someone summarize what Spectre consists of? and what exactly causes it?
thanks

[mac.6]

Spectre and meltdown are attack/exploitation of speculative execution:

https://spectreattack.com/spectre.pdf

[brucehoult]

Spectre

can someone summarize what Spectre consists of? and what exactly causes it?
thanks

It'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.

[OwO]

Is everyone who uses SoCs working with severe space constraints, so the processor and the FPGA need to be in the same PCB footprint?

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

[legacy]

@brucehoult
thanks! Clear and neat explanation! I got it! 

[nctnico]

Is everyone who uses SoCs working with severe space constraints, so the processor and the FPGA need to be in the same PCB footprint?

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

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

[Bassman59]

Is everyone who uses SoCs working with severe space constraints, so the processor and the FPGA need to be in the same PCB footprint?

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

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