Renesas Unveils the First Generation of Own 32-bit RISC-V CPU Core

[erek]

Very nice

"

"Renesas takes pride in offering embedded processing solutions for the broadest range of customers and applications," said Daryl Khoo, Vice President of the IoT Platform Division at Renesas. "This new core extends our leadership in the RISC-V market and uniquely positions us to deliver more solutions that accommodate a diverse range of requirements."

"We congratulate Renesas on achieving its recent milestone in 32-bit RISC-V MCU architecture development," said Calista Redmond, CEO at RISC-V International. "This achievement exemplifies how RISC-V ecosystem partners, such as Renesas, are rapidly advancing RISC-V innovation. Our RISC-V community now spans 70 countries with more than 4,000 members, and we eagerly anticipate further innovations emerging from this dynamic, expanding market."

The Renesas RISC-V CPU achieves an impressive 3.27 CoreMark/MHz performance, outperforming similar architectures on the market. It includes extensions to improve performance, while reducing code size.

Renesas is sampling devices based on the new core to select customers, with plans to launch its first RISC-V-based MCU and associated development tools in Q1 2024. Details of the new MCU will be published at that time. More information about RISC-V solutions is available at: renesas.com/risc-v. A blog article about the new RISC-V CPU is available here."

https://www.techpowerup.com/316205/...n-32-bit-risc-v-cpu-core-ahead-of-competition

 

[Xar]

Very nice

"
View attachment 617002
"Renesas takes pride in offering embedded processing solutions for the broadest range of customers and applications," said Daryl Khoo, Vice President of the IoT Platform Division at Renesas. "This new core extends our leadership in the RISC-V market and uniquely positions us to deliver more solutions that accommodate a diverse range of requirements."

"We congratulate Renesas on achieving its recent milestone in 32-bit RISC-V MCU architecture development," said Calista Redmond, CEO at RISC-V International. "This achievement exemplifies how RISC-V ecosystem partners, such as Renesas, are rapidly advancing RISC-V innovation. Our RISC-V community now spans 70 countries with more than 4,000 members, and we eagerly anticipate further innovations emerging from this dynamic, expanding market."

The Renesas RISC-V CPU achieves an impressive 3.27 CoreMark/MHz performance, outperforming similar architectures on the market. It includes extensions to improve performance, while reducing code size.

Renesas is sampling devices based on the new core to select customers, with plans to launch its first RISC-V-based MCU and associated development tools in Q1 2024. Details of the new MCU will be published at that time. More information about RISC-V solutions is available at: renesas.com/risc-v. A blog article about the new RISC-V CPU is available here."

https://www.techpowerup.com/316205/...n-32-bit-risc-v-cpu-core-ahead-of-competition

RISC-V is a good theory, but it needs more action in practice. When it comes to gaming and HEDT usages I mean.

 

[Zarathustra[H]]

RISC-V is a good theory, but it needs more action in practice. When it comes to gaming and HEDT usages I mean.

I am hopeful RISC-V is successful.

It will be great to have an open binary compatible instruction set any competitor can use.

But with RISC-V binary compatibility might be the problem, as it is designed to be customizeable based on the desired capability.

I think they may need to freeze a subset of instructions to ensure that RISC-V can be a more widespread compatible ISA.

 

[uOpt]

Why 32 bit? Are they insane?

 

[Absalom]

Why 32 bit? Are they insane?

Do we know their target markets? 32-bit is good enough for most automotive embedded markets as you don't really need 64-bit addressable memory. It is a strange choice, but maybe they've been sitting on the design for ten years?

At work, we were using a 32-bit ARM Cortex based SoC in our embedded products right up until this year. The only reason we switched to ARM64 is because the SoC went EoL. 32-bit was more than enough for our needs (automotive product).

 

[Nobu]

The blog post says they're for ASSP device voice and motor control, so 32-bit is probably fine. They can be used for other purposes, but for their primary usecase I don't see any problems with it.

 

[uOpt]

The next thing we know is the car companies whining how hard it is to port their software to 64 bits...

 

[Zarathustra[H]]

Do we know their target markets? 32-bit is good enough for most automotive embedded markets as you don't really need 64-bit addressable memory. It is a strange choice, but maybe they've been sitting on the design for ten years?

At work, we were using a 32-bit ARM Cortex based SoC in our embedded products right up until this year. The only reason we switched to ARM64 is because the SoC went EoL. 32-bit was more than enough for our needs (automotive product).

Heck, it wasn't all that long ago automotive applications were still using embedded 286 chips...

While the desktop version of the 286 ceased manufacturing in ~1991, I'm pretty sure special embedded versions (with higher clocks than the old desktop parts) lived on for a couple of decades after that, and were sold for industrial & automotive applications.

I vaguely remember there being up to ~25Mhz variants on smaller process nodes than the 8 - 12 Mhz desktop CPU's from the 1980's.

