Skip to main content

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.

Source facts

Repository
folsie/anlogic-fpga-workflow
Last source activity
May 9, 2026 at 05:11
Detected SKILL.md language
English
Stars
4
Forks
1

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
11 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
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