India reveals RISC-V CPU roadmap, expects product by 2023(pib.gov.in)
pib.gov.in
India reveals RISC-V CPU roadmap, expects product by 2023
https://pib.gov.in/PressReleaseIframePage.aspx?PRID=1820621
10 comments
> They should also invest more in research. Why does india have less supercomputers than sweden? Does this mean that india is doing less research in some aspects than a country of just 10 million people?
India is huge, but only about 100 million Indians were considered part of the global middle class before Covid and now it's apparently only about 70 million.
And the global middle class starts at about $3500 per year, which would probably mean starvation level in Sweden.
For people with comparable incomes, India is most likely "only" 3-4 Swedens, maybe even less. So maybe 40 million people.
Poor countries, people wise, are much smaller than they seem. I come from a poor country and you can definitely feel this.
India is huge, but only about 100 million Indians were considered part of the global middle class before Covid and now it's apparently only about 70 million.
And the global middle class starts at about $3500 per year, which would probably mean starvation level in Sweden.
For people with comparable incomes, India is most likely "only" 3-4 Swedens, maybe even less. So maybe 40 million people.
Poor countries, people wise, are much smaller than they seem. I come from a poor country and you can definitely feel this.
India has a glorious history of scholarship unparallelled by any other country, but that ended centuries ago. In terms of scholarship, modern India isn't 3–4 Swedens. It's 0.2 Swedens.
As one very crude measure, the Swedish-language Wikipedia has 2.56 million articles. Urdu Wikipedia has 0.17 million articles, Hindi Wikipedia has 0.15 million articles, and the other Indian-language Wikipedias like Tamil are even less. The Hindi Wikipedia is half the size of Esperanto.
(Though this is an imperfect measure—the Cebuano Wikipedia is bigger than anything but English because of one extremely prolific guy.)
It may be a bit unfair to compare India to Sweden on https://en.wikipedia.org/wiki/List_of_Nobel_laureates_by_cou..., since it's a Swedish prize, but as a second very crude measure, India has only 11 Nobel laureates, and two of them are Mother Teresa and Rudyard Kipling, who did not have to suffer from the Indian educational system. [Edit: and though the Poet was born in Kolkata, he was home-schooled.] Sweden has 32. Israel (9.5 million people, didn't exist until 01948) has 13. Poland, not noted for its wealth and prosperity since 01941, and with 4% of India's population, has 19.
— ⁂ —
So what's up? What's denying the billion Indians the opportunity to excel?
I don't think the problem is that 70 million people isn't enough to do research, or even that US$3500 per year isn't enough to build a semiconductor fab in your basement. It's not, but the Indian government presides over a US$3 trillion economy, nominal, which it has the power to tax. It spends US$36 billion a year on the military and the Union budget is US$490 billion a year overall. The US National Science Foundation's budget is US$8.3 billion a year, and the NIH is US$42 billion.
Caltech publishes more research than the entire country of India. Caltech spends US$4 billion a year, and though more than half of that is JPL, a lot of the rest goes to educating its undergraduate student body. Caltech is about 2400 students (most grad students), 300 professors, 40 Nobel Prizes (3½ times India), six Turing Award winners, and four Fields Medalists. It's two millionths the size of India, one twenty-thousandth the size of India's middle class, and 1% of the Union budget of the Indian government.
Neither population nor literate population nor material wealth is India's problem.
(To preemptively rebut the racist nonsense that someone will undoubtedly post, it's not genetics either—NRIs in the US number only 4.6 million, and only half that until 15 years ago, but have accrued three Nobel Prizes and a Fields Medal, and founded Sun, Robinhood, Spark Capital, and of course Khosla Ventures—and, apparently, 90 unicorns between 01997 and 02019: https://nitter.mint.lgbt/IlyaStrebulaev/status/1481662020659....)
I think the problem with India is the people in charge. They write cringe-inducing things like "DIR-V will see partnerships between Startups, Academia & Multinationals, to make India not only a RISC-V Talent Hub for the World but also supplier of RISC-V SoC (System on Chips) for Servers, Mobile devices, Automotive, IoT & Microcontrollers across the globe," or "RISC-V ... [is] pushing the Moore’s Law beyond its limits."
There are some extremely competent people at the IITs, including IIT Madras, which is how Shakti became such a decent implementation of RISC-V. But instead of being in charge of the sort of fools who think "mobile" and "startups" are proper nouns, that servers (as a hardware product category) are powered by SoCs, that Moore's Law is currently being pushed beyond its limits, or that CPU architectures are in any way relevant to whether semiconductor fabrication technology is developing faster or slower than Moore's Law predicts—those fools have somehow been put in charge of them.
How the hell are you going to have a government research strategy for making India a world power in semiconductor design when the people in charge of that research strategy evidently have the structure of the modern semiconductor industry all topsy-turvy in their minds? And it's not even because they don't have access to anybody who understands the issues—the Shakti design team, for one, is clearly pretty competent, and they're grappling with the limits of modern fabrication technology, and evidently Rajeev Chandrasekhar recognizes that. He himself got EE and CS degrees and worked at Intel on the 80486 design—30+ years ago. But evidently he doesn't consider it important to get their advice on whether Moore's Law is being "pushed beyond its limits" or not? Or, are they telling him the M1 Ultra is a RISC-V chip?
I don't have any idea how this kind of nonsense gets put out by a ministry headed by a former 80486 design engineer.
As one very crude measure, the Swedish-language Wikipedia has 2.56 million articles. Urdu Wikipedia has 0.17 million articles, Hindi Wikipedia has 0.15 million articles, and the other Indian-language Wikipedias like Tamil are even less. The Hindi Wikipedia is half the size of Esperanto.
(Though this is an imperfect measure—the Cebuano Wikipedia is bigger than anything but English because of one extremely prolific guy.)
It may be a bit unfair to compare India to Sweden on https://en.wikipedia.org/wiki/List_of_Nobel_laureates_by_cou..., since it's a Swedish prize, but as a second very crude measure, India has only 11 Nobel laureates, and two of them are Mother Teresa and Rudyard Kipling, who did not have to suffer from the Indian educational system. [Edit: and though the Poet was born in Kolkata, he was home-schooled.] Sweden has 32. Israel (9.5 million people, didn't exist until 01948) has 13. Poland, not noted for its wealth and prosperity since 01941, and with 4% of India's population, has 19.
— ⁂ —
So what's up? What's denying the billion Indians the opportunity to excel?
I don't think the problem is that 70 million people isn't enough to do research, or even that US$3500 per year isn't enough to build a semiconductor fab in your basement. It's not, but the Indian government presides over a US$3 trillion economy, nominal, which it has the power to tax. It spends US$36 billion a year on the military and the Union budget is US$490 billion a year overall. The US National Science Foundation's budget is US$8.3 billion a year, and the NIH is US$42 billion.
Caltech publishes more research than the entire country of India. Caltech spends US$4 billion a year, and though more than half of that is JPL, a lot of the rest goes to educating its undergraduate student body. Caltech is about 2400 students (most grad students), 300 professors, 40 Nobel Prizes (3½ times India), six Turing Award winners, and four Fields Medalists. It's two millionths the size of India, one twenty-thousandth the size of India's middle class, and 1% of the Union budget of the Indian government.
Neither population nor literate population nor material wealth is India's problem.
(To preemptively rebut the racist nonsense that someone will undoubtedly post, it's not genetics either—NRIs in the US number only 4.6 million, and only half that until 15 years ago, but have accrued three Nobel Prizes and a Fields Medal, and founded Sun, Robinhood, Spark Capital, and of course Khosla Ventures—and, apparently, 90 unicorns between 01997 and 02019: https://nitter.mint.lgbt/IlyaStrebulaev/status/1481662020659....)
I think the problem with India is the people in charge. They write cringe-inducing things like "DIR-V will see partnerships between Startups, Academia & Multinationals, to make India not only a RISC-V Talent Hub for the World but also supplier of RISC-V SoC (System on Chips) for Servers, Mobile devices, Automotive, IoT & Microcontrollers across the globe," or "RISC-V ... [is] pushing the Moore’s Law beyond its limits."
There are some extremely competent people at the IITs, including IIT Madras, which is how Shakti became such a decent implementation of RISC-V. But instead of being in charge of the sort of fools who think "mobile" and "startups" are proper nouns, that servers (as a hardware product category) are powered by SoCs, that Moore's Law is currently being pushed beyond its limits, or that CPU architectures are in any way relevant to whether semiconductor fabrication technology is developing faster or slower than Moore's Law predicts—those fools have somehow been put in charge of them.
How the hell are you going to have a government research strategy for making India a world power in semiconductor design when the people in charge of that research strategy evidently have the structure of the modern semiconductor industry all topsy-turvy in their minds? And it's not even because they don't have access to anybody who understands the issues—the Shakti design team, for one, is clearly pretty competent, and they're grappling with the limits of modern fabrication technology, and evidently Rajeev Chandrasekhar recognizes that. He himself got EE and CS degrees and worked at Intel on the 80486 design—30+ years ago. But evidently he doesn't consider it important to get their advice on whether Moore's Law is being "pushed beyond its limits" or not? Or, are they telling him the M1 Ultra is a RISC-V chip?
I don't have any idea how this kind of nonsense gets put out by a ministry headed by a former 80486 design engineer.
I just realized that another one of India's 11 entries on the Nobelist list is Amartya Sen, a professor at Harvard in the US, who I should have included with the 3 other US NRI Nobelists. He grew up in India and went to school there; moved to the UK in 01953; alternated between the UK, US, and India until 01971; between the UK and US from 01971 to 01987; and he's been at Harvard ever since. He won his economics Nobel 27 years after his last stint in India, in 01998.
I wonder if he would have been able to do the brilliant work he has done had he stayed in India. The shameful affair at Narendra University suggests otherwise.
I wonder if he would have been able to do the brilliant work he has done had he stayed in India. The shameful affair at Narendra University suggests otherwise.
> and two of them are Mother Teresa and Rudyard Kipling, who did not have to suffer from the Indian educational system
Asia's first Nobel Laureate, RN Tagore also did not suffer Indian (British colonial) education system. He was home-schooled.
Asia's first Nobel Laureate, RN Tagore also did not suffer Indian (British colonial) education system. He was home-schooled.
Thank you for that correction! I wonder how many others on that list similarly escaped its clutches.
>> I think the problem with India is the people in charge
There is a subliminal sentiment in India - whatever it has achieved/achieves is despite the people in charge.
There is a subliminal sentiment in India - whatever it has achieved/achieves is despite the people in charge.
It's also a matter of priorities. India has(had) significant amounts of people living in pretty bad conditions ( like poor quality housing with no running water).
Which do you prioritise, lifting people out of poverty/squalid living conditions, research, industrial expansion, power projection (aircraft carriers so that India can protect it's interests, live up to it's potential, counter Chinese expansion), etc. ? There's a decent argument to be made that just encouraging and investing in industry and research will increase incomes and improve living conditions but it's unlikely to be sufficient.
Which do you prioritise, lifting people out of poverty/squalid living conditions, research, industrial expansion, power projection (aircraft carriers so that India can protect it's interests, live up to it's potential, counter Chinese expansion), etc. ? There's a decent argument to be made that just encouraging and investing in industry and research will increase incomes and improve living conditions but it's unlikely to be sufficient.
China has managed to do both.
Are supercomputers practical, or a vanity project?
Supposedly that depends in part on whether you are a nuclear power.
They very much are practical for all sorts of research, e.g. simulations of molecular dynamics, fluid dynamics, light scattering etc, all very relevant for medical research for instance. A lot of the research work I do wouldn't really be practical without access to supercomputers, yet the results feed back into pretty much every high-tech industry.
Once a working computer is available commercially, A mandate would be issued by the central government ministries to 250+ Public Sector Undertaking ( Companies with >50% govt equity) to procure only these RISCV computers. This way we can definitely bring it up to speed real fast.
PS: From my experience working currently for one of those PSUs .
PS: From my experience working currently for one of those PSUs .
I doubt this will happen, even if they do issue a mandate.
Indian government computers are still running windows 7 or so and its hard to get them to switch to Linux.
What happens when theyre forced to run Linux and a new architecture ? All of them will just obtain exemptions to continue using windows + x86 claiming some software they need doesnt work.
Teaching a 50 year govt employee how to use QEMU + Wine to emulate x86 and then run a translation layer to run windows software is impossible.
Indian government computers are still running windows 7 or so and its hard to get them to switch to Linux.
What happens when theyre forced to run Linux and a new architecture ? All of them will just obtain exemptions to continue using windows + x86 claiming some software they need doesnt work.
Teaching a 50 year govt employee how to use QEMU + Wine to emulate x86 and then run a translation layer to run windows software is impossible.
> Indian government computers are still running windows 7 or so and its hard to get them to switch to Linux.
In many ways, switching from Win7 to Linux is more convenient than going with Win 10 and more recent MS products. This is a significant opportunity where real change might be possible.
In many ways, switching from Win7 to Linux is more convenient than going with Win 10 and more recent MS products. This is a significant opportunity where real change might be possible.
Many departments in Indian govt using CentOS
How so? Who is going to rewrite decades worth of software to run on linux?
Win7 software tends to run quite well in Wine. Of course some things like document/spreadsheet macros are more problematic, but those are not that common and can be rewritten.
Almost everything is web now. Have friends in TCS, and they get a lot of government contracts.
Almost everything is accessed through web GUIs nowadays.
Almost everything is accessed through web GUIs nowadays.
If the government makes a political decision, it can and does browbeat PSUs into compliance. There will be a lot of teething troubles and loss of productivity. But the thing is it won't matter for PSUs, nobody expects them to be highly efficient. I remember reading years ago that IDBI (A quasi-PSU Bank) switched to Linux for their terminals. The core banking for most Indian banks is powered by Finacle on Linux.
What if it is for mobile phones or tables? Everyone now a days knows to use android phone/tablets.
Sounds more like a push to get a bigger discount out of Microsoft.
Microsoft, Oracle have significant lobbying power within the government and PSUs.
This was true ten years ago. Not aware of the situation now.
Indian PSUs pay millions of dollars for sub-quality software.
This was true ten years ago. Not aware of the situation now.
Indian PSUs pay millions of dollars for sub-quality software.
And this will give government departments one more excuse to not deilver on time, Computer is not working or too slow.
As someone who doesn't follow RISC-V too closely, how does the most modern one (either available or planned) stack up in terms of perf compared to x86/arm? Just curious when these will begin to become viable for consumer devices. Years? Decades?
[deleted]
In terms of current chips they're the best part of a decade away. You can't buy a RISC-V processor competitive with a good arm chip let alone an X86 or a really good arm chip like M1
Current cores, however, are fairly competitive in terms of perf per MHz, but this has to be taken with a grain of salt because the proof is in the taste not the ingredients.
Current cores, however, are fairly competitive in terms of perf per MHz, but this has to be taken with a grain of salt because the proof is in the taste not the ingredients.
RISC-V cores are about 4 years behind ARM. So most they are most suitable for embedded systems and single board computers at the moment.
At the lower end they have a big advantage as they can reach similar performance as Arm at half the silicon which translates into 4x lower price at similar volume of production.
But for high-end chips you will not see this difference.
SiFive has caught up about 2 years each year. So I suspect it will not work 3-4 years before RISC-V can compete with Arm desktop computers. Competing with Apple will take much longer.
But such perspectives kind of miss the point. Then beauty of RISC-V is that it can be used in all sorts of specialized hardware such as accelerators. You may be able to program AI engines or maybe even some kind of graphics card with RISC-V instructions in the future.
At the lower end they have a big advantage as they can reach similar performance as Arm at half the silicon which translates into 4x lower price at similar volume of production.
But for high-end chips you will not see this difference.
SiFive has caught up about 2 years each year. So I suspect it will not work 3-4 years before RISC-V can compete with Arm desktop computers. Competing with Apple will take much longer.
But such perspectives kind of miss the point. Then beauty of RISC-V is that it can be used in all sorts of specialized hardware such as accelerators. You may be able to program AI engines or maybe even some kind of graphics card with RISC-V instructions in the future.
If anything, a more streamlined frontend matters more at the high-end, because it enables more scalable decode letting you extract increased parallelism out of the code. Better use of your frontend complexity budget also makes it easier to use things like fused microinsn sequences, or the RISC-V compressed insn set which brings code density on par with x86 (an outstanding result for such a clean design) for both RV32 and RV64. This is pretty much what we see going from x86 to ARM, and RISC-V only goes further in the same direction.
Decode doesn't take up much space in a high-end processor. Even if your architecture's decoder doesn't "scale" as well, you can just throw a bunch more transistors at it to get performance. That said, I doubt there's many CPU designers unhappy about a simpler ISA...
If macro op fusion is viable then there are more opportunities to throw more transistors at it to get more performance.
It's not yet clear if macro-op fusion will really be a thing.
Hmm, I'm no expert on the subject, but I had heard that CMP/Jcc and TEST/Jcc macro-op fusion has been critical to i386 and amd64 performance, for both Intel and AMD processors, for about 15 years?
Those are "simple" fusions that processor do perform productively. The thing with RISC-V is that a lot of the design rides on "oh we're just going to combine all the very RISC instructions into macro-ops to catch up to what ARM is doing" except nobody is really doing that kind of fusion right now, so it's not clear if this is even feasible.
Hmm, not even the Allwinner D1 or the SiFive P650? In https://news.ycombinator.com/item?id=29423006 Bruce Hoult says SiFive has been doing macro-op fusion in one case since the 7-series, and I think he's the one that implemented it.
In https://news.ycombinator.com/item?id=29444322 "ruslan" links the original macro-op fusion stuff from 02016: https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fu... and https://arxiv.org/abs/1607.02318. Surprisingly, those present "shootout" results that are really just "effective dynamic instruction" counts and "dynamic byte" counts, ending in a "design proposal"; they don't seem to have simulated macro-op fusion at RTL level, much less in an FPGA or a MOSIS run.
In https://news.ycombinator.com/item?id=29444322 "ruslan" links the original macro-op fusion stuff from 02016: https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fu... and https://arxiv.org/abs/1607.02318. Surprisingly, those present "shootout" results that are really just "effective dynamic instruction" counts and "dynamic byte" counts, ending in a "design proposal"; they don't seem to have simulated macro-op fusion at RTL level, much less in an FPGA or a MOSIS run.
Certainly I didn't implement it, that was Andrew Waterman. I'm not a hardware person.
I think macro-op fusion (with a few exceptions) is useful only on a narrow set of mid-range cores. High end cores want to split everything up (RISC-V comes pre-split), while low end cores want to use as little hardware as possible.
There are a few exceptions, for example combining a LUI or AUIPC into a full 32 bit constant with the following instruction(s). There is a full 32 bits for that data path already, so that has zero effect on the back end (except just removing an instruction). SLLI/{SRLI,SRAI} pairs is probably another.
I think macro-op fusion (with a few exceptions) is useful only on a narrow set of mid-range cores. High end cores want to split everything up (RISC-V comes pre-split), while low end cores want to use as little hardware as possible.
There are a few exceptions, for example combining a LUI or AUIPC into a full 32 bit constant with the following instruction(s). There is a full 32 bits for that data path already, so that has zero effect on the back end (except just removing an instruction). SLLI/{SRLI,SRAI} pairs is probably another.
I appreciate the correction! Is anybody doing those?
> High end cores want to split everything up (RISC-V comes pre-split)
Yes but a high-end core does not necessarily splits instruction the same way as RISC-V does.
For instance an indexed store:
RISC-V ISA splits it into an ADD+STORE pattern which may be recognized by macro-op fusion, while a high-end core splits it into a store_address uop (that compute the effective address and update the address field into the store-buffer entry) and a store_data uop (that update the data field into the store-buffer entry, and this uop is "address agnostic")
Yes but a high-end core does not necessarily splits instruction the same way as RISC-V does.
For instance an indexed store:
RISC-V ISA splits it into an ADD+STORE pattern which may be recognized by macro-op fusion, while a high-end core splits it into a store_address uop (that compute the effective address and update the address field into the store-buffer entry) and a store_data uop (that update the data field into the store-buffer entry, and this uop is "address agnostic")
Little addendum:
Macro-op fusion (alone) does not only reduce the number of uop, it could also reduces physical register usage as intermediate results are not stored into physical registers.
For instance, the indexed load pattern (ADD+LOAD) without macro-op fusion needs:
- 2 physical registers in read;
- 2 physical registers in write (one per macro-op), meaning that 2 physical registers will be allocated.
While the macro-op fused version needs:
- 2 physical registers in read;
- 1 physical register in write, meaning that a single physical register will be allocated.
Macro-op fusion (alone) does not only reduce the number of uop, it could also reduces physical register usage as intermediate results are not stored into physical registers.
For instance, the indexed load pattern (ADD+LOAD) without macro-op fusion needs:
- 2 physical registers in read;
- 2 physical registers in write (one per macro-op), meaning that 2 physical registers will be allocated.
While the macro-op fused version needs:
- 2 physical registers in read;
- 1 physical register in write, meaning that a single physical register will be allocated.
> lot of the design rides on "oh we're just going to combine all the very RISC instructions into macro-ops to catch up to what ARM is doing"
There are more macro-op fusion suggestions for RISC-V precisely because RV instructions are simple. This gives more opportunity for macro-op fusion.
> so it's not clear if this is even feasible
What macro-op-fusion are you talking about exactly? Most of the macro-op-fusion suggested are quite trivial and have already been implemented
There are more macro-op fusion suggestions for RISC-V precisely because RV instructions are simple. This gives more opportunity for macro-op fusion.
> so it's not clear if this is even feasible
What macro-op-fusion are you talking about exactly? Most of the macro-op-fusion suggested are quite trivial and have already been implemented
> Most of the macro-op-fusion suggested are quite trivial and have already been implemented
In which chips, and how much of a win are they?
In which chips, and how much of a win are they?
I talk about feasibility, not about design win in a high perf. circuit, since there is no real high perf. RISC-V today and since it's the feasibility that is questioned by the parent.
I can't say if the macro-op fusion will be enough to beat ARM & x86, but I can tell it's feasible.
I can't say if the macro-op fusion will be enough to beat ARM & x86, but I can tell it's feasible.
What do you mean by "implemented"?
Clearly macro-op fusion is a computable transformation of the instruction stream, so macro-op fusion is certainly feasible. I think what Jha was questioning was whether catching up to ARM is feasible if your main weapon is macro-op fusion. The Celio/Dabbelt/Patterson/Asanović tech report I linked yesterday shows that it's promising, but it's been six years and I'd like to know if that's actually being tried and how well it works.
Bruce Hoult's comment from a few months ago suggests that it wasn't really being tried at SiFive, but he left SiFive a couple years ago and might be out of date, and the Honey Badger designs are potentially a whole new ballgame.
Clearly macro-op fusion is a computable transformation of the instruction stream, so macro-op fusion is certainly feasible. I think what Jha was questioning was whether catching up to ARM is feasible if your main weapon is macro-op fusion. The Celio/Dabbelt/Patterson/Asanović tech report I linked yesterday shows that it's promising, but it's been six years and I'd like to know if that's actually being tried and how well it works.
Bruce Hoult's comment from a few months ago suggests that it wasn't really being tried at SiFive, but he left SiFive a couple years ago and might be out of date, and the Honey Badger designs are potentially a whole new ballgame.
The thing that makes most macro op fusion non-viable on x86 is that most of the macro ops you'd want to fuse are already a single instruction!
All of the commercially available RISC-V processors I'm aware of are microcontrollers -- they're competing with ARM Cortex-M. They're still a ways off from anything that can compete with ARM Cortex-A application processors or Intel/AMD desktop/laptop CPUs.
Not just controllers. There are several commercially available single board computers running Linux. Check out the "explaining computers" YouTube channel for at least a couple fairly recent board reviews.
They are slow but do exist
They are slow but do exist
Many billions of RISC-V of CPUs have shipped, so, pedantically, that means they're already viable for including inside consumer devices. However as other replies have noted, you'll have to wait a number of years before they'll be used as the main CPU, rather than just some tiny core off on the side doing power management or whatever.
IIRC the Shakti family didn't include the C extension, which would make it incompatible with most Linux distros who have chosen to require it.
Is this still the case?
Is this still the case?
Even if that were the case, recompiling Debian with different compiler options is not rocket science—thanks to decades of tireless work by thousands of volunteers.
Probably someone will read your comment and think "the C extension" means "support for the programming language C", but that is not the case. Standard RISC-V instruction set extensions are identified by letters: M for multiply (and unfortunately divide), F for floating point, D for double-precision floating point, A for atomic memory operations (necessary for SMP), V for vector operations, and so on.
The C extension is the "compressed" extension, which represents the most common instructions in 16 bits instead of the usual 32. Without the C extension, RISC-V code is relatively bulky, which is a disadvantage not only for limited-memory microcontrollers but also because, if you have an instruction cache, less code fits into it, so most software runs slower. With the C extension, RISC-V code density is at least competitive with the best alternatives like Thumb2, and in most cases slightly better. This is particularly interesting in the 64-bit space, because arm64 (aarch64) has abandoned the Thumb2-style compressed instruction approach.
Probably someone will read your comment and think "the C extension" means "support for the programming language C", but that is not the case. Standard RISC-V instruction set extensions are identified by letters: M for multiply (and unfortunately divide), F for floating point, D for double-precision floating point, A for atomic memory operations (necessary for SMP), V for vector operations, and so on.
The C extension is the "compressed" extension, which represents the most common instructions in 16 bits instead of the usual 32. Without the C extension, RISC-V code is relatively bulky, which is a disadvantage not only for limited-memory microcontrollers but also because, if you have an instruction cache, less code fits into it, so most software runs slower. With the C extension, RISC-V code density is at least competitive with the best alternatives like Thumb2, and in most cases slightly better. This is particularly interesting in the 64-bit space, because arm64 (aarch64) has abandoned the Thumb2-style compressed instruction approach.
The very first Skakti test chip didn't support C. All their following ones do.
Vega doesn't seem to be supporting C extension. A very bad decision, if true. C is not expensive to support, and certainly cheaper than building larger icache to make up for not supporting it -- let alone the cost of compiling your own Linux distro if you don't support C.
I'm not aware of a single commercially-produced RISC-V microcontroller that doesn't support the C extension, so there's no reason at all that something with MMU and FPU wouldn't.
Leaving it out is just something that is possible for student projects and to simplify early teaching, not something that is a good idea to do in real life.
Vega doesn't seem to be supporting C extension. A very bad decision, if true. C is not expensive to support, and certainly cheaper than building larger icache to make up for not supporting it -- let alone the cost of compiling your own Linux distro if you don't support C.
I'm not aware of a single commercially-produced RISC-V microcontroller that doesn't support the C extension, so there's no reason at all that something with MMU and FPU wouldn't.
Leaving it out is just something that is possible for student projects and to simplify early teaching, not something that is a good idea to do in real life.
I don't know whether Shakti didn't support C extension in the past, but it certainly supports it now. I just checked the decoder source code right now.
I remember an equally ambitious initiative called HSMC (Hindustan Semiconductor Manufacturing Company) was in talks a few years ago. I hope this one takes-off the ground in a better way. It's about time.
Here’s hoping there’s a standard that develops for building the motherboards and for how peripherals communicate etc so that it avoids the weirdness in the ARM ecosystem.
First time in my life seeing a localized ISA
China already did that decades ago. They initially choose MIPS with their LoongSon processors in 2000s, and pivoted to arm processors with the mobile chips wave later with Allwinner and Unisoc. They had supercomputers running with their own MIPS cpus too.
There's nothing "localized" or exclusive to India about RISC-V, it's simply the most prominent open ISA at present.
Used to be instruction sets were corporate (IBM, DEC, Burroughs etc), seeing one mandated by a country really isn't that different
[deleted]
abc_lisper(1)
They should also invest more in research. Why does india have less supercomputers than sweden? Does this mean that india is doing less research in some aspects than a country of just 10 million people?
https://en.wikipedia.org/wiki/TOP500
India is not and has not been living up to its potential. But as has been shown in the US, Japan, China, etc, all it takes is political will and political stability and you can make significant strides in just one generation.