Live data from Hacker News

An ARM killer from IIT-M?

factordaily.com

101–110 of 130 posts

Re: An ARM killer from IIT-M?

#101

Earlier quoted context omitted.

That is simply not true. 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 i…

> What is this even supposed to mean? Digital hardware design hardly takes clock speeds into consideration 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…

> delays across different parts of the circuit

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.

Re: An ARM killer from IIT-M?

#102

To be honest though building a processor these days is not exactly difficult. That is especially true if you start with someone else's ISA and they have already created a GCC or LLVM back end for it. I was at Sun during the development of SPARC and as part of the Systems group we got to see a lot of the trade offs up front but these days transistors are not nearly so scarce. If you stick to 30 - 50Mhz for your first…

That is simply not true. 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 i…

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

Re: An ARM killer from IIT-M?

#103

As the lead architect of Shakti and the guy who helped kick-start the project, I figure I am owed my 2 cents ! 1. We never positioned it as an ARM killer ! That was the imagination of the reporter who wrote the article. 2. Shakti is not a state only project. Parts of Shakti are funded by the govt, these relate to cores and SoCs needed by the Govt. The defense and strategic sector procurement is huge, runs in the 10s…

Thanks for the clarifications - always good to hear from the source. I think there are many people waiting for some real RISC-V ISA silicon. The existing chips are really under powered samples at this point. So, this article made me glad to see this announcement.

That is what the team is spending is spending its time on, PPA optimization so that we have a good idea how far we can go. Iterating with as many process corners as possible to get the right compromise.. But we have to be careful, it is a new low power process node. The backend team is a very accomplished team from a leading VLSI design services entity who are helping us out. That team is also doing a 7nm tapeout simultaneously for a commercial customer, so they know how to route a chip ! Take apart a flagship mobile phone and you will see their handiwork. It is not a bunch of students trying their hand at PnR. Our team sticks to the architecture, design, coding and verification since these are our core strengths. We also get our work audited by external entities. Bottom line, we are as professional and process oriented as any commercial outfit.

Re: An ARM killer from IIT-M?

#104
post #93

To be honest though building a processor these days is not exactly difficult. That is especially true if you start with someone else's ISA and they have already created a GCC or LLVM back end for it. I was at Sun during the development of SPARC and as part of the Systems group we got to see a lot of the trade offs up front but these days transistors are not nearly so scarce. If you stick to 30 - 50Mhz for your first…

Depends a lot on what you are building. If you're talking about a von Neumann machine with symmetric registers -- basically a PDP-11 derivative aka "C machine" -- then you're right: you "simply" have the hard part of, you know, designing a chip, which is an art, and at any appreciable clock frequency, de facto mixes digital and analog design. But as soon as your stray off that path you're on your own (and you still h…

The Mill folks are a good example of going right for the high end.

Re: An ARM killer from IIT-M?

#105

Earlier quoted context omitted.

That is simply not true. 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 i…

I'm not sure why pedroaraujo is being downvoted other than in response to his criticism of HN topcommenter Chuck McManis. Pedro is correct; toy CPUs , like what Chuck mentioned building, are so trivial that undergraduate students can build functioning models of them in a few days or hours. They are quite literally thousands of times less complex than the CPUs (even RISC arches) that are discussed in the article. I al…

> I'm not sure why pedroaraujo is being downvoted other than in response to his criticism of HN topcommenter Chuck McManis.

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.

Re: An ARM killer from IIT-M?

#106

Earlier quoted context omitted.

Thank you for the effort to free knowledge.

That is a compliment I will gladly accept. Look I come from a long line of theologians and philosophers dating back a millenia plus . The Indian ethos of not charging for knowledge has prevailed this long and I am not about to break a tradition ! It is not that we are averse to the ways of capitalism, folks from my family have funded and run some of the biggest tech startups in the valley. I have also run startups ea…

I hold that there is no incompatibility between charity and capitalism. The market is an emergent behaviour of the personal desires and values of individuals. There's nothing anti-market about wanting to contribute to a public good voluntarily, nor to taking work that is ideologically more attractive to you (even at reduced pay).

Re: An ARM killer from IIT-M?

#107
post #52

Earlier quoted context omitted.

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

I thought that what OP meant is that if you can only run the simulation for a relatively simple CPU at, say, 1 MHz, you can run and debug firmware for a 30 MHz CPU effectively, even if it's a little annoyingly slow - your 1-second init routine takes 30 seconds, but that's OK. If you have a 1 GHz CPU, whose more complicated architecture can only be simulated at 500 kHz, then a simulation is really tedious. A 20-second…

For what its worth this captures it well. A processor design in the 30 - 50Mhz range can be usefully simulated on hardware on the engineer's desk (a workstation class PC).

Re: An ARM killer from IIT-M?

#108
post #46
post #28

Earlier quoted context omitted.

> And DEC alpha. 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…

IIRC one of those homegrown Chinese HPC chips were rumored to more or less use the Alpha ISA. 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…

> No byte load/store until, uh, EV56(?).

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.

Re: An ARM killer from IIT-M?

#109

Earlier quoted context omitted.

That is simply not true. 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 i…

I'm not sure why pedroaraujo is being downvoted other than in response to his criticism of HN topcommenter Chuck McManis. Pedro is correct; toy CPUs , like what Chuck mentioned building, are so trivial that undergraduate students can build functioning models of them in a few days or hours. They are quite literally thousands of times less complex than the CPUs (even RISC arches) that are discussed in the article. I al…

"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 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?

Re: An ARM killer from IIT-M?

#110

Earlier quoted context omitted.

That means I have to develop all the code from scratch anyway. the arch lic just gets me a ISA spec doc.Might as well start with another ISA that is free. But the issue is bigger. Shakti is also an exercise in using a high level HDL. We would not exist but for Bluespec, we really get a 6x to 10x productivity increase over Verilog. I also get the ability to do true formal proving of the correctness of my code. There i…

No, an ARM license gets you the implementation of a core in source form. You are free to modify it if needed, as many licensees do.

Depends on the license.
Post reply on HN