The ICALEPCS 2019 pre-conference workshop on FPGA design was held on the Saturday before the ICALEPCS 2019 conference, October 5, in New York City. The venue was the Marriott by the Brooklyn Bridge, and the workshop was held in the Greenpoint room (see pdf floor plan).
As a result of the workshop, a wiki was set up to facilitate future collaboration, as well as a forum for discussion.
Many Printed Circuit Boards (PCBs) used in controls and data acquisition make use of Field Programmable Gate Arrays (FPGAs) for flexible implementation of their digital part. With time, these chips have become very dense, capable of implementing very complex logic. This has driven the need to enhance development flows to efficiently handle the complexity of the ensuing designs. Measures include use of high-level languages, standard buses and automatic code generation for registers, memory and core interconnect. However, these efforts have not benefited from much sharing across labs so far. This workshop did not intend to teach HDL/FPGA design to attendees. That would be an unreasonable goal for a one-day event. Instead, it catered to practitioners in different institutions and aimed at bringing together the varying solutions used to help in development, with the hope to establish a good basis for future collaboration in this domain.
To make this more concrete, here are some examples of the type of tools we had in mind: FuseSoC, HDLMake, Cheby, Kactus2, Migen and LiteX.
For any questions or remarks about the workshop, please send us an email.
Timetable
Time Slot | Subject |
---|---|
08:30 - 08:50 | Welcome |
08:50 - 09:00 | Workshop introduction |
09:00 - 09:20 |
PandABlocks - a Flexible Framework for Zynq7000-Based SoC Configuration Glenn Christian (Diamond) |
09:20 - 09:40 |
Minimalist FPGA Control Andrei Sukhanov (BNL) |
09:40 - 10:00 |
Sirius Gateware/Software Tools and FPGA Development Workflow Lucas Russo (LNLS, Sirius) |
10:00 - 10:30 | Coffee break |
10:30 - 11:15 |
FPGA Project Development Walkthrough Dimitris Lampridis (CERN, BE-CO-HT) link to sources |
11:15 - 11:45 |
Vivado HLS C->HDL compiler Scott Cogan (FRIB) |
11:45 - 12:00 |
Leveraging CI and Hardware-In-Loop tests during firmware development Vamsi Vytla (LBL) |
12:00 - 13:30 | Lunch break |
13:30 - 14:15 |
Discussion Session #1 Tools |
14:15 - 15:00 |
Discussion Session #2 Workflows |
15:00 - 15:30 |
Discussion Session #3 Open Development |
15:30 - 16:00 | Coffee break |
16:00 - 16:45 |
Discussion Session #4 Sharing / Re-use / Deployment |
16:45 - 17:00 | Wrap-up |
Topics Discussed
This workshop was intended to be a place for discussing new ideas and possible areas of common development. As such, the following non-exhaustive list tries to summarize some topics that we considered interesting for further discussion and group them into four broad categories.
-
Tools
- Vendor-independent project management tools: How to synthesize your project with different tools and for different FPGAs? Do you need/want this?
- Code generators: Helping to avoid boilerplate code for register-maps, interconnects
- High-level languages: Migen/Litex, Chisel, others. Could they help automate things and provide a more widespread adoption of FPGAs?
- Gateware Frameworks: lots of "local" initiatives to avoid dealing with FPGA specificities. Are FPGA framework development just too young to be comparable to, say, Web Frameworks?
-
Workflows
- Gateware DevOps: is Continuous Integration/Delivery/Deployment feasible for FPGAs? Would we gain a lot from it?
- Dynamic gateware interface and auto-discoverability: How to keep the gateware and software synchronized with minimal effort? Can we (or do we want to) modify the gateware like we change software?
- Gateware Duality: Is gateware more like hardware or more like software? FPGA developers use to say "Write software, but think in gates". Do we really need to think this way?
- Best way to include a (semantic) version number, synthesis time and git hash into gateware registers.
-
Open Development
- FPGA/SoC open standards (or the lack of them): The internet thrived arguably because of standards (IETF). Do we need more or just a widespread adoption of the existing ones?
- Open-Source FPGA synthesis/implementation/bitgen: is "GCC for FPGAs (SymbiFlow)" the final answer?
- GPL for HDL: what is a "good" license to use in a IP core?
-
Sharing / Re-use / Deployment
- Common repository of gateware IP cores: lots of implementation for the same basic building blocks
- IP core packaging: Do we need/want something such as a debian/rpm-like package?
- IP core buses: Wishbone, AXI, Avalon, Bus-Agnostic interface. Which one to choose? Can we make them interoperable with minimal penalty?
Abstracts
PandABlocks - a Flexible Framework for Zynq7000-Based SoC Configuration (20 min)
Glenn Christian (Diamond)
The PandABlocks framework comprises the FPGA logic, TCP server, webserver, boot sources and root filesystem, developed for the PandABox platform by Diamond Light Source and Synchrotron Soleil, for advanced beamline scanning applications. The PandABox platform uses a PicoZed System-on-Module, comprising a Zynq-7030 SoC, coupled to a carrier board containing removable position encoder modules, as well as various input and outputs. An FMC connector provides access to ADC/DACs or additional I/O, and gigabit transceivers on the Zynq allow communication with other systems via SFP modules. Specific functions and hardware resources are represented by functional blocks, which are run-time configurable and re-wireable courtesy of multiplexed data and control buses shared between all blocks. Recent changes to the PandABlocks framework are discussed which allow the autogeneration of the FPGA code and tcl automation scripts, using Python and the jinja2 templating engine, for any combination of functional blocks and SFP/FMC modules. The framework can target hardware platforms other than PandABox and could be deployed for other Zynq-based applications requiring on-the-fly reconfigurable logic.
Minimalist FPGA Control (15-20 min)
Andrei Sukhanov (BNL)
The feature-rich control of a FPGA-based device is achieved using the JTAG connector, which normally used for FPGA programming and it requires only 4 signals (TCK,TMS,TDI,TDO). A small-form-factor Raspberry Pi Zero is used to generate JTAG signals for: 1) FPGA programming, 2) slow control, 3) control of the SPI devices, 4) in-system logic analyzer. The flash-based FPGAs (IGLOO2 and PolarFire from Microsemi) are better suited for minimalist design as they require less board area (no need for EPROM) and less power than the SRAM-based FPGAs. They are better tolerant to radiation damage, and can be placed closer to equipment. Access to FPGA fabric is provided by UJTAG design element (similar to Xilinx' BSCANE2), up to 240 UJTAG elements are available for user. This approach was used to control 400K-channel silicon-tungsten calorimeter at RHIC and to develop 8-channel, 5 GSPS ADC for sub-20 ps TOF measurements.
FPGA Project Development Walkthrough (30-45 min)
Dimitris Lampridis (CERN, BE-CO-HT)
We present the FPGA development workflow followed by BE-CO-HT at CERN, by taking a complete project and walking through the various steps from project creation to synthesis (and beyond, into providing low-level software support). The following topics will be covered:
- HDLmake, including examples of hooks for synthesis customisation, firmware compilation and other custom actions.
- Handling of dependencies via Git submodules.
- Common HDL code and software support for our FPGA carriers (aka "The Convention").
- Handling of constraints.
- Cheby: a design tool to generate register maps and interconnect.
- EDGE: a linux driver generator.
- How more complex drivers are handled.
Sirius Gateware/Software Tools and FPGA Development Workflow (15-20 min)
Lucas Russo (LNLS, Sirius)
In Sirius, the diagnostics group is responsible for specifying, developing, testing and maintaining FPGA-based systems, such as: Beam Position Monitor, Timing Generators/Receivers and Fast Orbit Feedback. In order to ease development among team members and other institutes a set of frameworks and tools are used to automate tasks and code generation as much as possible. Some of the gateware tools being used by the team are: HDLmake and FuseSoC for FPGA project management and IP core packaging, Wbgen2 and Cheby for register-map and interconnect generation. As for the software side, an in-house developed userspace framework helps abstracting the gateware cores by means of high-level entities that automatically exports the cores’ functionality to be used by remote clients. In this presentation, the tools being used by the group, the workflow and some ideas for the evolution of FPGA development will be discussed.
Vivado HLS C->HDL compiler (30 min)
Scott Cogan (FRIB)
I share my impressions of Vivado HLS, a C to HDL compiler, in the context of FRIB diagnostic development. A short introduction to how HLS works, support for resource pipelining, integration of IP cores, etc. I would speak a bit to: How optimal is resource usage? Timing performance? Maintainability and portability of code? Is HDL human readable? Where might HLS give the greatest benefit? (IMHO, complicated state machines or signal processing.)
Leveraging CI and Hardware-In-Loop tests during firmware development: What have we learned so far? (15 min)
Vamsi Vytla (LBL)
We believe that adopting version control, dependency management, continuous integration, and hardware-in-loop tests has benefited us greatly in terms of maintaining an ever evolving codebase. Working with several teams both inside and outside our institution, we have accrued a large amount of common code base over time. In order to easily maintain the code base we have adopted dependency management (through Docker), continuous integration and tests (with Gitlab and racks of hardware). The talk will be about some details in how we got there, and what are some of the challenges, and what we plan to do from here on. In addition to the above, maintaining a large verilog codebase, has forced us to look into several automation and code generation tools, like FuseSoC, MiGen, Litex. I would like to briefly touch upon what we learnt from trying them and where we stand currently.