Board Support Package and xil_io.h

Applications, development tools, FPGA, C, WEB
Post Reply
_undex
Posts: 6
Joined: Thu Dec 18, 2014 1:20 pm

Board Support Package and xil_io.h

Post by _undex » Thu Dec 18, 2014 2:25 pm

Hello everyone,

I'm really new to the RedPitaya board and Zynq, so for the start I tried to recreate this tutorial with the RP https://www.youtube.com/watch?v=kxvEcCchRrI. I made the design and bitstream (with the right zynq package etc) and created a Linux Hello World projekt in the SDK (I don't want to use the standalone OS). The problem I have here is that the generated code ps7_init.c needs a header named xil_io.h.

After some time on google I found out that I need a Board Support Package in my workspace. This requires a device tree from the RP, so I cloned the master RP branch on github and tried to compile the devicetree with vivado. The problem here was that it needed a directory (../hw/system.xml) which wasn't inside the vivado directory. I saw that the same directory existed in the ahead part of the fpga directory, so I copied it from there.

This time the compiler said this:

Code: Select all

make[1]: libgen: Command not found
I am sure that I called

Code: Select all

source /opt/Xilinx/Vivado/2014.4/settings32.sh
source /opt/Xilinx/SDK/2014.4/settings32.sh
in the RedPitaya directory.

Hope someone can help me

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

Re: Board Support Package and xil_io.h

Post by Nils Roos » Thu Dec 18, 2014 3:00 pm

I am not familiar with the tutorial, but if you are working with the RedPitaya source tree, you should really use the recommended development environment (which is Vivado 2013.3 or ISE 14.6).

Xilinx made a number of backward-compatibility-breaking changes between 2013.3 and 2014.1, especially in the area of the devicetree and the board support packages (eg the libgen tool is no longer part of the tools-suite).

_undex
Posts: 6
Joined: Thu Dec 18, 2014 1:20 pm

Re: Board Support Package and xil_io.h

Post by _undex » Thu Dec 18, 2014 4:06 pm

Thank you for your quick reply :D . I'm now downloading Vivado 2013.3. Let's see if it works then.

_undex
Posts: 6
Joined: Thu Dec 18, 2014 1:20 pm

Re: Board Support Package and xil_io.h

Post by _undex » Sun Dec 21, 2014 1:01 pm

I successfully built the RP source from git and I'm able to use the BSP. But the lack of "xil_io.h" remains. I searched for it and found it here: RedPitaya/OS/linux/linux-xlnx/drivers.
Anyway, the main reason I'm doing this, is to send data and recieve it from my design on the fpga inside a linux application. So my main question is:
How am I able to do this? So far I built the bitstream file of my design.

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

Re: Board Support Package and xil_io.h

Post by Nils Roos » Sun Dec 21, 2014 9:06 pm

I successfully built the RP source from git and I'm able to use the BSP. But the lack of "xil_io.h" remains. I searched for it and found it here: RedPitaya/OS/linux/linux-xlnx/drivers.
That's slightly odd, since the SDK should set up the include paths correctly for you - maybe some detail about how you configured the bsp. But if it's not a problem for you anymore, we'll let it slide.
Anyway, the main reason I'm doing this, is to send data and recieve it from my design on the fpga inside a linux application. So my main question is:
How am I able to do this? So far I built the bitstream file of my design.
The method commonly applied throughout the Red Pitaya design is to define a memory region on the AXI GP bus and map that memory on /dev/mem on the linux side.

To do that, you would connect your module to the system bus with these signals in red_pitaya_top.v:

Code: Select all

   // System bus
  .sys_clk_i       (  sys_clk                    ),  // clock
  .sys_rstn_i      (  sys_rstn                   ),  // reset - active low
  .sys_addr_i      (  sys_addr                   ),  // address
  .sys_wdata_i     (  sys_wdata                  ),  // write data
  .sys_sel_i       (  sys_sel                    ),  // write byte select
  .sys_wen_i       (  sys_wen[6]                 ),  // write enable
  .sys_ren_i       (  sys_ren[6]                 ),  // read enable
  .sys_rdata_o     (  sys_rdata[ 6*32+31: 6*32]  ),  // read data
  .sys_err_o       (  sys_err[6]                 ),  // error indicator
  .sys_ack_o       (  sys_ack[6]                 )   // acknowledge signal
(I used the only free slot in the original design, nr 6)

Additionally, comment out the placeholder signal assignment, also in red_pitaya_top.v:

Code: Select all

//assign sys_rdata[ 6*32+31: 6*32] = 32'h0;

//assign sys_err[6] = {1{1'b0}} ;
//assign sys_ack[6] = {1{1'b1}} ;
Your module declaration needs to define the following signals (<your module>.v):

Code: Select all

   // System bus
   input                 sys_clk_i       ,  //!< bus clock
   input                 sys_rstn_i      ,  //!< bus reset - active low
   input      [ 32-1: 0] sys_addr_i      ,  //!< bus saddress
   input      [ 32-1: 0] sys_wdata_i     ,  //!< bus write data
   input      [  4-1: 0] sys_sel_i       ,  //!< bus write byte select
   input                 sys_wen_i       ,  //!< bus write enable
   input                 sys_ren_i       ,  //!< bus read enable
   output     [ 32-1: 0] sys_rdata_o     ,  //!< bus read data
   output                sys_err_o       ,  //!< bus error indicator
   output                sys_ack_o          //!< bus acknowledge signal
, declare the following sysbus signals:

Code: Select all

