Z180 - why is there no DMA support for CSIO devices ?

[Marten Feldtmann]

This is the other question I have in mind. Devices connected via CSIO may be high-speed devices. Due to this - why is there no DMA support for them ? Interrupts ? Yes, but no DMA support.

Even with external ICs like the TP3565 DMA was not considered ...

[Douglas Miller]

I'm not sure about the original engineers design decisions, but it turns out with modern SPI devices that CSIO is not all that practical - the order bits are shifted is wrong for most SPI devices, like SDCards. That means every byte sent/received has to be bit-reversed in software. Modern SPI device protocols are not very conducive to use of DMA, either.

If the original intent of CSIO was to interface to low-level hardware - like JTAG, I2C, etc - it was probably not considered necessary to add DMA. Also, I'm not sure what limitations the Z180 DMA engine has, and if adding another channel to support CSIO was even possible.

[Bill McMullen]

The CSI/O interface is not that high speed of a device.  It's fastest baud rate is PHI/20 which for 8 bits gives 160 T states per byte.  In an embedded or single tasking environment that should normally allow plenty of processing power between bytes to store or fetch data.  In the original HD64180, this half-duplex interface was not intended for SPI, SD cards, etc.

Per the HD64180 data book:
"The CSI/O is ideal for implementing a multi-processor communication link between the HD64180 and the HMCS400 series (4-bit) and the HD6301 (8-bit) single chip controllers as well as additional HD64180 CPUs."

[Alan Cox]

On Tue, 27 Dec 2022 at 13:32, Douglas Miller <durga...@gmail.com> wrote:
>
> I'm not sure about the original engineers design decisions, but it turns out with modern SPI devices that CSIO is not all that practical - the order bits are shifted is wrong for most SPI devices, like SDCards. That means every byte sent/received has to be bit-reversed in software. Modern SPI device protocols are not very conducive to use of DMA, either.

CSIO is fine for some SPI modes (it can't do the timing for all of
them) and the bit order is irrelevant because the CPU can reverse
order the byte faster than the CSIO can send the previous one. You've
got over a hundred clocks to do the bit reverse so you don't even need
a lookup table.

> If the original intent of CSIO was to interface to low-level hardware - like JTAG, I2C, etc - it was probably not considered necessary to add DMA. Also, I'm not sure what limitations the Z180 DMA engine has, and if adding another channel to support CSIO was even possible.

CSIO was intended to interface to other CSIO devices. At the time it
was designed SPI wasn't really a thing the way it is today. What SPI
there was also usually ran slowly and had low data volumes. The "stuff
things down one wire very fast" mindset, the needed drivers and
routing are a very much more modern thing. Even devices like the
68HC11 and 683xx that had SPI on board didn't have DMA for it because
the mindset of the time was "go wide to go fast" for bulk data and SPI
drove clocks, sensors and the like.

The second reason you often didn't see DMA on an SPI master is that if
your SPI is slow you don't need it, and if your SPI is fast relative
to the CPU it didn't help either. Slow SPI was handled by interrupt,
fast SPI the overhead of setting up DMA for a typical message would
exceed the benefits of just polling, and because SPI is master-clocked
there is no risk of missed bytes unlike serial. In fact at speed it's
the SPI slave that needs DMA or a FIFO buffer.

Alan

[Marten Feldtmann]

Thank you all for the answers ...


Marten