Per that page, "multiple high performance [RISC-V] chips have been produced, at 45 and 28nm", which is very encouraging.
More from the page, enough to get me interested:
On performance: "As a rough guide we would expect ~500-1GHz at 40nm and ~1.0-1.5GHz at 28nm."
Is volume fabrication feasible?
Yes. There are a number of routes open to us. Early production runs are likely to be done in batches of ~25 wafers. This would yield around 100-200K good chips per batch. We expect to produce packaged chips for less than $10 each.
Looking at this slide show: https://speakerdeck.com/asb/lowrisc-a-first-look I see they're doing some very interesting things. Besides a lot of usual stuff, 2 cores each with I+D L1 and a shared L2 cache, they've added tags!
2 bits of tags, and they're thinking general purposes (e.g. GC) as well as security. That's big, something we haven't seen in hardware since Lisp Machines, to my knowledge.
Also I/O "minions", non-coherent RISC-V cores, like the CDC 6600 etc.
> 2 bits of tags, and they're thinking general purposes (e.g. GC) as well as security. That's big, something we haven't seen in hardware since Lisp Machines, to my knowledge.
The IBM AS/400 or whatever it is called this week uses tags too for security. (A bit is flipped if a pointer is written too thereby preventing changing pointers.) The PowerPC chip has optional support for tags because of this.
Read and write barrier instructions could be very nice for GC, but those can be done at the page level, I think (I would look at the Azul's Pauseless collector for one state of the art custom hardware approach, and their C4 for doing without on x86_64).
But I'm more interested in tags for dynamically typed languages like Lisp. You don't need many bits, Symbolics used only 4 "hard" ones in the 36 bit 3600 line, which allowed for immediate 32 bit integer and floating numbers, then another 4, leaving 28 bits for word based addressing.
In modern byte addressed CPUs, you can use the least significant bits that are 0 in a pointer for tagging, so the 2 "hard" bits you propose are enough to work with. Basically, as long as we don't have to box floats!
Although it would be nice if we could set things up so that e.g. floating point operations could proceed at full speed, generating a fault if the tag bits on the operands aren't correct ... although superscalar CPUs can do both in parallel without "hard" tags. Are your two main cores going to be superscalar?
And I guess to finish my wishlist, a potential for a lot of ECC DRAM would be nice, at least 16 GiB.
ADDED: flip side is don't let the Second System Syndrome sink this effort (the Raspberry Pi being the first; just going to your own new architecture SoC is a really big step!).
The 2-4 main cores will be derived from the UC Berkeley Rocket core generator https://github.com/ucb-bar/rocket. Currently this is single issue, in-order though it is designed to be a dual-issue in-order core (i.e. superscalar).
Errr, correct me if I'm wrong, but as I read the v2 RISC-V spec (starting with the absence of a flags register!), plus some quality time on Google, RISC-V has no provision for integer computation errors besides divide by zero (which can be checked for). From the spec:
"We did not include special instruction set support for overflow checks on integer arithmetic operations. Most popular programming languages do not support checks for integer overflow, partly because most architectures impose a significant runtime penalty to check for overflow on integer arithmetic and partly because modulo arithmetic is sometimes the desired behavior."
!!!
Or, RISC-V is a Worse is Better (https://en.wikipedia.org/wiki/Worse_is_better), New Jersey style processor, following the same exact model of the primacy of implementation simplicity.
Well, especially since we aren't going to get people to use "safe" languages prior to e.g. software errors killing 4-6 figures of people, I guess it's a really good thing you're adding tag bits that can be used to improve security in unsafe languages.
On the other hand, as a CPU for The Right Way operating systems and languages like Lisp, RISC-V would seem to be ... subpar, especially since who knows what other corners have or will be cut. (Yeah, I know you can check, and for Lisps, it would be fairly cheap to have fixnums be 32 to 29 bits (subtracting LSB bits for more tagging) and then promote them to bignums, but....)
While I think you're doing a very good thing for the world as it is, my personal interest has dropped ... but that's OK, I've got a couple of years to muse about this as you develop your design and get it into production.
I am personally very sympathetic to concerns about the efficiency of overflow checking. There has been some discussion of this on the riscv-hw mailing list, e.g. https://lists.riscv.org/lists/arc/hw-dev/2014-09/msg00007.ht.... The current position of the Berkeley team is that overflow checking just adds a single rarely taken branch, which can easily be predicted. If new data is produced (such as evaluating a wider range of instruction traces, e.g. those from programs not in C), there may well be an argument to be made for new instruction set additions. There is a plan for some sort of RISC-V consortium with representation from all major implementors, though this is will take a while to develop. I imagine we'll be discussing this at the RISC-V Workshop 14th-15th Jan in CA http://riscv.org/workshop/
> the current position of the Berkeley team is that overflow checking just adds a single rarely taken branch, which can easily be predicted
I find this argument VERY weak: you need many of these 'very rarely taken branch' overflow checking instructions and they pollute the instruction cache..
It's quite possible: http://www.lowrisc.org/