FPGA meets DevOps - Introduction
Why DevOps for FPGA development?
During the development and support phase of a product containing an FPGA bitstreams are released containing new features, bug fixes etc.
Releases are more frequent during the development phase as new features are added to the design. The support phase can last from a couple of years for a consumer product to five or more years for an industrial product.
During the years, I have experienced first(or second)-hand issues like:
The released bitstream was built using a different source code tree from the one tagged for release
If the bitstream is built on the developer's PC, then local changes might not have been saved in the source version control system and the source tree tagged for the release is different from the one used to build it.
It works/builds on my PC
Releases should be built in an environment where OS, libraries and tools are under control and it is easy to recreate the build environment. Developers' PC might break or new OS/libraries/tools are installed and the build tools might not work anymore. This is particular important when the support period is long (5+ years).
The only engineer that can do a release is on holiday/business trip/left the company
When the release process is not automated, it is prone to error (even if well documented) and it makes more difficult to scale-up the development team.
It is not possible to replicate the environment or get the source code that was used to build a particular version that has a bug
If a bug has been flagged, it should be possible to easily recreate an environment where the bug can triggered and debugged. Sometimes the suggestion "use the latest version" might seem to fix the problem, but it could just hide the issue.
The objective of this series of blog posts is to share tips and tricks on how to use DevOps tools and techniques like source version control, continuous integration/testing, release automation applied to FPGA development. The same tools and techniques can be applied to microcontroller firmware development or in general where an artifact (binary) is created from a source code tree using a tool like a compiler.
The goals of DevOps include not only solving the issues mentioned about, but also:
- Improved deployment frequency
- Faster time to market
- Lower failure rate of new releases
- Shortened lead time between fixes
Read the articles published so far:
Follow Starware Design on Twitter @starwaredesign to get notified of new blog posts.