New feature: high speed continuous recording

Discussions about active development projects
rothmart
Posts: 14
Joined: Fri Nov 13, 2015 3:10 pm

Re: New feature: high speed continuous recording

Post by rothmart » Mon Nov 21, 2016 10:49 am

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?

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Mon Nov 21, 2016 9:48 pm

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.
All in a day's work for Bicycle Repair Man

VincKem
Posts: 2
Joined: Tue Feb 02, 2016 12:37 pm

Re: New feature: high speed continuous recording

Post by VincKem » Sat Dec 10, 2016 3:48 pm

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
You do not have the required permissions to view the files attached to this post.

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Sun Dec 11, 2016 4:20 pm

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.
All in a day's work for Bicycle Repair Man

carlos.e.teixeira
Posts: 13
Joined: Mon Nov 28, 2016 1:00 pm

Re: New feature: high speed continuous recording

Post by carlos.e.teixeira » Mon Jan 09, 2017 1:08 pm

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!

pavel
Posts: 478
Joined: Sat May 23, 2015 5:22 pm

Re: New feature: high speed continuous recording

Post by pavel » Mon Jan 09, 2017 4:10 pm

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.

carlos.e.teixeira
Posts: 13
Joined: Mon Nov 28, 2016 1:00 pm

Re: New feature: high speed continuous recording

Post by carlos.e.teixeira » Mon Jan 09, 2017 5:16 pm

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!

carlos.e.teixeira
Posts: 13
Joined: Mon Nov 28, 2016 1:00 pm

Re: New feature: high speed continuous recording

Post by carlos.e.teixeira » Mon Jan 09, 2017 6:25 pm

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!

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Mon Jan 09, 2017 9:03 pm

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.
All in a day's work for Bicycle Repair Man

tsitsimp
Posts: 14
Joined: Mon Oct 17, 2016 1:36 pm

Re: New feature: high speed continuous recording

Post by tsitsimp » Tue Jan 17, 2017 10:59 pm

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

Post Reply
jadalnie klasyczne ekskluzywne meble wypoczynkowe do salonu ekskluzywne meble tapicerowane ekskluzywne meble do sypialni ekskluzywne meble włoskie

Who is online

Users browsing this forum: No registered users and 3 guests