Store your Helm charts in Singularity Container Services
Discover an efficient solution to improve your workflow. Explore the benefits and get step-by-step guidance on implementation.
At many EDA companies today, a gap exists between IT and Engineering requirements. 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.
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:
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.
This article was originally published on insideHPC
Discover an efficient solution to improve your workflow. Explore the benefits and get step-by-step guidance on implementation.
Optimize Your containerized OCI workflows with the latest Singularity Enterprise release. Dive into the enhancements today.
Pyro: A Comprehensive Pipeline for Eukaryotic Genome Assembly introduces a groundbreaking tool that can significantly advance our understanding of genetics and contribute to vital scientific discoveries. Pyro offers a comprehensive pipeline for assembling eukaryotic...