Re: BURST Xactions CROSSING BAR BOUNDARIES

[Tom Hicks <thicks@fore.com>]

I think what people are not considering is a host bridge that
performs write combining, as described in the 2.1 spec.

Consider this scenario:
	 app1 writes a burst ending on the last word defined by its
	 BAR
	 app2 writes a burst starting on the first word of its BAR
	 app1 device and app2 device are mapped to sequentially
	 increasing address spaces.

the host bridge could then combine the writes into a single burst.
if the target did not disconnect at it's boundary, it's own operation
might be compromised (where are those additional words going?), but,
more importantly, the app2 target will not receive the data it was
supposed to.

If you take into consideration that a bridge might at some point perform
write combining, then a card which didn't disconnect could cause some
weird problems that would be difficult to track down.

-Tom

> 
> The original question refers to a BURST transaction in which the master
> crosses the BAR boundary.  This isn't related to address decoding since
> presumably the address is decoded to be within the target's assigned
> memory space.  I couldn't find anything in the 2.1 spec which defined a
> required response by a target if a burst transaction crosses a BAR
> boundary.  There are several ways to respond to this situation but I
> wasn't able to find any rules that defined a response.
> 
> For what it's worth I don't think that this situation calls for a hardware
> solution.  Applications should never issue transfer requests which will
> cross a BAR boundary.  The proposed response may not work too well since
> the transfer was continued across the boundary by the time the
> application/device driver terminates the transaction. 
> 
> Stuart.
> 
>  On Thu, 23 Jan 1997, Mark Gonzales wrote:
> 
> > 
> > If the target does not disconnect exactly at the boundary, it will 
> > claim data phases intended for some other pci target. This will 
> > result in data corruption, and a system crash. 
> > 
> > If a target is mapped to a range of addresses, it must claim 
> > addresses within that range, and ignore addresses outside that range.
> > 
> > I'm not sure why anyone would think that a computer system with 'fuzzy'
> > imprecise address decoding would ever work. Am I misunderstanding your
> > question?
> > 
> > --Mark
> > not speaking for Intel
> > 
> > kands@usa.net writes
> > >
> > >Hi,
> > >
> > >It is not very clear in the specs of PCI2.1 regarding the BURST Xactions
> > >Crossing BAR BOUNDARY.
> > >
> > > Let me be more exact on the problem. Suppose a Master Starts a Posted
> > >Memory Xaction close the BAR BOUNDARY and during the Xaction crosses the
> > >Boundary, Is it a must that the PCI target must issue a disconnect when
> > >the Master crosses the Boundary or is it O.K if the PCI target takes
> > >care by signalling to the application (the actual target where the write
> > >was targeted) that the Master has crossed the boundary, and leaving the
> > >responsiblity to the application to detect this condition and to issue
> > >a disconnect to the target which whill in turn be reflected to the PCI
> > >bus after say two clocks after the Master has crossed the BAR Boundary.
> > >
> > >If it is a must that the target has to disconnect exactly at the BAR
> > >Boundary, Pls. let me know where it has been specified in the specs.
> > 
> > 
> 
> 
> 
> 
€o