News for hackers. Stuff that matters.
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by rkagerer on Thursday May 21, 2020 @05:37PM (#23265727)
I'm disappointed today's general purpose CPU's and microcontrollers don't come with some integrated FPGA space, similar to how you have SRAM and other peripherals. Intel talked about it a few years back [1] but I'm not sure anything materialized.

The closest I've seen in popular chips is a few gates worth of programmable logic. Are there any hidden gems I've missed out on?

[1] https://www.nextplatform.com/2018/05/24/a-peek-inside-that-i...

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by londons_explore on Thursday May 21, 2020 @05:41PM (#23265767)
With the transition of compute from performance focussed to performance per watt focussed (due to cooling usually being the limiting factor), the niche for the FPGA has almost vanished.

There are very very very few compute tasks where an FPGA solves a problem with better performance per watt than both a CPU and a GPU.

I would bet that emulating a RISC-V program on x64 is far more power efficient than running a RISC-V core on an FPGA for example.

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by analognoise on Thursday May 21, 2020 @09:17PM (#23267721)
"the niche for the FPGA has almost vanished."

While Xilinx posts record quarterly profits and there are more FPGAs moved than ever before.

But go on. Enlighten us...

"There are very very very few compute tasks where an FPGA solves a problem with better performance per watt than both a CPU and a GPU."

Oh right. Let me just slap those into my satellite, radio system, aircraft control system, military system, enmbedded system... How could I have not seen the light?

"I would bet that emulating a RISC-V program on x64 is far more power efficient than running a RISC-V core on an FPGA for example." Hahahahahahaha. What size bet, chief? I need a new pair of shoes.

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by hornetblack on Thursday May 21, 2020 @10:48PM (#23268226)
Low-volume networking hardware comes to mind. Where you need very-high performace routing, but aren't shipping enough units to make up the cost of using an ASIC.

The aren't many of the them so power usage isn't a bit cost, but their performance effects the performance of many other machines, where most of the power draw is.

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by aseipp on Thursday May 21, 2020 @09:43PM (#23267873)
An ECP5 will sit on the order of ~100mW and you can clock those up to dozens of MHz. They can have multiple cores running in parallel (an ECP5 85k will fit dozens, probably well over a hundred RISC-V cores if you do your homework.) Even a laptop sitting at 10W is going to be orders of magnitude more power inefficient than this in terms of raw instructions-per-cycle-per-watt if you're emulating. That is not the best metric, necessarily, but there you go.

And since you mentioned perf-per-dollar -- ignoring soft CPUs, any deeply pipelined algorithm is very likely going to destroy price-comparable CPUs in terms of throughput e.g. you can do 16-to-32 bytes per cycle of AES on a dinky FPGA from 10 years ago for a few dollars, and at 50MHz you're doing 1.6GB/s, and people have been achieving this, or multiple times this, for 15+ years. Things like TDP are not a measure of "overall system design efficiency", it's a measure of thermal capacity, thermal budgets, and nothing more. (BTW, the only general purpose CPU that comes close to this number directly for AES is, like, Ice Lake, since VAESNI can turn out 16 bytes per cycle or whatever IIRC, but now you're well back into "multiple watts" territory on a multi-GHz CPU.) The reason people still use CPUs for these tasks isn't because they don't want better performance: it's because software has better agility and is easier to acquire and modify and distribute. You can have systems that are dozens of times more efficient than commodity ones for a wide variety of tasks, they will just be a pain in the ass to use, program, acquire, and build. You can figure out most of this with basic napkin math.

Stop thinking so much about individual components, and start thinking about global system design -- because the entire system has its own performance criteria that may vary drastically compared to an individual component within it.

> There are very very very few compute tasks where an FPGA solves a problem with better performance per watt than both a CPU and a GPU.

This is like stating "There are very few tasks where a car would do as well as a snowmobile." They aren't comparable for purpose. Hacker News is pop-culture-y so everyone thinks "the only thing that matters is a cool CPU running in a rack with a 7nm TSMC process that can run my Go application on Kubernetes that will disrupt The Market of Smart Toilets" or whatever they do day to day, and extrapolate from there. But I'd guess the vast majority (like, 85% or more) of FPGA field has literally nothing to do with this. A huge amount of work basically revolves around "just" interfacing with analog devices at pico/nanosecond level resolutions...

The quest for best perf-per-watt is one largely driven by datacenters and personal consumer electronics, which have both high volume and high yield, and where the largest challenges revolve around power, cooling, etc. Furthermore these systems run workloads that are largely general purpose "state machines" that use some memory and some CPU and some disk, etc, and need to try and hit a balance among all of these. There is a large amount of resource arbitrage going on. "A rising tide lifts all boats" in this case. But little of that applies in this field; people use older nodes and the same chips for 5-10+ years (or longer) straight because they need to deliver latency-sensitive solutions, customized hardware at low volume, "hardware glue" for various analog systems, highly specialized algorithmic solutions for the lowest total BOM cost, etc. They aren't aiming to replace the systems created by digital Silicon Valley software programmers.

There is a push to move FPGAs into the datacenter (see: Xilinx and their exploding revenue) but it's unclear if they will settle into specific niches or be used as supplementary devices or whatnot.

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by mleonhard on Friday May 22, 2020 @03:51AM (#23269646)
Your comments will be much better without the condescending tone. I point this out because I also talk down to people unintentionally. It's a difficult habit to break.
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by RL_Quine on Friday May 22, 2020 @04:23AM (#23269806)
It’s hard to get across just how out of their depth someone is without putting it fairly explicitly.
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by monocasa on Thursday May 21, 2020 @05:46PM (#23265828)
There's a lot of use cases today where perf per watt doesn't matter.
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by londons_explore on Thursday May 21, 2020 @06:18PM (#23266162)
Name some... Any task where perf per dollar matters also boils down to perf per watt, since watts cost dollars...
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by monocasa on Thursday May 21, 2020 @06:27PM (#23266248)
Say, robotics where the difference between an FPGA and something else is way overshadowed by the motors.

Or really basically anywhere that has you interacting with the real world directly connected to your compute, and not just compute off in a datacenter.

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by comex on Thursday May 21, 2020 @07:31PM (#23266892)
> Or really basically anywhere that has you interacting with the real world directly connected to your compute, and not just compute off in a datacenter.

Which, at least in mass-market applications, mostly happens on phones and other battery-powered devices. :)

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by monocasa on Thursday May 21, 2020 @07:33PM (#23266915)
Or the dozens of other devices in your house that have the benefit of mains voltage.

I don't think perf per watt was a differentiator in the compute chosen for your TV, your monitor, your AV receiver, your fridge, etc.

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by mlyle on Friday May 22, 2020 @12:49AM (#23268732)
Yes, but none of these things use significant compute.
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by monocasa on Friday May 22, 2020 @01:02AM (#23268793)
Monitors and TVs absolutely do.

And it's not unheard of for them to have FPGAs for that reason.

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by pjmlp on Friday May 22, 2020 @02:16AM (#23269157)
I guess one could consider the video hardware decoder a FPGA, although I would bet that the smart models just use a GPU in some SOC model instead.
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by ghusbands on Friday May 22, 2020 @08:43AM (#23271426)
No, there are literal FPGAs in some TVs and monitors. It happens more often on early runs on new tech. You don't need to rename something else.
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by alfalfasprout on Thursday May 21, 2020 @07:45PM (#23267001)
But many, many important applications are not mass-market.
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by alfalfasprout on Thursday May 21, 2020 @07:43PM (#23266987)
realtime systems. avionics, robots, radar processing, low latency network appliances, trading platforms...
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by anonymousDan on Thursday May 21, 2020 @06:02PM (#23265997)
I thought FPGAs were more power efficient than GPUs for many ML applications for example (CNNs aside)?
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by londons_explore on Thursday May 21, 2020 @06:20PM (#23266184)
For unusual ML architectures, like 1 bit precision, that might be true.

For anything using floating point maths, it isn't true.

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by anonymousDan on Friday May 22, 2020 @11:07AM (#23272895)
What about this paper then, section 5.1.2, energy efficiency: https://dl.acm.org/doi/10.1145/2694344.2694347

Substantial gains in terms of performance per watt for FPGAs?

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by opencl on Thursday May 21, 2020 @05:52PM (#23265888)
Not in the desktop/server space but there are a few products like this. Xilinx has the Zynq line with 1-2 Cortex-A9 cores paired to an FPGA. Microsemi has their Cortex-M3 based Smartfusion line and is supposedly launching their Polarfire SoC with 4 RISC-V cores plus an FPGA later this year.
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by analognoise on Thursday May 21, 2020 @11:38PM (#23268437)
The 1-2 Arm A9 Zynqs were introduced in 2011. There has been much progress!

MPSoCs have 4x Arm A53s and 2x Arm R5s (and Mali-400 graphics, although they're moving away from that because they found most customers don't care about that).

RFSoCs have something similar - strapped directly to tiles that do 4-6 Gbps analog/digital or digital/analog converters. If you're trying to make a badass missile front end, radio system, or radar system they're amazing!

They even have FEC hard cores that run incredibly fast. They're amazing for all kinds of waveform work.

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by throwaway4590 on Thursday May 21, 2020 @06:50PM (#23266486)
They have the patents to do even better than that and create hierarchies of miniature programmable fabric, similar to the concept of L1-L4 caches except for FPGA designs [0]. Unfortunately, they don't have the organizational willpower to do true innovation though. From what I have heard, significant portions of the designs for their processor lines are not understood by any current or recent employees. There is a tremendous amount of legacy "code" and fear of changing things that may break backwards compatibility. There is no vision at the top, their process lead is gone, and the architecture team is patching decades of bad security without simplifying designs.

It seems like they are just riding out their market share for as long as they can, which could be a while. Intel has a really strong brand.

[0] https://patents.google.com/patent/US10310868B2/

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by magicalhippo on Thursday May 21, 2020 @06:01PM (#23265986)
Well Xilinx has the Zynq-7000 SoC[1], featuring an ARM Cortex-A9 CPU along with a potentially quite large FPGA.

Not exactly cheap though, at least in small quantities[2]

[1]: https://www.xilinx.com/products/silicon-devices/soc/zynq-700...

[2]: https://www.digikey.com/products/en/integrated-circuits-ics/...

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by mhh__ on Thursday May 21, 2020 @06:20PM (#23266177)
Intel has the Cyclone V range.

Also, I've never done it myself but I've read that digikey prices are almost never the actual price for FPGAs even in relatively small quantities (haggling with avnet).

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by LargoLasskhyfv on Friday May 22, 2020 @11:50PM (#23279743)
There is another interesting path for the hobbyist, based on the Terasic DE10-nano. A group of retrocomputing enthusisasts has chosen this as their base to work upon: https://github.com/MiSTer-devel/Main_MiSTer/wiki and it even got picked up by some gaming hardware magazine, earlier this year: https://hothardware.com/reviews/mister-diy-console-fpga

While i don't care so much about the systems they emulate, and the cores they offer, this seems like a nice place to get started because of the many examples one can learn from.

Also Intel themselves offer many tutorials for it, on github and elsewhere.

And it creates an 'ecosystem' of reasonably available hardware expansions, without the usual markup for that stuff, should one need, or want them.

Would i start today, i'd use this. As it is, i've spent much more for similar stuff in the past.

I approve!

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by variaga on Thursday May 21, 2020 @07:31PM (#23266883)
Can confirm. The only time I've ever been quoted list price for an FPGA from a distributor (other than digikey) was when our purchasing agent managed to personally enrage the sales guy.

We still didn't end up _paying_ list price (after I made the purchasing guy apologize - no details, but he was 100% in the wrong).

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by l33tman on Thursday May 21, 2020 @08:41PM (#23267460)
Well, that is true for all components at digikey. You don't mass-produce stuff with components bought from DK (or avnet either, for that matter, depending on where you do your production)
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by guan on Friday May 22, 2020 @12:59PM (#23274259)
What’s a little frustrating with the Xilinx parts listed on Digi-Key, and to some extent other FPGA vendors, is the lack of any price breaks.

I looked up a random i.MX6 processor from NXP. It’s $32.08 for one of them, and $20.95 per part when you get a reel of 500. If you need a few thousand units made, it’s perfectly reasonable to order parts from Digi-Key. You might be overpaying compared to what a good purchasing person can get you, but it’s fine for a few thousand parts, and quick and easy.

Look up any Xilinx part on Digi-Key, and there’s just a single price break at 1 unit. Even Lattice parts only go up to price breaks of 100.

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by Ductapemaster on Thursday May 21, 2020 @06:39PM (#23266366)
Worked with FPGAs at a past gig, and that is correct. There is heavy markup due to the accessibility of the parts.
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by Teknoman117 on Thursday May 21, 2020 @08:34PM (#23267401)
The FPSLIC comes to mind (https://www.digikey.com/catalog/en/partgroup/fpslic/14188?mp...) and the Cypress PSoC
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by sneak on Thursday May 21, 2020 @05:40PM (#23265766)
Are there many applications that would benefit from having it on die versus across a few PCIe lanes? AFAIK putting it on a card would still grant it the same full speed DMA it would have being on-die with the CPU.
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by wmf on Thursday May 21, 2020 @05:47PM (#23265836)
The benefit from putting it on-die is not speed but economy of scale.
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by phkahler on Thursday May 21, 2020 @08:47PM (#23267501)
One possible reason is that people designing with FPGAs already have 2 options - FPGAs with on-chip processors, and using soft cores built in the FPGA.

In other words, don't get some FPGA with your micro. Get a micro with your FPGA. The later exists.

Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by rjsw on Thursday May 21, 2020 @08:04PM (#23267149)
There was a company that had an FPGA implementation of HyperTransport so that you could link the FPGA to a network of AMD Opteron CPUs.
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by LargoLasskhyfv on Saturday May 23, 2020 @12:02AM (#23279808)
https://en.wikipedia.org/wiki/Torrenza ? That got any real world use, ever?
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by pkaye on Thursday May 21, 2020 @09:25PM (#23267766)
What about the Xilinx Zynq?
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by zozbot234 on Thursday May 21, 2020 @06:35PM (#23266323)
Don't general purpose CPU's and μC's use replaceable microcode as part of the chip implementation? Shouldn't that boil down to the same thing?
Re:VexRiscv is a quadcore, Linux-capable RISC-V softcore for... by jimktrains2 on Thursday May 21, 2020 @08:09PM (#23267196)
The microcode is still controlling a microprocessor, not defining gates. It's more like microcode is the assembly language and the x86 or w/e is byte code.