wyvernSemi/vproc

Need more infomation at README

Closed this issue · 11 comments

I have problem when make all. The project reports an error that many .c and .h files are missing. Can you commit all file to repo ?

There is much more information in the manual in the doc/ folder including required prerequisites. Please provide more specific information on exactly what errors are reported, which platform you are running on and which simulator you are targeting.

Thank you for your reply. I build Vproc with make all command then make run (for Model Sim), at Centos 7 OS.This is log when make run :
image_2024_01_05T10_09_04_156Z

Can you check this ?

It is complaining that the VProc.so shared object is a 32-bit compiled shared object. This is required if running ModelSim since this is a 32-bit application. Are you sure you are not running QuestaSim, which is a 64-bit application? You can get the make file to compile for 64-bits with: make ARCHFLAG=-m64 run. You will need to do a make clean first to remove all the 32-bit object files you have compiled already. Note that it is not necessary to do separate make and make run steps, as the make run command will compile everything necessary. If running QuestaSim is the issue, then you can, if you wish, permanently update ARCHFLAG in the makefile to be set to -m64, and thenmake run will work without additional command line arguments.

tks u for your reply. I used Questa for compile, after using make ARCHFLAG=-m64 run, the issue has resolved. But there are some new issue :
image
Now I can continue debugging, but it would be better if you give me a few more suggestions :D

Are there any other warnings or errors? You have only shown me a partial log. If you can save the whole output to a text file, this can be attached to a comment. Do a make clean first so that all warnings will be present when compiled and run, then do a make run 2>&1 | tee sim.log and then attach this sim.log file to a comment

The partial log indicates that something is wrong connecting the Verilog system tasks to the C code, and a prior warning may give a clue.

The log is in attachment. There are some warning above. Can you take a look ?
sim.log

The log suggests that the pointers for the PLI C functions are not the right type for the table which associates them with the system tasks, which is why these aren't defined when the simulation is run, which implies a compilation problem. What versions of gcc (gcc --version) and CentOS (cat /etc/redhat-release) are you running? Less likely an issue, but what version of QuestaSim are you running as well? My setup uses gcc 4.8.5 with CentOS 7.9.2000, and QuestaSim 21.1.

I should say that I have now run this simulation on QuestaSim under CentOS with no problem. VProc is usually tested under Ubuntu (for Linux) and with much later gcc versions, but since I've now run it successfully on CentOS with an earlier version of gcc it seems that I'm unlikely to be able to reproduce the problem that you are seeing. So I'm not sure where to go from here. It is now the weekend and I have other things to attend to, so I can't guarantee I will be able to get back to this until Monday.

My setup uses gcc 4.8.5 with CentOS 7.9.2000, and QuestaSim 10.7e. Thank you for your help, Have a nice weekend !!

At the moment, I can't get my simulation to fail, even if I change the prototypes of my PLI functions (thinking that would give the warnings about incompatible pointers). I did try casting the pointers in the veriusertfs table to be (an incorrect)char*, and this did give the same warnings. However, the simulation still ran correctly. The VProc code doesn't use any of the parameters passed in to the PLI functions, so it shouldn't matter what the prototypes for these functions are---and that is what I see. So I'm not sure that these warning are indicating an issue, especially as your log would suggest that the VInit function was run. But it is a difference that I can't yet explain.

I do have a different Questa simulator as I use that which is bundled with the Intel/Altera Quartus FPGA tools. The place where the type for the pointer to the PLI functions is defined veriuser.h that's in the tool. In my installation this is in <questa installation directory>/include/veriuser.h. Is it possible for you to send me this file from your installation? I can then see if the definitions for these PLI function types are any different. I don't have much hope, as the definitions should be part of the Verilog standard, and I can't get a failure, even if a force the warnings.

Please assure me, though, that the vproc repository you are running with is a clean and unmodified checkout (apart from the -m64 change we discussed), and there have been no other modifications?

When first time I build Vproc, log report missing some .h file, like this :
In file included from code/VUser.h:28:0,
from usercode/VUserMain0.c:9:
code/VSched_pli.h:29:22: fatal error: veriuser.h: No such file or directory
#include "veriuser.h"

Then I copy from other place. It seems cause Error. I clean all then copy some missing file from /include/ , It seems the problem has been resolved. Thank you for your support !!

You shouldn't really need to do this. If your environment for QuestaSim is set up correctly, then an environment variable MODEL_TECH should be defined, and the VProc makefile uses this to locate veriuser.h in the simulator's include/ directory. For example, my MODEL_TECH environment variable is set up as:

/opt/altera/21.1/questa_fse/linux_x86_64

Your installation path will be different, but this variable should point to the directory that contains the libraries (such as libmtipli.so) and vsim and the other command executables. If you set this environment variable, then the makefile will pick up the header file directly from the Questa installation---though if you're happy with what you have, then that is fine as well.