redpitaya - vivado 2015

[Arnold1]

hi,

how can i synthesize redpitaya default fpga code (https://github.com/RedPitaya/RedPitaya/tree/master/FPGA) using your approach?

$ make NAME=red_pitaya all    ??

i tried to import the redpitaya project (https://github.com/RedPitaya/RedPitaya) into vivado 2015 but ended up in these errors: http://ideone.com/4WUUsB ...any idea how to fix it?

could you upload a vivado project which fixes these errors?

[pavel-demin]

Hi,

The command to build the same FPGA configuration as on the default RedPitaya SD card is

make NAME=red_pitaya_0_92 all

I tested it with Vivado 2015.1 and the monitor/generate/acquire commands. All worked well.

The project with the name red_pitaya contains the latest code from the devel branch of the RedPitaya repository and it's, at the moment, incompatible with the acquire command.

BTW the most common solution to the problem that you posted on the RedPitaya forum is

sudo ln -s make /usr/bin/gmake

I added this command to my notes.

Cheers,

Pavel

[pavel-demin]

Concerning the Vivado 2015.1 errors with a project imported from the RedPitaya repository, I'd say that TMDS_33 should be replaced with LVCMOS33 on lines 143 and 144 in FPGA/release1/fpga/code/red_pitaya.xdc.

[Arnold1]

thanks for the quick reply. thanks already fixed the gmake issue...

cant i also use the following command to build the FPGA configuration? whats the difference between the red_pitaya_0_92 and red_pitaya?

make NAME=red_pitaya all

regarding the gui bases synthesis: after replacing TMDS_33 with LVCMOS33 the synthesis should work as expected?

does your ubuntu sd card image also have the monitor/generate and webserver installed?

[pavel-demin]

The project/red_pitaya directory contains the latest code from the devel branch of the RedPitaya repository and it's, at the moment, incompatible with the acquire command. At least, it does not work for me.

In other words, make NAME=red_pitaya will produce a FPGA configuration that will not work with acquire command and most probably will not work with other RedPitaya data acquisition tools like oscilloscope, etc.

I'd say that it's currently safer to stay with the version 0.92 of the RedPitaya code and wait till the RedPitaya developers release a new stable version of their code.

The Ubuntu SD card image does not have the monitor/generate/acquire and webserver installed.

The monitor/generate/acquire programs are very easy to build with the following commands:

git clone https://github.com/RedPitaya/RedPitaya.git
cd RedPitaya
git checkout 0.92
make -C Test/monitor CROSS_COMPILE=arm-linux-gnueabihf-
make -C Test/acquire CROSS_COMPILE=arm-linux-gnueabihf-
make -C Test/generate CROSS_COMPILE=arm-linux-gnueabihf-

Then you can copy these three programs to your red-pitaya-notes directory, edit scripts/sdcard.sh to uncomment cp acquire generate monitor $root_dir/usr/local/bin/ on line 52 and then run sudo sh scripts/image.sh red-pitaya-ubuntu-14.04.2.img. This way, you'll have monitor/generate/acquire installed on the SD card image.

I've never tried to make the RedPitaya web server running on the Ubuntu SD card. I just boot from the original RedPitaya SD card when I need it (very rarely).

[pavel-demin]

after replacing TMDS_33 with LVCMOS33 the synthesis should work as expected?

As you don't have any other errors, I'd say that it should work.

[pavel-demin]

project/red_pitaya_0_92 contains the version 0.92 of the RedPitaya code https://github.com/RedPitaya/RedPitaya/tree/0.92/FPGA/release1/fpga/code/rtl

project/red_pitaya contains the code from the devel branch of the RedPitaya repository https://github.com/RedPitaya/RedPitaya/tree/devel/FPGA/release1/fpga/code/rtl

[Arnold1]

i tried to compile it, but got this error: http://ideone.com/pgyMDl

[pavel-demin]

Before cross-compiling nginx, you need to cross-compile its dependencies (pcre, zlib, etc).

I'd say that it could be easier to install pre-built ngnix, nginx-extras, gcc, etc on the Ubuntu SD card from the Ubuntu repositories:

apt-get install nginx nginx-extras build-essential gcc

and then build (by running gcc on the RedPitaya board) only the RedPitaya specific module: https://github.com/RedPitaya/RedPitaya/tree/master/Bazaar/nginx/ngx_ext_modules/ngx_http_rp_module

[Arnold1]

i checked the synthesis for red_pitaya_0_92.... vivado reports that some timing constraints are not met for the design... are those ok? e.g. total negative slack (TNS): -32.712 ns intra clock paths: adc_clk: TNS(ns): -26.374

[pavel-demin]

It seems to work even with these timing problems.

The RedPitaya developers fixed most of them in the devel branch. So, hopefully, there won't be any timing problem in the next release.

[Arnold1]

any idea when the next release will role out?

[pavel-demin]

any idea when the next release will role out?

No idea. It's a question for the RedPitaya developers.

One of the reasons I put together this project was to not care about the RedPitaya releases.

[Arnold1]

i see there is .xpr project created in tmp for vivado when i run make... i opened it with vivado and can also see the block design... does that mean i can also generate the bitstream using the gui based flow?

[pavel-demin]

Yes, sure, you can combine GUI and command line.

You can tell make to create .xpr project and then stop with the following command:

make NAME=sdr_receiver tmp/sdr_receiver.xpr

Then you can open the project in Vivado and generate the bitstream.

Or you can generate the bitstream from the command line:

make NAME=sdr_receiver tmp/sdr_receiver.bit

[Arnold1]

i tried to run the default blink application with the bitstream generated by vivado 2015... it seems there some issues resulting that my app crashes unexpected... can you try to fix the timing issues i saw in the synthesis and possible other causes by looking at the warnings?

could you also upload the fpga bitstream from the default ecosystem (generated with vivado 2013)? i want to double check the behavior...

[pavel-demin]

i tried to run the default blink application with the bitstream generated by vivado 2015

What is the default blink application? Google returned nothing relevant for my "red pitaya blink application" request. What project are you using to generate the bistream red_pitaya_0_92 or red_pitaya?

can you try to fix the timing issues i saw in the synthesis

No, it's too much work for me. I'm neither the author nor the maintainer of the Red Pitaya Verilog code. As I mentioned in one of my previous comments, I tested red_pitaya_0_92.bit with Vivado 2015.1 and the data acquisition programs monitor/generate/acquire worked. Moreover, most of the timing problems are already solved in the devel branch of the RedPitaya repository.

could you also upload the fpga bitstream from the default ecosystem (generated with vivado 2013)?

Why you can't do it yourself? Just follow the instructions at http://wiki.redpitaya.com/index.php?title=FPGA_development_environment

[Arnold1]

I tested red_pitaya_0_92.bit. The default blink application maps the fpga memory using mmap to the user space and writes to register 0x40000030: http://ideone.com/g0Vunb I will look at the synthesis warnings but not sure if i can fix it...

How is the red_pitaya_0_92.bit different from the original bitstream?

i thought u have the original bitstream available or know where to find it...

i could try the dev version: make NAME=red_pitaya all

[pavel-demin]

The red_pitaya_0_92.bit bitstream should not be different from the original bitstream. I copied the Verilog code from the RedPitaya repository (tag 0.92).

I don't have the original bitstream and I don't have Vivado 2013.3 to rebuild it.

I've just tested a simplified version of your blink program together with red_pitaya_0_92.bit built using make NAME=red_pitaya_0_92 tmp/red_pitaya_0_92.bit and Vivado 2015.1. Everything worked without any problem. The third LED blinked ten times :-)

You can find pre-built red_pitaya_0_92.bit, blink.c and pre-built blink at the following location: https://0c2d3ba9cf2a7be9395f36aa24dd59103ca884e9.googledrive.com/host/0B-t5klOOymMNfmJ0bFQzTVNXQ3RtWm5SQ2NGTE1hRUlTd3V2emdSNzN6d0pYamNILW83Wmc/red_pitaya_0_92/

[Arnold1]

thanks. i figured out that the mapping to /dev/mem and writing to the fpga memory causes this problem...

/dev/mem provides you with access to all physical memory which can be a security risk.

can you add the following change? the /dev/uio device just maps a custom memory region in a new file e.g. you can map from 0x40000000 to 0x4000ffff into /dev/uio0 and use that instead of /dev/mem

all you need is to update your script and add those to your devicetree:

CONFIG_UIO=y
# CONFIG_UIO_CIF is not set
CONFIG_UIO_PDRV_GENIRQ=y
# CONFIG_UIO_DMEM_GENIRQ is not set

reference: http://forums.xilinx.com/t5/Embedded-Linux/help-with-simple-Zynq-PL-device-access-via-Linux-UIO-based-user/td-p/270836/page/2

on the linux side you can simple adapt the following code: http://svenand.blogdrive.com/Zynq/Lab2/LED_DimmerUIO.c

[pavel-demin]

What you are proposing is not correct. Please check your information before posting it here.

The lines CONFIG_UIO=y etc have nothing to do with the device tree. These lines belong to the Linux kernel configuration file.

UIO has been enabled by default since quite some time in the Linux kernel provided by Xilinx. Here is the default configuration for 2015.1: https://github.com/Xilinx/linux-xlnx/blob/xilinx-v2015.1/arch/arm/configs/xilinx_zynq_defconfig

I already played with UIO and even patched a small bug in drivers/uio/uio_pdrv_genirq.c. You can find this patch in https://github.com/pavel-demin/red-pitaya-notes/blob/master/patches/linux-xlnx-xilinx-v2014.3.patch

Xilinx removed compatible = "generic-uio" from the UIO driver in 2015.1: https://github.com/Xilinx/linux-xlnx/commit/7ebd62dbc727ef343b07c01c852a15fc4d9cc9e5#diff-7a207b020a76c6547eaf2f654c20fb92

According to the comment to this commit, the following should be added to the kernel arguments:

uio_pdrv_genirq.of_id=generic-uio

So, if you need UIO in one of your projects, here is what should be done:

• add uio_pdrv_genirq.of_id=generic-uio to the boot_args variable on line 8 in scripts/devicetree.tcl
• modify your device tree file to add compatible = "generic-uio" to the device that you want to access via UIO
• rebuild devicetree.dtb
• copy new devicetree.dtb to /boot on your SD card
• reboot Red Pitaya

[Arnold1]

ok. thanks for the info.

i will patch my tmp/red_pitaya.tree/zynq-7000.dtsi file with the following code?

uio0: uio@40000000 {
    compatible = "generic-uio";
    reg = <0x40000000 0x7FFFFF>; /* 7.99 MB */
    #interrupts = < 0 29 0 >; /* IRQ 61 */
    #interrupt-parent = <&gic>;
};

and can mmap /dev/uio0 ?

[pavel-demin]

As I'm not sure what is the meaning of #interrupts, I'd remove the interrupts related lines.

I'm not sure about the exact syntax but looking at other entries in zynq-7000.dtsi, I'd write something like:

                uio0: uio@40000000 {
                        compatible = "generic-uio";
                        reg = <0x40000000 0x10000>;
                };

[Arnold1]

# was to be meant as a comment... i should use // wait... why 0x10000?

could you add a devicetree_uio.patch after i tested it?

whats the difference between system.dts and zynq-7000.dtsi?

[pavel-demin]

The problem with this patch is that it is very application specific. Your application requires 64k at 0x40000000. Some of my applications require 4k at 0x40000000 and 32k at 0x40010000.

As I try to keep all the patches as generic as possible, I don't think that I'd add this patch.

I'd suggest you to fork this repository and add whatever patches you need. If you develop a more generic patch that can be used for different projects, I'd be happy to accept your pull-request.

[Arnold1]

i think about a patch that will be updated at runtime depending on what the user specifies in the makefile?

whats the difference between system.dts and zynq-7000.dtsi?

[pavel-demin]

As far as I know, the device tree is read during the boot up sequence. If you want to change it, then you need to reboot.

It's not impossible that there are other ways to enable/disable UIO devices at run time without describing them in the device tree. The name of the following repository suggest such possibility: https://github.com/mandeepsandhu/uio-hotplug-test

[Arnold1]

what i meant is to update my patch_file with a size parameter (set in the Makefile) and compile the device tree...

whats the difference between system.dts and zynq-7000.dtsi? i create the patch for system.dts?

[pavel-demin]

whats the difference between system.dts and zynq-7000.dtsi? i create the patch for system.dts?

I don't know. As you prefer.

[Arnold1]

your makefile doesnt use zynq-7000.dtsi to create devicetree.dtb?

[pavel-demin]

One of the first two commands in system.dts is /include/ "zynq-7000.dtsi".

[pavel-demin]

I'm closing this issue as I think I answered all the questions related to Vivado 2015.1, projects/red_pitaya and projects/red_pitaya_0_92.

[pavel-demin]

Last time when I tried UIO, it was with Vivado 2014.3 and with a very simple project that contains a register connected to the AXI bus and to the LEDs:

https://github.com/pavel-demin/red-pitaya-notes/blob/master/projects/cfg_test

The device tree files generated automatically for this project already contained all the necessary entries.

I had just to replace compatible = "xlnx,axi-cfg-register-1.0"; with compatible = "generic-uio"; in cfg_test/pl.dtsi.

(OK, I also had to patch a small bug in the driver UIO source code that I mentioned earlier)

At that time, I did not know about the uio_pdrv_genirq.of_id kernel boot argument.

Knowing about uio_pdrv_genirq.of_id, I think that I don't need to patch the device tree files anymore.

I'll try to add uio_pdrv_genirq.of_id=axi-cfg-register-1.0 or uio_pdrv_genirq.of_id=xlnx,axi-cfg-register-1.0 to the boot_args variable on line 8 in scripts/devicetree.tcl and I'll post the results.

The command to generate the device tree files for this simple project is

make NAME=cfg_test tmp/cfg_test.tree/system.dts

The device tree entry for the register connected to the AXI bus is in tmp/cfg_test.tree/pl.dtsi.

[pavel-demin]

Here are the results of my test.

Adding uio_pdrv_genirq.of_id=axi-cfg-register-1.0 to kernel boot arguments did not work.

Adding uio_pdrv_genirq.of_id=xlnx,axi-cfg-register-1.0 worked.

My patch for the UIO driver is not needed anymore. I removed it from linux-xlnx-xilinx-v2015.1.patch.

All the files that I used for this test can be found at the following location: https://0c2d3ba9cf2a7be9395f36aa24dd59103ca884e9.googledrive.com/host/0B-t5klOOymMNfmJ0bFQzTVNXQ3RtWm5SQ2NGTE1hRUlTd3V2emdSNzN6d0pYamNILW83Wmc/cfg_test/

The files boot.bin, devicetree.dtb and uImage should be copied to the /boot directory on the Ubuntu SD card.

[pavel-demin]

I'm locking this issue as I answered all the questions related to Vivado 2015.1, projects/red_pitaya and projects/red_pitaya_0_92 and I'm not interested in further discussion of the UIO driver.

If you have other questions about my notes on the Red Pitaya Open Source Instrument, please open a new issue.

For general questions about the Red Pitaya Open Source Instrument, please use the Red Pitaya forum.

[pavel-demin]

The timing problems in the red_pitaya_0_92 project are fixed in the commit https://github.com/pavel-demin/red-pitaya-notes/commit/0d92b543de4dbd77c6a5dafe9e91bad6d73a7557