Skip to content

feat: add VLSI Global Placement benchmark (Frontier-Eng) - #98

Open
y-ji24 wants to merge 2 commits into
Einsia:mainfrom
y-ji24:master
Open

feat: add VLSI Global Placement benchmark (Frontier-Eng)#98
y-ji24 wants to merge 2 commits into
Einsia:mainfrom
y-ji24:master

Conversation

@y-ji24

@y-ji24 y-ji24 commented Jul 25, 2026

Copy link
Copy Markdown
Collaborator

Summary

This PR adds a new Frontier-Eng benchmark for VLSI Global Placement, based on the ISPD 2005 placement benchmark suite.

The task requires an agent to generate legal placements for movable components while minimizing Half-Perimeter Wirelength (HPWL) under placement constraints.

The benchmark includes two representative datasets with different difficulty levels:

  • adaptec1 (Easy)
  • adaptec3 (Medium)

Highlights

Benchmark

  • Based on the ISPD 2005 placement benchmarks
  • Deterministic evaluation
  • Independent HPWL and legality computation
  • Pure Python implementation using only the standard library

Agent Interface

The agent can modify only the place_components() function in scripts/init.py, which is enclosed by an EVOLVE-BLOCK. All evaluation logic, data loading, and output interfaces remain read-only.

Evaluation

The evaluator independently verifies:

  • Half-Perimeter Wirelength (HPWL)
  • Cell overlap
  • Out-of-bound placement
  • Fixed-cell movement
  • Missing cells

A candidate is considered valid only if all legality constraints are satisfied.

Baseline

A deterministic row-based placement baseline is provided.

The baseline:

  • produces legal placements,
  • is fully deterministic,
  • serves as a simple optimization starting point for Frontier-Eng agents.

Repository Structure

This benchmark follows the standard Frontier-Eng layout, including:

  • scripts/
  • verification/
  • baseline/
  • references/
  • frontier_eval/

with scripts/init.py as the only editable source file.

Verification

Verified on both benchmarks.

Benchmark Difficulty Valid HPWL Overlaps OOB Fixed Moved
adaptec1 Easy 1.32e9 0 0 0
adaptec3 Medium 4.98e9 0 0 0

Runtime:

  • adaptec1: ~5.5 s
  • adaptec3: ~12.2 s

Docker Support

Containerized evaluation is supported through verification/docker/Dockerfile.

Notes

To reduce repository size, the benchmark stores netlists in a compact index-based representation. During loading, the representation is deterministically expanded into the original in-memory format. This compression is lossless and does not affect placement, legality checking, or HPWL computation.

Only two datasets (adaptec1 and adaptec3) are included in this benchmark. Frontier-Eng benchmarks are not required to include every instance from the original ISPD 2005 benchmark suite; representative instances covering different difficulty levels are sufficient.

@github-actions

Copy link
Copy Markdown

🤖 AI Code Review (gemini-3-flash-preview)

🇬🇧 English Analysis

1. Executive Summary

  • Core Purpose: This PR introduces a new benchmark task for VLSI Global Placement, a critical stage in the Electronic Design Automation (EDA) physical design flow. It leverages industry-standard ISPD 2005 contest benchmarks (adaptec1, adaptec3) to evaluate an agent's ability to minimize Half-Perimeter Wirelength (HPWL) while adhering to strict physical constraints (no overlaps, boundary limits, and fixed cell preservation).
  • Modified File Structure & Modifications:
    • .gitattributes: Configures JSON reference files to be treated as binary/non-diffable to handle large datasets.
    • benchmarks/ElectronicDesignAutomation/VLSIGlobalPlacement/README.md (and _zh-CN.md): Provides comprehensive navigation, quick start guides, and dataset descriptions.
    • benchmarks/ElectronicDesignAutomation/VLSIGlobalPlacement/Task.md (and _zh-CN.md): Detailed engineering background on the ASIC flow and formal problem definition.
    • benchmarks/ElectronicDesignAutomation/VLSIGlobalPlacement/baseline/solution.py: Implements a deterministic row-based placement algorithm as a reference.
    • benchmarks/ElectronicDesignAutomation/VLSIGlobalPlacement/frontier_eval/: Contains metadata files (agent_files.txt, constraints.txt, run_eval.py, etc.) required for integration with the frontier_eval framework.
    • benchmarks/ElectronicDesignAutomation/VLSIGlobalPlacement/references/: Contains preprocessed JSON versions of the ISPD 2005 benchmarks.

