Re: [Discuss-gnuradio] Using USRP from multiple applications simultaneously

[Eric Blossom]

On Sun, May 01, 2005 at 08:27:34PM +0200, Harald Welte wrote:
> Hi!
> 
> AFAICT, at the moment there is no way to use a single USRP from multiple
> application programs at the same time.  This is quite unfortunate, since
> you might want to run a transmit and a receive program that are totally
> independent (or even two tx and two rx programs).

> While browsing through the usrp fx2 firmware and the low-level host-side
> code, I learned that there are three seperate usb interfaces which one
> endpoint each.  What was the idea of splitting control/in/out to
> seperate interfaces? 

The Tx and Rx sides are completely independent and we often run
different apps for Tx and Rx simultaneously.  The Tx and Rx paths have
different USB endpoints for their streaming data.  This is what allows
different apps/processes to open them.  They share a common control
endpoint (EP0), but that can be opened by more than one processes
since only usb command packets are used.

> Wouldn't it be nice to actually provide multiple interfaces that each
> correspond to a certain amount of USRP hardware?  This way each
> interface can be claimed by a seperate program.

Yes.  However, the FX2 is limited in the number of endpoints that it
supports.  See page 15 of the CY7C68013 datasheet.  Right now we are
running with endpoints 2 and 6 "quad buffered", 4 512 byte buffers
each.  One is used for Tx data, the other for Rx data.  It would be
possible with a bit of hacking to run endpoints 2, 4, 6 and 8 "double
buffered", 2 512 byte buffers each.  That would give us 4 bulk
endpoints to work with (and would also lower the worst case latency).

> Seperating it into four interfaces (2rx, 2tx) might be complicated,
> since there certainly are shared data structures and functional blocks.

Mostly the complication comes in the FPGA.  As implemented, all 4 DACs
and their signal processing code are in one clock domain and run
their signal processing paths in parallel.  This is where the
constraint on using the same interpolation factor comes from.  The
situation is the same on the Rx path and leads to them requiring the
same decimation factor.

> Providing two interfaces (one for each AD9862) should be easier,
> since full control over a singe AD9862 would be in one program.

Not the issue.  We already split control over the Tx and Rx parts of a
given AD9862 across processes.

> I haven't yet looked at the FPGA verilog, but maybe you can give me some
> comments on whether you think
> 
> 1) this is a good idea (and was planned but never implemented)
> 2) there are any serious known issues (which?)
> 
> If it looks feasible, I would probably be looking into that issue.

May be feasible, depending on your feature set.  In an ideal world,
there would be a separate endpoint and corresponding data stream
connecting to the output of each digital downconverter (or whatever
code you've got in the fpga) and likewise for the Tx path.  Then there
would be additional problems related to signaling between the FX2 and
FPGA which packets were to/from each endpoint etc.  There are no
unused pins between the FX2 and FPGA that could be used for addressing
the packets on the GPIF.  We're out of pins on the FPGA.

Eric