Re: [Discuss-gnuradio] I&Q on same or separate channels?

[Eric Blossom]

On Fri, Dec 14, 2007 at 10:45:26AM +0100, Uwe Bonnes wrote:
> >>>>> "Eric" == Eric Blossom <address@hidden> writes:
> 
>     Eric> On Thu, Dec 13, 2007 at 04:35:51PM -0500, George Nychis wrote:
> ...
>     Eric> I and Q are not on separate channels.  They are interleaved, I0,
>     Eric> Q0, I1, Q1...
> 
> This leads again to my question some time ago about how the USB data stream
> is organized. With the partial answer from that thread my understanding
> boils down to the following:
> - The FX2 has blocks/fifos of 512 bytes
> - We can put a data stream of interleaved sample in the fifo, but the data
> must form blocks of 512 bytes
> - If the fifo is full for some reason, the FX2 will block on a 512 byte 
> boundary
> - If the FPGA detects a FIFO stall, the FPGA must restart with DATA0 of the
> datablock 

The FPGA never stalls part way through a packet.  The flow control
between the FX2 and FPGA is based on signaling that there's room for
an entire packet.  When those flags are asserted, a 512 byte packet is
burst across the GPIF.

> - On the PC side, the kernel always always receives 512 byte blocks
> - If the user process always reads 512 blocks we never get out of sync
> 
> However the last postulate gives me some headache. How do we make sure that
> the user process always fetches 512 byte blocks.

The host code in our library manages this.   At the lowest level, it
never does anything that's not a multiple of 512 bytes.

> Can a crashing user process manage to read less then 512 bytes?

No.

> What if a rogue process reads less then 512 bytes. If the user process
> gets out of sync with the 512 bytes for some reason, is there any
> way to resynchronize?

Uwe, we've never seen this happen since we started working on the
USRP, and that's been something like 3 years.

If you still have doubts, I suggest that you look at the code.

Eric