Skip to content
Casuality5

Casuality5/Fresh-RISC-Processor

Other

Fresh-RISC-Processor

1 0SystemVerilogPush 2mo agoListed 11d agoNo license on GitHub

No GitHub topics on this repo.

  • SystemVerilog88.3%
  • Python11.7%
View on GitHub

Report a problem

1 Review

Fresh-RISC-Processor is a focused and interesting hardware project: a 5-stage pipelined RV32I core written in SystemVerilog, with the repository split cleanly into rtl, tb, and scripts. The README does a good job explaining the intent of the design: classic IF/ID/EX/MEM/WB staging, RV32I base integer support, and a verification flow that compares RTL retirement behavior against Spike. That verification angle is the strongest part of the project. For a small processor repo, having scripts/RV32_LOCKSTEP.py automate assembly compilation, ELF-to-memory conversion, Spike execution, Vivado simulation, and trace comparison shows much more seriousness than a waveform-only demo.

The RTL structure is also easy to follow. rtl/Top.sv wires the stage modules and pipeline registers in a way that mirrors the architecture described in the README, and rtl/Pkg.sv centralizes enums and packed bundles for control signals, immediates, ALU operations, branch types, load types, and stage payloads. That makes the design easier to inspect than a monolithic CPU file. The presence of a hazard unit, forwarding signals, branch flush/stall wiring, load/store handling, and a writeback trace interface suggests this is more than a minimal single-cycle teaching core.

The biggest improvement would be making the project reproducible for someone outside the author’s machine. The testbench writes to an absolute Windows path, and the Python script has hardcoded Vivado, WSL, desktop, and project paths such as C:/Users/creat/.... That is understandable during development, but it makes the otherwise strong verification story difficult for reviewers or contributors to run. A small config file, command-line arguments, or environment variables for Vivado paths, test names, memory paths, and output logs would make the project much more adoptable.

I’d also add a license, repository description/topics, and a short “how to run one verification test” section with required tools and expected output. There are no open issues and no CI workflow, which is normal for a young HDL project, but even a lightweight lint/syntax workflow or documented Vivado batch command would improve confidence. Overall, this is a compact but credible RISC-V processor project with a strong verification instinct; the next step is packaging that workflow so other people can reproduce the results without reverse-engineering the author’s local setup.

Casuality5
@Casuality59d ago

Will surely implement what you advised. Thanks