Contributor guide
Work in small, reviewable steps.
pccxai welcomes focused issues, documentation improvements, reproducible experiments, and carefully scoped code or RTL changes. The shared rule is simple: describe the boundary, show the evidence, and avoid unsupported release language.
Become a contributor
Start by reading the repository README and open issues. For a first change, prefer documentation fixes, small tests, narrow bug reports, or issues labelled for new contributors.
Open a discussion before starting non-trivial architecture, public API, release, security, or hardware-sensitive work. Maintainers own those decisions and need to align on scope before implementation starts.
Choose a repository
pccx
Use this for documentation, specification, roadmap, and release coordination changes.
pccx-FPGA-NPU-LLM-kv260
Use this for RTL, formal models, simulation flow, and hardware evidence.
pccx-lab
Use this for CLI/core analysis, trace tooling, verification workflow, and lab UI work.
pccx-llm-launcher
Use this for the local launcher scaffold and integration planning that depends on reviewed hardware evidence.
systemverilog-ide
Use this for editor diagnostics, xsim log integration, and SystemVerilog workflow support.
Issues and pull requests
Search existing issues and pull requests first. File one topic per issue, include the affected repository, and provide enough context for another contributor to reproduce or review the problem.
Pull requests should target main, stay focused,
link the related issue or discussion, and describe motivation,
approach, and verification. Avoid unrelated formatting, renames,
generated output, or repository setting changes in the same diff.
Do not report security findings in public issues. Use the organization security policy instead.
Documentation writing style
Write plainly. Prefer concrete nouns, current project status, command output, version identifiers, and links to source material. Separate what is implemented from what is planned.
Use cautious labels such as development preview, pre-stable, early scaffold, or host dry run when the work has not reached a reviewed release boundary. Avoid promotional phrasing and avoid turning targets into results.
Evidence rules and unsupported claims
Claims need evidence: commands, logs, reports, screenshots, board setup, commit SHA, model configuration, test input, or CI run, depending on the claim. Link the evidence from the issue, pull request, or documentation page.
Do not claim production readiness, stable API or ABI, KV260 inference, timing closure, bitstream readiness, measured throughput, or a tokens-per-second result without reviewed, reproducible evidence.
Code and RTL comment style
Comments should explain intent, invariants, interface boundaries, clock and reset assumptions, dataflow expectations, and non-obvious constraints. Do not narrate each line of code.
RTL comments should be especially careful around timing, handshake behavior, widths, reset state, and synthesis assumptions. If a value is temporary, name the TODO owner or issue. If a path is generated, make the source of generation clear.