Data flow between LMS7002M and FW/FPGA and how to configure

Oh is it? I can see FX3 code sending over I2C-SPI bridge for all the requests related to FPGA/LMS7002M and handling nothing else after that. I think it’s definitely using I2C-SPI bridge to send requests to FPGA.
Thanks for your response.

Hi @gchat,

Initially many on-board peripherals were controlled using I2C SPI bridge. Then we moved this task to NIOS CPU (as @andrewback rightly mentioned) and control commands from the PC are sent to different endpoints. Hence control functionality is still in the FX3, but it is not used.

Oh Ok @Zack. Thanks for that.
So, are they alternates to each other. I mean I can either use I2C-SPI Bridge or NIOS-II for controlling the peripherals??
Using the bridge would make it easier in terms of Host PC sending all requests to the same endpoint, right? But what is the use of NIOS in that case? Only providing SPI from FPGA to LMS7002M or something else?

In other case of using NIOS for these tasks instead of I2C-SPI Bridge, can you please point me to any manual or document describing the control/data flow.

Thanks a lot @Zack and @andrewback for the help so far. Regards.

SPI going via FX3 parallel interface -> FPGA NIOS -> LMS7002M is much faster than when the route is from FX3 I2C via bridge and on to LMS7002M. I2C provides a bottleneck in the latter.

We will only officially support the current mechanism using NIOS-II for SPI, but given it’s open source, you are free to modify the host and FX3 code, FPGA RTL and NIOS-II firmware as you please :slight_smile:

We use FX3 modification with 32 bit GPIF data interface to FPGA. There is FX3 flavor with 16 bit GPIF interface, but data throughput is two times less than in 32 bit case. But there is no native SPI interface in 32 bit GPIF flavor. Hence initially we decided to use I2C to SPI bridge, while native I2C is sill there. But the issue was that it slows down the control communication. To overcome this we implemented NIOS for this task.

No difference from software point of view.

Mainly to control all the on-board peripherals. NIOS doesn’t have an access to IQ data.

Can you please help me find the code in FX3 for this. Which requests are supported using this mechanism. That would be a great help. Also, how would SPI be used if 32-bit GPIF is used?
Thanks

There is no FX3 code involved in this task at all. The control packets from PC are just re-transmitted to GPIF interface where NIOS catches it.

Ok thanks. So it’s only coded in FPGA and NIOS IP code?

In that case, is the FX3 code using: I2C_Addr = I2C_ADDR_SC18IS602B; and CyU3PI2cTransmitBytes () obsolete
for requests like CMD_LMS7002_WR, CMD_LMS7002_RD, CMD_BRDSPI16_WR, CMD_LMS_MCU_FW_WR etc.?

Well, there is FX3 code involved in endpoint setup only. And after that PC and NIOS are involved.[quote=“gchat, post:12, topic:1501”]
In that case, is the FX3 code using: I2C_Addr = I2C_ADDR_SC18IS602B; and CyU3PI2cTransmitBytes () obsolete
for requests like CMD_LMS7002_WR, CMD_LMS7002_RD, CMD_BRDSPI16_WR, CMD_LMS_MCU_FW_WR etc.?
[/quote]

Correct. I just would not say it is obsolete. It is just reserved for other tasks, but officially not supported.

Great. Thanks for letting me know. But is there any document giving some details about these changes. Because from the first look at code, I don’t think anybody would figure out that these things are not used.
So, in short GPIF is being used for everything between FW and FPGA: Controlling Peripherals and Data transfer both.
And between FPGA, it’s SPI for control and Port1 & Port2 data lines for data. Correct? And all the control part is handled by NIOS?

I will study more and will have many more questions now :slight_smile:
Regards

Can someone please help me with this understanding. Thanks in advance.

Hi, I am also interested in the inner workings of communications.
I am hoping to be able to be able to bypass the USB completely so that I can hook up a SPI or even a uart to the FPGA through the available GPIO lines. This would allow me to use a bare metal micro to process the I and Q data without the need for the LimeSDR USB driver. I have looked at the LMS7 register map and it is pretty straightforward to read and write to the registers. My plan is to modify the FPGA/NIOS code to map this GPIO-based interface to the SPI going to the LMS7 chip and to also respond to requests for bulk data transfers of the I and Q data.

Does any of this sound possible or is there an easier way to talk to the LimeSDR over SPI rather than USB?

Hi @rene,

Check this:

Here you will find FPGA gateware and Arduino example on how to control LMS7002M chip via external SPI, connected to GPIOs.

Thanks Zack.
This confirms I can use the GPIO lines as a spi.
Questions:
Am I correct to assume that the code changes are in the NIOS II?
Am I correct to assume that the I and Q data is processed by the FPGA before being streamed out the USB and if so, do you have any ideas on how to access the stream without the USB? For example, could one add code to the NIOS II to pre-process the I and Q data and then send it out the GPIO/SPI that is being used also for register read/writes?

Hi @rene,

You are not. In the link I just shared, LMS7002M SPI lines are routed to LimeSDR-USB board GPIOs. You need an external SPI master like Arduino in this case, to be able to control LMS7002M. NIOS now doesn’t have an access to LMS7002M SPI.

Correct. But processing is just packet for USB construction.[quote=“rene, post:18, topic:1501”]
if so, do you have any ideas on how to access the stream without the USB? For example, could one add code to the NIOS II to pre-process the I and Q data and then send it out the GPIO/SPI that is being used
[/quote]

Well, you may write IQ samples to the RAM, then process it and then send the data via SPI (means slowly) to the outside world. But this should be a custom gateware.

I see. So the code changes you provided re-route the SPI connection that NIOS II was using to the GPIOs.
We do have to build a custom gateway because we plan to do some signal processing at the FPGA and then take the resulting data and provide it on demand (so we can use the same spi for commands and data transfer). We are downsampling so the resulting data rate will be 1kHz which I’m assuming should not be an issue to fetch every half second or so.

2 Likes

Hi @rene,

Correct.

Looks like a nice project!

Yes, a nice challenging project - it is already a lot of fun. So far we are quite pleased with the capability of the LimeSDR - just a little overwhelmed with all the signal processing choices.

On the subject of data transfer:

  1. If I bypass the FPGA, using the code you referenced, can I still read the I and Q data directly from the LMS7 chip? I looked at the LMS7 register map and I could not find the register address from which to read the I and Q data.

  2. I am currently reading I and Q at 30 MB/s through the SoapySDR interface with the standard gateway. Do you know if this means 30 Mega Samples per second where 1 sample is two 12-bit values or does it literally means 30 Mega bytes (8-bit) per second?

Hi @rene,

There is no possibility to read data from LMS7002M via SPI. Well, there is, but it is not synchronized with the clock and dedicated for test purposes only. You have to catch the IQ data with FPGA via digital interface.

It is megabytes per second.

Thanks Zack - that makes sense to get precise timing without jitter.