Over at Sylabs, Ian Lumb writes that Singularity containers can liberate EDA toolchains from specific operating systems, making this engineering process more sustainable over the long term.
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:
- 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.
Sign up for our insideHPC Newsletter
