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…
LowRISC: Open-source RISC-V SoC
31–40 of 44 posts
Re: LowRISC: Open-source RISC-V SoC
#32Hm... 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…
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
#33Earlier 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…
Re: LowRISC: Open-source RISC-V SoC
#34Earlier 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.
Re: LowRISC: Open-source RISC-V SoC
#35Earlier 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
Or am I missing something? Have a link?
Re: LowRISC: Open-source RISC-V SoC
#36I 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
#37I'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.
Re: LowRISC: Open-source RISC-V SoC
#38RISC-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?
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
#39That 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.
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
#40RISC-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?
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.