Contributor guide
Contribute to the Altifigence™ development flow.
Altifigence™ work spans docs, RTL, Lab tools, and the SystemVerilog IDE. Contributions should focus on small reproducible changes and validation records.
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 labeled 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.
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.
Contribution records
Review notes can include commands, logs, reports, screenshots, board setup, commit SHAs, model configuration, test input, and CI runs when those records help reviewers. Link relevant records from the issue, pull request, or documentation page.
Keep contribution notes focused on source changes, validation records, and documented review steps.
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.