본문으로 건너뛰기
cccskills
무료GitHub에 공개

dse-loop

Explore hardware and electronic design configurations by repeatedly running programs, measuring results, and adjusting parameters. Track constraints and every trial, then report the best configuration found within the time and iteration limits.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

Autonomous design space exploration loop for computer architecture and EDA. Runs a program, analyzes results, tunes parameters, and iterates until objective is met or timeout. Use when user says "DSE", "design space exploration", "sweep parameters", "optimize", "find best config", or wants iterative parameter tuning.

설치 방법 보기

이럴 때 유용합니다

  • Tuning cache sizes and processor configuration
  • Reducing circuit area while meeting timing constraints
  • Comparing compiler flags for runtime or code size
  • Exploring tradeoffs between multiple design objectives

포함된 파일(1)

  • SKILL.md13.8 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

DSE Loop: Autonomous Design Space Exploration

🔁 Do not wrap this skill in /loop / CronCreate. It already loops internally until its objective is met or it times out. Unlike the verdict-bearing review/audit skills, its stop gate is an objective machine-checkable metric (Type-A), so its self-termination is safe same-model — the reason not to wrap it is scheduler duplication, not the verdict fence. See shared-references/external-cadence.md.

Autonomously explore a design space: run → analyze → pick next parameters → repeat, until the objective is met or timeout is reached. Designed for computer architecture and EDA problems.

Context: $ARGUMENTS

Safety Rules — READ FIRST

NEVER do any of the following:

  • sudo anything
  • rm -rf, rm -r, or any recursive deletion
  • rm any file you did not create in this session
  • Overwrite existing source files without reading them first
  • git push, git reset --hard, or any destructive git operation
  • Kill processes you did not start

If a step requires any of the above, STOP and report to the user.

Constants (override via $ARGUMENTS)

ConstantDefaultDescription
TIMEOUT2hTotal wall-clock budget. Stop exploring after this.
MAX_ITERATIONS50Hard cap on number of design points evaluated.
PATIENCE10Stop early if no improvement for this many consecutive iterations.
OBJECTIVEminimizeminimize or maximize the target metric.

Override inline: /dse-loop "task desc — timeout: 4h, max_iterations: 100, patience: 15"

Typical Use Cases

ProblemProgramParametersObjective
Microarch DSEgem5 simulationcache size, assoc, pipeline width, ROB size, branch predictormaximize IPC or minimize area×delay
Synthesis tuningyosys/DC scriptoptimization passes, target freq, effort levelminimize area at timing closure
RTL parameterizationverilator simdata width, FIFO depth, pipeline stages, buffer sizesmeet throughput target at min area
Compiler flagsgcc/llvm build + benchmark-O levels, unroll factor, vectorization, schedulingminimize runtime or code size
Placement/routingopenroad/innovusutilization, aspect ratio, layer configminimize wirelength / timing
Formal verificationabc/sbybound depth, engine, timeout per propertymaximize coverage in time budget
Memory subsystemcacti / ramulatorbank count, row buffer policy, schedulingoptimize bandwidth/energy

Workflow

