Live data from Hacker News

LowRISC: Open-source RISC-V SoC

lowrisc.org

31–40 of 44 posts

Re: LowRISC: Open-source RISC-V SoC

#31
post #18

Earlier quoted context omitted.

I would attempt a nibble based compact instruction representation to reduce external memory bandwidth. Fixed width instructions kinda suck now that memory is such a bottleneck.

I've long wished of a middle ground between FPGAs and CPUs - namely a CPU with user-changable instructions. Have a CPU that is a CISC (but internally a microcoded TTA), but with a large chunk of the microcode user-writable (So you have push-inst and pop-inst, where push-inst pushes the new instruction microcode into the microcode storage and copies the old instruction microcode onto the stack and pop-inst does the op…

JITs could synth new instructions.

Re: LowRISC: Open-source RISC-V SoC

#32
post #21
post #11

Hm... the link only talks about the CPU, but calls itself a SoC. There's a lot more than needs to go on any chip that calls itself a "SoC", and much of it is very poorly served by existing "open source" solutions: + DRAM + I2C + GPIO (with stuff like 3.3v, tristate outputs, pull up/down, etc...) + USB2 host/device + SD/MMC And that's just at the very basic level. Once you get into the consumer world you need to start…

The peripherals you list span a wide range of complexity. GPIO, I2C, and SD interfaces (in approximately increasing order of complexity from my point of view) are one-person jobs for the right person. I've been in charge of all the GPIO for complex mixed-signal chips several times in the past, and I could crank these out in no time. But someone who's never designed for ESD and latchup, beyond-the-rail inputs, etc., w…

USB2 has a fairly sane external PHY specification though with lots of parts in the market. I was thinking about USB in the context of the data layer, which (to my mostly-software eyes) seems comparatively straightforward and sane.

But absent some random hackery on opencores.org, no one seems to have really put effort into doing it on an open part in a serious way.

Re: LowRISC: Open-source RISC-V SoC

#33
post #18

Earlier quoted context omitted.

I would attempt a nibble based compact instruction representation to reduce external memory bandwidth. Fixed width instructions kinda suck now that memory is such a bottleneck.

I've long wished of a middle ground between FPGAs and CPUs - namely a CPU with user-changable instructions. Have a CPU that is a CISC (but internally a microcoded TTA), but with a large chunk of the microcode user-writable (So you have push-inst and pop-inst, where push-inst pushes the new instruction microcode into the microcode storage and copies the old instruction microcode onto the stack and pop-inst does the op…

The arc processor line from Synopsys does this commercially, I believe. Risc-v seems to be trying to support this sort of thing; there is reserved opcode space for implementation specific extensions

Re: LowRISC: Open-source RISC-V SoC

#34
post #27

Earlier quoted context omitted.

> The mix of 16-bit and 32-bit instruction lengths is reminiscent of ARC. MIPS has also MIPS16..

And now microMIPS, another attempt at 16-bit encodings.

Thanks, I didn't know about microMIPS. I read about and was surprised by the LWMx(Load Word Multiple) instruction which doesn't seem in the RISC spirit at all.. That's funny, I think that ARM with its v8 ISA (64bit registers) dropped a similar instruction which it had before.

Re: LowRISC: Open-source RISC-V SoC

#35
post #33

Earlier quoted context omitted.

I've long wished of a middle ground between FPGAs and CPUs - namely a CPU with user-changable instructions. Have a CPU that is a CISC (but internally a microcoded TTA), but with a large chunk of the microcode user-writable (So you have push-inst and pop-inst, where push-inst pushes the new instruction microcode into the microcode storage and copies the old instruction microcode onto the stack and pop-inst does the op…

The arc processor line from Synopsys does this commercially, I believe. Risc-v seems to be trying to support this sort of thing; there is reserved opcode space for implementation specific extensions

I was under the impression that Synopsys' ARC processors were configurable at design time, not runtime.

Or am I missing something? Have a link?