2. AI Content Analysis

  • Estimated AI Component: 65%
  • Reasoning & Evidence:
    • Documentation Structure: The README and Task files follow a highly structured, "template-like" format common in AI-generated technical documentation (e.g., the "Engineering Background" and "Why HPWL?" sections).
    • Boilerplate Code: The run_eval.py and the file-loading logic in solution.py (using Path(__file__).resolve()) exhibit standard patterns often produced by LLMs for scaffolding.
    • Domain Specificity: While the logic in place_components (row-based greedy placement) is domain-specific, it is a textbook implementation of a basic placement algorithm, which AI can generate accurately given the prompt context.

3. Engineering & Economic Assessment

  • Engineering Reality Check: High. This is not a "toy example." The task involves handling hundreds of thousands of cells (210k to 450k), which reflects real-world ASIC design complexity. The inclusion of hard constraints (overlap and boundary checks) and the use of the HPWL metric align perfectly with industrial EDA standards.
  • Economic Value: High. Global placement is a foundational problem in chip design. Improvements in placement algorithms directly translate to reduced chip area, lower power consumption, and better timing closure, which are multi-million dollar concerns in semiconductor manufacturing.

4. Quality Assurance

  • Verification & Testing:
    • frontier_eval Integration: Yes.
    • task_name: ElectronicDesignAutomation/VLSIGlobalPlacement
    • Execution & Dependencies: The README.md clearly documents the pip install command for verification/requirements.txt and provides specific CLI commands for running the baseline and the evaluator.
  • Documentation Quality: Excellent. The PR provides bilingual documentation (English/Chinese). It includes a clear file tree, task summaries, and technical references. No significant grammatical errors or formatting inconsistencies were detected in the provided diff.
  • Organizational Structure: Logical and Scalable. The separation of baseline, references, scripts, and verification follows best practices for benchmark repositories.

5. Security & Privacy Check

  • Sensitive Files: Clean. The .gitignore correctly excludes temp/, artifacts.json, and debug scripts (_debug_*.py). No .env or API keys were found.
  • Absolute Paths: None detected. The code uses relative path resolution via the pathlib library (e.g., Path(__file__).resolve().parent.parent).

🇨🇳 中文分析

1. 摘要

  • 核心目的: 此 PR 引入了一个针对 VLSI 全局布局 (Global Placement) 的新基准测试任务,这是电子设计自动化 (EDA) 物理设计流程中的关键阶段。它利用行业标准的 ISPD 2005 竞赛基准(adaptec1, adaptec3)来评估智能体在遵守严格物理约束(无重叠、边界限制、固定单元不移动)的同时,最小化半周长线长 (HPWL) 的能力。
  • 修改的文件结构与变更摘要:
    • .gitattributes: 配置 JSON 参考文件为二进制/不可差异化处理,以应对大数据集。
    • benchmarks/ElectronicDesignAutomation/VLSIGlobalPlacement/README.md (及 _zh-CN.md): 提供全面的导航、快速入门指南和数据集说明。
    • benchmarks/ElectronicDesignAutomation/VLSIGlobalPlacement/Task.md (及 _zh-CN.md): 详细介绍了 ASIC 流程的工程背景和正式的问题定义。
    • benchmarks/ElectronicDesignAutomation/VLSIGlobalPlacement/baseline/solution.py: 实现了一个确定性的行式布局算法作为基准参考。
    • benchmarks/ElectronicDesignAutomation/VLSIGlobalPlacement/frontier_eval/: 包含集成到 frontier_eval 框架所需的元数据文件(agent_files.txt, constraints.txt, run_eval.py 等)。
    • benchmarks/ElectronicDesignAutomation/VLSIGlobalPlacement/references/: 包含预处理后的 ISPD 2005 基准测试 JSON 文件。

