Why 32 bit CPUs with 16 bit DMA transfer counters?

[peter-h]

It seems strange to have say 10M-100M transistors on a chip and not have a 32 bit DMA counter.

[Brianf]

It seems strange to have say 10M-100M transistors on a chip and not have a 32 bit DMA counter.

What practical application is there for a DMA unit that will do more than 64k transfers?

[ataradov]

It is enough in most practical applications. A lot of those CPUs don't have more than 64 K of SRAM. Usually bigger CPUs include channel linking, so you can assemble whatever size you want.

Plus in most cases it is 64K transfers, so if you are just copying the memory blocks, you can use word transfers and get 256 Kbytes with a single transaction.

For multi-channel DMA controller everything multiplies and becomes quite big. A single counter may be 32-bits. But 8 32-bit counters with 8 32-bit compare registers is quite a bit of logic for no real gain in performance except in a couple marginal cases.

[hans]

It seems strange to have say 10M-100M transistors on a chip and not have a 32 bit DMA counter.

What practical application is there for a DMA unit that will do more than 64k transfers?

Framebuffer transfers for LCDs? Don't need a crazy high resolution screen to get to 64K transfers (256K 16-bit = 128K pix, ~= 480x272 screen size). Admittedly though, it's a relative niche case. For more serious graphics performance, you'd get a MCU like the STM32F427 with DMA2D that has lines/rowsize numbers (14x16bit) as region transfer setting.

And even if you don't get DMA2D, the penalty of 1 IRQ per 64K is not too bad, especially if you can set up ping/pongs in hardware. 64K is also a lot of data to set up and reserve.. so 2 ping-pong buffers is also a huge chunk of memory gone.

DMA streams can run for much much longer in circular mode, but I wouldn't really count that use-case as it's not about accessing a linear region src/dst of greater than 64K at once.

[ataradov]

Framebuffer transfers for LCDs?

But you don't need cycle perfect performance for this, so a couple minor interruptions to reload the counters and pointers is not a huge deal and does not affect overall performance.

[SiliconWizard]

It seems strange to have say 10M-100M transistors on a chip and not have a 32 bit DMA counter.

What practical application is there for a DMA unit that will do more than 64k transfers?

For small MCUs, this would indeed be unusual due to the limited amount of memory you have access to anyway, but for beefier MCUs, there sure could be uses. For graphics stuff for instance.
But I think some have dedicated DMAs for this. For instance for some STM32's, you have a DMA2D block which can (IIRC) handle larger transfers than 64KB.

[ataradov]

Regular DMA does not guarantee timings, so it is not useful for driving raw display panels directly anyway. And it is not that hard to send the frame buffer in multiple transfers. It may be inconvenient, but no more than that.  And I definitely can't  see it as a justification to increase hardware complexity.

There may be some middle ground with 24-bit counters, for example, which has to cover everything for a while. But the issue does not seem to be too urgent to warrant hardware redesign.

And more recent designs do include larger counters. Even RP2040 has DMA with full 32-bit counters.

[SiliconWizard]

Even the PIC32MX did AFAIR. Appeared 15 years ago.

[peter-h]

There may not be much more than 64k spare RAM on-chip, but to drive some things (like LCDs which are to display fast graphics/video) you have to bring out a load of address/data lines anyway (can't use SPI, and the bigger LCDs don't have SPI anyway) so you could easily have megabytes of RAM (off-chip).

The CPU is plenty fast enough.

[ataradov]

Sure, but a minor interruption to reload the counter is well amortized with 64K chunks.

It is convenient to do it all in one go, for sure. And for new designs I would absolutely consider 24- or 32-bit counters. It is just not an urgent issue to modify the existing well proven IP.

[janoc]

There may not be much more than 64k spare RAM on-chip, but to drive some things (like LCDs which are to display fast graphics/video) you have to bring out a load of address/data lines anyway (can't use SPI, and the bigger LCDs don't have SPI anyway) so you could easily have megabytes of RAM (off-chip).

