Mastering Compute Resource Planning and Cash Flow for IC Design Projects

Why Compute Planning and Cash Flow Matter

For semiconductor design companies, balancing compute resource planning with cash flow is a critical art: allocating too much capacity wastes money, while allocating too little can stall projects. Two illustrative diagrams—"Guarding Cash Flow" and "Life Is a Gamble"—highlight the financial stakes of resource decisions.

Typical Challenges

Periodic spikes in compute demand caused by process milestones.

Uncertain resource estimates each time the process is adjusted; estimates are often inaccurate.

Occasional need for internal resources (memory or compute) that are unavailable.

Real‑World Example: Monthly Compute Usage

An 18‑month chip project (named "QuanSheng") involves front‑end, verification, and back‑end teams. The first four months have low demand; demand rises steadily from month 5, peaks at month 11, reaches a maximum at month 16 with a monthly scheduling peak exceeding one million core‑hours, and then drops sharply. The peak‑to‑valley ratio exceeds 20×.

Step‑by‑Step Guide to Compute Planning

Part 1 – Beginner Algorithm (New Project, New Team)

Assumptions:

Total R&D staff: 100

Team ratio (front‑end : verification : back‑end) = 2 : 1 : 1

Project divided into three 4‑month stages (only for the beginner algorithm)

Resource types: front‑end uses compute machines; verification uses compute early then memory machines; back‑end uses memory machines

Formula for each team’s peak core‑hours in a stage:

PeakCoreHours = (PeakCoresPerJob * JobsPerPerson) * TeamSize

Stage 1 (months 1‑4) – front‑end: 10 cores × 50 people × 1 job = 500 core‑hours; verification: 20 cores × 25 people × 1 job = 500 core‑hours; total = 1 000 core‑hours.

Stage 2 (months 5‑8) – detailed per‑month resource needs are listed, e.g., month 5 front‑end 1 × 18‑core node per person, verification 4 jobs × ≈18 cores each, back‑end 1 × 18‑core node per person.

Stage 3 (months 9‑12) – similar calculations for verification and back‑end teams.

Part 2 – Experienced Algorithm (Leverage Historical Data)

Teams fill a template with:

Peak cores per job (and peak memory per job) for each team.

Maximum parallel jobs per month ("job count").

The total monthly peak is the sum of each team’s PeakCoresPerJob × JobCount. Example: front‑end 10 cores × 50 jobs = 500; verification 20 cores × 25 jobs = 500; back‑end not active yet.

Part 3 – Converting Peak Demand to Realistic Usage

Peak demand assumes 24 h × 30 days per month. Real usage is often lower, e.g., 22 days × 8 h. Adjust the peak core‑hours accordingly. Small wave peaks (e.g., back‑end 30 days × 18 h) and large wave peaks (e.g., back‑end 30 days × 24 h) are used to produce a realistic monthly demand curve.

Part 4 – Choosing the Right Procurement Strategy

Three lines on the final chart illustrate options:

Gray line : purchase enough local resources to cover the peak (high cash‑flow impact).

Orange line : use cloud resources on a pay‑as‑you‑go basis (cash flow spreads over time).

Green line : hybrid approach, combining local and cloud resources.

The decision depends on the company’s cash‑flow situation, procurement lead time, and tolerance for risk.

Key Takeaways

Monthly compute demand can vary by up to 20× across a project lifecycle.

Accurate peak estimation and realistic usage conversion are essential for budgeting and avoiding project delays.

Choosing between local, cloud, or hybrid resources should balance cash‑flow constraints, procurement cycles, and performance requirements.