EEVblog Electronics Community Forum
Electronics => FPGA => Topic started by: brucehoult on December 05, 2018, 02:08:40 am
-
Details: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga (https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga)
Press gumpf: https://www.sifive.com/press/industrys-first-risc-v-soc-fpga-architecture-brings (https://www.sifive.com/press/industrys-first-risc-v-soc-fpga-architecture-brings)
-
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
-
Looks nice! It's nice to see someone stirring up the FPGA market.
-
I will wait the pricing before saying anything about this product because is doesn’t look cheap
-
I will wait the pricing before saying anything about this product because is doesn’t look cheap
Yes. 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!
-
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 (https://www.eetimes.com/document.asp?doc_id=1334032)
-
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.
-
i saw this announcement a couple of weeks ago.. didn't even know microchip got microsemi
PIC32RZ when? >:D
-
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.
NXP 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.pdf (https://github.com/open-isa-org/open-isa.org/blob/master/Reference%20Manual%20and%20Data%20Sheet/RV32M1DS_Rev.1.1.pdf)
Plus 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 Summit http://open-isa.org/order/ (http://open-isa.org/order/)
-
http://open-isa.org/order/ (http://open-isa.org/order/)
US Only :(
-
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.
-
NXP also just announced a chip (RV32M1) ... a Zero-RISCY paired with the M0+, and a RI5CY paired with the M4F.
I 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?
-
NXP also just announced a chip (RV32M1) ... a Zero-RISCY paired with the M0+, and a RI5CY paired with the M4F.
I 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?
It 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".
-
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.
And what toolchain do I need for the FPGA and, say, C for the RISC-V? Are the tools already available?
-
I 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?
As mentioned above, this is marketing, plus a good way to keep ARM license fees honest :)
If NXP have a proven RISC-V in silicon, you can see how the next license negotiations will pan out. >:D
-
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.
And what toolchain do I need for the FPGA and, say, C for the RISC-V? Are the tools already available?
There 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 to https://github.com/riscv/riscv-gnu-toolchain and follow the instructions.
There's also a lot of information at https://wiki.debian.org/RISC-V including instructions for getting pre-built toolchains.
Most recent distros should just be able to apt-get or yum or whatever by now.
-
There's some quite good information in this article
http://linuxgizmos.com/worlds-first-risc-v-based-fpga-soc-runs-linux/ (http://linuxgizmos.com/worlds-first-risc-v-based-fpga-soc-runs-linux/)
-
LTT @ SiFive HQ
https://www.youtube.com/watch?v=jNnCok1H3-g (https://www.youtube.com/watch?v=jNnCok1H3-g)
-
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 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.
-
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.
-
If you want the latest, and don't mind building things yourself (takes about 20 min on a quad core i7) then go to https://github.com/riscv/riscv-gnu-toolchain and follow the instructions.
On 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 ram :palm:
e.g. can't norm people assume that I need 64bit (>>4Gbyte) for the stack just to compile a browser :palm:
-
Porting Ada to HPPA2 has recently been a bloody experience. I really hope Ada (GNAT) will go on RISCV with less suffering.
-
So... microsemi now belongs to microchip?
(https://memegenerator.net/img/instances/61552215/i-totally-missed-something.jpg)
-
So... microsemi now belongs to microchip?
Indeed: https://www.microchip.com/investor/Pressrelease/MCHP%20to%20Acquire%20Microsemi%20Corporation.030118.pdf (https://www.microchip.com/investor/Pressrelease/MCHP%20to%20Acquire%20Microsemi%20Corporation.030118.pdf)
-
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 (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.
-
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
-
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
-
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 :D
-
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!
-
More interesting details, especially regarding (selective) deterministic execution and security.
https://www.electronicdesign.com/industrial-automation/hard-core-risc-v-cores-mate-fpga (https://www.electronicdesign.com/industrial-automation/hard-core-risc-v-cores-mate-fpga)
-
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.
-
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?).
-
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.
-
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.
-
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.)
-
Spectre
can someone summarize what Spectre consists of? and what exactly causes it?
thanks
-
Spectre and meltdown are attack/exploitation of speculative execution:
https://spectreattack.com/spectre.pdf
-
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.
-
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.
-
@brucehoult
thanks! Clear and neat explanation! I got it! :D
-
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.
-
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.