anlogic-needs-analysis

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.