wire [ 32-1: 0] addr         ;
wire [ 32-1: 0] wdata        ;
wire            wen          ;
wire            ren          ;
reg  [ 32-1: 0] rdata        ;
reg             err          ;
reg             ack          ;
, and instantiate a bus synchronizer:

Code: Select all

// bridge between <your module> and sys clock
bus_clk_bridge i_bridge
(
   .sys_clk_i     (  sys_clk_i      ),
   .sys_rstn_i    (  sys_rstn_i     ),
   .sys_addr_i    (  sys_addr_i     ),
   .sys_wdata_i   (  sys_wdata_i    ),
   .sys_sel_i     (  sys_sel_i      ),
   .sys_wen_i     (  sys_wen_i      ),
   .sys_ren_i     (  sys_ren_i      ),
   .sys_rdata_o   (  sys_rdata_o    ),
   .sys_err_o     (  sys_err_o      ),
   .sys_ack_o     (  sys_ack_o      ),

   .clk_i         (  adc_clk_i      ),
   .rstn_i        (  adc_rstn_i     ),
   .addr_o        (  addr           ),
   .wdata_o       (  wdata          ),
   .wen_o         (  wen            ),
   .ren_o         (  ren            ),
   .rdata_i       (  rdata          ),
   .err_i         (  err            ),
   .ack_i         (  ack            )
);
To enable reading data from your module, put in something like:

Code: Select all

always @(*) begin
   err <= 1'b0 ;

   casez (addr[19:0])
     20'h00000 : begin ack <= 1'b1;          rdata <= <your output register 0>       ; end 
     20'h..... : ...

     20'h1???? : begin ack <= <your BRAM data valid signal>;     rdata <= <your BRAM block at address ????>              ; end // (optional)

       default : begin ack <= 1'b1;          rdata <=  32'h0                              ; end
   endcase
end
If you need to write to your module from linux, put in something like:

Code: Select all

 reg [32-1:0] your_reg;

always @(posedge adc_clk_i) begin
   if (adc_rstn_i == 1'b0) begin
      your_reg <= 32'h0   ;
   end
   else begin
      if (wen) begin
         if (addr[19:0]==20'h0)    your_reg <= wdata[32-1:0] ;
         if (addr[19:0]==20'h.....)    ...
      end
   end
end
In linux, you then need to mmap() the memory region 0x40600000 - 0x406fffff on /dev/mem (see /Test/monitor/monitor.c for example). The pointer that you obtain from mmap() will allow you access to your FPGA logic by simple dereferencing.

I'm assuming in all this that your module runs on the adc_clk which is the clock that all ADC/DAC 14bit datapaths run on.

_undex
Posts: 6
Joined: Thu Dec 18, 2014 1:20 pm

Re: Board Support Package and xil_io.h

Post by _undex » Mon Dec 22, 2014 8:26 pm

Thanks a lot :D . I'm now able to control the LEDs on the RP with mmap. However I read that the communication with the PL with mmap is only a test/debug solution.
What is the right way of doing it? I saw that a driver (a ".c" and a ".h" file) was generated for my custom ip. How do I use these files with the default linux OS?
I tried to generate a BSP, but the only code there was "xparameters.h".

Also one off-topic question: I read that there is an onboard serializer in the Zynq-chip. Is it possible to use it to generate a high frequency signal that can be outputted to the fast analog output?

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

Re: Board Support Package and xil_io.h

Post by Nils Roos » Tue Dec 23, 2014 6:46 pm

_undex wrote:However I read that the communication with the PL with mmap is only a test/debug solution.
What is the right way of doing it?
Where did you read that ? It is true that mmap()ing an address range on /dev/mem is not commonly used for communication with devices, because only root is allowed to mmap on /dev/mem, and direct access to hardware registers is usually not provided to userland.
But as far as the Red Pitaya is concerned, it is used pervasively. All the web apps (scope, scope+gen, freqanalyzer, etc.) use it and generate, monitor and acquire use it, too.

The "right way" to do it would be to write a kernel module that registers itself as a driver for the PL and wraps the functionality in the usual linux abstractions - eg. ioctl() calls for settings and read()/write() for moving data. If you'd like to take a look at a working example, I've written a Red Pitaya driver that does some of that (beware, this driver looks for some additions in the PL that help with device enumeration, and will not install if it cannot find these additions).
_undex wrote:I saw that a driver (a ".c" and a ".h" file) was generated for my custom ip. How do I use these files with the default linux OS?
I tried to generate a BSP, but the only code there was "xparameters.h".
I have not yet done an ip design that came with a driver, so I cannot really say anything specific. But generally speaking, drivers are either included in the kernel build or added later in the form of "insmod"-able modules. In both cases you need to write a simple Makefile (see for example any Makefile in /OS/linux/linux-xlnx/drivers, or the one that comes with my driver).
_undex wrote:Also one off-topic question: I read that there is an onboard serializer in the Zynq-chip. Is it possible to use it to generate a high frequency signal that can be outputted to the fast analog output?
There are serializers and deserializers in the ZYNQ, but they operate purely in the digital domain. But you can load arbitrary waveforms into the DAC buffer and play them at any rate up to 125MS/s.
If that is not what you need, I think I don't understand exactly what your goal is.

_undex
Posts: 6
Joined: Thu Dec 18, 2014 1:20 pm

Re: Board Support Package and xil_io.h

Post by _undex » Sat Dec 27, 2014 2:25 pm

I will create a new thread where I describe my goal.

Anyway, thank you very much for your help Nils. I will use mmap for the future, as it is the easiest way of transferring data, I think.

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 45 guests