Re: HP's proposal for PCI specification modification

[Alan Deikman <alan@znyx.com>]

Listmembers,

The below was originally a private e-mail to me from Mr. Corella
and I asked him to post it to pci-sig (which he did) in the hopes 
that individuals on the list more inventive than myself can 
contribute by poking holes in either their argument or mine.

For my own part, a modification to the PCI specification is to be
avoided, but not at all costs.  HP apparently feels that the 
problem is serious enough to warrant a change, but I believe it
can be solved without changing the specification.

>From: Francisco Corella <fcorella@gslxsrv2.rose.hp.com>
>Subject: address aliasing

>We've had an internal email discussion here at HP about your solution
>for the ordering problem by address aliasing.  Here are some comments
>extracted from that discussion.  
>
>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?  

>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.

>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.

>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.

>4. If something goes wrong in all this and two masters end up
>accessing the same alias at the same time, you will have the worst
>kind of intermittent error.  The system will usually work fine, and
>perhaps even pass a rigorous test.  But then there could be rare and
>mysterious problems in the field to deal with.

The worst engineering nightmare, true, but in this case it leaves me
unmoved.  The only opening for this to happen is if you have rogue
software running about the system, (in which case you have a bigger
problem) or possibly a memory walking routine.  I suspect that there 
are ways of dealing with this, particularly with hardware support,
but I don't have time just now to work out the details.  If anyone
else has ideas on this, I would like to hear them.

Best Regards,


--------------------------------
  Alan Deikman, ZNYX Corporation
  alan@znyx.com
üH7