Deploying Board Resource Depot for Large Scale Semiconductor Companies With Multi-Geographical Teams
In this article, explore the definition, development, and deployment of the Board Resource Depot for large semiconductor companies scattered globally.
Join the DZone community and get the full member experience.Join For Free
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 CI/CD (continuous integration/continuous deployment) 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 SW 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 blog explores just such an example: 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 accessible application, for the development groups scattered globally.
To explain, semiconductor industry vendors offer a vast selection of product families, along with supporting IDEs, embedded IP, and many reference designs. A major component of the support portfolio consists of development boards, and there are a plethora of such boards for those semiconductor vendor’s devices.
Despite the tremendous 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. The same scenario follows for other large semiconductor manufacturers as well. Here, continuous integration/continuous deployment would save time and effort for their 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, 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 build automation tools through a library of plugins, making Jenkins highly flexible and extensible.
Jenkins also lends itself easily and effectively to server hardware cluster deployments to support larger development 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 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.
The Board Resource Depot enables globally scattered development teams/users to create a new application from a range of boards available across the Board Resource Depot.
There is a cascade of benefits accrued to semiconductor companies’ board developers. 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 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 (unit) 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. The 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 nonetheless supports multiple object-oriented and procedural languages. The framework is keyword-driven and can be extended using available libraries.
Using Robot, 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 (UART, I2C, clocks, and so forth.) This board test suite was 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.
Huge semiconductor companies like Xilinx, Lattice, Microsemi, etc. have over 1,000 development boards to offer their customers, 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 has provided engineering teams the means of continuous and efficient application/product lifecycle management which, in the end, accelerates the embedded software development cycle.
Published at DZone with permission of Chirag Swarnkar. See the original article here.
Opinions expressed by DZone contributors are their own.