Re: Transaction abort

["David O'Shea" <daveo@corollary.com>]

At 02:04 AM 8/15/96 EDT, Rafi Boneh wrote:
>Hi.
>
>Suppose I am trying to burst from a host PC as a master, to a slave PCI
>board, by copying data from the host memory, to the board, by the CPU.
>What happens if my board stops the transaction by doing Retry, Disconnect 
>or Target-Abort, or the PCI arbitrator force the host to do a 
>Master-Abort?
>
>How can the CPU know that the transaction was interrupted, and after how
>many data phases?
>
>Dose [sic] the host bridge generates some kind of exception the CPU  in this 
>case?
>
>I'd appreciate any comment.
>
>Rafi Boneh.

The Execution unit of the CPU does not know that the device is retrying it.
As a result, first any write posting buffers in the Host Bus Bridges pathway
will fill.   Once these are full, the Host Bus Bridge will signal the
CPU via a HostBus/CPU specific mechanism that the Host Bus is itself 
retrying transactions (say on a P6 bus).  On a Pentium Bus the Host Bus
Bridge would simply stall the current transaction.    Still, in a typically
built system, the execution unit of the CPU does not know that everything
is blocking up.   Assuming that the PCI board's memory space is in an
uncached region (how depends on architecture) then the last few writes of
the execution unit end up in some write posting buffers within the CPU.
When these have filled, then the execution unit is stalled.   All of these
stall points have a maximum time limit enforced by a timer.   Eventually
one of them will go off and the semi-burst write (rep movs on x86) will
fail.   On the x86 the CPU execution unit will not be affected by this 
failure, it will just keep writing memory (with the failed unit writes
lost).   Generally, the timeout mechanisms at each point are tied to an
interrupt mechanism of some kind.   Usually this is NMI on PC architecture
machines.  The software if it gets an NMI will try to figure out why it
got one.  Usually the event stream above will not leave many helpfull clues
about the true cause of the failure that generated the NMI.

So in on PC architecture machines, the S/W gets notified by an NMI in most
cases.  This is not very usefull if not fatal.  Don't design your device
driver to burst data that the target slave cannot handle on a guaranteed
basis.   This generally means putting a small buffer on the target device.
The driver is then designed to transfer data chunks in 1/2 buffer sizes when
ever the buffer drops below 1/2 full.   The device interrupts the system
when the buffer is 1/2 empty.  

This type of slave oriented design works on PCI but does not make very good
use of the BusMastering capabilities of the Bus for the targets.   Usually
you want a only "slave" control interface.  The driver tells the target that
it has some work for it, gives it the particulars of where the work is in 
memory, and instructs the target to go get from or send to the place
in memory where the data is.   The Target bus masters the data at a minimum.
Sometimes the interface is such that all of the particulars about a job are
also put in memory, and a pointer is the only thing passed to the target.
The target BusMasters in the particulars, analyses them, and then bus masters
in-or-out the data transaction.   The target then controls the data flow
since it is the BusMaster in both directions. The later method is more
"PCI LocalBus-ish".   

-David O'Shea
daveo@corollary.com
8