Hacker News Reader

Comment by CalChris | Hacker News Reader

AJIT uses SPARC-V8 [1]. There's another project, the Shakti, which uses RISC-V [2].

[1] https://www.indiatimes.com/technology/news/meet-ajit-1st-ent...

Yes I was also quite surprised not to see SHAKTI mentioned here since it seems to be a far more advanced project. [Edit: After reading a bit more I see the aim of this project is to build local FAB experience, whereas SHAKTI seems to be about developing an Indian-designed server chip which is manufactured abroad. Both are independent and worthwhile goals.]

Some of their team contacted me about porting Fedora/RISC-V to SHAKTI. (Unfortunately because SHAKTI doesn't support the Compressed extension, which both Fedora and Debian require, straight Fedora/RISC-V binaries won't run on SHAKTI and so the whole distro will need to be rebuilt).

Hi rwmj,

I think there's been some blur in the goal here. SHAKTI's aim is not to just build a Indian-based server chip manufactured abroad. For instance, if you see their tapeouts page (http://shakti.org.in/tapeouts.html), you can see that they have taped out a chip in India as well with 180nm..

Also, Compressed instruction support has been supported on SHAKTI since and a beta version is now available publicly. The reason for that contact was to try to port Fedora on the already taped out chip which does not support compressed instructions.

I didn't know that Intel made their fab lines available but apparently they do.

More on the India built version of SHAKTI: https://link.medium.com/L25lUFUo6V

Runs at 70 MHz

The key difference between the AJIT and Shakti seems to be the fabrication partner. AJIT is fabricated locally. Shakti was built at an Intel Fab using its 22nm process. They serve different purposes.

What makes the design tied to the fabrication partner though? Why couldn't this team have used the Shakti design?

Because it's 64 bit and significantly complex, probably far too large for the 180nm process.

The SHAKTI they taped out with Intel 22nm FinFET is AFAIK conservatively an order of magnitude less complex than the Pentium III, which was successfully manufactured on 250nm and 180nm.

Sparc V8 would mean 32 bit. Which is somewhat curious, as servers are mentioned as a potential market in some of their material.

Does anyone know the license for SPARC-V8?

I would imagine it would be important to use an open ISA for such a strategic project.

It's mostly open. There are some annual dues you have to pay, which range from very low for academia, to 5 figures/year for commerical manufacturers. https://sparc.org/faq/

This is insane. With this in mind, why would they not use RISC-V?

My better guess is that they started it a long time ago. Long enough for RISC-V not to be in usable condition.

Hopefully, they'll redo the frontend.

At scale, it's much cheaper than, say, ARM, where you pay a percentage of revenue based royalty.

Yes, and it likely made sense if risc-v wasn't ready back when they started this project.

SPARC already has an ecosystem thanks to Sun/Oracle. Gaisler did open implementation, Leon3. Sun/Oracle did T1 and T2. Registration to say it was SPARC compatible was only $99 when I looked at it years ago. My only question was why the heck isn't someone cranking them out for security or FOSS markets?

Didn't get a chance to find out. Now we have RISC-V chips being developed with lots of companies getting behind it. Still easier to get ahold of SPARC chips, though. I'll also add that quite a few projects in academia used SPARC. OpenPiton being one that might justify using SPARC over RISC-V, esp if NUMA machine. :)

http://parallel.princeton.edu/piton/#

RISC-V is getting quite the ecosystem, though.

IIRC, an effort made by Western Digital has made it possible to cross-compile stuff for RISC-V.

Debian works just fine on RISC-V silicon. Right now the big thing seems to be getting real-time, hardware-supported JavaScript processing working so that the modern web works on it well.

>real-time, hardware-supported JavaScript processing

You mean JIT, right?

The benefits of being interpreted falls flat when, in practice, everyone needs to run a highly tuned just in time compiler.

Yes, that. Words were failing me, as was Google.

The cross compiler looks like it was mostly contributions from SiFive, not WD. WD uses it, and references it.

There are actually a few open source SPARC implementations, including the first two Niagra revisions.

https://en.wikipedia.org/wiki/SPARC#Open_source_implementati...

Thanks. I was about to write about no need for yet another instruction set.

Why? There's still a lot of opportunity for advancement in this area.

Reply on news.ycombinator.com