[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PCI DMA controller

At 08:46 PM 4/1/97 -0500, Brad and Renea Ree wrote:
>We are working on a design which would use a AMCC PCI interface chip. 
>We want to use burst mode, but our software guy has informed me that the
>PC does not have a DMA controller, and the only way to do burst mode is
>if the card can be a burst master.  To me this sounds very bizarre.  I
>was wondering if anyone knows if there is a DMA controller which he can
>use to do burst transfers from the PC's memory to my PCI card.  Thanks
>in advance.

Essentially, your software guy is correct.  There really is not a 
bursting agent to uncached memory (like PCI devices) in the "PC"
architecture.   You really do have to implement the bus master on your
device in order to do bursts.

Here is the reason.   The original IBM PC AT design has a DMA controller
which is still carried over into today's designs.  This sits on the ISA or
EISA busses (or MCA bus) and is useless for PCI transfers because it sits
behind a PCI to ISA bus bridge.   Because of this, it is very slow, and
you are better off actually using the CPU and the Host Bus bridge to do
direct programmed I/O transfers over using this DMA engine when doing PCI

What you are really looking for is a PCI DMA agent in the PC, and there
is not one.  This is because boards can have bus master capabilities,
and so there was no requirement for a PCI DMA Master engine (in the opinion
of Intel and other PCI chipset manufacturers).   This obviously makes it
hard to implement easy, dumb, slave-only interfaces that are on the PCI
bus and do burst transfers (can you say impossible).

Further, the CPU itself does not make a good bursting agent when talking
to PCI devices on the PC architecture.   The problem is in the Intel
80x86 CPU architecture.  Even with all the fancy instructions that 
Intel has added in their new MMX enhancements to the x86 instruction set,
they chose to continue to ignore the issue of bursting to uncached memory.
(Probably, because with BusMaster PCI devices its not an issue).

When talking to uncached memory (like PCI device memory), the best possible
instruction that a programmer could use to transfer memory in a programmed
I/O fashion would be a   "rep movsd es:[edi], ds:[esi]".   For discussion
call a "read" the direction of transferring from device memory to system
memory (S/W read).  A write is the other direction.

Well, reads will never burst on the PCI bus.  This is because the rep movsd
instruction does not issue a burst read.  It is just the fastest way to
repeatedly do individual reads.  There is no burst read instruction to
UNCACHED memory on the x86 architecture.  Each read cycle completes before
the next cycle starts.

For writes, you can get "some" bursting.   This is really achieved by the
CPU bus to Host bus bridge when it occurs.  Again, the rep movsd performs
individual writes of 32 bit quantities.    These writes really go to the
"CPU bus -> PCI bus bridge" were they are posted temporarily.  While the
bridge arbitrates and wins the PCI bus and proceeds to transfer, the CPU
is transferring another 32 bit DWORD in another transaction.  If the CPU
is fast enough, or the bridge slow enough, the posting buffers can fill up
in the bridge, and then when the bridge wins the PCI bus, it will perform
a burst transaction of the merged posted DWORDS to the PCI bus.   This can
give short bursts on writes.

That is it for slave interfaces on the PC architecture.  In terms of PCI, no
effort was put in to allow for fast, bursting, slave-only interfaces.  You
have two choices.   Be slow or be a bus master.

So, your programmer guy was correct.

David O'Shea