Oh Renesas are ex-Hitachi; well that explains a lot how such a unfamiliar name is one of the top chip companies. Reminds me of the convoluted pattern where Motorola split into Freescale who were acquired by NXP who in turn are ex-Philips. Occasionally I feel the need for some sort of chart of the semi industry to keep track who is who.
Fun fact: Broadcom is now actually a former HP spin-off spin- off (HP->Agilent->Avago), but is now worth more than Hewlett Packard Enterprise, HP Inc, Agilent and Keysight combined.
Oh, the website is back up. It's been down for months and the project seemed to have gone into stealth mode (or maybe died). Still no news for about three years though. Unsure why this is being posted now, unless I've missed some news.
Personally I think they need someone with the time to engage with/build a community. At the moment they only seem to have people actually building things, nobody is acting as an evangelist.
I am seeing more and more of what look like viable alternatives to RISC-V. Agner Fog has an ISA with vector instructions that should influence all future designs. The Bitmanip extension to RISC-V is likewise an education, and should inform any future designs.
RISC-V itself? The core design seems very academic. Seriously, who omits rotate instructions?
Someone trying to minimise gate counts (a full barrel-shifter is an N squared sort of thing)
People forget that RISC comes out of researchers doing analysis of instruction use, and removing stuff you don't use much - if you can bump the clock speed by 5% by halving the size of a full barrel-shifter then you can execute more instructions per second even if you have to use 3 to do a rotate
ROT (and shifts) is N log N. Look at shuffle networks.
If you have shift operations in the core, their is no reason you cannot have a ROTATE operation. It doesn't add much additional HW.
Yeah, RISC-V omitted rotate from its 47 instruction base ISA. You don't get to be that small without cutting the unnecessary and rotate would require a barrel shifter which in turn would rarely be used. Instead, rotate (rol, ror, rori) can be found in the “B” Standard Extension for Bit Manipulation.
Viewing it from the other side, when you split some of the useful but different operations into a bunch of orthogonal extensions, then when you have to do something really useful, you have to implement the entire extension. That equally bloats your core.
In this case, one cannot just implement ROT, one has to implement the entire Bit manipulation extension. Scale it up across the extensions - say you need 3 basic ops from 3 different extensions.
Sure you can add your custom ROT op, but then you end up breaking compatibility.
[Edit] The principle of removing unused/rarely used HW goes for a toss since now you have a bunch of operations from these extensions that would lie unused yet consume HW. It is not the basic operations that cause bloat, it is the functional variants - need to support different width, indexing, different constant. In this case shift and rotate have the same function. Immediate ones are the variants.
An "academic" design is better than the armchair design of somebody who doesn't know how barrel shifters are implemented. Sure, you could microcode it, but are the instructions really that big?
If you don't have a barrel shifter in your design, but your design is microcoded, you may choose to implement a rotate with a few μops, much the same way that you would write it in software.
They are trying to be big and small. When the Intel dropped its barrel shifter, they caught a lot of hell for the massive performance hit. They promptly re-included it in processors following the P4.
That ROT is 3 instructions rather than 1 on the absolute base RISC-V design is the most common criticism I see of RISC-V on HN bodes well that it is a good design.
People are adopting RISC-V not because it is an order of magnitude better ISA, but it frees them from vendor lock-in.
Whether it is the one good design to rule them all, we'll only be able to tell after a decade or two when the computing/tech world has moved on to different applications.
For e.g. what happens when 128b register widths become the norm ?
I suspect the base core and may be the FPU will remain relevant (because by then it would be legacy with vast amount of software base), however the other extensions will be superseded/replaced. This will lead to managing the extensions with conflicting encoding like one has to manage different SW library versions.
There was a publication in IEEE COOL Chips 21 (2018) [978-1-5386-6103-1/18] which compared a closed source implementation by a company (whose founder was involved in the creation of SuperH i think) of SH2 with RISC-V and an historic (pirate (as in patents were not expired then)) implementation of SH2 called Aquarius by some hobbyist.
The comparison seems to have some methodological flaws. But one result is, that is unaffected by them in my opinion is "that 2 stage SH2 re-implementation" needs fewer FPGA resources than "that 2 stage RISC-V re-implementation" on the same hardware at the same clock.
That honestly does not say much but it is the best comparison i am aware of.
I recently did technical deep dives on my late model Volvo XC90 and XC60. I was amazed to still see SuperH SH4 processors in use in various parts of the telematics system.
I worked in automative for lots of years. Up until around 2010 SH4 was mostly the dominating architecture for infotainment systems. Either with Windows CE or QNX running on top of it. Due to long development and product cycles as well as software reuse new cars with SH processors might have been released up to much later points in time.
The community communication has lot's of room for improvement. For example the mailing list is down for over an year. The website is not really updated. All communications happens p2p over eMail or is not logged like the IRC. This is frustrating.
Their roadmap did not work out because no plan survives contact with the enemy. From what i gathered J4 and J64 were targets in which there was not so much interest. (The customer demand was for J1 and even smaller ones from fabs who want to add it to their library.)
They actually made it past J2 since J1 is available here https://github.com/cr1901/jcore-j1 . Note: this is hosted by a community member not J-Core itself.
The past development model seem to have been: Develop solution in house for client at SE-Instruments, ask if they can open source it later.
There was a push on #j-core on Freenode for a new source release last week but nothing has materialized yet.
Neat, but it looks like this hasn't been in development since 2016. I would think it's probably best to use a RISC-V design if you want an open RISC CPU core to put on an FPGA. You'll get better compiler and tool support, and probably a wider variety of available designs.
