memw details?

[jeeves]

I couldn't find this info in any docs. How many cycles does memw take, on avg and in worst case? I found online that on esp8266 (where it's supposedly a nop) it takes two cycles.

Then, are the reads on the APB/AHB bus (0x6000....) speculative like DPORT? IOW, could the memw be dropped for accesses via that bus? (and why do some sources call it APB and some AHB?)

The errata doc at least specifices that APB writes are supposed to not be speculative. They are told to be slower, but that is also unclear on how much slower. Just the 80MHz vs 240MHz difference?

[ESP_Sprite]

As it effectively flushes memory writes to memory, it depends on how long that flushing takes. That can be very quick (in case of no outstanding memory writes or only outstanding writes to RAM) to nearly a hundred cycles (for e.g. memory flushes to RTC slow RAM)

AHB/APB reads, to my knowledge, are not speculative. I think APB reads are slower by the 80/240MHz difference, but there may also be some latency to account for.

[jeeves]

Is there info on all kinds of flushes and their delays? And what types of RAM are used by which components. E.g. if I don't use RTC anywhere, is there a possibility the wifi uses it "secretly", or some other component.

[ESP_Sprite]

No, sorry. In general, there are so many things influencing the duration of instructions in a modern SoC like the ESP32 that putting out exact cycle numbers isn't really useful anymore. If you can tell me what you need to know this for, perhaps we can suggest an alternate approach though.

[jeeves]

For my GPIO polling code, see the Unreliable GPIO topic. memw seems to have the potential to cause long delays, so I'd like to know the details of how long and when - even if there's enough headroom, minimizing variance is nice.

[jeeves]

https://esp32.com/viewtopic.php?p=35711#p35711

In the event of a cache miss, the cache line is automatically filled via a read from the flash chip. The cache line size is 32 bytes. With Quad SPI (QIO mode) this requires something like 75 clocks to fill the cache (8 clocks for the command plus 64 clocks to read 32 bytes of data at 4 bits per clock). At 80MHz (max flash speed) this means 1000ns to read a line, approx 16MB/sec max throughput.

The devkitC's recommended default setting is 40MHz, aka one cache miss would be 2us. I presume memw will wait for another core's cache miss?

This then makes me question which buses get locked by that cache miss DMA exactly. Does it lock dport or apb? Main memory naturally, but over what bus.

[jeeves]

p 117, section 6.3.1 of the technical manual

The DMA Engine accesses SRAM over the AHB BUS.

not what I hoped for. If it was DPORT and AHB was free, and AHB did not need memw, that would allow GPIO writes over AHB to proceed unhindered. But DPORT requires memw.