- name
- anlogic-needs-analysis
- description
- Use when Anlogic FPGA work still needs requirement decomposition, device and resource judgment, interface analysis, module partitioning, timing/data-flow planning, or upstream design direction. This stage must decide when the requirement is clear enough to hand off either to `anlogic-python-signal-pre-research` for a reference timing baseline or to later specialist Anlogic skills.
# Anlogic FPGA Needs Analysis Skill
Use this skill as the default entrypoint for new-design requirement analysis.
## Role
Turn user requirements into engineering-input conclusions and decide whether the flow may leave the requirement stage.
## Inputs
- user goal and acceptance target
- board or system context
- device and package candidates
- interface, throughput, latency, and timing expectations
- the latest stage summary when this task is part of a larger flow
## Boundaries
- do not jump directly into RTL when requirement decomposition is still incomplete
- do not treat example projects as proof that board, device, or DDR identity has been locked
- do not replace later design, testbench, or project-creation work
## Outputs
- engineering-input conclusions
- routing guidance for the next stage
- a compact stage summary at `doc/stage-S0-summary.md`
## Not Doing
- not writing long free-form restatements when a compact summary is enough
- not routing around missing requirement evidence
## Responsibilities
- Decompose the requirement into engineering-input conclusions
- Judge device, package, speed, resource, and interface fit
- Define module partitioning, data flow, and control flow
- State clocks, resets, buffering, and throughput assumptions
- Recommend primitives, hard IP, wrappers, and TD IP priorities
- Decide whether the requirement is already specific enough to build a Python reference timing baseline
## Frequent Downstream Skills
- `anlogic-python-signal-pre-research`
- `anlogic-design`
- `anlogic-code-design`
- `anlogic-project-creation`
- `anlogic-timing-constraints`
## Default Flow
1. Clarify the functional target and system context.
2. Judge device, package, and major resource fit.
3. Judge interface capabilities and bottlenecks.
4. Form module partitioning, top-level architecture, and data flow.
5. Produce primitive/IP/wrapper guidance.
6. Decide whether the requirement has reached signal-and-timing granularity.
7. If yes, hand off to `anlogic-python-signal-pre-research` before `anlogic-code-design`.
8. If not, keep the task in this stage until the decomposition is complete.
## Mandatory Handoff Rule
When the requirement has already been decomposed into key signals, sequencing assumptions, time range, and sampling intent, do not jump directly into RTL. Hand off to `anlogic-python-signal-pre-research` first so the flow gets a saved reference-waveform baseline.
## Output Requirements
At minimum, output:
- recommended device or candidate devices
- key interface judgment
- rough internal resource budget
- module partitioning
- top-level architecture
- major data flow and control flow
- primitive / hard IP / wrapper / TD IP guidance for `anlogic-code-design`
- project-input guidance for `anlogic-project-creation`
- stage-routing guidance stating whether `anlogic-python-signal-pre-research` is now required
- fixed summary fields:
- `current_stage`
- `goal`
- `confirmed_constraints`
- `artifacts`
- `decision`
- `blocking_reason`
- `next_action`
## Routing Rules
- Requirement or board context is still unclear: stay in this skill
- Requirement is decomposed to signal timing and sequence level: hand off to `anlogic-python-signal-pre-research`
- Requirement is clear enough for orchestration decisions: coordinate with `anlogic-design`
- Only after the reference baseline is ready should the flow move into `anlogic-code-design`
## 2026-05-06 Rule: DDR Hard-IP Identity Lock
- For DDR-class projects, needs analysis must explicitly lock:
- board identity
- exact device and package
- DDR generation
- whether the DDR subsystem is hard-IP based
- If the DDR subsystem is hard-IP based, state explicitly whether DDR pins are expected to be defined by top-level hard-IP hookup rather than normal board ADC/SDC IO planning.
- Do not allow later stages to infer this from examples. Put it in the needs-analysis conclusion.
- If two boards use different hard-IP DDR generations or different device/package bindings, treat them as different platform baselines even when their surrounding benchmark structure looks similar.
View on GitHub