The other IP blocks are increasingly programmable. In the mobile world the die is taken up with GPU, modem, DSPs. All heavily programmable but radically different style from the cores, optimized with in some cases decades of history. Server SOCs will add networking processors. There are a few things which might be "Chisel simple": crypto, compression. We will probably see growth in both kinds of functionality.
Perhaps RISC-V could make sense inside the smart accelerators but since the proposition driving them is often specialized data flow for minimal power, the instruction set "extension" is likely to be more significant than the classics, and freedom to pivot the instruction set around the needs of the data flow may trump benefits in reusing a proven ISA.
The RISC-V ISA looks good. I've written code generators for several RISC including MIPS and generally like the trade-offs you have chosen, they fit well with a modern short pipeline with multiple instruction dispatch and parallel execution units.
While 99% of the compute operations in an SoC might be done on specialized accelerators, 99% of the needed total lines of code run on the general-purpose processors. You need a capable CPU inside any SoC.
Unlike ARM, RISC-V has a slim base ISA on which to build programmable accelerators, many of which fetch and decode an instruction stream. Unlike Tensilica and ARC, the RISC-V base ISA was designed to extend up to powerful general-purpose systems.
It should be far easier to develop software for an SoC full of RISC-V general-purpose cores and RISC-V-based specialized accelerators, than one that has a smorgasbord of home-brewed ISAs everywhere.
Purely fixed-function (non-programmable) pipelines are also important in some places. We'd recommend Chisel for those (chisel.eecs.berkeley.edu).
Krste & team, It is good to have free IP for a core but it comes late in the day. Looks like the cores (including their cache) occupy 10% of a modern SOC and the rest of it is an ever growing sea of IP blocks for everything from graphics to encryption. Such blocks may offload specific workloads at 100x the power efficiency of a general core and as the whole SOC is commonly power limited, that is making more and more sense to have much of the die idle until needed. It will be as unremarkable to have idle silicon as it will be to have software which is called only when needed. In some ways power has replaced clock speed as the limit to complexity metric which RISC was founded on. So the size and complexity of the SOC can sensibly balloon far beyond what RISC prescribed, as a network of cooperating specialists.
Would you agree, and how would you compare that to experimenting with reserving extentions of the instruction set? It seems like those extensions assume the functionality is under control of the core, but the modern trend seems to be separation and independence.
RISC-V already has variable-length instructions and read/modify/write instructions (in the standard "A" extension). We are working on experimental memcpy instructions as part of a "virtual local store" subsystem. The vector units we design have some very complex addressing modes. So, RISC-V might be the CISC you're looking for.
Many people have asked about AMBA/AXI and though we haven't implemented it yet, it would be very straightforward to support given that our existing interconnect is based on simllar point-point links.
RISC-V really looks like MIPS done right, it is a quite solid base, albeit not an original one.
I dream some other university had the resources to build a competing CISC ISA, a x86 without all the problems, but keeping the variable instruction lenght, complex addressing, read/modify/write instructions, memcopy instructions...
The SPARC standard and brand belongs to www.sparc.org, both the V8 and the 64bits V9 edition. The "SPARC architecture licence", one time cost is 99$. The situation of recent insturction set extensions by Sun/Oracle and Fujitsu is not clear though.
While playing with my own CPU designs, I decided to create yet another on-chip interface bus, as both Wishbone and AMBA AHB/APB looked terrible and unsuitable for my purposes. (like CPU ISAs, there are gazillions protocols like CoreConnect, Avalon, OCP...)
Is AMBA AXI good enough ? Do you work on a open ASIC bus protocol ?
Irrespective of the analysis of the relative merits and defects of the ISA, what is important now is to quickly come out with appropriately configured SoCs and low-cost evaluation/development boards along the lines of Rasperry Pi; along with a robustly engineered ecosystem, for under $50/-. This will quickly proliferate in academia and industry. Once the copmmunity starts designing actual products around them, the commercial microprocessor families are going to get a real run for their money!
We did share it with many universities, which was an interest that we expected; the surprise was there is interest outside academia, which we only realized 6 months ago when non-academics were download from our course website and then complained if we made changes.
I've got to say that I'm surprised that you believe academics don't open their processes to outsiders. We even put our software that is under development on publicly accessisble on GitHub, and will talk to anyone who is welling to let us give a talk.
I believe there are a few other parts of our field that are a bit more closed than academia
Krste, thank you very much for explaining further. Project management (like economics) is a significant and potentially very interesting side aspect of computer architecture.
I am somewhat disappointed that academics did not seek collaboration. As I stated earlier, this saves time/effort in the longer run. For businesses, I receive the impression that even if individuals wanted to respond corporate policy may have prevented such; I recently read that some corporations filter incoming mail not merely to avoid wasting the highly valuable time of the skilled but to avoid accusations of idea stealing.
I can sympathize with not wanting to waste other's time and respect that honorable choice.
I am disappointed with the lack of signal on comp.arch—much of the noise is easy to filter if one is willing to sacrifice a little signal—, but there are not many places on the Internet to post or discuss thoughts on computer architecture.
Anyway, I apologize for whining in a public forum. (I am sending a longish email; I hope you are good at skimming as there might be some copper nuggets hiden in the wall of text. I am selfish, but I do not want to completely waste your time.)
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.