DevOps has evolved over the last decade as a combination of practices that combine software development and IT operations. Because of its utility, flexibility and sophistication, DevOps has become an essential ingredient of success in supporting basic software engineering principles such as continuous integration/continuous deployment (CI/CD) and the exploratory iterations of Agile development.

Organizations that follow DevOps practices create a reusable development pipeline and overarching methodology for software development. These frameworks include highly automated workflows that facilitate rapid and repeatable coding efforts, experimentation, test automation, and production-level deployment. New software products can be conceptualized, created, and then stored systematically with archived and auditable data, code versions, documentation, toolchain configurations/dependencies, and scripts. These archives serve purposes such as re-creating original software development environments, tracking changes, ensuring version reproducibility, and facilitating further enhancement and evolution of software products.

However, the interplay between embedded software stacks and underlying hardware provides an unexpected and highly salutary effect stemming from DevOps with respect to the development of system hardware solutions. This article explores just that—the definition, development, and deployment of the board resource depot for large semiconductor companies. The board resource depot is a cluster arrangement of servers intended to be a shared remotely for the development groups scattered globally.

Semiconductor vendors offer a vast selection of product families, along with supporting integrated development environments (IDEs), embedded IPs and reference designs. A major component of the support portfolio consists of development boards, and there is a plethora of such boards for semiconductor vendor’s devices.

Despite a wide variety of such boards, every design shares a general software commonality. Among them are the device bootup code, JTAG boundary scan testing, application stack installation, OS implementation, and IDE/toolchain access. Here, CI/CD would save time and effort for the engineering teams, permitting those teams to focus on the application stack development for which the board was intended.

The first choice for building the DevOps pipeline is always an open-source product, specifically the Jenkins automation server. It’s a multi-OS, java-based server that automates the creation and deployment of DevOps flows for CI/CD software development. The server supports a wide variety of versioning and software automation tools through a library of plugins, making Jenkins highly flexible and extensible.

Figure 1 A broad view of how Jenkins facilitates automation testing. Source: Novature Tech

Jenkins also lends itself easily and effectively to server hardware cluster deployments to support larger organizations and parallelization of projects. The IBM Spectrum Load Sharing Facility (LSF) software can be used to configure a server cluster to support the board resource depot. LSF is a multi-OS compatible, scalable, and fault-tolerant job scheduler that distributes and load-balances high-performance computing (HPC) workloads across hardware platforms. An administrator can manage the hosting hardware hierarchically, set policies, and leave the LSF to control hardware resources, queue jobs, and execute them in accordance with those policies while the administrator monitors activity.

Based on java servlet containers, Jenkins uses a web interface for setup and configuration and creates a CI/CD pipeline from user-chosen plug-ins. The pipeline provides multiple builds, test, and deployment stages that are codified in a Jenkins-specific coding language and syntax and automatically stored in a text file as part of the project archive. The pipeline architecture offers a high degree of flexibility to developers, including the ability to fork an existing project, workflow loops for A/B testing or Agile development, and task parallelization to accelerate code module development.

Board resource depot’s key features

The board resource depot enables globally scattered development teams and users to create a new application from a range of boards available across the depot. There is a cascade of benefits offered by the board depot. Some of the major benefits include:

Increased board re-use

The ability to reserve boards in advance

Real-time notification of board release to production, along with a timestamp

Automated email notifications for the completion of tasks or milestones in new board development via Jenkins server

A regular schedule of ‘health checks’ for boards to alert users of boards that were experiencing functional problems

Automation of new board additions to the farm resource reserve through a set of dedicated scripts

The board’s support software can be tested by creating a library of Python-coded test modules. This test module library is developed using Pytest, a unit testing framework available with its library of over 300 plug-ins that help developers quickly develop testing regimens for their Python code. Tests can be simple or complex, and the test setup is flexible, modular, and scalable. Tests can be re-used, repeated with results logged, and multiple test fixtures can be set up at the same time.

The final piece of the puzzle is finding a way to implement a robust, repeatable, and automated board testing schema. Robot Framework—an open-source framework available under Apache license—is widely used for such scenarios of test automation and robotic process automation. Implemented in Python, it supports multiple object-oriented and procedural languages. The framework is keyword-driven and can be extended using available libraries.

Figure 2 Robot Framework reads and processes data, executes test cases, and generates reports and logs. Source: Devopedia

Using Robot Framework, a full JTAG boundary scan-based test suite can be created in Python for scanning the power management (PM) bus, FPGA I/O, and board-level peripherals like UART, I2C, clocks, and so forth. This board test suite is integrated into the Jenkins pipeline to facilitate re-use, traceability, and versioning. MySQL scripts are used to produce statistics involving reports and graphs on archive activity and the operations of the server cluster. The board resource depot also helps to plot the real-time usage statistics per user, per user-group, per board.

Reformulation as a DevOps pipeline

Semiconductor companies like Xilinx, Lattice and Microsemi have over 1,000 development boards to offer to design engineers, all of which can be a part of such board resource depot and its Jenkins server pipeline. The key to the success of board resource depot is its reformulation as a DevOps pipeline.

By streamlining the building, testing, and deployment, the board resource depot DevOps pipeline provides engineering teams the means of continuous and efficient application/product lifecycle management. That, in turn, accelerates the embedded software development cycle.

Chirag Swarnkar is director of embedded software at Softnautics.