Front End Computers (FECs) are at the heart of the accelerator control system. They are typically embedded in a crate and connected over a backplane with dedicated add-in modules to accelerator equipment. The standard way to access these modules from the FEC is through a so-called Linux device driver. Drivers are typically resident in memory and are considered part of the Linux kernel. Tasks from user space can use drivers to access hardware modules using system calls.

Traditionally, kernel development, including drivers, has been considered complex and risky. Indeed, all safety nets one enjoys when developing in user space are implemented in the kernel itself. When one programs the kernel, there is no safety net. You can easily compromise the whole system. On the other hand, many drivers are relatively straight-forward in their functional needs (mostly reading and writing registers and allowing a task to wait for interrupts). For this kind of drivers, automating kernel code generation presents many advantages. Enter EDGE.

The “Encore Driver GEnerator” (EDGE) takes a text description of a memory map as an input and automatically generates a Linux device driver, a user-space library and a test program. By automating code generation, we can make sure the resulting driver is high-quality, avoiding the most common pitfalls in kernel development. Updates of the driver following a change in memory map are also trivial.

The FEC team in BE-CEM-EDL just released version 3.0 of EDGE. This new release comes with a number of improvements. One of them, hardware simulation, is especially interesting for teams designing their own hardware modules. A new plug-in system provides placeholders for user code which simulates the behaviour of the hardware itself. This allows software developers to start coding even before the first hardware prototypes are available. The Comma-Separated Value (CSV) text file representing the memory map is the “contract” between the hardware and software teams.

Another advantage of hardware simulation is that Continuous Integration (CI) can easily include (simulated) hardware access now, so tests are more complete but developers can avoid the costly and complex setup of a dedicated hardware testing facility.

The new release comes with extensive documentation including examples. Give it a try and feel free to write to be-dep-cem-edl-support@cern.ch if you need any help!