Building a CPU can be "easy" if you want to build something that works. If you want to build something that is power efficient and, at the same time, quite performant, then the complexity of the problem escalates very quickly.
Sticking at 30-50 MHz? What is this even supposed to mean? Digital hardware design hardly takes clock speeds into consideration, except during physical implementation in the later stages of the hardware development.
TSMC or Global Foundries will help translating HDL into a reliable node? Do you even know what you are talking about? This "translation" that you refer to is called synthesis and physical implementation and it is done by the design house. The foundry only provided the logic cells their technology and they manufacture the final die that is going to ship on the product.
The CPUs you mentioned were simple micro-controllers, they were not designed for heavy processing tasks, they don't even have a branch predictor which is something fundamental to have some significant performance.
Nothing about your post made any shred of sense in terms of hardware design.
I also concur with Pedro on the clock speed part - clock speed has absolutely nothing to do with your hardware design until you have written all the HDL, simulated its behavioral characteristics, actually synthesized the logic, completed the analog and I/O components of the design, and are actually preparing for tapeout. There's a reason only AMD and Intel make large CPUs for the consumer market, and it's not because college students are too busy.
I'm going to fade into the grey background for this, but ChuckMcM's comment is yet another disappointing step toward the total calcification of this forum. It's not a commentary on the article; it simply states, lazily, and ignorantly, that whatever it is they're attempting at IIT-M, it can't be too hard. What an an incredibly condescending and blasé thing to say, especially on a public forum where what you say can't be erased.
I'm actually quite glad to see another implementation of RISC-V from outside the US. The horde of nearly identical ARM cores on the market is terribly uninspiring.
So you're going to do all of that without even thinking about your target clock rate? Unlikely
But your comment I can respect, as you explained things politely
> I'm actually quite glad to see another implementation of RISC-V from outside the US. The horde of nearly identical ARM cores on the market is terribly uninspiring.
Totally agree
I suppose it could be deleted though. I would hate to be a contributor to calcification.
One of the things that stuck out to me about the article was that everyone of their stated goals would be met "instantly" if they bought an ARM architecture license. They aren't cheap but in terms of man years of effort they aren't expensive either.
As a result of owning such a license they could make processors of their own design which leveraged they ARM infrastructure (this is what Apple does for example). That could meet their 'openness' of implementation goals, their 'made in india' goals, and their 'range of architectures from controller to server'. But they aren't doing that.
I understand you read it as condescending, but my intention was to be illustrative of the part of the problems they missed in that grand vision they wrote about in the article. How would you suggest I say that such that you would not hear it as a dismissal?
Aside, I hope my comment didn't seem too abrasive. It's hard not to get attached to something you work closely on most of your life.
As for abrasiveness, I read it as a passion more than insult. I also read it as a signal of frustration and I like to understand the roots of the frustration in order to improve things.
Because he phrased too much of his disagreement as personal attack. That's against the HN rules.
And because he took the example of chips from two generations ago (which is about how far back you have to go to find non-mainstream but reasonable chips) and says that they "were simple microcontrollers". IIRC, the NS32032 was close to equivalent to the Intel offerings of the time. Didn't even have a branch predictor? Nobody else did in those days, either.
pedroaraujo's points get lost in the vitriol and in trying to apply today's expectations to examples from 20 years ago. Most of the discussion seems to be centering on his points, which is good. But the tone of the post is certainly downvote-worthy.
> The CPUs you mentioned were simple micro-controllers, they were not designed for heavy processing tasks, they don't even have a branch predictor which is something fundamental to have some significant performance.
So it seems his comparison was fair, after all? Given that the article is about microcontrollers too.
My first gut reaction to his reply was "troll."
You purport to correct him and then you drop this phrase, which is questionable at best and wrong at worse.
You do design something that has different clock speeds differently. (Pipelining, power consumption, delays across different parts of the circuit). This is not anything too fancy, this is digital design/IC design 101.
Your post makes a lot less sense than his
guess that's not "digital". After all i expect say gimp to run on my old linux 2.3 thinkpad or on a magnitudes faster i7, but of course with respect to the feasability of heavy effects and huge memory loads.
I think what OP means is that you can simulate in software a 30-50MHz version of your own CPU, without having the hardware ready, so you can starting testing if i.e. Linux can boot.
That's not to say there's not someone coming in this morning to step through the overnight simulation they ran, but it's a lot easier to work with when your simulation runs nearer real time.
We clearly see things a bit differently, but I also want to separate what I said, and what you read. I don't think they were necessarily the same thing. My intention here is to share with you some of the thinking behind what I wrote.
The article states, "The Shakti project is based on the RISC-V ISA started at UC Berkeley. ... The first chip of the Shakti series will be a C-class controller chip, an entry-level processor, which would find use-cases in IoT, smart cards, and security applications."
The current CPUs in this space (IoT, Smart Cards, and Security Applications) are the ATMega AVR series, the ARM Cortex M0/M0+ and a handful of others like the PIC32 and the MSP series from TI.
Designing the logic for such a CPU is an undergraduate exercise. It is "easy" in the sense that if you have been taught VHDL or Verilog, and someone hands you a RISC style instruction set architecture which defines the registers, instructions, and flags. A group of students should be able to get something working in a semester which simulates on a VHDL test bench. Here is the call out for Stanford's EE108 Class from the Fall of 2014[1]. Which states --
"EE108b introduces students to architecture and design of efficient computing and storage systems. The main topics include: overview of key techniques for efficient systems, efficiency metrics (performance, power and energy, cost), hardware/software interface (instruction set, data and thread-level parallelism), processor design (pipelining and vectors), custom accelerator design, cache memories, main memory, basic I/O techniques, and architectural support for operating systems. The lab assignments involve the detailed design of a processor on a FPGA prototyping system. The programming assignments involve optimizing the efficiency image processing applications on a portable computing platform."
I wasn't dismissing the challenge as something kids in nursery school can do, but I do see the challenge as something of a 'solved problem' for new EE's.
You asked about "Sticking at 30-50 MHz? What is this even supposed to mean? Digital hardware design hardly takes clock speeds into consideration, except during physical implementation in the later stages of the hardware development." which might make a bit more sense in the context of the previous comment about its a well solved problem.
When you are building chips in FPGAs and ASICs the "challenge" after you have it running in a test bench, is getting a timing closure. In case you are new to this, that is making sure that signals from different gates arrive in time to be used in the next stage of the operation. This is important because the propagation of signals takes finite time and, assuming you are doing synchronous design, you want to have all the inputs settled given their worst case timing before the clock edge looks at them and does the next step.
It has been my experience that when people do their first FPGA designs and the tool tells them how fast they can run reliably, they are disappointed. So they spend some amount of time floor planning and organizing their layout to speed that up. That problem is exacerbated in silicon because the velocity factor of polysilicon wires is much lower than that of metal wires. And typically to keep down costs and complexity you will want to run your signals on the metal layers. But sticking to that can spread out your gates and size is an issue as well when it comes to cost. There is a reason that the majority of the chips for the "IoT, Security, and Smart Cards" top out at clock rates under 50Mhz. It is a 'sweet spot' for cost versus chip complexity versus circuit design. If you want to build cost effective chips in that market you might find yourself in the same design space.
As for design houses vs foundries, I am sure you can use your own design house if you choose to, I expect if you use the foundry's [2] you might avoid delays associated with disagreements between what the design house feels like the process should be able to do, and what the foundry feels like it can do. There is nothing quite so disappointing as a design team saying the foundry "should" be able to do something and the foundry saying that it is "impossible." If you want some interesting stories around that you can read the history of the SPARC 10 and Sun's interaction with Texas Instruments (foundry). But my assumption was that any fabless efforts today would go to the design services of the foundry they chose to minimize both schedule risk and the risk that the two won't get along. It may still be possible to show up at a foundry with a shipping box of masks and say "here make me some of these" but it would not be my starting strategy.
And then you said (and this was me being unclear), "The CPUs you mentioned were simple micro-controllers, they were not designed for heavy processing tasks, they don't even have a branch predictor which is something fundamental to have some significant performance."
Perhaps the reason we saw this differently is that I have seen multi-billion dollar companies depending on a computer to run their business in the back office that didn't have a branch predictor. Before my time the machines didn't even have virtual memory. As a result, I don't think the first CPU out of the gate is going to be have multi-issue superscalar pipelined performance. I don't think the folks in the article do either. You see they mentioned they were starting simpler, like ARM did, like Intel did, like IBM did, like Sun and Apple did and every single company that has ever designed and deployed a new CPU design. It is absolutely a huge undertaking to improve the micro-architecture of a modern Pentium or the Power9 or the ARM A5x 64 bit architecture. If IIT-M gets to that point, that will be at least 10 years from now, maybe 15 or 20. And understanding that as I do I know that they need to get traction with their systems early on.
> "Nothing about your post made any shred of sense in terms of hardware design."
I can certainly agree with that, because what IIT-M is taking on is not hardware design. All of the hardware design between now and their first $100M is all well understood and doesn't push the envelope at all. They are trying to bring a new system into the world, one that has an ecosystem of software, peripherals, and a variety of CPU implementations. The article gave me the impression that the author of the article felt that if they just built a new CPU it would usher in a new era of computers from India. I think that is a necessary but insufficient step along the road, and that there will be many challenges unrelated to hardware design that will threaten the success of this effort decades before they have engineers wondering which form of register coloring provides fewer bubbles in a hyper-threaded execution pipeline.
[1] https://lagunita.stanford.edu/courses/Engineering/EE108b/Win...
[2] http://www.tsmc.com/english/dedicatedFoundry/services/design...
Recall that the US semiconductor industry did have plenty of govt help at its inception. The Indian govt can similarly provide early support by being a customer. But still, it is going to be a tough row to hoe.
I really wish all these "open source" chips would just steal the DEC Alpha microarchitecture and implement it. It's been almost 20 years--even the patents on EV7 should have run out by now.
It was a really clean, mostly orthogonal microarchitecture that had most of the really annoying implementation corners filed down. EV5 is a very straightforward chip and maps very well to low power implementations (see StrongARM). EV6 is pretty straightforward in modern technology nodes.
And, best of all, it's documented. Compilers exist. Operating systems exist. Old hardware exists that can be used for validation and initial development. It wouldn't require you to build an entire ecosystem up front in order to bootstrap.
That being said, I wonder if at this point all the low level software (kernels, toolchains etc.) have bitrotted to the point that you're not buying much, if anything, compared to using RISC-V.
And it's not like Alpha doesn't have those irritating ISA idiosyncrasies. E.g. the most crazily relaxed memory model known to man. No byte load/store until, uh, EV56(?). And it's big endian, which per se isn't wrong in any way, you'll just be dealing with endian bugs forever and ever when porting since the rest of the computing universe, for better or worse, has converged on little endian (x86, ARM, even Linux on OpenPOWER)
I believe that you can blame a MIPS patent for that, IIRC.
> And it's big endian, which per se isn't wrong in any way, you'll just be dealing with endian bugs forever and ever
Actually, that was one of the biggest benefits to porting Linux to Alpha. A HUGE number of assumptions got cleaned up. I suspect the current ARM ports of Linux would be almost a decade behind without that.
https://lwn.net/Articles/647636/
[If you wanted to resurrect the Alpha, though, please do not resurrect the crazy memory consistency semantics, where you need to put a full memory barrier between
r0 = load(&x);
r1 = load(r0);The memory semantics are of course so lax so that the processor doesn't need to check the computed addresses of all in-flight stores before issuing a concurrent memory operation. My understanding is that it's mostly a footgun for assembly programmers, but I'd love to see any estimates of the speed and power efficiency benefits of the lax memory semantics.
But as soon as your stray off that path you're on your own (and you still have the chip design problems as well). The Mill guys have been at it 14+ years (admittedly none full time AFAICT).
http://www.adapteva.com/andreas-blog/semiconductor-economics...
https://www.eetimes.com/author.asp?section_id=36&doc_id=1266...
https://www.eetimes.com/document.asp?doc_id=1330568
There's also companies that are a cross between ASIC's and FPGA's called Structured ASIC's that can get the initial NRE down for a prototype. eASIC and Triad Semiconductor are two. eASIC has a lot of IP on it already.
The last point is that operations such as DARPA show that government funding can knock out the worst of the NRE. India is using government funding. The reason we normally see things done that way still being very expensive is that those receiving the government funding are trying to maximize profit, get lots of patents, and eliminate competition that threatens that profit. An alternative for those aiming for public benefit is to work out the bugs from an initial CPU or SOC whose NRA was government backed to then release just over cost or at a decent markup. Each new wave of funding that produces new iterations soaks up the high NRE with the steady sales revenue doing the rest. Might work.
OpenPITON and PULP are two things that came to mind as having potential there with one an alternative to SMP/multicore in server side and other for embedded. PULP actually used that model that I can tell.
It is certainly possible, but it is a long game and you have to survive the early years. Go back and read the history of ARM (and Acorn), Intel (and IBM), Motorola (and Sun and Apple), and Power PC (and Cisco). Then read the history of the Z8000, the NS32032, the AMD88000, and the TI 9900. When you look at the history from where we sit today you will see that building a new CPU is the easiest thing in the world, staying alive until it is relevant is exceptionally difficult and requires quite a bit of luck in addition to good design.
I wish these guys a lot of luck, I would love to see a fully open architecture be even half as successful as ARM has been. They have to walk into this with their eyes open though, it is not going to be easy.