Maturity scale

M0 · Idea
Description, template or specification without usable RTL.
M1 · Prototype
Source exists, but no tests were found.
M2 · Simulation-tested
The repository contains tests or a testbench.
M3 · Board-proven
Confirmed board run or reproduced by FPGA.camp.
M4 · Production-ready
Tests, CI, releases and active development within the last year.

The level is derived automatically from the GitHub repository check. Sources outside GitHub stay at M1 until an editor confirms a board run. Editors can only lower the level.

Audience

Catalog readers, maintainers, reviewers, and FPGA engineers.

Beginner summary

Start from the source repository, license, maturity, verification evidence, and board or toolchain constraints before using the core.

Engineering details

Review interfaces, clocks, resets, bus protocols, parameters, test coverage, synthesis evidence, and known limitations as separate facts.

RAG chunking strategy

Chunk the page by task, evidence type, integration constraints, review checks, and source URLs so RAG answers can cite exact claims.

Common mistakes

  • - Treating tags, repository popularity, or package metadata as proof of quality.
  • - Mixing license, maturity, verification, and board compatibility into one vague score.
  • - Reusing a core before checking clock/reset assumptions, constraints, and reproducible commands.

Review questions

  • - Which exact source supports this claim?
  • - What evidence exists for simulation, synthesis, board use, or production use?
  • - What must be verified before this core is used in a composition or board project?

Relevant primary sources