There's no multiplexed code/data path in a harvard architecture. The code comes from one place and the data from another. However, if you you have DMA, then there have to be address paths and data paths to both the memory and the peripherals. If those are to be shared between the CPU and the DMAC, there has to be arbitration-controlled multiplexing in that path, and that, then, becomes the rate-determining path that sets the maximium rate at which the MCU can operate. If you double the number of logic elements in the path, and allow for propagation time through them, then the rate at which the MCU can operate is severely impacted.

You'll have to convince me that there's a NEED for DMA on an MCU with so few resources.

What I'm wanting to do is to isolate the now-closely-coupled timers and serial channels from the MCU, and then make it easy to interface them, or any other peripheral that one can dream up, via SFR-space. I'd love to see lots and lots of bit-addresable locations in SFR space. I'd also love to see more SFR space. Because there are only 128 bytes of each, however, I'm considering replacing the "standard" locations with custom ones, since it's conceivable that there might be no UARTS and no timers at all, but that there might be USRT's with their own internal baud rate generators based on an external timebase. I see no reason to limit what can be done within a soft core to what guys who were feeling their way along by Braille did 30 years ago.

DMA isn't ruled out, but it would probably take the form of an additional MCU core, perhaps of a different architecture, using two-ported memory as the shared resource.

RE