[xja]

RISC-V really seems to be gaining momentum with 2 crowdfunded silicon implementations currently seeking funding:

https://www.crowdsupply.com/onchip/open-v

https://www.crowdsupply.com/sifive/hifive1

Looking forward to a future where CPUs that are open hardware, from the transistor up are generally available.

[jordskott]

I have some reservations towards Open-V, I would be careful before backing it:

https://www.reddit.com/r/linux/comments/5ekuck/openv_the_wor...

https://www.reddit.com/r/cpudesign/comments/5eep88/the_world...

[e19293001]

I agree with what was said from your links. The code was poorly written but that does not mean that this can't be improved once they get an active community. Sadly, right now they are inactive and I don't know why.

[TD-Linux]

I think the complaints about peripheral source are valid, but they have had it running on silicon for months, so the answer to "will it work" is pretty clear.

[jokr004]

"First of all, it is just a simple microcontroller and the implemented RISC-V instructions are not that significant for the purpose. It's like expecting the SIM cards used in mobile phones to be equivalent to PCs because they run "Java"."

Who is calling this a PC? OpenV seems to be marketing itself as a microcontroller, it keeps comparing itself to Arduino.

[bostand]

These are very valid concerns.

I should also add that the "boring" mips is right now significantly more open than riscv, more mature and easier to get hold of.

[Narishma]

His concerns are with OpenV, not RISC-V.

[e19293001]

I was interested to be an active contributor for open-v but this project turned out to be like a school project. Tried to clone the mriscvcore and created my own testbench for the code then found out to have a simple critical bug on the handshake signals for read and write ports[0]. I don't know what is really happening to the authors but they seem to be inactive for a long time which is so disappointing.

I am still searching for an active RISC-V verilog implementation project for me to contribute through design and verification. For those who are looking for contributors you may want to drop me an email: my username at gmail dot com.

[0] - https://github.com/onchipuis/mriscvcore/issues/3

[aseipp]

Why not picorv32? Size-optimized, open licensed (no 64-bit, but that's where you could come in and be a star!) Clifford Wolf, the author, also wrote Yosys and Icestorm, which you can use to synthesize picorv32 for the iCE40 FPGAs with a fully open source HDL toolchain. It's really nice and usable!

Clifford has also been doing a lot of cool work adding SMT-based verification tech for synthesis via Yosys, and even started working on a verification bench for RISC-V implementations: https://github.com/cliffordwolf/riscv-formal - he's also very nice and approachable IMO. I'm sure he'd appreciate some extra help.

Sounds like exactly what you want, perhaps.

[xkarga00]

You may want to check out lowRISC.

http://www.lowrisc.org/

https://github.com/lowRISC

[ajross]

Pedantry: but RISC-V is open hardware only from the logic level up.

The "transistor" level would require open source silicon layout software, and probably some level of NDA relaxation on the part of the fabs who surely won't allow a production mask set on their modern[1] processes to be released to the public. I don't see that happening any time soon.

[1] Mature/legacy processes actually do have public design rules available. The MOSIS "scalable CMOS" rules apparently work for real devices at the 180nm node or thereabouts.

[skissane]

I wonder, if the logic level was copyrighted under a sharealike license such as GPL, and the mask is a derivative work, does that make the mask subject to the sharealike license too? (I know that there exist "mask work rights" as a separate legal category from copyrights, but I'm not sure how a mask work right would interact with a sharealike copyright license...)

[ajross]

My informed amateur opinion is that no one really knows. There's no case law on this that I'm aware of.

Basically: the "shape of a transistor" (and highly tuned structures like SRAM & flash cells, etc...) in modern logic processes is itself a tightly guarded secret. Outside some crappy electron microcroscopy done by people like Chipworks and the much-prettier-but-really-spun pictures released by the fab's marketing departments, no one involved in the process releases anything.

Now, maybe that's because it's that the masks are ultimately copyrighted by the fab and protected. Or maybe if they leaked they'd be perfectly fine. But what really happens in practice is that before the fab will consent to make your chips for you, they force you to sign an elaborate NDA with no doubt huge contractual penalties.

Again, I don't expect this to change. Silicon fabrication at the mask level will not be open source any time soon, though maybe there's hope that open source tooling might arrive. We just won't be able to see its output.

[BuuQu9hu]

Hardware isn't subject to copyright. There are places in China that can reverse engineer boards from hardware back to design files, so GPLing board designs is pretty pointless.

There are patents, but they don't protect designs or individual physical items, just processes.

There is IC mask protection, but that doesn't protect modified versions of the IC masks (if I understand it correctly):

https://en.wikipedia.org/wiki/Integrated_circuit_layout_desi...

[d33]

Wait, so this is mostly a microcontroller chip, right? I keep hearing about its applications in smartphones, but I kind of doubt it could make it @ 160mhz... not to mention PCs.

Am I getting something wrong?

[NonEUCitizen]

It's an instruction set architecture with different extensions, a "family" if you would. Just like ARM has 32-bit Cortex M0..M4 microcontrollers, as well as ARM64 with MMU and the works.

These RISC-V silicon implementations on CrowdSupply are on the low end, RV32I (32-bits, integer-only). The SiFive one supports M (multiply) A (atomic) C (compressed, like Thumb for ARM) extensions. No, you cannot build a smartphone with these.

But there are other implementations. An example high-end implementation, 64-bits (you cannot buy silicon yet, but maybe you can burn your own FPGA) is BOOM:

  https://github.com/ucb-bar/riscv-boom

[gchadwick]

Part of the problem is to produce a high-end RISC-V chip doesn't just need the RISC-V core. It needs all of the supporting IP as well which can be substantial (interconnect, system caches, memory controllers, peripherals etc). Plus to produce something that can complete with modern mobile APs you'll need to fab on a modern process (e.g. 28 or 20nm, though that's a bit long in the tooth if you're targetting things coming out rather than matching current technology, 16FF would be better) which increases costs substantially. Simple, slow, microcontrollers can be fabbed on older and far cheaper processes.

[bogomipz]

">16FF would be better"

Did you mean 16NM or are you referring to something else other than process size?

[rrmm]

FF is probably FinFet here. e.g. http://www.tsmc.com/english/dedicatedFoundry/technology/16nm...

[gchadwick]

rrmm is correct. 16FF is generally used to mean the 16nm FinFet process.

[bogomipz]

Ah OK I am glad I asked thanks then, thanks for link too.

[aseipp]

> but I kind of doubt it could make it @ 160mhz...

The second chip in those links is a Arduino-compatible MCU that already runs at 320mHz+, so it's got 2x as many cycles as you wanted!

> not to mention PCs.

There have also been demo runs of some 64-bit RISC-V boards, using the same FPGA core that 320mHz chip uses ("Rocket"), that have already hit 1gHz+ on old (think 180nm?) fab processes. It can certainly do GHz, it seems.

[cperciva]

RISC-V is a microarchitectural standard, not a chip. Think "x86-64", not "Core i7". There will be a wide range of implementations.

[bogomipz]

I thought it was an ISA specification and not an implementation(microarchitecture.)specification.

https://riscv.org/

[PhilWright]

RISC-V is an instruction set architecture (ISA) specification. So the standard is really just a definition of some instructions and what they should do. The unique part is the fact it is an open standard and so does not require any licensing or royalties.

This means that anyone can then go away and build their own processor implementation to that standard. Intel could create their own chip for that instruction set and get it running at 4Ghz with your latest fab facility. At the other extreme I could sit at home and use Verilog to create a soft core that is downloaded to an FPGA and be up and running with a much slower implementation). Neither of us has to pay anyone for the right to do so and the code we write should work on both because it adheres to the same standard.

In contrast, if you want to create an ARM or x86 processor then you have to pay a license fee. Even if you implement the entire processor from scratch and use nothing from ARM or Intel except the instruction set specification, you still need to pay and it is not cheap. There are many situations where you want to avoid that cost. A researcher wants to experiment with a new idea, you want an internet of things processor but cannot afford the license cost of an existing processor. Or your Samsung and produce zillions of phones a year and saving that dollar per phone is worth having.

As the RISC-V standard is relatively new it means that the first designs to market are the targets that are easiest to create, so microcontrollers. SiFive are now moving up the scale and are working on a full processor with MMU that could be used to run something like Linux. I would expect to see something like that appear within a year or so.

[detaro]

These initial chips in crowdfunding are smallish/microcontroller-like, since they are easier to make and what people like to toy with initially.

RISC-V is an ISA that can be used for all kinds of chips eventually, just like there are ARM offerings from <100 Mhz microcontrollers to >1 GHz multi-core phone SoCs.

[samlittlewood]

Think 'ARM' - RISC-V is an instruction set with similar extensions (MMU, 32/64, FP, vector, compressed etc.)

There a range of implementations - from micro up to superscalar out of order.

AFIK, the two implementations here are both at the micro end of the scale.

[microcolonel]

HiFive1 is fully* funded. Mine will be coming in the mail any day now. ;- )

