Ok then.

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...