It didn't need to have screaming CPU performance or be able to access large amounts of memory. It just needed to be cheap and reliable.

For embedded firmware type code, the 16MB RAM the 286 maxes out at is really quite a lot.

Surprisingly I can't find anything about that in my google searches right now, but I'm pretty sure this didn't come from some sort of fever dream I had.

Anyway, the point here is that yes, 32bit is more than enough for these types of applications, just as the 16bit 286 was.

Though it is kind of curious that they wouldn't pursue a 64bit design just to make it more general purpose in its applicability.

 

[erek]

Heck, it wasn't all that long ago automotive applications were still using embedded 286 chips...

While the desktop version of the 286 ceased manufacturing in ~1991, I'm pretty sure special embedded versions (with higher clocks than the old desktop parts) lived on for a couple of decades after that, and were sold for industrial & automotive applications.

I vaguely remember there being up to ~25Mhz variants on smaller process nodes than the 8 - 12 Mhz desktop CPU's from the 1980's.

It didn't need to have screaming CPU performance or be able to access large amounts of memory. It just needed to be cheap and reliable.

For embedded firmware type code, the 16MB RAM the 286 maxes out at is really quite a lot.

Surprisingly I can't find anything about that in my google searches right now, but I'm pretty sure this didn't come from some sort of fever dream I had.

Anyway, the point here is that yes, 32bit is more than enough for these types of applications, just as the 16bit 286 was.

Though it is kind of curious that they wouldn't pursue a 64bit design just to make it more general purpose in its applicability.

Why 32 bit? Are they insane?

what if they have a Paginated (32-bits addressable at time) framework overlaying the memory space on a software or firmware layer to extend the apparent physical addressing although via some potential latencies?

 

[Xar]

what if they have a Paginated (32-bits addressable at time) framework overlaying the memory space on a software or firmware layer to extend the apparent physical addressing although via some potential latencies?

Semi 32/64 compatible likely. No company in the right mindset would go solely 32-bit in 2024.

 

[Red Falcon]

Heck, it wasn't all that long ago automotive applications were still using embedded 286 chips...

While the desktop version of the 286 ceased manufacturing in ~1991, I'm pretty sure special embedded versions (with higher clocks than the old desktop parts) lived on for a couple of decades after that, and were sold for industrial & automotive applications.

I vaguely remember there being up to ~25Mhz variants on smaller process nodes than the 8 - 12 Mhz desktop CPU's from the 1980's.

The same thing was done with the embedded Motorola 68000 CPUs where the 32-bit original was released around 1979 and ceased production in the late 1990s.
The embedded version was used up until the mid-2010s and was only replaced in favour of embedded ARM which to this day is all 32-bit, albeit with a larger memory address bus.

It didn't need to have screaming CPU performance or be able to access large amounts of memory. It just needed to be cheap and reliable.

For embedded firmware type code, the 16MB RAM the 286 maxes out at is really quite a lot.

Correct, while the 80286 is a 16-bit CPU the memory address bus is 24-bit which caps out at 16MB of addressable RAM, similar to the Motorola 680X0 CPUs from the 1970s-1980s.
I don't think there is a need for 64-bit embedded CPUs/SoCs at this time due to the increase in code base size, potential compatibility issues with existing 32-bit code, and the lack of need for addressable RAM and hardware for such tasks to keep costs down.

 

[Zarathustra[H]]

Correct, while the 80286 is a 16-bit CPU the memory address bus is 24-bit which caps out at 16MB of addressable RAM, similar to the Motorola 680X0 CPUs from the 1970s-1980s.
I don't think there is a need for 64-bit embedded CPUs/SoCs at this time due to the increase in code base size, potential compatibility issues with existing 32-bit code, and the lack of need for addressable RAM and hardware for such tasks to keep costs down.

Agreed. It depends on the application, right?

Engine management system, ABS, traction control, stability systems, and other firmware type things that control the cars behavior are probably just fine at 32bit.

Only place you might want/need more is with the fancy entertainment systems cars come with these days, and those are typically a separate module anyway.

 

[Lakados]

As stated above there are lots of industrial applications for 32 bit, there are so many legacy technologies still in active use in vehicles, machinery, manufacturing, and they are still made on 160nm or larger because it’s cheap, trustworthy, and it just works.

Fabs are getting tired of making those, silicon is too expensive to be wasting it on 200mm wafers, and the government subsidies keeping those parts cheap won’t continue forever.

RISCV can very much be the answer to this problem and the first companies to deliver those industries their desired chip will likely become the provider for them for the next decade or more.

 

[erek]

Agreed. It depends on the application, right?

Engine management system, ABS, traction control, stability systems, and other firmware type things that control the cars behavior are probably just fine at 32bit.

Only place you might want/need more is with the fancy entertainment systems cars come with these days, and those are typically a separate module anyway.

Scope this out,

https://www.nextplatform.com/2023/12/01/meta-sees-little-risk-in-risc-v-with-custom-accelerators/