Parallella Community

I have started a simple project that includes just bare bones needed to keep Epiphany chip in reset state:

https://github.com/Kirill888/parallella-fpga-dummy-io

I have tried it on my 7010 based board, nothing is broken after using it, so I assume it's ok. I used Vivado 2015.3 for this work, but it should work with older versions also, you won't be able to use scripts, but you can use dummy_parallella_io module in your design and connect things manually, link above contains sample design as a picture.

Next, I will add sample project that actually does something, and some c++ code that verifies operation of the fpga block. I already tried it, just needs a bit of a clean up and documentation.

One thing to note, when using bitstream without eLink interface you will need to disable eLink access on Linux, otherwise kernel crashes can occur, since memory address ranges for eLink are not pointing to anything meaningful anymore. I had to disable parallella-thermald service to successfully boot with the "empty" bitstream.

Code: Select all

     echo manual | sudo tee /etc/init/parallella-thermald.override


I have now updated the repository with a simple design that includes custom IP. AXI based multiplier circuit.

Repository linked below includes design, sample app and instructions on how to run it:

https://github.com/Kirill888/parallella ... ter/sample

Design looks something like this:

Interesting, I've something else planned but maybe tomorrow I'll give it a try.

I started reading over the Readme file, did you do a rudimentary benchmark on your example ? Also I was wondering what the "dummy" IO block does it connect the GPIO or is it "empty" ?

Theo V.

Thanks for feedback Theo. The "dummy io" part refers to RX/TX/CCLK_P/CCLK_N and DSP_RESET_N signals, GPIO and I2C are connected in exactly the same way as in the Adapteva's design, I use the same modules internally. It's really more like "dummy eLink". Naming things is hard.

Regarding benchmark -- I haven't measured timing. I know it will be slower than a CPU implementation of the multiply, by ALOT. This is not a "this is how you accelerate an algorithm using FPGA" tutorial. I chose multiply because that's what tutorial on fpgdadeveloper.com was using, and because I couldn't do a simple "flash a LED" demo on parallella.

Having said that, I am interested in "FPGA as a co-processor use-case", but for that we need to use DMA based design with interrupts for completion notification. This is the next thing I want to learn how to do.

I added the SDK to my Vivado 2015.3, downloaded your git project, followed the steps, got a bit file in a couple of minutes, loaded it in, changed the device tree, compiled the examples and everything worked!

So that makes me happy camper, now I'll try out some other examples and IO. I changed the program a little to loop a multiply for a million times, which gave results as I thought and the loop was going at a few million times per second, using a user account program (I changed the device permissions).

T.

Hi all,

I'm trying to go through kirill's instruction. Everything is ok except after generating new device tree generic-uio appears in device tree, but there is no any /dev/uio* device.
As I understand I should have some support in kernel or install a kind of uio driver for making it work.
Looking in kernel options I see:

linaro-nano:~> zcat /proc/config.gz | grep UIO
# CONFIG_UIO is not set

I'm using ubuntu Desktop With Disply image from parallella site:
ubuntu-14.04-hdmi-z7010-20140611.img.gz

So, what I'm doing wrong? Should I use some another image (headless?) or recompile kernel with some additional options?

You are definitely missing the driver. I tested this on headless version of the kernel, my setup is "desktop edition" (7010).

I'm using headless version of the ubuntu image, most likely this one:
ftp://ftp.parallella.org/ubuntu/dists/t ... 0.1.img.gz

Code: Select all

parallella@parallella:~$ md5sum /boot/uImage
3cf8c4cf4f96d1f012b391de90890203  /boot/uImage
parallella@parallella:~$ zcat /proc/config.gz | grep _UIO
CONFIG_UIO=y
CONFIG_UIO_PDRV_GENIRQ=y
CONFIG_UIO_DMEM_GENIRQ=y
CONFIG_UIO_XILINX_APM=y
parallella@parallella:~$ uname -a
Linux parallella 3.14.12-parallella-xilinx-g40a90c3 #1 SMP PREEMPT Fri Jan 23 22:01:51 CET 2015 armv7l armv7l armv7l GNU/Linux


Your options are
1. try headless version of the kernel
2. compile your own kernel
3. compile uio drivers as modules for your current kernel

Thanks for reply.

I've solved an issue installing headless image version and everything works fine!
Before that I tried to recompile kernel enabling UIO options, but I wasn't lucky - system just hangs after that.

Hi Kirill888,

Thanks a lot! This was exactly what I was looking for. Espacially that you use VHDL is great for me. Everything works fine using a desktop parallella with 7020.

I have one stupid question: How is the /dev/uio0 generated? Is this done by the modifications of the devicetree and then something magic happens?

Two things need to happen for /dev/uio0 to be created

1. Your kernel needs to have UIO drivers enabled: uio_pdrv_genirq
2. Your device tree needs to have correct entries for the soft peripheral you are creating (described in Patching Device Tree section)

In the case of the headless linux, all the needed drivers are compiled into the kernel, so they are loaded on startup and nothing extra needs to be done. It seems that hdmi linux builds do not have these compiled into the kernel. See discussion few comments up, if you followed the steps for device tree patching but still don't see /dev/uio0 you are probably missing the driver. To check if your kernel has the right driver run this command on parallella

Code: Select all

zcat /proc/config.gz | grep _UIO


If uio driver is compiled as loadable module you can try loading it with

Code: Select all

sudo modprobe uio_pdrv_genirq


Note that it's probably not a good idea to use hdmi enabled build for this kind of experimentation. Since you are removing hdmi block from the fpga you can not know how hdmi drivers will react to that. It's best to use headless version of the kernel to minimise possibility for errors.