What would you like to see in The Next Chip?

[WiFive]

- More ram: That's kinda hard... the largest part of the chip already is RAM, and making more of it RAM decreases yields and increases cost by a fair amount...
- 'Real' deep sleep: Well, the hardware on the ESP32 already supports keeping RAM powered in deep sleep, but there's a physical limit you'll always run into, and that is that keeping RAM powered eats into the power budget by a lot. Maybe later on we can make some kind of 'hibernate' mode that saves the entire state of the CPU to flash, for true zero-power deep sleep and instant state restore... Anyway, what I'm saying is don't expect new silicon to change the status quo here; if we implement something like this, it's probably also going to support the ESP32; the issues are mostly in software.

- doesn't have to be on die, but in package (mt7686). 2mb+ is pretty much what iot chips from the big players are shipping now.
- how about fram or sub threshold in package

[WiFive]

More pins! No pin mux conflicts! With strapping pins or peripherals. Have you seen the number of pins t200/artik053 has?

[ESP_Sprite]

USB Device+host: As far as I understand, dual-mode doesn't take up that much more silicon (protocol is nearly the same anyway), so we'll probably strive for that. Integrated PHY is something I want as well; specifically for USB1.1 it should be possible.

Quadrature decoder: You can actually already do that with the ESP32: as far as I know, the pulse counter is intelligent enough to do quadrature decoding.

In package PSRAM: That is an option. Will look into this.

SOIC28 package e.d.: Not sure if that's an option. I've heard something from an analog guy about impedances of pins that can mess up WiFi reception... also, not sure if there's a market for it. (Which unfortunately is a requirement. Otherwise, I'd have a run of DIP ESP32's made, just for shits and giggles.)

On chip crystals, PSRAM, matching circuitry etc: Sorry, but those things are pretty hard to integrate on the silicon. You're more likely to get that from a module like this than on the same silicon as the rest of the new chip.

Backwards compatibility with ESP-DF: At the moment (in contrast to the ESP8266 SDK back then), ESP-IDF does everything we need. Even if we were to change a lot on the chip, I see no reason not to keep using it.

More pins: Will look into this. There's a cost/benefit thing there too, I's guess: if we need to switch to BGA, I'd guess modules need to go through more extensive testing because you can't visually inspect the pins anymore.

[cjsm74x]

Hardware accelerated graphics (like STM32 for example)

[nicolas]

Thanks for asking. Again, USB host+device would be great as long as CPU overhead is minimal (but in the meantime, I'd still be glad if you could share your experimental RMT implementation of Host USB 1.1)

And the never-ending and boring MORE list ;
- more "no wait-state" DRAM + default 4MB of PSRAM onboard
- improved latency/speed on classic GPIO
- more I2S interfaces, I love them
- more configurable DACs per I2S, like 4 or more, through I2S matrix, ie 24 channel on one I2S -> 3 x 8 bit DACs, or 24ch -> 4 x 6bits (configurable with static unused bits)
- 2 X independant frequency and better precision PLLs (possibly supported by other interfaces than I2S)
- more I/O pins and ubiquitous 5V tolerant pins FTW !

Bonus : mini CPLD ! Not really kidding, some minimal PSOC-style, high-speed digital logic would be handy to have.

[mnemonix]

I would like to see:

- RISC-V ISA instead of Tensilica (spares some license costs and allows upscaling to 64/128 bits later, I see Espressif is already a Risc-V member)
- more than 2 cores
- Better ADC specs (range down to zero)
- Maybe a fast, low resolution ADC, i.e. 8bit 32 MHz
- Integrated SigmaDelta Audio DAC (min 16bit, 2 channels)

[ESP_igrr]

I would like to see:
- more than 2 cores

Can you give us some indication what kind of application you are aiming at? Do you need symmetrical cores or specialized ones / accelerators?

[ESP_Sprite]

- Hardware accelerated graphics: What exactly would you like to see? We already have the hardware to control parallel displays in hardware, is there anything you'd like to see added to that?
- More speed on GPIO: Will look into that. Agreed that the APB bottleneck feels somewhat uncomfortable for bitbanging tricks.
- More DACs: may I ask what things you have in mind where e.g. PWM doesn't suffice? As far as I understand, analog stuff on a digital chip is somewhat of a PITA.
- More PLLs, more I2S: Noted.
- Mini CPLD: Hehe, got some ideas about that myself. Not sure if they're all doable, but we'll see.
- More than 2 cores: Not saying we won't do that, but just curious: can I ask if you have specific use cases you're able to do with more cores that you can't do with two?
- RiscV: Not saying we're not looking into this, we're not a RiscV foundation member without reason but fyi, your argument specifically with respect to licensing cost unfortunately doesn't hold much water. Tensilica isn't the most expensive core to license, and if we go to RiscV we still need to license a core for it, invest a lot of time or effort to adapt an open-source core or even more time to build our own. Especially with multiple cores, the latter two can get hairy: things like multicore cache/CPU consistency unfortunately aren't the easiest things to solve. There are other reasons we're looking into RiscV for sure, but cost isn't really one of them.
- Integrated hi-res SIgmaDelta DAC: Hm, there's an idea. Although I'm wondering if we don't already have something similar with the PDM support of one of our I2S peripherals.
- Better ADC specs: Agreed that we can improve upon our current ADCs.
- Fast lo-res ADC: Can I ask what use case you have in mind for this?

[WiFive]

Also *cough* nosiliconbugs *cough*

[ESP_Sprite]

No silicon bugs? But where else would our software developers get the thrill of running into a problem and not knowing if it's the chip or their program? And what other excuse would they have to talk to the digital guys? /s