TL;DR: Tools are critical to automating the design of integrated circuits and Systems-on-a-Chip (SoCs) – lots of tools with underlying dependencies. Singularity containers can liberate toolchains from specific operating systems, and make this engineering process more sustainable over the long term.  

EDA’s 4X Challenge

If you know something about Electronic Design Automation (EDA), you might expect this 4X challenge to be about getting products to market four times faster. Or, perhaps, improving the responsiveness of a product by four times … or even shrinking its footprint by 4X. Although each of these 4X gains might translate to competitive advantage, the 4X emphasis here is on the sustainability of the EDA toolchain.

To properly appreciate this application-centric challenge consider that like industrial manufacturing for the automotive and aerospace sectors, EDA is an engineering discipline that relies upon a certified toolchain: “… literally the toolchain stack detailed from the application and its workflow, down to the operating system and hardware, and everything in between … in some cases, with surprising degrees of granularity!”

Whereas Mechanical Design Automation (MDA) relies upon an order of 10 applications, the situation in EDA is completely different. Those in-the-EDA-know at the Design Automation Conference (DAC) earlier this week in Las Vegas acknowledge the need for an order of 40 applications to design a single integrated circuit (IC) or System-on-a-Chip (SoC). Taking MDA as the baseline then, the 4X challenge inherent in EDA becomes evident.

To exacerbate matters, and as you might expect given that order of 40, use needs to be made of apps from an array of commercial Independent Software Vendors (e.g., ISVs such as Cadence, Mentor Graphics and Synopsys) potentially alongside in-house tools. Amplify that by efforts underway in the Open Source Software (OSS) community, and it’s easy to see that support matrices are required to map apps to operating systems. Whereas vendors such as Red Hat and SUSE provide ample encouragement to adopt their latest enterprise offerings of RHEL and SLES, respectively, EDA shops are literally hamstrung by their toolchain. Put in simple terms, whereas EDA shops might like to move to RHEL 8 or SLES 15, they have a business-critical need for sustained use of apps within their toolchain on ‘legacy versions’ of these enterprise distributions. Let’s be clear, this is not necessarily an industry that is change averse; this is an industry that is change controlled by their toolchain. The need to revisit IC or SoC designs from even the recent past serves only to amplify this dependency.

Singularity Containers for EDA

Thus the norm between engineering and IT, at the majority of EDA companies today, is a gap that presents far better prospects for ever-increasing expansion than contraction. Because they break the tightly coupled dependence between the toolchain runtime and the operating system kernel, Singularity containers present the unique opportunity not to close this gap, but to avoid it completely.

Briefly, Singularity containers can be utilized to encapsulate a specific EDA application and all of its required dependencies into a single, immutable, and portable software image that can be cryptographically signed for purposes of authenticity. The resulting secure Singularity Image Format (SIF) file can be stored on local or shared filesystems or, even better, hosted via the Sylabs’ Container Library – a public repository for container images that is one of the three services provided via Singularity Container Services (SCS). (Whereas this container library is designed to be a service exposed in public, Sylabs is already deploying a functionally equivalent set of services to enterprise customers in privately hosted settings – e.g., within their on-premise data centers or colocation sites.) To cryptographically sign and verify container images for use by Singularity, a key service is a second critical component of SCS. Finally, the ability to create images for Singularity through use of a Remote Builder, rounds out the triad of offerings currently available in SCS.

The nature and demands of design and verification practices are such that computationally intensive workloads result from the use of many of the order of 40 applications in the EDA toolchain. As a consequence from isolated IC/SoC projects, to EDA organizations as a whole, there exists a profound need to optimize for throughput. Fortunately, Singularity containers are a solid fit in this regard as well as:

• Overhead is minimal – Other than a minor penalty at the outset, EDA applications execute with bare-metal performance characteristics. Because these containers execute in user space, making computational use of GPUs, FPGAs, InfiniBand, and other devices, equates to a simple proposition – a proposition whose simplicity is guaranteed owing to a preference for integration over pure isolation in the Singularity case. Although benchmarking for EDA-specific use cases remains a gap at the current time, results from similar classes of applications are available independently.
• Workload management is expected – This is important, as the only way to effectively and efficiently optimize for throughput at the enterprise scale of EDA shops is to make routine use of workload managers (WLMs) such as Altair PBSPro, IBM Spectrum LSF, Slurm, or Univa Grid Engine, for example. To the WLM, the Singularity container runtime manifests as a binary executable that is seamlessly inserted at the command line or into a job-submission script. Thus the resulting containerized EDA application can be managed alongside other workloads in shared environments (e.g., compute clusters on the ground, or in cloud-based deployments.)
  The majority of the applications employed in an individual EDA toolchain or a workflow require use of one or more licensing tokens specific to the corresponding commercial ISV(s). The introduction of containerization by Singularity is essentially immaterial in this regard – for example, from interactions with license managers (e.g., Flexera FlexNet Manager) to location-based constraints (e.g., node-locked vs. floating, site vs. country, on-premise vs. cloud).

Singularity containers introduce a compelling means for unlocking the implied dependency between application toolchains and operating system. By encapsulating everything but the kernel in a single file, Singularity containers decouple the runtime and allow it to be highly portable in a trusted way. Because there’s nothing like detailed, real world use cases to demonstrate this decoupling in practice, future posts will consider more-specific examples that are relevant to EDA. In the interim, as many who learned about Singularity through our workshop at DAC are already doing, feel free to get in touch with us here. Adopting Singularity for containerizing EDA application toolchains on the ground makes sense today. And then, if your path forward involves a cloud computing component, the benefits of containerization via Singularity will offer even greater value. We look forward to hearing from you!