Re: LowRISC: Open-source RISC-V SoC

#36
(Disclaimer: I'm developing my own RV64 FPGA implementation.)

I wish the page was a little more clear on what the intentions are, etc, but seeing RV64 in silicon would be immensely exciting. Producing a simple in-order machine, even with usual set of peripherals isn't very hard at all and nor that expensive on an older process node, but there's a world of difference if we start talking superscalar out-of-order multi-core SMP. Seeing OpenRISC on the Advisory Board I suspect it's more the former than the latter.

Re: LowRISC: Open-source RISC-V SoC

#37
post #8

I'm not familiar with the IP issues. Would it be possible to center open-source processor development around the ARM instruction set? It looks like the privileged part of the RISC-V ISA is not finished yet. This is a great project, but it seems a long way off.

I'm surprised they don't just use OpenRISC, there's already hardware shipping that uses ASIC implementations of that internally.

Or SPARC, which is patent and license free, open, and has a decade of shipping in real hardware to back it up.

Re: LowRISC: Open-source RISC-V SoC

#38
post #28

RISC-V looks like MIPS but with some of the more dubious design decisions of the time (e.g. branch delay slots) fixed. The mix of 16-bit and 32-bit instruction lengths is reminiscent of ARC. In other words, the characteristics of SoCs using this core will likely be very similar to the many out there using MIPS: cheap and simple, with performance that's acceptable for applications like routers and other embedded devic…

That raises an interesting point -- the original MIPS ISA hasn't been patent encumbered in quite a while (and even then, only two non-essential instructions were patent protected). Why should a person is this unknown ISA instead of MIPS?

RISC-V started off from a modified MIPS ISA, but we frankly ran out of opcode space. We needed 64b, IEEE floating point, and a ton of opcode space to explore new accelerator and vector ISA extensions.

Even the smallest changes to MIPS to clean up things like branch delay slots means it's a new ISA anyways, so you get zero benefit keeping it "mostly MIPS". You can read a bit more about this in the "history" section in the back of the user-level ISA manual.

Re: LowRISC: Open-source RISC-V SoC

#39
post #10

That hardware implementation of RISC-V listed on their website is written in Scala (using Chisel). That's very cool. I want to see synthesis results.

Hi, are you talking about the Sodor cores? I wrote those and wouldn't mind answering any questions about RISC-V or Chisel.

Regarding Sodor, they're designed to be instructional (we use them on our undergrads at Berkeley) and open for anybody with a C++ compiler so they can learn about Chisel and RISC-V. I pushed them through synthesis once just for kicks, but I didn't work on making them FPGA-ready. Chisel will give you the Verilog of the core, but you'd still need to write a test-harness that's specific to your FPGA.

The RISC-V user manual lists some of our existing RISC-V silicon implementations (8 so far, listed in Section 19.2), whose RTL aren't (yet) open-source.

Re: LowRISC: Open-source RISC-V SoC

#40
post #28

RISC-V looks like MIPS but with some of the more dubious design decisions of the time (e.g. branch delay slots) fixed. The mix of 16-bit and 32-bit instruction lengths is reminiscent of ARC. In other words, the characteristics of SoCs using this core will likely be very similar to the many out there using MIPS: cheap and simple, with performance that's acceptable for applications like routers and other embedded devic…

That raises an interesting point -- the original MIPS ISA hasn't been patent encumbered in quite a while (and even then, only two non-essential instructions were patent protected). Why should a person is this unknown ISA instead of MIPS?

I think it may be to avoid any political/legal issues - despite the patents having expired, MIPS still sells ISA licenses. On the other hand, RISC-V basically is most of MIPS (but most RISC ISAs are very similar anyway).

They also avoided the patented instruction issue completely by removing all alignment restrictions from the regular load/store; probably a good idea, with memory bandwidths being the bottleneck now and buses growing wider - the extra hardware is also negligible, basically a barrel shifter and logic to do an extra bus cycle if needed.

Post reply on HN