Looking for overview information on the project

RE: Looking for overview information on the project

Re: Looking for overview information on the project

Beagle FPGA board - status update

Hi,

A quick status on the Beagle FPGA project:

Boards are back from the PCB fab and the first one has been assembled 
and is being tested. Configuration software is available and the board 
is working with both the Angstrom Stable and Unstable development trees. 
So far all power, ID, clocking and configuration support circuitry is 
working as designed. Off-board I/O and the remaining Beagle interface 
remains to be tested.

Find out more about this project at the following sites:

http://members.cox.net/ebrombaugh1/embedded/beagle/beagle_fpga.html

http://www.elinux.org/BeagleBoard_Tracker

Please let me know if you have any questions or comments on this.

Thanks,

Eric

Re: Beagle FPGA board - status update

Re: Beagle FPGA board - status update

As you noticed, the interface between Beagle & FPGA is mostly 
uncommitted. There are a few options that stand out:

* McSPI3 - this is a 1-bit serial stream, simultaneous I/O which 
supports up to 48Mbps. SPI is inherently packetized and so may not be 
ideal for isochronous streams like one often finds in SDR.

* McBSP3 - this is a 1-bit serial stream with simultaneous I/O that also 
includes framing. It can operate up to 48Mbps in several different 
modes, some of which support isochronous streams. This seems like it 
would be ideal for SDR, especially since the McBSP can be piped into the 
on-chip C6x DSP.

* MMC2 - this is an 8-bit parallel stream with muxed I/O and separate 
commands that is primarily intended for communication with MMC/SD/SDIO 
cards. With some creative FPGA wrapper logic and corresponding driver 
code in the OMAP MCU it could conceivably be adapted to a fairly high 
bandwidth packetized interface that could support fairly high data rates 
- a quick skim of the TRM suggests a maximum clock frequency of 52MHz 
for a theoretical data rate of 52MBps, but there's a fair amount of 
handshaking involved with the SD protocols that would cut the aggregate 
down from that considerably. Also, the current interface allocation 
between Beagle and FPGA is not optimized to use this interface, so a 
minor circuit revision would be required to explore this.

Eric

On 05/18/2010 11:49 AM, Stephen Hersey wrote:
> Here's a question: What I/O do tyou plan to use between the FPGA and
> BeagleBoard? From the schematic, it seems evident that you can use one
> or more McBSPs (which ought to be good for SDR data traffic); do you
> also envision doing parallel I/O?
>
> On Tue, May 18, 2010 at 2:30 PM, Eric Brombaugh <ebrombaugh1@...
> <mailto:ebrombaugh1@...>> wrote:
>
>     Hi,
>
>     A quick status on the Beagle FPGA project:
>
>     Boards are back from the PCB fab and the first one has been
>     assembled and is being tested. Configuration software is available
>     and the board is working with both the Angstrom Stable and Unstable
>     development trees. So far all power, ID, clocking and configuration
>     support circuitry is working as designed. Off-board I/O and the
>     remaining Beagle interface remains to be tested.
>
>     Find out more about this project at the following sites:
>
>     http://members.cox.net/ebrombaugh1/embedded/beagle/beagle_fpga.html
>
>     http://www.elinux.org/BeagleBoard_Tracker
>
>     Please let me know if you have any questions or comments on this.
>
>     Thanks,
>
>     Eric
>
>
>
>
> --
> Steve Hersey N1XNX
> n1xnx@... <mailto:n1xnx@...>
> -----
> Each of us has strengths and talents that others don't. Whether innate
> or learned, these are gifts -- and a gift not shared is a sad and lonely
> thing. Using our gifts for the benefit of all is an ethical obligation
> for every intelligent being. (The magic only works if you pass it on!)
>

Re: Beagle FPGA board - status update

Re: Beagle FPGA board - status update

