This is the canonical entry point for both human contributors and AI coding agents working on Vortex. It captures the rules — invariants, conventions, and footguns — that every change should respect. Build/test/debug recipes live in the topic docs linked below.
- docs/install_vortex.md — initial install + build setup
- docs/building_toolchain.md — building Verilator, RISC-V GNU, LLVM, compiler-rt, musl, POCL from source
- docs/environment_setup.md — environment variables and toolchain layout
- docs/fpga_setup.md — FPGA target setup
- docs/codebase.md — repo file-tree map
- docs/microarchitecture.md — pipeline & cache architecture
- docs/cache_subsystem.md — cache subsystem details
- docs/hardware_library.md —
hw/rtl/libs/reference
- docs/coding_guidelines_cpp.md — C++ style
- docs/coding_guidelines_verilog.md — Verilog/SystemVerilog style
- docs/simulation.md — driver modes (simx, rtlsim, opae, xrt) and blackbox usage
- docs/testing.md — test and regression flow
- docs/debugging.md — debug traces (
--debug), VCD, scope, trace_csv - docs/debug_mode.md — debug-mode hardware support
- docs/perfetto_analysis.md — Perfetto trace and analysis
- docs/synthesis_analysis.md — synthesis/PPA analysis
- CONTRIBUTING.md — public fork/PR contribution flow
- docs/bug_fixes.md — bug-fix discipline (root-cause vs patch)
- docs/continuous_integration.md — CI pipeline
- docs/proposals/ — design and migration proposals (drafts and in-progress)
- docs/designs/ — accepted designs (post-proposal, post-implementation)
See docs/install_vortex.md for the full recipe. The non-negotiable rules:
- Out-of-tree. From the repo root:
mkdir -p build && cd build ../configure --xlen=64 --tooldir=$HOME/tools # or --xlen=32 ./ci/toolchain_install.sh # first time only make -s
- Separate build dirs per major variant (
build32/,build64/,build_fpga64/, ...) to avoid config/tool contamination. Never reuse one build dir for incompatible configurations. configuregenerates a runnable tree by copying and instantiatingci/,runtime/,sim/, andtests/intobuild/. For execution and test automation, always prefer the generated scripts/Makefiles underbuild/over the source-tree.infiles.- Re-
../configurefrombuild/whenever yougit pull, edit source Makefiles, or add/remove a build-participating directory. Symptom of forgetting this: stale binaries, missing targets, or "I edited this Makefile and nothing happened." ccachecan serve stale objects onfmt-version mismatches (typical symptom:fmt::v8undefined-reference link errors in sim builds). Before deep-diving, retry withCCACHE_DISABLE=1.
See docs/bug_fixes.md for the full rationale and examples. The rules:
- Fix root causes, not symptoms. Diagnose before patching.
- Don't paper over upstream regressions or mask bugs with fallback paths and suppressed warnings.
- If a patch is genuinely unavoidable (e.g. blocked by an external dep), label it as a patch explicitly in the commit message and pair it with a follow-up to do the proper fix.
See docs/testing.md and docs/debugging.md for recipes. The rules:
- All test commands run from
build/. The generatedci/scripts assume it. - 120-second timeout cap on every test invocation. No exceptions.
CONFIGSmust match on both sides.blackbox.shonly rebuilds the driver. If your test was compiled with-DVX_CFG_NUM_THREADS=4, blackbox can't fix that — rebuild the app first:make -C tests/regression/<app> clean CONFIGS="-DVX_CFG_NUM_THREADS=8 -DVX_CFG_EXT_TCU_ENABLE" make -C tests/regression/<app> CONFIGS="-DVX_CFG_EXT_TCU_ENABLE" ./ci/blackbox.sh --driver=simx --app=<app> --threads=8
make tests/make -C tests/regressionbuild with default macros. UseCONFIGS+ explicit per-app rebuild for non-default configurations.--rebuild=1forces a driver rebuild even if the hardware configuration is unchanged. Use it when iterating on the driver itself;--rebuild=0suppresses rebuild regardless.- RTL coverage path is
xrt, notrtlsim. When discussing or planning RTL verification,xrtis the canonical path —rtlsimbypasses the AFU surface.rtlsimremains useful for fast iteration on processor RTL;xrtis what proves the full integration. ci/regression.shis the canonical source of tested configurations. Use it to discover supported parameter combinations before inventing ad hoc ones.- When RTL debugging stalls, switch to the SimX-as-oracle pattern. For numerical bugs, deep pipeline races, or any failure mode where rtlsim is "close but wrong": (1) build/extend the SimX C++ model so it mirrors the new RTL architecture and gets to PASS; (2) add matching trace dumps to both SimX and RTL (cycle, FU events, SRAM addresses+data, hazards) — same CSV format on both sides; (3) diff trace files — the first divergence is the bug. Don't keep guessing from output values; localize via trace diff. See docs/debugging.md.
./ci/blackbox.sh --driver=simx --app=demo
./ci/blackbox.sh --driver=simx --app=sgemm --args="-n10"make -C tests/regression run-simx
make -C tests/regression run-rtlsim
make -C tests/opencl run-simx
make -C tests/opencl run-rtlsimblackbox.sh exposes the common knobs directly: --clusters=, --cores=, --warps=, --threads=, --l2cache, --l3cache, --debug=, --perf=. For anything not exposed as a flag, use CONFIGS="-D..." (all parameters take the VX_CFG_* prefix — e.g. -DVX_CFG_NUM_THREADS=8, -DVX_CFG_EXT_TCU_ENABLE). Baseline parameters live in VX_config.toml and VX_types.toml at the repo root — edit those only when an override is needed for all builds, and re-configure afterward.
- Align with mainstream CUDA, HIP, OpenCL, and Vulkan API and driver stacks. For any design question — driver surface, command-processor model, memory model, scheduling — pick the solution those stacks would use. This keeps Vortex's externals familiar to mainstream software and avoids one-off abstractions.
See docs/coding_guidelines_cpp.md and docs/coding_guidelines_verilog.md for full style. Cross-cutting comment rules:
sw/{kernel,runtime}/andsim//hw/are bidirectionally isolated. Source files undersw/kernel/andsw/runtime/MUST NOT reference anything inhw/*orsim/*. Equally, source files undersim/*andhw/*MUST NOT reference anything insw/kernel/orsw/runtime/. If the layers genuinely need to share host-side helper code or an on-wire ABI definition, put it insw/common/— vortex-internal, never installed, accessible from all four layers. Enforced by ci/check_sw_sim_boundary.sh.- Default to no comment. Add one only when the why is non-obvious — a hidden constraint, a subtle invariant, a workaround for a specific bug, a surprising behavior.
- Comments explain why, not what. Well-named identifiers carry the what.
- Never reference the current task, PR, caller, issue number, or fix. Those belong in the commit message and rot in code. Don't write
// used by foo(),// added for the X flow,// handles issue #123. RTL_PKGSis forVX_*_pkg.svonly. Verilog interfaces are illegal there. If an interface isn't being discovered, fix it via include paths or file naming — not by stuffing it intoRTL_PKGS.- Library RTL defaults to
TRACING_OFF. Modules underhw/rtl/libs/are excluded from VCD by default to keep waveform size manageable. Toggle per-file withTRACING_ON/TRACING_OFF, or globally withCONFIGS="-DTRACING_ALL". - No multi-paragraph docstrings or multi-line block comments for trivial code. One short line is the ceiling unless the logic genuinely needs more.
- No
// removed codeor stale-rename breadcrumbs. If something is unused, delete it.
Design and migration proposals belong in docs/proposals/ — never in build dirs or the repo root. A proposal captures the why of a non-trivial change before the code lands.
Accepted designs that outlive their proposal phase live in docs/designs/.
This file is versioned alongside the code and evolves with it. Both humans and agents are expected to update it:
- Add a rule when you discover a footgun the next contributor will hit. Include the why.
- Update or remove a rule that's gone stale. A stale rule is worse than no rule.
- Don't duplicate content from the topic docs in
docs/. AGENTS.md links; the topic doc explains. - Branch-specific addenda are forbidden. Branch context goes in a
docs/proposals/<feature>_proposal.md, not in branch-localAGENTS.mdvariants. If the rule is general, promote it here; if it's a project-tracking detail, keep it in the proposal.