Phase 0: Parse Task & Setup

  1. Parse $ARGUMENTS to extract:

    • Program: what to run (command, script, or Makefile target)
    • Parameter space: which knobs to tune and their ranges/options (may be incomplete — see step 2)
    • Objective metric: what to optimize (and how to extract it from output)
    • Constraints: hard limits that must not be violated (e.g., timing must close)
    • Timeout: wall-clock budget
    • Success criteria: when is the result "good enough" to stop early?
  2. Infer missing parameter ranges — If the user provides parameter names but NOT ranges/options, you MUST infer them before exploring:

    a. Read the source code — search for the parameter names in the codebase:

    • Look for argparse/click definitions, config files, Makefile variables, module parameters, #define, parameter (SystemVerilog), localparam, etc.
    • Extract defaults, types, and any comments hinting at valid values

    b. Apply domain knowledge to set reasonable ranges:

    Parameter typeInference strategy
    Cache/memory sizesPowers of 2, typically 1KB–16MB
    AssociativityPowers of 2: 1, 2, 4, 8, 16
    Pipeline width / issue widthSmall integers: 1, 2, 4, 8
    Buffer/queue/FIFO depthPowers of 2: 4, 8, 16, 32, 64
    Clock period / frequencyBased on technology node; try ±50% from default
    Bound depth (BMC/formal)Geometric: 5, 10, 20, 50, 100
    Timeout valuesGeometric: 10s, 30s, 60s, 120s, 300s
    Boolean/enum flagsEnumerate all options found in source
    Continuous (learning rate, threshold)Log-scale sweep: 5 points spanning 2 orders of magnitude around default
    Integer counts (threads, cores)Linear: from 1 to hardware max

    c. Start conservative — begin with 3-5 values per parameter. Expand range later if the best result is at a boundary.

    d. Log inferred ranges — write the inferred parameter space to dse_results/inferred_params.md so the user can review:

    # Inferred Parameter Space
    
    | Parameter | Source | Default | Inferred Range | Reasoning |
    |-----------|--------|---------|---------------|-----------|
    | CACHE_SIZE | config.py:42 | 32768 | [8192, 16384, 32768, 65536, 131072] | powers of 2, ±2x from default |
    | ASSOC | config.py:43 | 4 | [1, 2, 4, 8] | standard associativities |
    | BMC_DEPTH | run_bmc.py:15 | 10 | [5, 10, 20, 50] | geometric, common BMC depths |
    

    e. Boundary expansion — during the search, if the best result is at the min or max of a range, automatically extend that range by one step in that direction (but log the extension).

  3. Read the project to understand:

    • How to run the program
    • Where results are produced (stdout, log files, reports)
    • How to parse the objective metric from output
    • Current/baseline configuration (if any)
  4. Create working directory: dse_results/ in project root

    • dse_results/dse_log.csv — one row per design point
    • dse_results/DSE_REPORT.md — final report
    • dse_results/DSE_STATE.json — state for recovery
    • dse_results/inferred_params.md — inferred parameter space (if ranges were not provided)
    • dse_results/configs/ — config files for each run
    • dse_results/outputs/ — raw output for each run
  5. Write a parameter extraction script (dse_results/parse_result.py or similar) that takes a run's output and returns the objective metric as a number. Test it on a baseline run first.

  6. Run baseline (iteration 0): run the program with default/current parameters. Record the baseline metric. This is the point to beat.

Phase 1: Initial Exploration

Goal: Quickly survey the space to understand which parameters matter most.

Strategy: Latin Hypercube Sampling or structured sweep of key parameters.

  1. Pick 5-10 diverse design points that span the parameter ranges
  2. Run them (in parallel if independent, via background processes or sequential)
  3. Record all results in dse_log.csv:
    iteration,param1,param2,...,metric,constraint_met,timestamp,notes
    0,default,default,...,baseline_val,yes,2026-03-13T10:00:00,baseline
    1,val1a,val2a,...,result1,yes,2026-03-13T10:05:00,initial sweep
    ...
    
  4. Analyze: which parameters have the most impact on the objective?
  5. Narrow the search to the most sensitive parameters

Phase 2: Directed Search

Goal: Converge toward the optimum by making informed choices.

Strategy: Adaptive — pick the approach that fits the problem:

  • Few parameters (≤3): Fine-grained grid search around the best region from Phase 1
  • Many parameters (>3): Coordinate descent — optimize one parameter at a time, holding others at current best
  • Binary/categorical params: Enumerate promising combinations
  • Continuous params: Binary search or golden section between best neighbors
  • Multi-objective: Track Pareto frontier, explore along the front