Agree - McBSP3 looks like the best way to get streaming data into the 
Beagle in such a way that it can be pre-processed in the DSP. It limits 
the bandwidth a bit over trying to work out something using MMC2, but is 
probably good enough for a lot of useful stuff and it will be a heckuva 
lot easier to get going.

One thing to consider - setting up McBSP3 as an ordinary audio device 
running at 48ksps would be a great way to bootstrap into GnuRadio - I 
believe there are already audio sources/sinks that would hook right up, 
and a decimating/interpolating FPGA design could probably be set up to 
generate I2S-compatible data streams without too much effort, with 
side-channel control for frequency and bandwidth taking place over the 
SPI4 port that's already in use for the FPGA setup. I've got a TXDAC 
design to plug into two of the connectors on the FPGA board out to fab 
now and hope to have this testing in a few weeks.

Eric

On 05/18/2010 01:18 PM, Stephen Hersey wrote:
> McBSP3 -- Bingo! That looks like the best candidate for SDR I/O; piping
> data directly between the FPGA and the DSP at many Mbps means that
> compute-intensive tasks can be done entirely in the DSP, or partially in
> the DSP and partially in the FPGA, without needing to bother the ARM CPU
> for the data transfers. Might even be able to implement a packet-radio
> modem in the DSP, and pass payload data frames to and from the DSP from
> the ARM CPU as a virtual-serial-port device. Time to start reading up on
> the DSP system, woohoo!
>
> Oh, and I forgot to mention it the first time: Your FPGA peripheral rocks!
>
> Thanks, Steve

Need a clue to solve a Boost inconsistency under Angstrom

I'm attempting to build OSSIE using the Bitbake build system for the
BeagleBoard. I've successfully built the Angstrom x11-image
(local.conf lists DISTRO = "angstrom-2008.1") on my cross-build system
(running Debian Lenny updated a week ago), so I trust the basic sanity
of my OE toolchain and the basic Angstrom build.

I've followed the instructions at "Getting started with Embedded SDR"
(http://www.opensdr.com/node/7), with adaptations that seem reasonable
for the latest bitbake, mainly replacing ${OEDIR} with ${OETREE}. (I
notice those instructions date from 2008, so there may be something
else obsolete I'm doing...) I have also compared them to the Overo
build instructions, and I don't see any obvious incompatibilities.

The OSSIE version I'm getting from the SVN repo at
https://svn.geekisp.com/opensdr/OE/ossie_collection is 0.7.0.0, tagged
as ossie-cf-0.0.0+svnr380-r2.

When I try to bitbake a console-image with the OSSIE collection
included, I get an error compiling the OSSIE CF, which seems to be an
incompatibility with the Boost package, version 1_36_0, that is pulled
in by bitbake. The error is listed below:

FileSystem_impl.cpp: In member function 'virtual void
FileSystem_impl::remove(const char*)':
FileSystem_impl.cpp:95: error: void value not ignored as it ought to be
FileSystem_impl.cpp: In member function 'virtual
CF::FileSystem::FileInformationSequence* FileSystem_impl::list(const
char*)':
FileSystem_impl.cpp:168: error: 'class
boost::filesystem::basic_directory_entry<boost::filesystem::basic_path<std::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
boost::filesystem::path_traits> >' has no member named 'leaf'

There's a post on Nabble
(http://old.nabble.com/-filesystem--compiling-code-breaks-on-1.36-td19002108.html)
that mentions a very similar error, suggesting that Boost 1.36.0 broke
compatibility with older revs in regard to the filesystem.

All of this speaks to me of a version incompatibility between the
copies of OSSIE and Boost I'm using; either I'm following an outdated
set of instructions and fetching an old version of OSSIE from the
wrong place, or there's a setting I've neglected to tweak.

Can anyone who has recently built OSSIE on Angstrom, perhaps even for
the BeagleBoard, suggest where I may be going wrong here? I've got the
build logs if necessary, but in the interests of brevity I won't just
paste them all in here...

Thanks, Steve N1XNX