2. AI 成分分析

  • 预估 AI 含量: 65%
  • 判断依据与证据:
    • 文档结构: README 和 Task 文件遵循高度结构化、模板化的格式,这在 AI 生成的技术文档中非常常见(例如“工程背景”和“为什么选择 HPWL?”章节)。
    • 样板代码: run_eval.py 以及 solution.py 中的文件加载逻辑(使用 Path(__file__).resolve())表现出 LLM 在构建脚手架时常用的标准模式。
    • 领域专业性: 虽然 place_components 中的逻辑(贪心行式布局)具有领域专业性,但它是基础布局算法的教科书式实现,AI 在给定上下文的情况下可以准确生成。

3. 工程与经济评估

  • 工程现实检验: 。这并非“玩具示例”。该任务涉及处理数十万个单元(21万到45万),反映了真实的 ASIC 设计复杂度。硬约束(重叠和边界检查)的加入以及 HPWL 指标的使用完全符合工业级 EDA 标准。
  • 经济价值: 。全局布局是芯片设计的核心问题。布局算法的改进直接转化为芯片面积的减少、功耗的降低和时序收敛的优化,这些都是半导体制造中涉及数百万美元成本的关键因素。

4. 质量保证

  • 验证与测试:
    • frontier_eval 集成: 是。
    • task_name: ElectronicDesignAutomation/VLSIGlobalPlacement
    • 运行与依赖: README.md 清晰地记录了 verification/requirements.txt 的安装命令,并提供了运行基线和评估器的具体 CLI 命令。
  • 文档质量: 优秀。PR 提供了中英双语文档。包含清晰的文件树、任务摘要和技术参考文献。在提供的 diff 中未检测到明显的语法错误或格式不一致。
  • 组织结构: 逻辑清晰且具备可扩展性。将 baselinereferencesscriptsverification 分开存放符合基准测试仓库的最佳实践。

5. 安全与隐私检查

  • 敏感文件: 未发现异常.gitignore 正确排除了 temp/artifacts.json 和调试脚本 (_debug_*.py)。未发现 .env 或 API 密钥。
  • 绝对路径: 未检测到。代码通过 pathlib 库使用相对路径解析(例如 Path(__file__).resolve().parent.parent)。

@wrh-human

Copy link
Copy Markdown
Collaborator

