# Anlogic Needs Analysis

> 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.

- Skill: `folsie/anlogic-needs-analysis` (Agent Skill, multi-file: 11 files)
- Install (CLI): `npx skillmds@latest add folsie/anlogic-needs-analysis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/folsie/anlogic-needs-analysis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: folsie (https://skillmd.com/u/folsie)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/folsie/anlogic-needs-analysis

---


# 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.