How to bring printf support in simulation environment ?

[isaar-ahmad]

Is there an existing CVA6 bug for this?

• I have searched the existing bug issues

Bug Description

Hi,
I found that there has been recent discussion (May 2024 - July 2024) regarding printf statement support in CVA6 simulations (see #2103 #2184 #2220 ). It seems that CVA6 simulation environment, in its current form (e.g. with Verilator), doesn't support this.

For example, Dhrystone C files [1] have debug_print statements in them. To a newcomer, this would give an initial impression that these prints should be visible somewhere in the logfiles or console output. However, a closer inspection reveals that the implementation of debug_print() function is empty. In development stage, it is common in bare-metal environments to disable print statements, so that other parts of the test can pass through.

That being said, printf statements are useful in debugging, especially when the target under debug is a CPU itself. (I only speak for myself, based on my experience with RTL verification of ARM CPUs, and some RISC-V CPUs as well).

Please advise on this :

1. Is there any ongoing (or planned) development for C print statements ? If yes, where can we find details regarding this ?
2. What parts of the testbench and RTL files will need major changes, if such an update is planned?

Thanks,
Isaar

Code reference :
[1] Dhrystone source files (dhrystone_main.c and dhrystone.c) : Fetched by install-riscv-tests.sh

[JeanRochCoulon]

Indeed this feature is highly requested. But as you know it is not supported. The solution would be to support pk which provides the print feature. If someone is ready to work on it, we can provide recommendations.

[isaar-ahmad]

Yes, please share a plan (or an outline) for the required functionality. That would be helpful in assessing whether someone (e.g. myself) can take up the task.

[JeanRochCoulon]

@valentinThomazic the floor is yours to explain how to proceed ;-)

[valentinThomazic]

Hey sorry for the delay, the riscv proxy kernel used to be supported in this repo (I can give some directions if needed).
For it to be supported again, we would need it to be cleanly integrated to the flow.
It should be possible to activate it with an env variable or a parameter for instance.
The difficulty would come from the complexity of the cva6.py script, the verif/sim/Makefile and ./Makefile, we really don't want to add more.

[jason23g]

Hello @valentinThomazic, @JeanRochCoulon ,

Could you please give some directions to be able to support riscv proxy kernel in the current environment of cva6. I tried to install riscv pk from the corresponding repository of riscv but when i run the executable of Variane_testharness along with the proxy kernel and the desirable executable ( in my case an elf file of hello world in order to see the print happening in my terminal) all i get is an Assertion Failed "ariane_testharness.sv:671: Assertion failed in TOP.ariane_testharness.p_assert: B Response Errored". In addition i would like to ask if the riscv proxy kernel after it had been built will it support to run in spike tandem mode ?

Thanks in advance for your time

[isaar-ahmad]

Hi @JeanRochCoulon @valentinThomazic . Apologies for the delayed response.
I have some time over the next few weeks and can contribute if there is clarity on the following :

1. The requirement of 'clean integration' : Apart from activation through an env variable/parameter, what more are your requirements for a 'clean' integration ?
2. Scope of changes required : What modules/folders will need to be touched?
3. How was it integrated previously ? Is there any old branch/commit that provides this detail ?
4. More details on the challenges of cva6.py script and makeflow

The answer to the above questions will help in planning out the work, and possibly lead to a clean pull request, with minimal rework required. Please respond. I am available to discuss in further detail.

Thanks in advance

Thanks

[valentinThomazic]

Hey @jason23g,

You may have a compilation options issue. For instance if you are trying to run the pk on one of the 32 bits configuration of the CVA6, were the pk and the hello_world compiled for 32 bits ?

This may help you : #1358 (comment) as it will work on the Makefile default's configuration. Please note that we will not provide support for using make verilate command flow. This is given only for testing and potential integration into the current flow.

[jason23g]

Hello @valentinThomazic ,

The pk and the hello world were compiled for 64 bits with the flow of the comment you gave in #1358 and it worked . Could you please give some directions to be able to support riscv proxy kernel in the current environment of cva6 and can be run in spike tandem mode.

Thanks in advance for your time

[valentinThomazic]

Hey @isaar-ahmad and @jason23g

1&4 => If you take a look at cva6.py you can see that there are some flaws. For instance, there are 3 functions to run directed tests depending on the extension of the program to run which are basically copy pasted from each others. Because of that, redundant work is sometime needed and it is the cause of issues and errors. IIRC some functionnalities are broken like running several programs from a directory.
Also the simulation flow is quite complex : simulations are ran through cva6.py which uses verif/sim/Makefile which uses ./Makefile.

I am not asking you to clear and refactor cva6.py or the simulation flow but it is just to explain that when I was talking about integrating the functionality cleanly I was asking you to be precautious with the added complexity.

2 => You will probably need to change cva6.py, verif/sim/Makefile and ./Makefile.

3 => This is how it would have been done previously : #1358 (comment), pk was dropped with : #1663 but the instructions were already broken so you should take a look at the issue comment instead. Basically the compilation and the pk and the program were done manually, it would need to be automated:

1. The user enable an env variable (a cva6.py arg could also be used)
2. A simulation is run by the user (with cva6.py)
3. The pk and the program are compiled for the configuration on which the simulation is run
4. Both the pk executable and the program are passed to the simulator

This should work for all configurations and simulators combination and if possible with Spike Tandem.

Hope this helps.