* With some private subsidy

[Kostic]

HiFive1 dev kit looks quite nice. And approachable (price-wise).

Anybody have any experience with it?

[aseipp]

I have one. I'm writing a Forth for it at the moment, using the ISA simulator as well. It's nice hardware in terms of looks/stability, has arduino compatible pin layout, etc.

It has a lot of Flash for your images or whatever but very little SRAM, even compared to e.g. the Arduino Zero. Only 16KB. So that's quite unfortunate. I only had a Uno R1 though, so it's an upgrade for me in every dimension.

The clock speed is very high comparatively so it could drive some things that may've been out of reach, but they aren't entirely clear on the power usage. The Dhrystone/mW metric is obviously very good but if you don't need raw speed and little SRAM, it's unclear how well it fares power-wise. You could probably get away with less.

The tooling seems to work fine, including the OpenOCD-based debugger (though it has some natural limitations), and compiler toolchain. It'll be nice when the binutils port is upstream so I can get rid of a custom build.

I don't know about the Arduino IDE support. I don't use it. While it's pin-compatible, most Arduino libraries probably need some light modifications to work with the HiFive1 so you can reliably use stock shields/extensions. They have some examples (e.g. Adafruit capacitive display library) on GitHub of doing this. So you can use it with existing stuff if you get your hands a little dirty.

There are no gerber files or masks or whatever I guess, though the RTL they use is available, and they do have directions on how to synthesize the RTL for a small Xilinx Artix FPGA to develop the chip. The FPGA is about $70 I think so you could also go that route and use the soft-core version, though only if you care about HDL.

It's all very new, e.g. the original Dhrystone port on GitHub was a bit busted, but they fixed it very fast. Expect some roughness, but it's mostly been smooth for me since I just use GDB/GCC, OpenOCD and the simulator.

I'd suggest buying it if you want to experiment with RISC-V, support the project, and play with the new tooling -- but probably not as an Arduino replacement, if you have something like a Zero already. Unless you're willing to get your hands dirty, which maybe you are!

[jabl]

No personal experience, but a review at https://hackaday.com/2017/01/05/hands-on-with-the-first-open...