Page 25 of 30

Re: New feature: high speed continuous recording

Posted: Mon Nov 21, 2016 10:49 am
by rothmart
Okay, rp_remote_acquire works fine in server mode in combination with Matlab Simulink ‘TCP/IP Receive’ block. Just insert IP and port, devide data by 4 and you can handle data streams. But it’s important to load ddrdump.bit before starting ./rp_remote_acquire. Option –l ddrdump.bit isn’t needed.

Now I plan to use that project with further verilog modifications (onboard demodulation). So I would need your Vivado project that builds the ddrdump.bit – is it possible to publish that?

Re: New feature: high speed continuous recording

Posted: Mon Nov 21, 2016 9:48 pm
by Nils Roos
It's on github in my fork of the Red Pitaya repo. It's based on the build processes of the <= 0.93 releases, so it may seem unfamiliar when compared to the current versions.

Re: New feature: high speed continuous recording

Posted: Sat Dec 10, 2016 3:48 pm
by VincKem
Hi everyone,
First of all, thanks Nils for everything you have put together so far.
I tried to recompile the sources for rp_remote_accquire from the bkinman folder (on my Ubuntu machine and on the RP). But I keep getting the same error when compiling the transfer.c file when calling the transfer_mmappipe function (See screenshot below)
Any hints ?????
Thanks in advance.
Vincent

Re: New feature: high speed continuous recording

Posted: Sun Dec 11, 2016 4:20 pm
by Nils Roos
Hi Vincent,
the function to splice the dma buffers into a pipe was an experiment that never worked correctly. It has long since been removed from rp_remote_acquire - in newer version than the one in Brandon's repository. You can find more up-to-date sources here.

Re: New feature: high speed continuous recording

Posted: Mon Jan 09, 2017 1:08 pm
by carlos.e.teixeira
Hi everyone!

I think that this topic is the proper one for my issue.

I'm taking a look at this section of code which concerns the changement of FPGA clock and the HP0 bus width, just to understand how it works. It cames from one of the Pavel's projects.

Code: Select all

slcr = mmap(NULL, sysconf(_SC_PAGESIZE), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0xF8000000);
  axi_hp0 = mmap(NULL, sysconf(_SC_PAGESIZE), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0xF8008000);
  cfg = mmap(NULL, sysconf(_SC_PAGESIZE), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0x40000000);
  ram = mmap(NULL, 1024*sysconf(_SC_PAGESIZE), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0x1E000000);

  // set FPGA clock to 143 MHz and HP0 bus width to 64 bits
  slcr[2] = 0xDF0D;
  slcr[92] = (slcr[92] & ~0x03F03F30) | 0x00100700;
  slcr[144] = 0;
  axi_hp0[0] &= ~1;
  axi_hp0[5] &= ~1;
I've already understand the role of this code, but I would like to have a complete understanding.

First of all, the code maps the memory at a specific address to its corresponding pointer. Taking a look at the UG585 Technical Reference Manual Documentation (page 114), I could check the base address 0XF8000000 corresponds to the System Level Control Registers. Also, I could check the base address 0xF8008000 corresponds to the High Performance Port 0 (HP0).

As the comment itself implies, it changes the FPGA clock by configuring some System-Level Control registers (SLCR Registers) and it changes the HP0 bus width to 64 bits by configuring the corresponding registers.

It is not so difficult to see that variables 'axi_hp0[0]' and 'axi_hp0[5]' correspond respectively to AFI_RDCHAN_CTRL and AFI_WRCHAN_CTRL registers (page 786) and by setting their bit '32BitEn' (bit 0) to zero, it enables the 64-bit bus width for both read and write channels.

My problem lies in understanding the set up of SLCR registers.

As the page 1580 shows the complete description of the register, I've checked that 'slcr[2]' corresponds to the SLCR_UNLOCK register and by writing the value 0xDF0D, it enables writes to the SLCR registers. If I'm correct, 'slcr[92]' corresponds to the register MIO_PIN_12 and 'slcr[144]' corresponds to the register GPIOB_CFG_CMOS25. For the GPIO_CFG_CMOS25, I noted that only allowed values for this register are 0x00000000 (reset value) and 0x0C301100 (normal operation). However, I do not understand the following line 'slcr[92] = (slcr[92] & ~0x03F03F30) | 0x00100700;'

Finally, how is this code able to change the FPGA clock?

Thanks in advance and Happy New Year!!

Best regards!

Re: New feature: high speed continuous recording

Posted: Mon Jan 09, 2017 4:10 pm
by pavel
If I'm correct, 'slcr[92]' corresponds to the register MIO_PIN_12 and 'slcr[144]' corresponds to the register GPIOB_CFG_CMOS25.
slcr[92] corresponds to FPGA0_CLK_CTRL

Code: Select all

Name FPGA0_CLK_CTRL
Relative Address 0x00000170
slcr[144] corresponds to FPGA_RST_CTRL