For each iteration:

  1. Select next design point based on results so far:

    • Look at the trend: which direction improves the metric?
    • Avoid re-running configurations already evaluated
    • Balance exploration (untested regions) vs exploitation (near current best)
  2. Modify parameters: edit config file, command-line args, or source constants

  3. Run the program: execute and capture output

  4. Parse results: extract the objective metric and check constraints

  5. Log to dse_log.csv: append the new row

  6. Check stopping conditions:

    • Timeout reached? → stop
    • Max iterations reached? → stop
    • Patience exhausted (no improvement in N iterations)? → stop
    • Success criteria met (metric is "good enough")? → stop
    • Constraint violation pattern detected? → adjust search bounds
  7. Update DSE_STATE.json:

    {
      "iteration": 15,
      "status": "in_progress",
      "best_metric": 1.23,
      "best_params": {"cache_size": 32768, "assoc": 4, "pipeline_width": 2},
      "total_iterations": 15,
      "start_time": "2026-03-13T10:00:00",
      "timeout": "2h",
      "patience_counter": 3
    }
    
  8. Decide next step → back to step 1

Phase 3: Refinement (if time allows)

If the search converged and there's still time budget:

  1. Local perturbation: try ±1 step on each parameter from the best point
  2. Sensitivity analysis: which parameters can be relaxed without hurting the metric?
  3. Constraint boundary: if a constraint is nearly binding, explore near-feasible points

Phase 4: Report

Write dse_results/DSE_REPORT.md:

# Design Space Exploration Report

**Task**: [description]
**Date**: [start] → [end]
**Total iterations**: N
**Wall-clock time**: X hours Y minutes

## Objective
- **Metric**: [what was optimized]
- **Direction**: minimize / maximize
- **Baseline**: [value]
- **Best found**: [value] ([improvement]% better than baseline)

## Best Configuration
| Parameter | Baseline | Best |
|-----------|----------|------|
| param1    | default  | best_val |
| param2    | default  | best_val |
| ...       | ...      | ... |

## Search Trajectory
| Iteration | param1 | param2 | ... | Metric | Notes |
|-----------|--------|--------|-----|--------|-------|
| 0 (baseline) | ... | ... | ... | ... | baseline |
| 1 | ... | ... | ... | ... | initial sweep |
| ... | ... | ... | ... | ... | ... |
| N (best) | ... | ... | ... | ... | ★ best |

## Parameter Sensitivity
- **param1**: [high/medium/low impact] — [brief explanation]
- **param2**: [high/medium/low impact] — [brief explanation]

## Pareto Frontier (if multi-objective)
[Table or description of non-dominated points]

## Stopping Reason
[timeout / max_iterations / patience / success_criteria_met]

## Recommendations
- [actionable insights from the exploration]
- [which parameters matter most]
- [suggested follow-up explorations]

Also generate a summary plot if matplotlib is available:

  • Convergence curve (metric vs iteration)
  • Parameter sensitivity bar chart
  • Pareto frontier scatter (if multi-objective)

State Recovery

If the context window compacts mid-run, the loop recovers from DSE_STATE.json + dse_log.csv:

  1. Read DSE_STATE.json for current iteration, best params, patience counter
  2. Read dse_log.csv for full history
  3. Resume from next iteration

Key Rules

  • Work AUTONOMOUSLY — do not ask the user for permission at each iteration
  • Every run must be logged — even failed runs, constraint violations, errors. The log is the ground truth.
  • Never re-run an identical configuration — check dse_log.csv before each run
  • Respect the timeout — check elapsed time before starting a new iteration. If the next run is likely to exceed the timeout, stop and report.
  • Parse metrics programmatically — write a parsing script, don't eyeball logs
  • Keep raw outputs — save each run's full output in dse_results/outputs/iter_N/
  • Constraint violations are not improvements — a design point that violates constraints is never "best", regardless of the metric
  • If a run crashes, log the error, skip that point, and continue with the next
  • If the same crash repeats 3 times with different configs, the harness code itself is the suspect — discard and reimplement the run/parse script cleanly from the spec (a peer move to another patch; delete only the script, never dse_log.csv / dse_results/; see shared-references/external-cadence.md § Let a broken attempt restart, not just patch). Before resuming the sweep, re-validate metric comparability: re-parse one COMPLETED iteration's raw output from dse_results/outputs/iter_N/ with the new parser and confirm it reproduces that row of dse_log.csv; on mismatch, either fix the parser or re-parse and flag all affected rows — never mix two parsing semantics in one log. If a clean reimplement crashes the same way, stop and report — the spec or the environment is then in question, which is what needs the human