Review — VLSIGlobalPlacement (PR #98)

Thank you for contributing this benchmark. VLSI global placement is a real EDA physical design problem using real ISPD 2005 benchmark data. After a line-by-line review of all files, the overall direction is correct, but a critical Docker integration bug and several other issues need to be addressed.


1. Domain, Economic Value, and Frontier-Eng Fit

VLSI global placement is a key stage in the ASIC physical design flow — after logic synthesis and floorplanning, standard cells are placed on the chip to minimize wirelength. Placement quality directly affects chip area, power, and timing closure. The task uses the ISPD 2005 placement contest benchmarks adaptec1 (~211k cells) and adaptec3 (~451k cells). HPWL is the industry-standard metric for placement quality. Economic value is clear, and starting from a feasible baseline with verifier-driven iterative improvement aligns with Frontier-Eng's positioning.

2. Not purely numerical

The agent modifies place_components(), which must decide the position of every movable cell in 2D chip coordinates while respecting fixed-cell constraints, die boundary constraints, and non-overlap constraints. This is a structured physical design algorithm problem involving cell dimensions, row height, macro cells, and multi-row placement — not parameter tuning.

3. Search space

Placing 211k-451k cells in a continuous 2D coordinate space creates an enormous search space that cannot be brute-forced. The baseline uses a deterministic row-based placement with intentionally poor HPWL, providing substantial headroom for improvement (e.g., via analytical placers like RePlAce, ePlace, DREAMPlace).

4. Evaluator and engineering verification

The evaluator independently implements HPWL computation and legality checks:

  • Fixed cells must remain at their initial positions (tolerance 1e-6)
  • All cells must be within the die boundary
  • No overlapping cell pairs (spatial hashing accelerates checks for 211k-451k cells)

HPWL is independently computed by the evaluator without trusting candidate-reported values. The candidate runs in a subprocess with a 600-second timeout.

5. Constraint enforcement

Constraints are implemented one by one in check_legality(): fixed-cell checks, boundary checks, and overlap checks (AABB intersection + spatial hashing). Violating any constraint returns valid=0.0 and combined_score=-1e18.

6. Baseline experiment ⚠️ Missing

baseline/solution.py (row-based placement) is provided, but there is no baseline/result_log.txt recording the baseline's actual HPWL and runtime. The baseline's concrete performance and scoring discriminative power cannot be directly verified.

7. Scoring system

combined_score = -HPWL (when valid). HPWL is the industry-standard metric. The scoring directly uses raw wirelength with no clipping or normalization, giving clear discriminative power — each unit reduction in HPWL directly improves the score by one unit.

8. Issues to address

Issue 1 (most critical): Dockerfile ENTRYPOINT hardcodes scripts/init.py, so Docker mode always evaluates the baseline instead of the candidate

In verification/docker/Dockerfile:

ENTRYPOINT ["python", "/workspace/verification/evaluator.py", "/workspace/benchmarks/ElectronicDesignAutomation/VLSIGlobalPlacement/scripts/init.py"]

The Docker container's ENTRYPOINT hardcodes the original scripts/init.py path. When the unified framework builds this image and runs frontier_eval/run_eval.py --candidate {candidate}, Docker executes the ENTRYPOINT (which evaluates the original init.py) and completely ignores the candidate path passed by the framework. This means:

  • In Docker isolation mode, no matter how the candidate improves, the evaluation always runs the frozen baseline
  • The candidate's optimizations are never measured
  • All candidates receive the same baseline score

This is a critical bug that breaks the benchmark's core purpose. Suggestions:

  • Remove the ENTRYPOINT, use CMD, or make the image accept a candidate path argument
  • Alternatively, have run_eval.py mount the candidate via a bind mount inside the container and explicitly call the evaluator on it

Issue 2: 73MB of reference JSON files committed directly to the repository

references/adaptec1.json (23MB) and references/adaptec3.json (50MB) are committed as uncompressed JSON. This significantly bloats the repository. Suggestion: use gzip compression (JSON typically compresses by >90%) and decompress at load time in the evaluator.

Issue 3: Missing EVOLVE-BLOCK boundary validation

scripts/init.py has a correct EVOLVE-BLOCK structure (lines 94-205 wrap only place_components(); load_benchmark(), compute_hpwl(), and main() are outside the markers). However, the evaluator never checks whether the candidate modified code outside the EVOLVE-BLOCK. A candidate could modify main()'s output format or load_benchmark()'s data loading logic without detection. Suggestion: validate the EVOLVE-BLOCK boundary in evaluate() before execution.

Issue 4: Candidate subprocess lacks resource limits

subprocess.run has no preexec_fn, lacking RLIMIT_NPROC, RLIMIT_AS, and RLIMIT_CPU. The 600-second timeout is the only protection. Suggestion: add resource limits as defense in depth.

Issue 5: No test file

There are no test_*.py files. At minimum, the following should be added:

  • Pass/fail tests for each constraint in check_legality() (fixed-cell movement, out-of-bounds, overlap, missing cells)
  • Boundary tests for the compute_hpwl() computation
  • A test rejecting EVOLVE-BLOCK boundary violations (after Issue 3 is fixed)
  • An end-to-end test of the complete evaluate() pipeline

Issue 6: No baseline run results

Suggestion: create baseline/result_log.txt recording the output of python verification/evaluator.py scripts/init.py --benchmark adaptec1 and adaptec3 (HPWL, runtime, legality metrics).

Issue 7 (non-blocking): Dockerfile is not pinned by SHA

FROM python:3.11-slim is not pinned by SHA256, so image drift could affect reproducibility. Suggestion: use python:3.11-slim@sha256:....

Other items verified

  • run_eval.py correctly delegates to evaluate(args.candidate), passing the candidate path
  • _decompress_netlist() correctly handles the compact netlist format
  • preprocess.py documents the Bookshelf-to-JSON conversion
  • check_legality()'s spatial hashing is efficient for large instances
  • compute_hpwl() skips missing cells (legality checks catch missing cells, so final scoring is unaffected)

Summary

The VLSI global placement direction is correct, using real ISPD 2005 data with independently reliable constraint validation and HPWL computation. Issue 1 (Docker ENTRYPOINT hardcoding causing the candidate to never be evaluated) is the most critical bug and must be fixed. Issues 2 (73MB data files), 3 (missing EVOLVE-BLOCK validation), 4 (no RLIMIT), 5 (no tests), and 6 (no baseline results) should also be addressed. The review can proceed once the above issues are addressed.

- Dockerfile: ENTRYPOINT -> CMD so Docker evaluation uses the candidate
- Compress reference JSONs with gzip (71MB -> 12MB), update all loaders
- Add EVOLVE-BLOCK boundary validation to the evaluator
- Add RLIMIT_CPU/NPROC/AS resource limits for the candidate subprocess
- Add verification/test_evaluator.py (15 unit + e2e tests)
- Add baseline/result_log.txt with recorded baseline results
- Update README/Task docs to match the compressed format
@github-actions

Copy link
Copy Markdown

🤖 AI Code Review (gemini-3-flash-preview)

🇬🇧 English Analysis

1. Executive Summary

  • Core Purpose: This PR introduces a new benchmark task for VLSI Global Placement based on the industry-standard ISPD 2005 contest suite. It challenges agents to implement algorithms that minimize Half-Perimeter Wirelength (HPWL) while satisfying physical constraints (no overlaps, boundary adherence, and fixed cell preservation).
  • Modified File Structure & Modifications:
    • .gitattributes: Configures .json.gz files as binary to prevent corruption during Git operations.
    • benchmarks/ElectronicDesignAutomation/VLSIGlobalPlacement/:
      • README.md & README_zh-CN.md: Comprehensive documentation of the task, file structure, and quick-start guides in English and Chinese.
      • Task.md & Task_zh-CN.md: Detailed engineering background, problem definitions, and metric explanations.
      • references/: Contains compressed benchmark data (adaptec1, adaptec3) and difficulty metadata.
      • scripts/init.py: The modifiable entry point for the agent, containing a baseline row-based placement algorithm.
      • verification/evaluator.py: The core evaluation engine that calculates HPWL and validates hard constraints.
      • baseline/solution.py: A standalone reference implementation of the row-based placement logic.
      • frontier_eval/: Integration metadata including run_eval.py, constraints.txt, and file mapping for the evaluation framework.

2. AI Content Analysis

  • Estimated AI Component: 25%
  • Reasoning & Evidence: The core logic for HPWL calculation and the row-based placement algorithm (solution.py) exhibits deep domain-specific knowledge of Electronic Design Automation (EDA) that is unlikely to be purely AI-generated without significant human guidance. However, the documentation structure (READMEs and Task descriptions) and the boilerplate configuration files in frontier_eval/ follow highly standardized templates, suggesting AI assistance in generating documentation and scaffolding. Variable naming is descriptive and professional (e.g., row_cursor, tall_cells), which is consistent with high-quality human engineering.

3. Engineering & Economic Assessment

  • Engineering Reality Check: Production-Grade. The task uses real-world datasets (ISPD 2005) with hundreds of thousands of cells, representing a significant computational challenge. It correctly identifies and enforces critical physical design constraints (overlaps, fixed cells). The use of gzip for JSON netlists demonstrates a practical approach to handling large-scale EDA data within Git size limits.
  • Economic Value: High. VLSI placement is a multi-billion dollar bottleneck in chip design. Improving placement quality directly translates to better chip performance (timing), lower power consumption, and reduced manufacturing costs (area). This benchmark provides a robust sandbox for testing AI-driven optimization in a high-value industrial domain.

4. Quality Assurance

  • Verification & Testing:
    • frontier_eval Integration: Yes.
    • task_name: ElectronicDesignAutomation/VLSIGlobalPlacement
    • Execution & Dependencies: The README.md clearly documents the installation of dependencies via pip install -r verification/requirements.txt and provides exact commands for running the baseline and the evaluator.
  • Documentation Quality: Excellent. The documentation is bilingual, provides a clear engineering context, and explains the mathematical objective (HPWL) thoroughly. The file structure tree is helpful for new developers. No significant grammatical errors or formatting inconsistencies were detected.
  • Organizational Structure: Logical and Scalable. The separation of references (data), verification (logic), and scripts (agent space) is clean. The inclusion of a baseline folder allows for easy performance comparison.

5. Security & Privacy Check

  • Sensitive Files: Clean. The .gitignore correctly excludes temp/, artifacts.json, and debug scripts. No API keys or .env files were found.
  • Absolute Paths: None detected. The code uses pathlib and relative path resolution (e.g., Path(__file__).resolve().parent.parent) to locate reference data, ensuring portability across different environments.

🇨🇳 中文分析

1. 摘要

  • 核心目的: 此 PR 引入了一个基于行业标准 ISPD 2005 竞赛套件的 VLSI 全局布局 (Global Placement) 新基准任务。该任务要求智能体实现布局算法,在满足物理约束(无重叠、边界限制、固定单元位置不变)的前提下,最小化半周长线长 (HPWL)。
  • 修改的文件结构与变更摘要:
    • .gitattributes: 将 .json.gz 文件配置为二进制,防止 Git 操作导致损坏。
    • benchmarks/ElectronicDesignAutomation/VLSIGlobalPlacement/:
      • README.md & README_zh-CN.md: 任务、文件结构和快速入门指南的中英文完整文档。
      • Task.md & Task_zh-CN.md: 详细的工程背景、问题定义和指标说明。
      • references/: 包含压缩的基准数据(adaptec1, adaptec3)及难度元数据。
      • scripts/init.py: 智能体可修改的入口文件,包含行式布局基线算法。
      • verification/evaluator.py: 核心评测引擎,负责计算 HPWL 并验证硬约束。
      • baseline/solution.py: 行式布局逻辑的独立参考实现。
      • frontier_eval/: 包含 run_eval.pyconstraints.txt 和评测框架文件映射的集成元数据。

2. AI 成分分析

  • 预估 AI 含量: 25%
  • 判断依据与证据: HPWL 计算和行式布局算法(solution.py)的核心逻辑表现出深厚的电子设计自动化(EDA)领域专业知识,不太可能在没有大量人工指导的情况下由 AI 纯粹生成。然而,文档结构(README 和 Task 描述)以及 frontier_eval/ 中的模板化配置文件遵循高度标准化的格式,表明在生成文档和脚手架代码时使用了 AI 辅助。变量命名(如 row_cursor, tall_cells)规范且专业,符合高质量的人工工程习惯。

3. 工程与经济评估

  • 工程现实检验: 生产级。该任务使用包含数十万个单元的真实数据集(ISPD 2005),具有显著的计算挑战。它正确识别并强制执行了关键的物理设计约束(重叠、固定单元)。对 JSON 网表使用 gzip 压缩展示了在 Git 容量限制下处理大规模 EDA 数据的务实方法。
  • 经济价值: 。VLSI 布局是芯片设计中价值数十亿美元的瓶颈。布局质量的提升直接转化为更好的芯片性能(时序)、更低的功耗和更低的制造费用(面积)。该基准为在高价值工业领域测试 AI 驱动的优化算法提供了一个稳健的沙盒。

4. 质量保证

  • 验证与测试:
    • frontier_eval 集成: 是。
    • task_name: ElectronicDesignAutomation/VLSIGlobalPlacement
    • 运行与依赖: README.md 清晰记录了通过 pip install -r verification/requirements.txt 安装依赖的方法,并提供了运行基线和评测器的确切命令。
  • 文档质量: 优秀。文档采用双语撰写,提供了清晰的工程背景,并深入解释了数学目标(HPWL)。文件结构树对新开发者非常有帮助。未检测到明显的语法错误或格式不一致。
  • 组织结构: 逻辑清晰且具备可扩展性references(数据)、verification(逻辑)和 scripts(智能体空间)的分离非常干净。包含 baseline 文件夹便于进行性能对比。

5. 安全与隐私检查

  • 敏感文件: 未发现异常.gitignore 正确排除了 temp/artifacts.json 和调试脚本。未发现 API 密钥或 .env 文件。
  • 绝对路径: 未检测到。代码使用 pathlib 和相对路径解析(例如 Path(__file__).resolve().parent.parent)来定位参考数据,确保了在不同环境下的可移植性。

@y-ji24

y-ji24 commented Aug 10, 2026

Copy link
Copy Markdown
Collaborator Author

Thanks for the detailed review. I have addressed all blocking and major issues in the latest commit (8ea6dcb).

Addressed issues

1. Docker evaluation bug (ENTRYPOINT hardcoding) — Fixed

  • Changed Docker configuration from hardcoded ENTRYPOINT to CMD, allowing the evaluation framework to pass the candidate path correctly.
  • Verified with a simulated invalid candidate:
    • Candidate execution produced valid=0 and n_cells_placed=543
    • Baseline execution produced valid=1 and n_cells_placed=211,447
  • This confirms that Docker evaluation now evaluates the submitted candidate rather than always running the baseline.

2. Reference data size — Fixed

  • Compressed reference files using gzip:
    • adaptec1.json / adaptec3.json: ~71MB → ~12MB total
    • adaptec1.json.gz: 3.7MB
    • adaptec3.json.gz: 7.9MB
  • Updated loaders in:
    • scripts/init.py
    • verification/evaluator.py
    • baseline/solution.py
  • All components transparently decompress the compact representation.
  • Verified that HPWL and legality results remain unchanged after compression.

3. EVOLVE-BLOCK validation — Fixed

  • Added check_evolve_boundary() in the evaluator.
  • The evaluator now verifies that candidate modifications are restricted to the intended EVOLVE-BLOCK region.

4. Resource limits — Fixed

  • Added process-level resource limits (RLIMIT_CPU, RLIMIT_NPROC, RLIMIT_AS) through preexec_fn on POSIX systems.
  • The existing 600-second timeout is retained as an additional safeguard.

5. Evaluator tests — Fixed

  • Added verification/test_evaluator.py.
  • Added 15 tests covering:
    • HPWL computation
    • Fixed-cell constraints
    • Out-of-bound checks
    • Overlap detection
    • Missing-cell handling
    • EVOLVE-BLOCK validation
    • End-to-end evaluation pipeline
  • All tests pass.

6. Baseline results — Fixed

  • Added baseline/result_log.txt containing baseline evaluation results for both benchmarks.

Verification after changes

Benchmark Valid HPWL Overlaps OOB Fixed Moved Runtime
adaptec1 1.0 1,318,928,036 0 0 0 ~5s
adaptec3 1.0 4,982,296,306 0 0 0 ~12s

Both benchmarks remain deterministic and produce legal placements.

Remaining non-blocking item

Docker image SHA pinning

We have not pinned python:3.11-slim to a SHA256 digest. Since this is a reproducibility hardening suggestion rather than a functional issue, we have left it unchanged for now.

Thanks again for the thorough review. The benchmark should now satisfy the Frontier-Eng evaluation requirements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants