Connectal Project

Bundling Bitstreams into Applications

2015-09-08T00:00:00+00:00

One of the problems we wrestled with for a while was version skew between application executables and their corresponding FPGA bitstreams.

We thought about embedding an application ID and version register into the programmable logic and then checking it when the application software connects to the hardware. This approach runs into the same problem as the version numbers on Linux shared objects. It leads to manual management of the version number, distinguishing compatible from incompatible changes.

Another problem is keeping track of which bitstreams are associated with an application.

Eventually, we decided just to embed the bitstream into the application executable, and then extended this approach to work with shared libraries, although it will currently only work with one shared library per application.

When the application or library first uses the hardware, it automatically invokes fpgajtag to program the hardware, pointing fpgajtag at the executable or shared library itself. The fpgajtag utility extracts the bitstream from the “fpgadata” section, which was added at build time, and programs the hardware with it. Once this has completed, the application software may safely use the hardware.

Simplifying Zynq Boot

2015-02-11T00:00:00+00:00

Creating a Zynq boot.bin has been a source of headaches for quite some time. It requires a toolchain different from the one in NDK build and also seems to have some dependences on variations of other common Unix tools.

The only reason anyone has to build a boot.bin themselves is because it contains the MAC address for the ethernet. On the zedboard, at least, there is not a better place to store it. Zybo does have an eeprom for this purpose, but we do not have that working yet.

I’m working on a web-hosted development environment, and as part of that took a step towards packaging zynq-boot in an easier to use way.

I packaged the stable, board-independent pieces into sdcard-zynq.zip and the faster changing or board-dependent components into bootbin-$(BOARD)-$(MACADDR).zip. If you only have one board of a particular type, you can use a prebuilt bootbin.zip. Otherwise, you’ll still need to be able to build boot.bin or to use the web-hosted boot.bin creation service when it’s available.

The current prebuilt images for zedboard, zc702, and zc706 are here:

https://github.com/cambridgehackers/zynq-boot-filesystems/tree/v15.02.1

From that link, download:

https://github.com/cambridgehackers/zynq-boot-filesystems/blob/v15.02.1/sdcard-zynq.zip

also download a bootbin*.zip for your board:

zedboard: https://github.com/cambridgehackers/zynq-boot-filesystems/blob/v15.02.1/bootbin-zedboard-00e00c009603.zip
zc702: https://github.com/cambridgehackers/zynq-boot-filesystems/blob/v15.02.1/bootbin-zc702-00e00c005603.zip
zc706: https://github.com/cambridgehackers/zynq-boot-filesystems/blob/v15.02.1/bootbin-zc706-00e00c004f03.zip

My SD card is labeled “ZYNQ” and under Ubuntu mounts as /media/jamey/ZYNQ. On OS X it mounts as /Volumes/ZYNQ. Update the following with the path to your SD card:

unzip sdcard-zynq.zip cp sdcard-zynq/* /media/jamey/ZYNQ unzip bootbin.zip cp bootbin03/* /media/jamey/ZYNQ

Now eject your SD card, plug it into the Zynq board, and turn it on.

Why Connectal?

2015-01-04T00:00:00+00:00

Are you happy with the connection between software development and hardware development on your projects? Do you wish you had more flexible tools for developing test benches, drivers, and applications using your hardware? Do you wish you didn’t need a kernel driver?

Do you wish that you could use a common flow to drive your hardware development, across simulation, timing verification, FPGA implementation, and even the ASIC back end?

Do you wish you could use a better programming language to implement the hardware? Do you miss declared interfaces and structural types?

Do you wish you had better tools for debugging the hardware? For reflecting conditions encountered on the hardware back into the simulation environment where you can drill down into the problem?

These are the kinds of problems we encountered which inspired us to develop the Connectal framework. With Connectal, we are trying to bring the productivity of software engineering practices to hardware development without compromising on the performance of the hardware.

Connectal provides:

Seamless development environment with test benches and apps written in C/C++
Streamlined application structure
Faster builds and greater visibility simulating hardware in bluesim/modelsim/xsim
Support for capture traces on interfaces and replaying them in test benches

Zedboard on Wheels

2015-01-02T00:00:00+00:00

We have published another Instructable describing how to build a simple two-wheeled motorized robot controlled by a Zedboard. The Connectal framework is used to implement control logic with both SW and HW (FPGA) components.

Connectal Documentation

2014-12-30T00:00:00+00:00

We have been focusing on documentation and tutorials for the last month or so. I have been working on using Sphinx to document the Connectal BSV libraries. In the process, I have implemented a BSV domain for Sphinx.

The Connectal Reference is still just a skeleton, because even in skeleton form it at least gives an index of key Connectal interfaces and modules.

Connectal Zynq Getting Started

2014-12-13T00:00:00+00:00

This Instructable describes how to set up a Zedboard for use with Connectal.

Connectal PCIe Getting Started

2014-12-12T00:00:00+00:00

This Instructable describes how to set up a Xilinx vc707 or kc705 board for use with Connectal.

Connectal at FPGA 2015

2014-12-03T00:00:00+00:00

We will be presenting a paper describing the Connectal framework at FPGA 2015 in February.

Building a Bluespec LED controller using Connectal Build

2014-10-29T00:00:00+00:00

We published an Instructable describing how to build a simple LED controller using Connectal Build.

One of the problems with CAD tools is that they are hard to install and often expensive. Fortunately, we are able to provide a public build service for open source projects written in Bluespec Systems Verilog using the Connectal framework.

This tutorial explains how to use the public Connectal Build service to build and simulate an application with hardware and software components written in BSV and C++ using the Connectal Framework.

We assume that you will store your design sources in a publicly available Git repository such as Github. The build service, which is based on buildbot, automatically builds your project when it detects changes. If you are simulating your design, the build service runs the applications and displays the logs automatically.

This tutorial builds the example and runs it in the bluesim simulator.

How to Blink the LEDs on a Zedboard using Connectal

2014-10-17T00:00:00+00:00

We published an Instructable describing how to blink the LEDS on a Zedboard using Connectal

We even include an FPGA action video:

How to boot Linux on a Zedboard without U-Boot

2014-10-16T00:00:00+00:00

We published an Instructable describing how to boot Android Linux on a Zedboard without using U-Boot.

Normally, the Zynq CPUs boot by running the first stage boot loader (FSBL) in ROM, to load the FSBL from the boot.bin file, which then loads U-Boot from the SD Card, which then loads the Linux kernel, ramdisk, and device-tree from the SD Card.

The FSBL and U-Boot images are both board-dependent, and U-Boot does not actually provide any capabilities missing from the FSBL and Linux, so we thought it would be simpler if we didn’t have to update U-Boot when porting Connectal to a ne Zynq board.

This Instructable describes how to set up a Zedboard to boot Linux directly from the boot.bin file.