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

Re: HP's proposal for PCI specification modification


Sorry for the delay in replying to your message.  (I was travelling
and couldn't check my email.)

> >We recognize that your solution has the important advantage that it
> >does not require the use of reserved connector pins, nor additional
> >pins on the chips.  It does not seem to work for DMA, but that could
> >be fixed by combining it with part of our solution, as discussed
> >earlier.  However, aliasing has additional drawbacks:
> Could you please elaborate on the argument of why aliasing won't work
> with DMA?  From the PCI standpoint, there is no difference between
> polling a device's registers from a CPU and a bus-master device 
> transferring data to and from host memory.  
> In an earlier e-mail (not copied here) you suggested that the host
> memory was too big to be aliased.  This is true, if you stick to 32-bit
> addresses, but what's wrong with implementing DAC?  

It's not theoretically impossible to alias all of host memory but it's
very awkward.  In the case of a PCI target, aliasing could be isolated
as a private matter between the target, the masters that access it,
and the device drivers involved.  Aliasing host memory N-ways would
require the cooperation of the OS.  And how do you choose N?

> >1. The card manufacturer would have to anticipate whether the card is
> >going to be used by multiple masters, and if so by how many.  A card
> >accessible by N masters will do for less than N, but how do you choose
> >N?  In practice, manufacturers will choose the simplest and cheapest
> >option, N = 1, i.e. no aliasing, and the problem will remain.
> I don't see this is different whether you implement the "master ID"
> pins or you encode the same information in the address bits.  You
> still have to have the target state machine logic to tell one master
> from another, and can choose to omit that from your design.

It's true that the target could ignore the master-id.  But if the
target uses the master-id, then it does not have to choose N.  It's
going to work when accessed by any number of masters.  So with
aliasing the card manufacturer has to choose between making the card
accessible to 1, 2, 4, 8, 16 or some other number of masters.  With
master-ids the choice is between 1 or *all*.

> >2. If a card with N-way aliasing must be addressed by N+1 masters,
> >then, to avoid the problem it will be necessary to ensure mutual
> >exclusion of accesses by masters that share an alias, and this will by
> >complex and will impact performance.
> Again, your proposal only provides for up to 16 masters on the "local"
> bus anyway, which ignores the problem of what to do with multiple
> masters on the other side of a PCI-PCI bridge.  This to me is more
> a matter of managing the product specification than it is a technical
> one.  In either scheme, you will trade off the cost of the logic
> required to handle more masters vs. the number of configurations the
> device could ultimately handle.

Our proposal has two parts: (i) the local master-id lines driven by
the arbiter, and (ii) the requirement that bridges and multi-function
devices only have one outstanding transaction at a time for a given
address.  (i) and (ii) together provide a complete solution to the
ordering bug.

> >3. Software is required to assume the burden of allocating the alias
> >images among the masters.
> Most device drivers already have to solve much harder problems than
> this, and are always concerned with knowing the absolute physical
> address of objects under their control anyway.  I agree that a 
> software-transparent solution would be nice from the standpoint
> of supporting "legacy" drivers, but this has to be weighed against
> the headache of modifying the PCI specification.

Well, modifying the PCI specification is turning out to be harder than
I thougt, I must say ;-)

Best regards,


| Hewlett-Packard Company      |                                      |
| Francisco Corella   M/S 5649 | Tel  : +1 916 785 3504               |
| 8000 Foothills Boulevard     | Fax  : +1 916 785 3096               |
| Roseville, CA 95747-5649     | Email: fcorella@rosemail.rose.hp.com |
| USA                          |                                      |