The CPU is plenty fast enough.

And why would you want to drive such LCD from such an MCU requiring off-chip RAM and complex design instead of using parts actually intended for the purpose, with sufficient RAM and dedicated display driving hw?  If you are abusing a low-end MCU for this anyway, then the 16bit DMA counters are likely the least of your problems.

[peter-h]

instead of using parts actually intended for the purpose, with sufficient RAM

On chip RAM is very expensive, and you can't get much no matter what you pay.

[AndyC_772]

It seems strange to have say 10M-100M transistors on a chip and not have a 32 bit DMA counter.

What practical application is there for a DMA unit that will do more than 64k transfers?

I hit this particular limit just last week. My application was to download a large quantity of data from a high speed UART to an external SPI Flash, at the fastest rate possible.

My UART driver uses a circular DMA buffer to receive data, so it can receive at high speed without interrupting all the time. Each time round its main loop, the application checks the number of DMA transfers which have occurred, and parses any characters which have been received since last time.

When the Flash is busy, the STM32 has nowhere to put the incoming data except its own internal RAM. The size needed for the UART Rx buffer becomes dictated by the Flash page write time and the incoming data rate; if the circular buffer fills before the Flash becomes available again, the entire buffer contents are lost.

Ergo, the highest transfer speed is limited by the buffer size, which in turn is limited by that DMA counter.

[MT]

It seems strange to have say 10M-100M transistors on a chip and not have a 32 bit DMA counter.

What practical application is there for a DMA unit that will do more than 64k transfers?

Variable sample rate audio playback DMA. Was used in Fairlight CMI I, II, IIx, III, MFX, Emu Emulator 1,2,3, Emax, Drumulator, Korg DSS1, DSM. AKAI S900, S950, S612, S1000,
and some other audio machines.

[Brianf]

It seems strange to have say 10M-100M transistors on a chip and not have a 32 bit DMA counter.

What practical application is there for a DMA unit that will do more than 64k transfers?

Variable sample rate audio playback DMA. Was used in Fairlight CMI I, II, IIx, III, MFX, Emu Emulator 1,2,3, Emax, Drumulator, Korg DSS1, DSM. AKAI S900, S950, S612, S1000, and some other audio machines.

But, as has been pointed out, DMA does not guarantee any sort of timing due to bus arbitration.

[peter-h]

It is really really close though, surely. On a 168MHz CPU for example, what is the max wait due to bus arbitration? A few clocks?

Also any kind of DMA activity where you want regularity is driven from a timer, or from an external DMA request signal.

[westfw]

When the Flash is busy, the STM32 has nowhere to put the incoming data except its own internal RAM.
:
Ergo, the highest transfer speed is limited by the buffer size, which in turn is limited by that DMA counter.

Sounds to me like the transfer speed is limited by the flash speed.  Since flash pages will probably also be smaller than 64k, doing larger flash writes probably takes longer, leaving you with a no-win situation.

See the various "Buffer bloat" discussions about The Internet, and/or the ancient paper (RFC790) on "packet switches with infinite memory."

[Siwastaja]

Framebuffer transfers for LCDs?

But you don't need cycle perfect performance for this, so a couple minor interruptions to reload the counters and pointers is not a huge deal and does not affect overall performance.

It would, however, make writing and maintaining code easier. I prefer helpful hardware which offloads the CPU, over hardware which needs constant baby-sitting by the CPU, even if said babysitting is not a big performance issue. It still needs to be implemented, tested and verified, and managing peripherals notoriously introduces weird rare corner cases and this is impossible to properly unit test or verify on a PC, because no simulation models exist for the hardware.

You don't have to go to the most expensive flagship models to have more RAM than 64K. UART, SPI, I2S or DCMI transfers can easily go in range of a few hundred K. You can't always utilize word-size transfers. Actually I would think 20-bit counter would cover almost all use cases, 24 for sure.

