... 60% of the time
The precious Parallella board (Kickstarter edition) arrived this week and I've been playing with it non-stop. This board contains the bigger Zynq FPGA device (7020) and thus it is capable of holding large designs like the full RISC-V IMAFD core generated with rocket-chip. Before testing my project though I had to make sure that the board works fine with just the latest Parallella E-SDK (2016.3.1) image loaded in the SD card. In this release page of the E-SDK you can find image archives for both Zynq FPGA devices: the 7010 (Desktop / Microserver editions) and the 7020 (Embedded / Kickstarter editions). These images actually contain a headless Linaro (Ubuntu) 15.04 distribution (root filesystem plus Linux kernel) along with the necessary boot files (FPGA bitstream, device tree file).
Since the board that I have has the 7020 Zynq FPGA device I downloaded the correct archive, unzipped it and wrote it to the SD card. The procedure is really easy and it's described in detail in a short SD card tutorial of the quick start guide of Parallella.
The board booted without problems and everything seemed to work fine with the latest E-SDK. I even run a couple of Epiphany example parallel programs that test the capabilities of the 16-core Epiphany chip onboard Parallella. These can be found in the home directory of the default Parallella user that is already setup for you.
After running for a while though the board seems to lose the connection to the Epiphany chip and the thermal daemon crashes. This behavior is completely random and I haven't been able to figure why this happens. It can happen on the first 5 minutes after boot or only after half or 1 hour uptime. It might be a temperature issue with these early boards but when I check the temps on both the Zynq and Epiphany chips they seem to operate in a normal range of 50 - 70 C. Until I have another board in my hands I won't make any effort on solving this and concentrate on testing my Parallella RISC-V project on the board.
I prepared the Parallella - RISC-V bitstream along with all of the supporting files and to my suprise nothing worked on the first try. Not even on the second or the third! This never happens (attempt for humor!) and thus I was set to find out why. No matter what I did I couldn't communicate with the RISC-V core's AXI bus that is connected to the HTIF interface. Using the designated RISC-V HTIF communication tool (front end server a.k.a fesvr), or just reading and writing to the bus from the ARM host using a simple memtest program, resulted in the immediate and complete hanging of the board. This was surely a sign that the RISC-V core programmed on the FPGA device was completely dead and any AXI requests couldn't return an answer and thus hanged all the inteconnect fabric. AXI buses don't have a 'timeout' feature and as their spec states they don't take a no for an answer from angry or dead peripherals.
After 3 endless days of debugging atlast I figured out the reason and it was ofcourse a very stupid ommission from my part in the system block design (Vivado). I didn't connect the reset signal to the MMCM clock manager that I use to drive RISC-V core's clock. Thus the MMCM didn't work and the core didn't get any clock at all and couldn't function. To my defense I thought that not connecting the reset signal is exactly like driving it with 0, something which is acceptable and sometimes recommended for Xilinx clock managers. Apparently this isn't what happens when you don't (or forget to) connect the reset signal there. What a waste of time...
With the above troubles in the past I was able to run a simple hello world program which verified correct HTIF communication with the RISC-V core from / to the ARM host (Zynq). Hurray!
parallella@parallella:~/$ sudo ./fesvr pk hello Hello World!
The next step is booting RISC-V Linux. This will be my focus for the current week. Stay tuned for the next update!