Incremental HLS Compilation Demo: Snake Game

Preface

In this demo we used the KiwiC compiler to generate a number or hardware designs that were automatically distributed over a multi-FPGA platform with all inter-wiring synthesised by HPR System Integrator.

This is the system demonstrated at 'Demo Night' in FPL 2017 in Ghent.

Available Hardware Platform

The tool is primarily aimed at FPGA meshes available in data centres, but we used something cheap and portable for our demo!

The hardware platform consists of two Zynq 7020 devices. The demo does not use the ARM processors (beyond booting). Everything was instead implemented in Verilog RTL and put into the programmable logic. Most of the logic was generated by KiwiC compiler with the remainder being small, hand-coded items. Every module was described in IP-XACT and the system was assembled using HPR System Integrator and a Makefile. The Makefile invokes the various tools, including Vivdao design suite, to generate a bit file for each FPGA. [An extension to Kiwi to make RTL a proper subset of its input language is being discussed here ... link missing...]

breadboard photo

The FPGAs were interconnected with a bidirectional serial channel. The channel uses differential signalling following the TMDS standard used for HDMI. This is used since it is the only differential signalling standard that is compatible with the available 3V3 bank on the ARTY-Z7 cards. TMDS or GTX would perhaps have been preferred standards if possible with the PCB bond out of the Zynq chip on another board.

Block Diagram

System Block Diagram

There are two demonstrations possible with this set of parts: either the inter-FPGA link is a visible resource that is explicitly accessed in the C# code running in various places. Or else the C# code is written to directly call from one dll to another, but the HPR System Integrator automatically adapts the inter-dll protocol to use the inter-FPGA link as a necessity. The demo of the second was not working until after the 2017 demo, but the principle was clear enough.

Source Code

There are a number of separately-compiled components. Some were hand-coded in RTL and others generated by runs of the HLS compiler. So that each can be automatically instantiated by the HPR System Integrator, tool, each is described in extended IP-XACT.

The demo is an interactive video game: the classic snake game where running into obstacles or over your own tail is the end-of-game event or incurs a score penalty. Although this is small example, it has to be mapped onto two blades in our demo since the framestore was connected to one and the joy stick to another.

The System Integrator tool will allocate components to each of the two FPGA blades by and write a top-level RTL file for each FPGA that also contains all of the necessary inter-blade link glue and protocol adaptors. It combines modules made available for this particular project with a library of pre-existing generic modules and blade-specific modules.

Project Modules for this Demo (Verilog and IP-XACT)

Project modules were made available from pre compiling the folowing C# programs:

The RTL and IP-XACT for these was created from the C# source using the following Makefile Makefile.

Hardened (non-portable) Modules

The design uses a number of hardened resources available on the FPGA blades. These are designated as non-portable and cannot be moved around by the System Integrator tool. Instead they are hard-coded in a blade-manifest.xml file for each file.

The IP-XACT files for each resource were generated by compiling a representative C# stub file, but any RTL output from those runs was discarded and replaced with hand-coded RTL that meets the constraints of the back-end FPGA flow for inferring hard IP blocks.

The hardened modules made available were:

Compilation of the C# stub files generates a .dll file that is handy for compilation and development for the code that uses it. Functional models of the final components can be freely coded in the C# stub because it will be discarded for hardware execution. Like the Kiwi-generated RTL, each of these blocks has its own IP-XACT component definition. And bus and abstraction definitions exist for all of the interconnection standards. These are written out by KiwiC when the stubs are compiled and can be referred to by all subsequent compilation steps.

The resulting XML descriptions for the components involved are HERE. (You may need to use 'view source' or 'save target as' to see them properly outside of your web browser.) These XML files contains various of the extensions that we are promoted for discussion and adoption.

Hand-Crafted Source Code For Leaf Component Shims

To be uploaded done ... I can show you one the laptop in Ghent.

Virtualisation Environment

The programs (KMeans and SnakeGame) can be run as mono applications natively. This is helpful for debugging. The Windows Forms environment works on linux and provides the graphical output (as in this earlier demo).

It should also be fairly easy to connect the SystemC output to an X-windows pixel buffer ... I have done that before and have the code somewhere.

Utilisation Metrics and Performance Evaluation

To be done ...

Footage From Demo Night

MP4 Video.

Conclusion

The point of this demo is not that this was a challenging application. Instead we aim to promote discussion regarding 'link editing' of HLS-generated components. Is IP-XACT a suitable basis to contain the meta information needed. Please ask for a private pre-print of a paper describing our IP-XACT extensions in use.

To be done ...


UP