Term · EDA Tools & Flows
Compute farm
The pool of shared servers on which EDA jobs are executed, managed by a batch scheduler that matches job resource requests to available cores, memory and licences.
Farm capacity and memory per job directly set a project's iteration speed.
- Also known as
- Server farm, Batch farm, Compute grid
- Type
- Term
- Domain
- EDA Tools & Flows, Compute and infrastructure
Notes
A single advanced-node full-chip timing or DRC job can demand hundreds of gigabytes of RAM on one machine.
Overview
A compute farm is a pool of shared servers on which a chip design team runs its EDA jobs, such as simulations, synthesis, place and route, timing analysis and library characterisation, under a batch scheduler that queues the work and starts each job on a machine with the cores, memory and licences it needs. Its capacity sets how many runs a team can complete each day, and so how quickly a project converges. Farms may sit in a company's own data centre, in a public cloud, or across both.
How it works
Engineers submit jobs to the scheduler rather than to a particular machine. Schedulers such as IBM Spectrum LSF and Slurm keep a queue of pending work, allocate machines, start and monitor jobs, and arbitrate between users when demand exceeds supply. Slurm, for example, runs a central controller plus a daemon on every compute node, and groups nodes into partitions that act as queues, each with its own limits on job size and run time, permitted users and priority.
EDA workloads are mixed: many short simulation jobs in a nightly regression alongside a few very large jobs, such as full-chip place and route or timing signoff, that need machines with a great deal of memory. Tool licences are often the scarcer resource. AWS notes that EDA licences typically cost several times more than the compute they run on, so schedulers are set up to treat licences as a resource: Slurm can hold a job until a licence from a declared pool is free, and the LSF License Scheduler can give signoff work priority over exploratory runs.
Cloud capacity lets a team grow the farm when on-premises machines run out. An AWS case study describes Arm's physical design IP team scaling its EDA environment from 5,000 to 30,000 cores on demand, after a data centre where adding capacity took months of approval and procurement. EDA vendors support this with pay-per-use licensing, and LSF can forward work to cloud resources.
Examples
- Arm's physical design IP team scaling from 5,000 to 30,000 cores on AWS for logic characterisation, as described in an AWS case study.
- A Slurm partition reserved for large-memory nodes that run full-chip timing and place-and-route jobs.
- A tapeout queue set to high priority and protected from pre-emption, while regression jobs run at lower priority on cheaper spot capacity.
Why it matters
Compute farm and HPC engineers, scheduler specialists, EDA infrastructure teams and licence administrators run the farm, while every design, verification and implementation engineer depends on it. Too little capacity, too little memory per job or badly balanced licences all show up directly as slower iterations and later tapeouts.
Related terms
- LSF
- Slurm
- Regression
- Cloud EDA
- Turnaround time
Part of the EDA Tools & Flows glossary, with every term in the topic and the lifecycles, tools and standards that use them.
Where it appears on the Hub
Used on 18 pages of the Hub. In each group, the pages that mention it most come first.
Roles
Skills
Suggest an improvement
Suggest an improvement to this entry
A clearer definition, an example, a correction or a source an editor can check. Editors review every suggestion before the entry changes.
Last reviewed . Written by The Semiconductor Hub editorial team. The full glossary