6th RISC-V Workshop Proceedings

The lowrisc project has something like that. They call them minion cores.

http://www.lowrisc.org/docs/memo-2014-001-tagged-memory-and-...

I like the idea, but unfortunately PCIe isn't easy or cheap to implement on silicon. The problem is that you'd need the PHY, which is the high speed, analog interface, and that needs to be designed and tuned for the fab and process node you're targeting. In practice the only sane way to get PCIe on your chip is to buy a PCIe IP block from Faraday or Synopsys. The same goes for SATA. Ethernet and USB on the other hand is available in discrete PHY chips, so writing some open-source controller RTL for RGMII and ULPI is much more reasonable for an open-source chip. (Obviously, if someone would cough up the money for taping out a RISC-V SoC with PCIe PHYs onboard and make it in a large enough volume that the price gets down to reasonable levels, I'd be buying a bunch of'em.)

That link is in the presentation.

Particularly they used Falcon cores for hardware video codecs, which lends itself to custom instructions if you're counting gates.

Wow, that video is a lecture by one of the leaders of RISC-V. I had no idea there was a RISC-2 and RISC-3, and that they were optimized for SmallTalk and Lisp respectively. Wonder what Alan Kay has to say about RISC-V? He's been banging on about how Intel messed up their chip design, does he approve of RISC-V? Seems like the perfect time to get things done right.

That was no-way near 15 minutes. Great talk though.

Is that because it's that hard or they bet against ARM with its style of ecosystem?

True, many are indeed using ARM (in house designs are also more popular than you might think in deeply embedded SoCs), but a lot of companies would love to be able to throw out ARM due to licensing cost & hassle, or at least have a viable option in RISC-V to throw at ARM at the bargaining table.

Intel is expensive, and not very power efficient in tiny chips. ARM is much cheaper and more efficient. RISC-V is similar to ARM, but even more cheaper.

nVidia are actively investing in RISC-V, which gives them a fairly good entry point into this market. Its a decent start.

Intel didn't really try. You know who did really try ? espressif, with their famous ESP32.

Or the startups: indie-semi, who sell mcu's built as lego's from multiple dies, affordably! which allows them to do custom-design and semi-custom design of mcu's per customer , while offering a large library of standard mcu's.

Or terechip, who built a chip packaging process who can handle dies orders of magnitude smaller than current systems - opening possibilities for far cheaper mcu's and other simple chips.

Or even ambiq-micro, which created a way to design mcu's that take ~10x(?) less power by enabling transistors to work on an extremely low supply voltage.

This is how you compete with entrenched competitors. By doing something they cannot do.

And Intel ? their fab doesn't even fit mcu's(no flash on logic processes, not good fit for analog). They had no advantage, no differentiation( maybe besides their neural network, a feature that didn't seem to attract customers). How did they expect to win ?

Not exactly true. There exist different tapeouts in academia (e.g. http://asic.ethz.ch/2016/Patronus.html or http://asic.ethz.ch/2015/Imperio.html) as well as in industry (which are not public).

They're downvoting because the entirety of your comment was a (baseless) worry about the definition of a word that would have taken seconds to check.

Well Haswell is 168 integer + 168 FP.

(EDIT: typos galore)

Thank you. Boy, this was a long time ago and I haven't written anything. I suspect it will be obvious for anyone skilled in the act, but I had to go look at my code at bit to remember some of this.

First a quick word from the POV of a compiler: the register windows are supposed to make function call easier and I suppose it works as designed for hand written code, but it actually adds a lot of complexity to indirect call/virtual functions and is a disaster for anything that switches stack (context switches, coroutines, etc). Another problem is the immediate fields which are just 8-bit unsigned, very often too small. And in practical terms, the GCC port really struggles to make good code for MMIX. Try it!

From the implementation POV: even ignoring the resource requirement for the full MMIX (which besides 256 registers includes a LOT of functionality), it's hard to pipeline as MMIX actually have fairly complicated semantics; just look at the state machine, the S_XXX symbols in https://github.com/tommythorn/fpgammix/blob/master/rtl/core.... While you can obviously deal with that (as witnessed by x86), it requires you to speculate a lot (for starters, speculate that you didn't get an interrupt). All speculation add complication as you need to recover from mis-speculation. This in term hurts cycle time by making stages more complicated and is a MAJOR source of verification work (AKA bugs).

My implementation is nearly completely un-pipelined, very similar to a simple interpreter but in Verilog. Once I had enough functionality that I could look back and consider a more realistic implementation, I really lost the enthusiasm and instead focused on MIPS which is dramatically more efficient and easier to implement (pesky branch delay-slot not withstanding). Of course, later a friend leaked word of nascent RISC-V and the world was forever different.

I actually asked Don directly why he hadn't gone with something like MIPS, but he answered vaguely that he wanted something for education.

On the positive side, I found a bug and scored a $2.56 check (real dollars) and a couple of MMIX T-shirts :)