Create permanent mapping from PCI bus to region of physical memory

[Howard, Marc]

>> The periperal is an FPGA.  No, there is no internal processor;
>> everything is coded in Verilog.
>>
>> Scatter/gather isn't a viable option because of this. 

>Er, why not, its an FPGA, everything is possible :)

Not if you're tight on routing resouces and/or design time ;-)

>So you have a PCI core, since you are planning to write to
>the host memory space, its a Bus Master PCI core.
>Who's FPGA, Altera, Xilinx, or someone else?

Xilinx Virtex 4, no internal PPC.  The vendor really isn't
germain to the problem at hand however.

>> Additionally non-contiguous memory would reduce bandwidth 
>> and increase FPGA design complexity. 

>Not necessarily. If the target is using bus master DMA to
>write to the host memory, then you can hit pretty close
>to the bandwidth of the PCI bus. If you are DMAing in
>big blocks, the overhead of a block change isn't too much.
>I did tests with the 440EP using a DMA controller on an
>adapter board and found that the PCI bridge in the 440EP
>was the limiting factor, i.e., for a 33MHz 32-bit bus
>with a potential for 132MB/s, the *best* you can do is
>about 40MB/s since the bridge only accepts data in cache
>line sizes before sending a retry to the target. I can
>send you those results.

Dave, I appreciate your input but scatter/gather just isn't
an option here for a variety of reasons.  Bandwidth/complexity/
latency/time to design/time to debug/FPGA density all
factor into this decision.  BTW we're talking 66/64 PCI-X;
33/32 PCI isn't nearly fast enough.

>Randomly accessible from where; the host or an I/O interface
>at the FPGA. The pages can be made to appear contiguous to
>a host processor user-space process using the nopage callback
>of the VMA.

>From the point of view of the FPGA.

>> I realize this isn't a standard linux request but having
>> fixed, linear memory is quite common in embedded apps.  There
>> should be a way to create this mapping in the 440GX's hardware
>> and I'm just looking for a system call (if there is one) to
>> implement it.

>Alas, this is one of the concessions one must make if you
>want to use a processor that enables the MMU. 

Nope, I disagree.  The MMU isn't involved here at all.  I'm
talking about setting up the PIM (PCI Inbound Map) via
a system call as opposed to just writing it directly.

>However,
>I don't see any fundamental limitation in the design
>that would preclude a little extra work on the FPGA.
>But, it does require additional Verilog to support
>the flexibility. The long-term advantage is that you
>don't have to provide a hack (eg. reserve a block of
>high-memory under Linux).

I really can't go into detail about my application for a
variety of reasons (both technical and legal) but suffice
it to say that 16 MB is just the starting point.

I guess I'll dig a little deeper into the source to see
where the kernel does the PIM mapping.  Re-architecting
our app at this stage just isn't a practical consideration.

Thanks again,

Marc 





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060410/9dad0b41/attachment.htm