chipyard-pnr-docker-test

Replace physical SRAM macros with mock modules for Chipyard PnR in Docker.

2|Updated Mar 16, 2026
One-click install
npx skills add https://github.com/xsw632/ChipAgent --skill chipyard-pnr-docker-test
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: chipyard-pnr-docker-test
Source: https://github.com/xsw632/ChipAgent/tree/main/skills/chipyard-pnr-test
Command: npx skills add https://github.com/xsw632/ChipAgent --skill chipyard-pnr-docker-test

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Large Chipyard hardware designs like SmallBOOM exhaust system memory during physical place-and-route flows that use real SRAM macros, making area, routability, and timing feasibility estimation impossible for teams without high-memory workstations.

Core Features & Use Cases

  • All-Mock SRAM Blackboxing: Replaces physical SRAM macros with lightweight mock modules, cutting peak memory usage from 50+ GB to ~20 GB to avoid out-of-memory failures.
  • Dockerized End-to-End Flow: Runs the full ORFS place-and-route pipeline inside Docker containers, requiring no local installation of Chipyard, ORFS, or related EDA tools.
  • Adaptive Multi-Round Tuning: Automatically adjusts PnR parameters across multiple rounds based on diagnostic results, with casebook warm-starts from past similar designs to accelerate closure, plus parallel candidate exploration for ambiguous failure modes.
  • Use Case: A hardware engineering team can quickly estimate the area and routability of a new SmallBOOM RISC-V core variant in under 8 hours, without provisioning a 64 GB memory server or waiting for full physical SRAM signoff.

Quick Start

Use the chipyard-pnr-docker-test skill to run a full place-and-route feasibility flow for your Chipyard design by providing the design config name and optional target frequency.

Frequently Asked Questions about chipyard-pnr-docker-test

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I avoid out-of-memory failures during Chipyard place-and-route for large RISC-V designs?

To avoid out-of-memory failures during Chipyard place-and-route, replace physical SRAM macros with lightweight mock memory modules. This reduces peak memory usage from over 50 GB to approximately 20 GB, enabling physical feasibility estimation on standard workstations.

Can I run ORFS place-and-route for SmallBOOM without installing Chipyard or EDA tools locally?

Yes, you can run the ORFS place-and-route pipeline for SmallBOOM without local installations by using a Dockerized end-to-end flow. This containerized approach executes the full physical design process without requiring local Chipyard or OpenROAD dependencies.

How does adaptive multi-round tuning work for RISC-V physical design closure?

Adaptive multi-round tuning automatically adjusts place-and-route parameters across multiple iterations based on diagnostic results. It leverages casebook warm-starts from similar past designs and explores parallel candidates for ambiguous failures to accelerate design closure.

Does replacing physical SRAM macros with mock modules affect timing and routability estimation?

Replacing physical SRAM macros with mock modules enables fast area, routability, and timing feasibility estimation for RISC-V cores. This approach bypasses full physical SRAM signoff, allowing hardware engineering teams to evaluate design variants in under eight hours.

What is the minimum system memory required to run physical place-and-route on large Chipyard designs?

The minimum system memory required to run place-and-route on large Chipyard designs is approximately 20 GB when using mock SRAMs. This bypasses the 50-plus GB memory requirement of physical SRAM macros, eliminating the need for high-memory servers.

Why does physical place-and-route fail with out-of-memory errors for SmallBOOM designs?

Physical place-and-route fails with out-of-memory errors because large Chipyard designs like SmallBOOM exhaust system memory when using real SRAM macros. The physical memory footprint exceeds standard workstation capacity, halting area and timing feasibility estimation.