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

Alan Deikman's solution


I realize that I didn't cc the reflector on my previous reply to your
message, so I'll say again that I think your solution is a very good
one.  I've forwarded it to my colleagues here at HP for evaluation.

But on further thought, it seems to have a problem.  It doesn't seem
to work for DMA accesses.  How could you alias all of main memory N
ways, N being the number of devices on all the buses behind a given
host bridge?  

However DMA is precisely the case where the master-id signals of our
solution can be provided without additional pins.  A DMA Delayed
Request travels upstream through zero or more pci-to-pci bridges and
then through the host bridge.  The target at each stage is the
upstream bridge on the bus.  If the arbiter is part of the bridge,
then the arbiter can communicate the id of the master to the bridge
target controller through internal signals instead of bus signals.

So it seems that the two solutions could be combined.  Aliasing is
used for accesses to devices on PCI buses.  Bridges tag Delayed
Requests travelling upstream with the local master id obtained from
the arbiter, the tag is copied to the completion when the completion
is obtained, and the completion is given only to a retry by the same
master.  In addition, when a PCI-to-PCI bridge forwards Delayed
Requests to its upstream bus, it makes sure that only one Delayed
Request for a given address (and of a given type, read or write) is
outstanding at any time.

(By the way, in your message you mentioned "hardware lookup tables of
masters".  No such tables are needed in our proposal.)

I'll write again when I hear from my colleagues.

Best regards,


---------------------- Alan Deikman's message -----------------------

>			  Proposed solution
>			  -----------------
>Four reserved pins are used to encode a Local Master ID.  This
>provides 16 distinct codes, which is more than the number of masters
>electrically feasible on a single bus.  The Arbiter knows the identity
>of the master of the current transaction and uses these four Master ID
>lines to communicate that identity to the target.
>  <etc.>

I came into this somewhat late, but I just got around to reading this
and it seems to me to be an unduly complex solution to this problem.
The complexity is not so much the mother-board, as the proposal seems
simple to implement there, but the target is going to be far more
involved, what with hardware lookup tables of masters, timeouts, etc.

Wouldn't it just be simpler to implement your target device in
such a way that you alias your decoded memory space N ways, where
N is the number of simultaneous masters you want to support?  Then 
each master uses a different alias for the same target entity.  
(Allocating alias images among masters will be left as an exercise 
for the student.)

For example, suppose your device implements a 1KB buffer memory,
and you want to support 16 masters.  Your BAR will now be constructed
so you are allocated 16KB instead of the "natural" 1KB.  Master
#1 accesses offsets 0-3FF, #2 access 400-7FF, etc.  The "Master
Number" is encoded into the address bits!  No semaphores, no 
modificiations to the host, no flim-flammery with the 2.1 spec.
And this will work across PCI-PCI bridges.

Did I miss something, or would this work?


  Alan Deikman, ZNYX Corporation