Looking for RISC-V Verilog implementation with test-bench and tests

5,448 views
Skip to first unread message

Jamil Mazzawi

unread,
Aug 31, 2018, 5:33:03 PM8/31/18
to RISC-V HW Dev
hi guys,

We are looking for RISC-V implementation in Verilog that has complete testbench and a few sample tests (or differnet SW examples)

Which implementation would you recommend and consider it to have good test-bench? and why?
(the testbanch can be in any language)

thanks
Jamil

iztok.jeras

unread,
Sep 3, 2018, 2:30:37 PM9/3/18
to RISC-V HW Dev
Hi Jamil,

I am also recently looking for RISC-V test environments, in my case for SystemVerilog RTL, and with focus on open source tools. For now I am focusing on testing the base ISA.
I would be glad if you could post your progress.

The main list of implementations is here, but there are few details provided: https://riscv.org/risc-v-cores/
It is possible commercial implementations lack a testbench, as it is usually only provided to paying customers.

I was looking at the next cores:

Pulp platform, should provide a good bench although I did not look into bench details yet.






I plan to use Verilator for simulations due to its great SystemVerilog support, but it only supports RTL code, so tests have to be written mostly in C++ or SystemC.

I would also like to use a simulator with an API, so I could run the simulation instruction by instruction, and each time check the internal state (GPR, PC, CSR) against the simulator.

Regards,
Iztok Jeras

Jamil Mazzawi

unread,
Sep 4, 2018, 11:09:11 AM9/4/18
to RISC-V HW Dev
thanks for the pointers Iztok!
So far we got a few recommendations for the "Rocket-Chip", but has not tried it yet.
We need Verilog, not SystemVerilog.
I was told the Rcoket Chip is written in Chisel, which can be translated |(freely) to Verilog RTL (not sure about SV).
I was told it has good testbench...
Here is a pointer:

https://github.com/freechipsproject/rocket-chip#fpga

BTW, how is your experience with Verilator? How does it compare to commercial simulators?
Does it support all languages? API? etc?


thanks
Jamil

Dr Jonathan Kimmitt

unread,
Sep 4, 2018, 11:40:38 AM9/4/18
to Jamil Mazzawi, RISC-V HW Dev
The Rocket Verilog output of the Chisel compiler is not intended for reading or modification, it is primarily structural level and contains many anonymous nets. It can certainly be read and simulated by newer versions of Verilator. An approach of arbitrary initialisation of registers is taken which has advantages (no X flooding in simulation) and disadvantages (weird and inconsistent startup values in simulation results). By default the ISA tests use the debug port to load programs which has a simulation performance impact. There are no release branches.

Translation from Chisel is via an intermediate language FIRRTL which could also convert to much nicer looking SV, but I am not aware of anybody working on this.

Sent from my iPhone
--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.
To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/d2586495-51b1-4be5-ae4e-ecf49de022c3%40groups.riscv.org.

iztok.jeras

unread,
Sep 4, 2018, 3:27:48 PM9/4/18
to RISC-V HW Dev
Hi Jamil,

I mentioned SystemVerilog (SV) because some of the projects listed are written in SV and some in plain Verilog.
You need tools with SV support for SV code, simulator for bench code and synthesis for RTL.
Both Intel/Altera and Xilinx latest FPGA tools support SV well, and professional tools (Cadence, Synopsys, ...) also.
Open source tools less so.
Verilator has good SV support but is not really a normal simulator,
nevertheless a great RTL simulator and used by many projects mainly because it is fast and free.
Icarus Verilog has some SV support, I am nut sure how good are the latest versions.

Regarding the CPU choice, I would recommend the Pulp platform (it uses SV).
They provide 3 32bit cores of different performance ranges for micro-controllers and a 64bit Linux capable core.
The 32bit cores are rather popular, with publicly known users in the industry (they also provided feedback with fixes for upstream).
The two universities involved also seem to have created a strong community around the project.

