[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Transaction abort
- To: Mailing List Recipients <pci-sig-request@znyx.com>
- Subject: Re: Transaction abort
- From: Devendra K Tripathi <tripathi@Synopsys.COM>
- Date: Thu, 15 Aug 1996 09:40:06 -0700
- Cc: pci-sig@znyx.com
- Resent-Date: Thu, 15 Aug 1996 09:40:06 -0700
- Resent-From: pci-sig-request@znyx.com
- Resent-Message-Id: <"tWAvq3.0.jU6.5Er4o"@dart>
- Resent-Sender: pci-sig-request@znyx.com
Hi Rafi,
> 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 the host bridge generates some kind of exception the CPU in this
> case?
>
PCI does not specify the exact action that should be taken under these cases. The two
ABORT cases, do have status bits associated with them. Generally, Retry being
considered a temporary phenomena, is supposed to be handled by host PCI interface
itself. I would guess, though, that Retry info would be communicated to DMA involved
and if there is latency issue, it may go to even higher level. PCI does suggest
SERR# for target abort if there is no way to communicate it to device driver.
Hope it helps.
Thanks,
Tripathi.
: È µ