SC12 support?

[OhSoGood]

Hi,

Does bladerf.dll support SC12 or is it only SC16 for over-the-wire formats ? If only SC16, could SC12 be added?

When dealing with high bandwidth and being at the max limit of USB3, to have SC12 is a real advantage to reduce bandwidth.

[rtucker]

Greetings...

Short answer: it is not currently supported, but it is quite possible. Because we're working in a byte-aligned world, there is a decent amount of implementation complexity, and also some non-trivial performance tradeoffs to consider.

Long answer:

The FPGA packs the SC16 (which are really sign-extended SC12) samples into a 64-bit-wide FIFO, in fifo_writer.vhd:

        --      | 63:48 | 47:32 | 31:16 | 15:0 | Bit indices
        --   1. |   Q1  |   I1  |   Q0  |  I0  | Channels 0 & 1 enabled
        --   2. |   Q0' |   I0' |   Q0  |  I0  | Channel 0 only enabled
        --   3. |   Q1' |   I1' |   Q1  |  I1  | Channel 1 only enabled

The first case is the MIMO mode (two channels enabled, one sample cycle per write); the second and third are the SISO mode (one channel enabled, two sample cycles per write).

That FIFO outputs the samples in 32-bit chunks to the FX3, which streams them to the host, which currently expects an integer number of bytes per sample (e.g. SC16 is 4 bytes).

An optimal 12-bit alignment would end up looking something like:

Frame 0: Q0(1)(3 downto 0) & I0(1) & Q1(0) & I1(0) & Q0(0) & I0(0)
Frame 1: I1(3)(7 downto 0) & Q0(2) & I0(2) & Q1(2) & I1(2) & Q0(1)(11 downto 4)
Frame 2: Q1(4)             & I1(4) & Q0(3) & I0(3) & Q1(3) & I1(3)(11 downto 8)

Frame 0: Q0(6)(3 downto 0) & I0(6) & Q1(5) & I1(5) & Q0(5) & I0(5)
...

where {I,Q}x(n) is the nth sample from channel x.

This would turn it into 5 sample cycles per 3 writes (assuming MIMO), which is somewhat more complicated to pack and unpack.

(The above is written from an RX perspective, but the same applies to TX.)

Also be aware that the USB interface (assuming SuperSpeed) works in blocks of 4096 bytes, but the closest you can get with 3x 64-bit chunks is 4080 bytes. However, the in-band metadata inserts 16 bytes at the start of every block, which (unless I f'd up the math) is the perfect amount of padding.

On the host side, keep in mind that there's no int12_t, and the buffers would not be directly castable to/from an array of int16_t. This would break the zero-copy architecture, which is a performance risk, but it's probably not too bad.

All that said, we would definitely consider a pull request that implements this :)

[KarlL2]

Hi @rtucker

How fast can you stream when using 2 RX with SC16 with a bladeRF 2.0 micro? On LimeUSB eg, it's possible to stream at 60MS/s but only in SC12. As the bladeRF 2.0 micro uses also FX3 USB 3.0, I guess it will be limited in the same way? Here is where they explain the math for their case.

Having SC12 would be useful if SC16 limits the number of samples we can receive.