Example Invocations

# Minimal — just name the parameters, let the agent figure out ranges
/dse-loop "Run gem5 mcf benchmark. Tune: L1D_SIZE, L2_SIZE, ROB_ENTRIES. Objective: maximize IPC. Timeout: 3h"

# Partial — some ranges given, some not
/dse-loop "Run make synth. Tune: CLOCK_PERIOD [5ns, 4ns, 3ns, 2ns], FLATTEN, ABC_SCRIPT. Objective: minimize area at timing closure. Timeout: 1h"

# Fully specified — explicit ranges for everything
/dse-loop "Simulate processor with FIFO_DEPTH [4,8,16,32], ISSUE_WIDTH [1,2,4], PREFETCH [on,off]. Run: make sim. Objective: max throughput/area. Timeout: 2h"

# Real-world: PDAG-SFA formal verification tuning
/dse-loop "Run python run_bmc.py. Tune: BMC_DEPTH, ENGINE, TIMEOUT_PER_PROP. Objective: maximize properties proved. Timeout: 2h"

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Plan and run ablation studies, experiments that remove or replace parts of a method to test their contribution. Organize reviewer questions, priorities, expected outcomes, and compute costs, then record results and findings.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Test how much each component contributes
  • Plan experiments that address reviewer questions
  • Prioritize comparisons within a compute budget
wanshuiyin/Auto-claude-code-research-in-sleep1.8만2026년 10월 19일 업데이트

Plan ablation studies, experiments that remove or replace parts of a machine learning method to test their contribution. Define reviewer questions, expected outcomes, priorities, execution order, and compute estimates, then implement experiments and record findings.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Testing the contribution of individual method components
  • Planning additional experiments before paper submission
  • Prioritizing experiments within a GPU budget
wanshuiyin/Auto-claude-code-research-in-sleep1.8만2026년 10월 19일 업데이트

alphaxiv

무료

Understand a single arXiv paper through an AlphaXiv summary, with full text and LaTeX source available when needed. Use it to identify key findings or ask specific questions about methods, experiments, and equations.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Get a quick overview of a paper from its URL
  • Check a paper's methods and experimental results
  • Ask about equations, proofs, or appendix details
wanshuiyin/Auto-claude-code-research-in-sleep1.8만2026년 10월 19일 업데이트

Compare machine learning experiment results from JSON or CSV files. Calculate improvements over a baseline, summarize variation across repeated runs, identify trends and unusual results, and suggest experiments to test possible explanations.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Compare model performance across experimental conditions
  • Check variation across runs with different random seeds
  • Identify trends as a parameter changes
wanshuiyin/Auto-claude-code-research-in-sleep1.8만2026년 10월 19일 업데이트

arxiv

무료

Search arXiv papers by topic or paper ID, review authors and abstracts, and summarize contributions stated in the abstracts. Download selected papers or all search results as PDFs to build a local paper library.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Find arXiv papers on a research topic
  • Retrieve details for a known arXiv paper ID
  • Download all PDFs from a set of search results
wanshuiyin/Auto-claude-code-research-in-sleep1.8만2026년 10월 19일 업데이트

Improve a compiled paper through two rounds of external model review, source edits, and PDF rebuilding. Check claims against evidence, resolve inconsistencies, and refine figures and layout, with optional checkpoints and restrictions on which edits are allowed.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Revising a generated paper before submission
  • Correcting mismatches between claims and evidence
  • Improving notation, figures, tables, and layout
wanshuiyin/Auto-claude-code-research-in-sleep1.8만2026년 10월 19일 업데이트

wanshuiyin의 스킬 모두 보기

이 스킬의 문제 신고