KB cores/coresRAG chunking

How to write a core manifest

How to write a core manifest guidance for /cores users: evaluate source evidence, risk, integration constraints, and review status before reuse.

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