Regards,
Iztok Jeras

lk...@lkcl.net

unread,
Nov 29, 2018, 12:31:10 AM11/29/18
to RISC-V HW Dev


On Friday, August 31, 2018 at 10:33:03 PM UTC+1, Jamil Mazzawi wrote:
hi guys,

We are looking for RISC-V implementation in Verilog that has complete testbench and a few sample tests (or differnet SW examples)

Which implementation would you recommend and consider it to have good test-bench? and why?

apologies for the delayed reply: i've only just started investigating how to run the riscv-tests in an iverilog simulated design.

the approach taken by picorv32 is illustrated at the following lines:

so there are two "special" (arbitrarily-chosen) memory locations, reserved effectively as memory-mapped GPIO.  0x10000000 is as a "print" statement, and 0x20000000 is as a successful "exit simulation" indicator (only if the value 123456789 is written to it).

in riscv_test.h (and in many other places) each ASCII letter that is desired to be communicated to the "outside world" is written, one at a time, to the address 0x10000000.  in the testbench.v code, this memory write is detected and handled by simply calling $display(data).

it really could not be simpler or more straightforward.

all that is needed is to not get hung up on modifying the calling conventions of the unit test suite, in this case choosing to replace the riscv_tests.h macros with something slightly different from what has been "supplied".  what's normally supplied with the riscv-tests is a call to the SBI to write chars to the console.  in picorv32, the decision was made to instead write to the address 0x10000000, and to take complete copies of the relevant riscv-tests unit tests source code.

l.

Matthew Ballance

unread,
Nov 29, 2018, 1:14:08 AM11/29/18
to lk...@lkcl.net, hw-...@groups.riscv.org
Thought I'd throw an alternative approach into the mix...

I used the Googletest framework (https://github.com/abseil/googletest) with Verilator as a testbench for the RISC-V soft core I created for the 2018 contest (https://riscv.org/2018contest/). My background is with SystemVerilog and UVM, and I found the Googletest framework pretty easy to use. You can have a look the code here if you're interested:

Post-contest, I'm investigating whether the Googletest approach scales to other simulators besides Verilator -- in other words, can I have the same testbench run with Verilator, Icarus, Modelsim, etc.

Best Regards,
Matthew



--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.
To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.

Dr Jonathan Kimmitt

unread,
Nov 29, 2018, 1:42:52 AM11/29/18
to hw-...@groups.riscv.org

This is something that has puzzled me with RISCV from the beginning. Rocket has a similar limitation (of relying on fixed arbitrary addresses) for it's HTIF interface. This results in counter-intuitive coding in the simulator to search for these special addresses in the symbol table. Maybe I'm being stupid here but why wasn't the approach taken of dedicating a couple of control and status registers (CSRs) in the core of the processor for a built-in UART or simulation equivalent ?

This would obviously make code a lot more portable so perhaps there were patent concerns with the way a certain RISC company does it ?

puls...@pulserain.com

unread,
Nov 29, 2018, 2:33:17 PM11/29/18
to RISC-V HW Dev
Probably you can try this core. (verilog 2001)


This core is also in the 2018 RISC-V Soft CPU contest. It works on both Lattice UP5K and Microsemi Smarfusion2 devices. And it supports compliance test with verilator. Zephyr embedded OS is also supported.

Christopher Celio

unread,
Nov 29, 2018, 5:25:26 PM11/29/18
to jr...@cam.ac.uk, hw-...@groups.riscv.org
I"m sure others can/will correct me, but as I recall, early Rocket/riscv-tests used to use tohost/fromhost CSRs ("ye olde CSR-based HTIF"). This is fine for very simple systems and non-synthesizable stuff, but once you try to build a real system (including one with multiple cores and domains) using magic CSRs to punch out to the host becomes less attractive. 

-Chris


Reply all
Reply to author
Forward
0 new messages