On 07/15/2010 01:30 PM, Kulp, Jim wrote:
Linux is good for now (assuming it is a competent embedded configuration).
Arm is probably fine (good gcc support?).
The GPP/FPGA interface for now assumes PCIe, although most of it is not
PCIe-specific. There is a "control plane" and a "data plane".
My problem is I've never done any PCI related driver work.
The control plane uses PIO, 32 or 64 bit load/store (doesn't require 64 bit,
but does require 32 bit). It does lifecycle control and configuration of
all IPs , both application (aka OpenCPI "HDL Application Workers": filter,
math, delay, split/merge, demod, etc.) as well as infrastructure (aka
OpenCPI "Device Workers": DRAM, ADC, DAC, GBE Mac, etc.).
Lifecycle control means software control of reset, init, start, stop, etc.,
analogous to SCA lifecycle, but at the level of each IP, including device
stuff.
So the control plane IP depends on a SW/HW system bus with 32 bit
load/store, and it currently PCIe.
The data plane does data streaming/async multibuffering/DMA/flow
control/push-pull etc. It is controlled (initialized) by the control plane,
but essentially does variable-length message streaming between HDL
applications and SW ("RCC") application workers.
This sounds really similar to what we have. Although the current FPGA
implementation is basically to replace the code that is in the USRP1 and
not be flexible. This is not intended to be the final word on how to do
things, but rather provide a system that works as an SDR and has plenty
of room for experimentation.
How is the OMAP/ARM attached to the FPGAs?
Via the GPMC controller on the OMAP.
Philip
Jim
On 7/15/10 12:25 PM, "Philip Balister"<[email protected]> wrote:
On 07/15/2010 11:46 AM, James Kulp wrote:
OpenCPI has run on a number of FPGA development boards.
Do you have a link/URL to the SW and HW on this board?
OpenCPI is certainly set up (modularized) in both FPGA and Software to
be portable to different environments, but the focus has recently been
on Linux (32/64, PPC/x86) and Xilinx (V5/V6).
I would answer "relatively easily" certainly assuming full doc and a
development environment.
The final product will have schematics and open source code for both
sides of the fgpa interface. The ARM on the OMAP runs linux. (Well, it
can run whatever, but it will ship with Linux)
How does opencpi view the GPP/FPGA interface?
Philip
Jim
On 7/15/10 10:35 AM, Philip Balister wrote:
At the ERRT workshop in Frankfurt last month Ettus Research showed
this piece of hardware:
http://balister.dyndns.org:8008/~balister/img_0819.jpg
Basically, this is an OMAP3 based device attached to a Spartan 3A DSP
FPGA. The data conversion section is similar to the USRP 1 hardware
and it uses a standard USRP daughterboards.
How hard is it to port OpenCPI to new hardware? I'm working on a
driver to move data between the FPGA and the OMAP3. I haven't looked
closely the FPGA/GPP interface. What sort of work/effort would be
needed to get openCPI running on this hardware?
Philip
_______________________________________________
opencpi_dev mailing list
[email protected]
http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
_______________________________________________
opencpi_dev mailing list
[email protected]
http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
_______________________________________________
opencpi_dev mailing list
[email protected]
http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
