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