An ARM killer from IIT-M?
factordaily.com
factordaily.com
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.
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.
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.
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.
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.
> 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."
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
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.
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.
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.
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.
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...
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.
Considering the 'prestige' and money that comes with working in the US, I'd be very surprised if the country can ever accumulate enough talent to do anything fundamentally significant (esp. since all of the relevant Education/Industry is entirely Anglophone).
I also feel there is generally a lot of self-flattering that goes on, often for this very reason. I'm old enough to remember the embarrassment that was to be 'India's answer to OLPC' (also conceived at an IIT of note).
Water on the Moon
However, But India barely has the kind of interests, state-apparatus or companies that'd want something like this to succeed. They have Flipkart, which is barely an Alibaba...
Flipkart last week announced a Designed and engineered in India Smartphone [1].
And this was done by a homegrown company smartron.com. Their website shows how heavily invested they are in IoT (apart from mobile phones). This company was founded by a Mahesh Lingareddy, who it seems was a co-founder for a company which was acquired by Intel for $250 million.[2] - so he has all the resources (or credibility to raise funds) to put in place the execution plan for their vision of "India’s first global brand with focus on innovation, design, engineering, products and platforms." [3]
Or in other words, things are changing - past is not an indication for future failures.
[1] www.flipkart.com/billion-smartphone-launch-store
[2] https://www.msn.com/en-us/finance/technologyinvesting/2-acqu...
[3] http://www.smartron.com/about.html
More about Smartron: www.thehindubusinessline.com/info-tech/smartron-plans-rs-1500cr-investment-to-expand-operations/article9622268.ece
> Considering the 'prestige' and money that comes with working in the US, I'd be very surprised if the country can ever accumulate enough talent to do anything fundamentally significant (esp. since all of the relevant Education/Industry is entirely Anglophone).
That was true maybe 10/20 years ago. Right now, thanks to Trump and Republicans, the US is much less attractive destination, especially for top-tier researchers. NSF funding rates are in the single digit percentage range, every year seems to see a new assault from state-level republicans on state university systems. Rising xenophobia and white nationalism obviously don't help the cause.
The situation in India is way better. There is more money available for research: the Shakti project is one example but many other big centers are being funded in various "institutes of national importance." There is a bi-partisan commitment to increasing funding and hiring for Indian research and there is a growing talent pool emerging from the non-IIT undergraduate colleges.
Twenty years ago, every R1 university in the US was better than every university in India. Now, once you get past the top-10 or 15, beyond the Berkeleys, MITs, Princetons and maybe Purdues, it's not at all clear that it is a good idea for a young assistant professor to go to say Virgina Tech over IISc or IIT Bombay. And in fact, these Indian institutes are consistently hiring people who would have been a shoo-in for a faculty position at places like VT.
umm, probably because both of these companies are not exactly known for their cutting edge r&d.
I'm not aware of anything of note coming from Baidu research. All they've done is a splashy celebrity hire of Andrew Ng, which is the exact opposite of how one would set up a serious research organization.
The US is still extremely attractive, especially for STEM talent.Indian educated migrants think of Trump as a temporary phase; and given how migrants power the American tech industry, they feel impervious to most Trump related threats.
Trump is by no means a temporary phase. The demographic trends that led to Trump will continue for a long while.
The "big sort" means that 70% of US population will be represented by 30 senators by 2050. Guess which party the other 70 senators representing primarily rural populations will belong to? The republican advantage in the electoral college will continue to grow as the rust belt becomes older and whiter. The supposed democratic flips of Arizona, Georgia and Texas due to rising Latino population are still far away in future and in the meantime, republican voter id legislation and gerrymandering of state-level districts to control state-level legislatures will ensure they remain red for the foreseeable future.
What all this really means is that the current situation -- where winning the primary is far more important than the general for republican politicians -- will continue for at least a decade or two more. Which means we WILL have more Trumps. The scary part of this is that the next guy won't be as incompetent at implementing his own agenda as this one.
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 of billions of USD.There is significant funding in terms of manpower, tools and free foundry shuttles provided by the private sector. In fact Shakti has more traction with the private sector than the govt sector in terms of immediate deployments.
3. The CPU eco-system including ARM's is a bit sclerotic. It is not the lic cost that is the problem, it is the inherent lack of flexibility in the model.
4. Shakti is not only a CPU. Other components include a new interconnect based on SRIO, GenZ with our extensions accompanied by open source silicon, a new NVMe+ based storage standard again based on open source SSD controller silicon (using Shakti cores of course), open source Rust based MK OS for supporting tagged ISAs for secure Shakti variants, fault tolerant variants for aerospace and ADAS applications, ML/AI accelerators based on our AI research (we are one of the top RL ML labs around). 4. the Shakti program will also deliver a whole host of IPs including the smaller trivial ones and also as needed bigger blocks like SRIO, PCIe and DDR4. All open source of course. 5. We are also doing our own 10G and 25G PHYs 6. A few startups will come out of this but that can wait till we have a good open source base. 7. The standard cores coming out of IIT will be production grade and not research chips.
And building a processor is still tough these days. Try building a 16 core, quad wide server monster with 4 DDR4 channels, 4x25G I/O ports, 2 ports for multi-socket support. All connected via a power optimized mesh fabric. Of course you have to develop the on-chip and off-chip cache coherency stuff too ! 8. And yes we are in talks with AMD for using the EPYC socket. But don't think they will bite.
Just ignore the India bit and look at what Shakti aims to achieve, then you will get a better picture. I have no idea how successful we will be and I frankly do not care. What we will achieve (and have to some extent already) is - create a critical mass of CPU architects in India - create a concept to fab eco-system ind India for designing any class of CPUs - add a good dose of practical CPU design knowhow into the engineering curriculum - become one of the top 5 CPU arch labs around
Shakti is already going into production. The first design is actually in the control system of an experimental civilian nuclear reactor. IIT is within the fallout zone so you can be sure we will get the design right. If you want any further info, mail me. My email is on the Shakti site. G S Madhusudan
My question is about Bluespec SV and the random logic synthesis of the written code. Is it good enough for good power consumption figures or is that not really a concern at this point? Do you know how its reception has been in industries in the last 4-5 years? Is it still the 'technology of the future'?
Another question I have is, this project being open source, are you seeing contributions from other educational institutions or industries? What would be needed get more institutions involved?
I just have one request though. If you are interested in Makers taking interest in your project please make sure your documentation is top quality. Also try to provide cheap dev boards so that the community can provide Linux or some RTOS port. I being in India it would help immensely if you have your dev resources at lower costs(FPGAs which I really doubt but dev boards with your processor, yes) so that people like me can help you with some OS ports. You can also follow the route of Adapteva Inc which can provide you with a template of good quality product (i.e. Good documentation, source code etc).
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.
I agree with your statement "I have no idea how successful we will be and I frankly do not care." There will be a lot of benefits as a result of this work regardless of the immediate outcome. Keep building the future!
There are a lot of comments here on HN that seem completely uninformed of what's actually happening with RISC-V. They are about to be surprised.
Silly question, but what do you mean by "sclerotic" here? I had to look up the word and only found medical definitions.
I think the world can use some competition in the server space between different ISAs, the current Intel(-and-sometimes-AMD) monoculture is problematic for a number of reasons.
When not even Google can get a CPU without built in IME/PSP "secure" processors running insecure code, that seems like an understatement.
It seems like almost everyone is ignoring the epic fallout of a truly malicious entity discovering and silently exploiting a remotely exploitable security hole in for example Intel ME. They could more or less shut down whole countries by a key press.
And that would be just the start. When you can't be sure if there is malicious software remaining deep inside your processors, you pretty much have to shred them. And the motherboard, and the disk drives (http://spritesmods.com/?art=hddhack), etc. You simply would have to replace your whole IT-infrastructure. Then you need to try to figure out what sensitive data was lost... It would be a nightmare for sure. If I were Google or Amazon I would be absolutely paranoid.
How much will it cost for USA to implement a replacement for Social Security Numbers after the Equifax leak?
As our dependence on IT increases it becomes a more attractive target, so a well protected IT-infrastructure will be an absolute necessity in the near future. To be able to build a secure infrastructure, we need a hardware foundation that we can trust. We simply don't have that today!
Shakti sounds like it can be the foundation we need, I very much hope so.
He's a security expert working for Google. Here he is explaining just how bad the situation is.
here he talks about lack of trustable CPU:s https://youtu.be/JCa3PBt4r-k?t=7m22s
The ISA isn't the hard part in building a chip, the building the chip part is. The thing they have going for using an existing ISA is that they get kernel and toolchain support.
They have many millions in support in the project and see all the reasons why they will succeed. What would be awesome is if AMD gave them assistance in getting their parts running in EPYC sockets.
ARMv8 ( Specifically the aarch64 part ) is like a clean start. I doubt RISC-V offer any advantage, especially we should now know the uArch is only tiny part of the equation, the implementation matters a lot.
Apart from the fear of lock in or ARM suddenly hike the price 100x, what exactly is the benefits and motives for RISC-V?
Or is this more of NIH Syndrome?
I’m assuming all their code is in this repo: https://bitbucket.org/casl/
Looking forward to the day when we would be able to run popular open source SW frameworks like NodeMCU and Linux on open hardware like this.
Submitted my first PR to the bitbucket repo (a minor one) https://bitbucket.org/casl/shakti_public/pull-requests/1
In addition to the above description, a picture should have been inserted above or below the paragraph.
We are one of the last refuges of the endangered black buck. The spotted deer and bonnet macaques are more common in India. Odd that a university campus in the middle of a city is a refuge. The pic is that of an albino black buck, an even rarer mutant.
I am happy when I can see a kestrel or a roe deer from my office. It must be amazing to work in such a beautiful scenery!
http://www.thehindubusinessline.com/multimedia/dynamic/02331...
Now if I could get the monkeys to learn bluespec ...
Sure they don't want to release a chip using the draft.
That said...
> “The capitalist computing bourgeoisie want to enslave us all with proprietary processing architectures, but the proletariat eventually produces its own processor alternative – an ISA for and by the people, where instruction sets aren’t subject to the whim of the royalty-driven class, and where licensing fees don’t oppress the workers’ BOMs (bill of materials),” writes Kevin Morris in the Electronics Engineering journal, lending colour and gravitas to what’s at stake in the processor industry.
Comparing RISC-V to communism is pretty grody. RISC-V is precisely a capitalist revolution, shedding a layer of state protection of the ISA from the market, and unleashing the greed, passion, and proprietary zeal of the world on the task of bringing designs to market.
There's really nothing capitalist about this at all.
Though I'd generally agree in the case of IIT Madras, which is specifically engaging in a state effort to reduce import dependence in microelectronics (especially for defense and national infrastructure).
The one way the U.S. government can come to own copy rights is by purchasing them from original rights holders. No copy right exists for any work of a U.S. government employee.
Of course an implementation would be far more useful, as it would be the likely target for lawsuits.
https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
There are also security reasons for wanting to make a processor for India. “We don’t know really whether the processor we are getting from outside is trustworthy. Is it secure?” asks Kamakoti. “Suppose I want variants of a processor, for different needs – not just strategic, even civilian needs – I have to basically rely on the processor available to me, and fit my application to that. It is something like I bought the slipper and I am cutting my feet to fit into it.”