What would you like to see in The Next Chip?

[eriksl]

The ESP-S3 is based on Xtensa cores which, as opposed to the ESP8266's version, have a register window. In many cases no access to the stack is required, only the register window start pointer is moved.

I do not know if the RISC-V cores also have this feature, but most modern processors have this, so I'd expect so.

Finishing with my well-known rant: if you're doing things that are so heavily dependent on timing, I think you're doing something wrong:
- use one of the many hardware modules that will take of timing perfectly, in hardware; this is a requirement in a multithreading multicore environment like we have on ESP32
- if you really just use bit banging workarounds, I'd suggest using a microcontroller that's more suitable for that, one that has predictable instruction timings, no mandatory interrupts (so no wifi or bluetooth...). There are plenty to choose from.

[eriksl]

Yeah more wishes from me:
- three or even just two I2C modules that have exactly the same features and the same interface, even though one of them is part of the RTC/ULP module. Now the RTC/ULP is very different and is very limited.
- I2C hardware modules with less bugs/workarounds required

[Baldhead]

The ESP-S3 is based on Xtensa cores which, as opposed to the ESP8266's version, have a register window. In many cases no access to the stack is required, only the register window start pointer is moved.

I do not know if the RISC-V cores also have this feature, but most modern processors have this, so I'd expect so.

Finishing with my well-known rant: if you're doing things that are so heavily dependent on timing, I think you're doing something wrong:
- use one of the many hardware modules that will take of timing perfectly, in hardware; this is a requirement in a multithreading multicore environment like we have on ESP32
- if you really just use bit banging workarounds, I'd suggest using a microcontroller that's more suitable for that, one that has predictable instruction timings, no mandatory interrupts (so no wifi or bluetooth...). There are plenty to choose from.

Regardless of the application, a modern microcontroller must have shadow registers.

[Sprite]

Regardless of the application, a modern microcontroller must have shadow registers.

FYI, I floated that to our CPU team at some point, with example implementation and all. They didn't implement it; modern (in-order) CPUs can do almost one instruction per clock cycle, which means the register file is very heavily used and usually part of the paths with the least slack. Implementing one or more extra sets of those means the CPU can't make its timing budget anymore, meaning it needs to be clocked slower. So It's not just 'throw some shadow registers at it and be done', there's actual trade-offs there.

[eriksl]

Are you discussing RISC-V now? As Xtensa has a register window?

[Sprite]

My previous comment was about a RiscV CPU indeed. I don't think we can mess with the deep internals of Xtensa, as we don't have the RTL for it (it belongs to Cadence, not us).

[eriksl]

I am not so familiar with RISC-V, doesn't it have register windows? Or is not (yet) enabled in the ESP's?

Back on topic:

I'd like to see an ESP32-S3 (so with all the bells and thrills possible) but then with 2 RISC-V cpu's, high speed of course, 240 MHz minimum. As discussed before three or even two I2C peripherals that are exactly the same in features and software interface (even though one of them can also be used by the ULP). Less, in my opinion, artificial limits, like 14 bits timers for the LEDC timer, why not use 16 bits or even more, I don't think that would be that hard to make in hardware. Make it possible to use a doubled or tripled base clock (160, 240 MHz), so we can make LED PWM circuits that are fine resolution (> 14 bits) and high frequency (when going above 14 bits). But also add dividers per timer so the minimum frequency isn't too high (CMOS transistors don't like to be switched at a high frequency when they're switching high power). So I'd say the minimum PWM frequency should be 30 Hz or at least 60 Hz, even at lower resolution (less bits).

[Sprite]

I am not so familiar with RISC-V, doesn't it have register windows? Or is not (yet) enabled in the ESP's?

It does not, and afaik there's also no extension for that. I think that RiscV solves things like this in a different way: you can have a small subroutine that does the register saving and loading, and if you have some optimized way to do this, you can replace that subroutine with that. I don't think we currently do this, although it may be an optimization we may be able to do given that on most 'large' ESP32s (specifically the ones with the AI instruction set) the datapath to RAM is wider than 32-bit.

I'd like to see an ESP32-S3 (so with all the bells and thrills possible) but then with 2 RISC-V cpu's, high speed of course, 240 MHz minimum. As discussed before three or even two I2C peripherals that are exactly the same in features and software interface (even though one of them can also be used by the ULP). Less, in my opinion, artificial limits, like 14 bits timers for the LEDC timer, why not use 16 bits or even more, I don't think that would be that hard to make in hardware. Make it possible to use a doubled or tripled base clock (160, 240 MHz), so we can make LED PWM circuits that are fine resolution (> 14 bits) and high frequency (when going above 14 bits). But also add dividers per timer so the minimum frequency isn't too high (CMOS transistors don't like to be switched at a high frequency when they're switching high power). So I'd say the minimum PWM frequency should be 30 Hz or at least 60 Hz, even at lower resolution (less bits).

Please take a look at the ESP32-P4, I think it satisfies a fair amount of the things you want:
[*] Dual RiscV up to 400MHz
[*] 3 I2C peripherals, although they're not exactly the same (LP one doesn't do slave)
[*] 20-bits PWM LEDC, although the max-freq clock source is 'only' 80MHz. (I need to poke the digital team for this as 20bit 80MHz means 8Hz max pwm freq which is too low)

The -P4 obviously doesn't have WiFi or other radios, but I don't think I'm revealing any secret info if I extrapolate that it's likely that future chips will be partially based on the state of the art of tech within Espressif that is also within the ESP32-P4. If you can tell me why you'd like the things that aren't satisfied by the current P4 loadout and your reasons are good enough (i.e. in the end allow us to sell more chips to make up for any extra silicon space they cost), I can discuss them with my colleagues.

Note that I don't think there's merit to low-resolution low-frequency support, as it's trivial to simply select a higher resolution and multiply your PWM value with a constant to match.

[eriksl]

Interesting, thanks!

I am already, eagerly following any progress/announcements around the P4, indeed. And yes, I do need wlan and bluetooth, so for now it's a no-go.

I don't need I2C slave access, so that's no problem. So as long as all of them can be accessed the same way, I'd be happy. Even if I would need it, it wouldn't be show stopper to have the slave on #0 or #1 only.

> [*] 20-bits PWM LEDC, although the max-freq clock source is 'only' 80MHz. (I need to poke the digital team for this as 20bit 80MHz means 8Hz max pwm freq which is too low)

Exactly. 18 bits would be acceptable for me, then you'd have a refresh of 32 Hz which is still too low.

I am worried about a minimum PWM speed too, look at the PDM peripheral, it can't do frequencies below something like 2 kHz. This is unsuitable for controlling power MOSfets, it will burn them (at least out of their safe operating area). So therefore I'd like attention to the lowest possible frequency as well, make sure there is enough clock divider "space" to reach low frequencies.

And no, sorry, you won't get any extra turnover from me, I am a very small customer. So I can only ask very politely