LimeSDR configuration speed optimisation

Image: detail from LimeSDR v1.4 schematic

Right from the outset the intention with LimeSDR has been to provide the very best performance and overall user experience, with a commitment to investing significant effort in engineering and striving to get the most out of the hardware platform.

A good example of this is the USB 3.0 interface and this is provided by a Cypress FX3 microcontroller, which is available in many different variants. One option would have been to select a device with a lower throughput on the interface used to transfer samples, but that incorporates an SPI core that would have made programming the LMS7002M transceiver far simpler. However, instead a higher throughput device was selected, that doesn’t have SPI but does have I2C.

Initially we used an I2C/SPI bridge to program the transceiver and this meant that, while we could support fantastic baseband throughput rates, transceiver setup took longer due to SPI transactions running at a reduced speed. However, what this did is to enable work to progress on the driver, getting fully functional prototype hardware into the hands of the community and together developing some truly great demos — all while receiving plenty of invaluable early feedback.

We are now pleased to be able to report a serious boost to the performance of the transceiver programming interface, thanks to SPI transactions instead being handled by a NIOS II soft processor in the Altera FPGA, which makes use of the same 32-bit parallel interface on the FX3 that is used for the I/Q data stream. The result of this work is that SPI transactions (read or write) now complete in ~120uS for one transceiver register, enabling much faster retuning and setting gains etc.

The vast majority of uses — whether an enthusiast simply scanning the broadcast FM band or an engineer prototyping a new waveform — will benefit from faster transceiver programming, as it results in a more responsive user experience and the ability to support frequency agile applications.

Edit 20/11/16: gateware, firmware and LimeSuite must be updated in order to benefit from the SPI optimisation. Those with prototype boards should take care to ensure that they select the gateware and firmware git branches which correspond to their hardware revision.

2 Responses to “LimeSDR configuration speed optimisation”

  1. My guess is that you are using a propriety SPI Host implementation provided by Altera for the Nios II.

    It might be that one day there will be an alternative implementation of it based on a Risc-V soft core with
    open source IP. But for sure, for now, its not a priority for anyone.

  2. Agreed, a RISC-V or OpenRISC core would be preferable, but the priority was to get a fast, working and reliable solution sooner.

    Of course, swapping out the NIOS II for a RISC-V or OpenRISC core would also make a great project for someone and we’d welcome such a contribution.

Leave a Reply