Mid-range STM32 DMA mapping system is just so ****ed up. They have gazillion of streams available (say, typically 2*8 = 16) - you never ever use that many in a real project simultaneously. But you can only map a few peripherals to each, so before committing to a PCB layout, one needs to verify if they can have even just two simultaneously. They waste a lot of silicon into needlessly high number of counters, comparators and control logic, yet did not want to create a simple full request matrix, but sixteen half-assed matrices instead.

H7 series was the first to finally add the DMAMUX. They could have halved the number of channels at the same time if they wanted to save some silicon. Instead, they added even more DMA controllers to the thing, but that's OK because the chip is expensive anyway.

[westfw]

I dunno.  I prefer peripherals that don’t interfere with deterministic performance of the cpu (ie by bus contention.)  I guess determinism is pretty much a lost cause, anyway, on more complex CPUs.

[SiliconWizard]

The OP seems to be generalizing a point while focusing on a pretty specific MCU line (STM32F4 is what the OP uses the most IIRC) anyway.
The only way of getting out of its limitations would be to switch to something else, something he's reluctant to do.

[peter-h]

Hmmm, no; this is not related to anything I am designing now.

There is no need to get personal. I know forums get like that but it's not productive. I thought it was a reasonable Q.

Anyway, most people (well, those who are trying to make things work, rather than just shaft their employer for more bread on the table at home) want to switch CPUs like they want a hole in the head (an English saying).

[thm_w]

I hit this particular limit just last week. My application was to download a large quantity of data from a high speed UART to an external SPI Flash, at the fastest rate possible.

My UART driver uses a circular DMA buffer to receive data, so it can receive at high speed without interrupting all the time. Each time round its main loop, the application checks the number of DMA transfers which have occurred, and parses any characters which have been received since last time.

When the Flash is busy, the STM32 has nowhere to put the incoming data except its own internal RAM. The size needed for the UART Rx buffer becomes dictated by the Flash page write time and the incoming data rate; if the circular buffer fills before the Flash becomes available again, the entire buffer contents are lost.

Ergo, the highest transfer speed is limited by the buffer size, which in turn is limited by that DMA counter.

DMA double buffer mode, if available.
or switch to another buffer when DMA interrupt half full occurs (kind of waste of RAM though).

[SiliconWizard]

There is no need to get personal. I know forums get like that but it's not productive. I thought it was a reasonable Q.

There was nothing personal about it. It was just factual. Your original statement was a generalization. As some of us have pointed out, a number of 32-bit MCUs do have DMAs which can handle larger transfers. Or do have specific peripherals for handling large tranfers of display data such as STM32's DMA2D.

For MCUs that only handle transfers with 16-bit counters, that is just one of many decisions designers have to make. On those chips they probably figured that it would have little value due to their limited amount of memory, and as others have said, due to the fact that handling transfers in chunks of 64K words has completely negligible overhead compared to transfering largers blocks in one go. Some of those design decisions may look pointless from an external POV, but chip design is a bunch of such decisions. Some may look a bit arbitrary but designing a chip is all about making decisions. Sometimes, part of the decision is purely marketing. The vendor may have a line of "performance" MCU with more RAM, better DMA controllers, etc, and doesn't want their mid-level lines to compete with that.

And, with that said, my point was that if you still absolutely need > 16K word transfers, there definitely are MCUs out there that can. While wondering why things are what they are is interesting (and we mostly came up with hypotheses rather than definite facts), ultimately we just have to deal with it and select our components accordingly.

[PCB.Wiz]

Why 32 bit CPUs with 16 bit DMA transfer counters?

My beef is Why 32 bit MCUs with 16 bit timers/counters ?
It's largely legacy reasons, and partly die costs, some vendors wanted to keep register conventions from their 8 bit parts, but it is thankfully becoming more common to see 24-32 bit timer/counter in 32 bit MCUs
I think NXP got this right early on.