Code: Select all

Name FPGA_RST_CTRL
Relative Address 0x00000240
However, I do not understand the following line 'slcr[92] = (slcr[92] & ~0x03F03F30) | 0x00100700;'
Neither do I. The mask corresponds to the active bits listed in UG585. But the value I had to copy from the FSBL code generated by Vivado HSI. According to UG585, 0x00100700 corresponds to SRCSEL = 0 (IO PLL), DIVISOR0 = 7, DIVISOR1 = 1. I don't know why these divisors correspond to 143 MHz.

Anyway, the only part relevant to the high speed continuous recording is the HP0 bus with.

Re: New feature: high speed continuous recording

Posted: Mon Jan 09, 2017 5:16 pm
by carlos.e.teixeira
Hi Pavel!

Thank you so much for the explanation!

By knowing the registers 'slcr[92]' and 'slcr[144]' correspond to the registers FPGA0_CLK_CTRL and FPGA_RST_CTRL (and not those ones I have mentioned), it becomes clearer. Now, it is easy to verify the applied mask results in slcr[92] = FPGA0_CLK_CTRL = xxxx xx00 0001 xxxx xx00 0111 xx00 xxxx. In other words, we have what you've just said: SRCSEL = 0 (IO PLL), DIVISOR0 = 7, DIVISOR1 = 1.

Otherwise, I keep on not understandind how these values result in a 143MHz-clock, just like you. Do you know if there is a table that lists these values and the corresponding clock frequency values?

Also, I was confusing about the indexes. Where could I find the description of these indexes? I mean, when I map the memory to the 'slcr' pointer, using the following code:

Code: Select all

slcr = mmap(NULL, sysconf(_SC_PAGESIZE), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0xF8000000)
How can I know the correspondence between SLCR registers and indexes (e.g., slcr[2] => SLCR_UNLOCK , slcr[92] => FPGA0_CLK_CTRL , slcr[144] => FPGA_RST_CTRL)?

In order to do that, I was seeing the page 1580 of the UG585. Actually, I thought the indices followed the order of the register summary table. Then, we would have slcr[0] => SCL, slcr[1] => SLCR_LOCK, slcr[2] => SLCR_UNLOCK and so on...). That's why I suspected slcr[92] => MIO_PIN_12 and slcr[144] => GPIOB_CFG_CMOS25.

Thank you again in advance, Pavel!

Regards!

Re: New feature: high speed continuous recording

Posted: Mon Jan 09, 2017 6:25 pm
by carlos.e.teixeira
Pavel,

About this issue mentioned earlier:
Otherwise, I keep on not understandind how these values result in a 143MHz-clock, just like you. Do you know if there is a table that lists these values and the corresponding clock frequency values?
I think I could answer our question. As we already know, by setting the SRCSEL to 00 (or 01), the source for generated clock will be IO PLL (10 => ARM PLL and 11 => DDR PLL). According to UG585, this source provides a 1GHz -clock. Note that, PLL Output Frequency will be 1GHz for both 33.33MHz and 50MHz input frequencies. In our case, as we've chosen SRCSEL = 0 (IO PLL), DIVISOR0 = 7, DIVISOR1 = 1, we have

FCLK0 = 1000MHz/7/1 = 142.86 MHz

Finally, I would like to know if it would not be necessary to write protect again the SLCR registers by writing 0x767B in the register SLCR_LOCK (absolute address: 0xF8000004). In page 510 of UG585, there is an exemple showing how to configure clocks, in this case the clocks for MIO.

PS.: In my last (previous) post, I also asked about the indexes of the 'slcr' pointer. I would appreciate a lot if you could help me on that!

Thank you for the attention!
Regards!

Re: New feature: high speed continuous recording

Posted: Mon Jan 09, 2017 9:03 pm
by Nils Roos
The indices for the slcr registers for array-like accesses are simply calculated from the address of the register relative to the base (0xf8000000).
slcr is a (uint32_t *), so
slcr[92] = 0xf8000000 + 92 * sizeof(uint32_t) = 0xf8000170
Finally, I would like to know if it would not be necessary to write protect again the SLCR registers by writing 0x767B in the register SLCR_LOCK (absolute address: 0xF8000004)
We recently found out that Xilinx's own slcr kernel driver unlocks the slcr registers and leaves them unlocked, so we decided to follow their lead.

Re: New feature: high speed continuous recording

Posted: Tue Jan 17, 2017 10:59 pm
by tsitsimp
Hello again,

Coming back to this, I used the rp_remote_acquire along with a udp receiver in Matlab and I do receive the data continuously. However, even though I feed the fast input with a 100mV sine wave, the plotted sine wave range between -500 and 2000 arbitrary units. Anyone knows why this is happening? On the matlab side, I ve set the the receive buffer size as 16384, the maximum length message at 255, and data type as int16; I assume that is correct? Am I once again missing something that I shouldn't?

Kind Regards,
Johnny