Issue when make run at verilog/test

[huy98no2]

Issue when make run at verilog/test

[huy98no2]

My environment is : Questa sim 10.7d, gcc 4.8.5 with CentOS 7.9.2000. Can you give me some suggestions?

[wyvernSemi]

If you look at the comment I added today on the issue you closed, you'll see a reference to MODEL_TECH requiring to be defined. Actually I have now updated makefile to set this if it isn't defined, to avoid this problem. If you get a clean vproc clone you will not need to have MODEL_TECH already setup. You will also need to remove any local copy of veriuser.h.

…

On Mon, 8 Jan 2024 at 10:18, huy98no2 ***@***.***> wrote: Hi Simon Southwell, I was able to execute the VProc example and had some problems with make run at *verilog/test* . The log is in attachment. Can you take a look ? there are some error like this : /usr/bin/ld: cannot find -lmtipli /usr/bin/ld: skipping incompatible ../../../vproc/libvproc.a when searching for -lvproc /usr/bin/ld: cannot find -lvproc collect2: error: ld returned 1 exit status make_run.log <https://github.com/wyvernSemi/pcievhost/files/13858684/make_run.log> — Reply to this email directly, view it on GitHub <#2>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFHTY33RLDGTKGMNEJKH7GDYNPBWBAVCNFSM6AAAAABBRGPAGOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA3TAMJTGQYDQMQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[huy98no2]

Thank you for your reply. I just checked that comment and deleted define MODEL_TECH in makefile, and now the log file reports that :

/usr/bin/ld: ../../lib/libpcievhost.a(codec.o): relocation R_X86_64_32S against .bss' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: ../../lib/libpcievhost.a(mem.o): relocation R_X86_64_32S against .bss' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: ../../lib/libpcievhost.a(pcie.o): relocation R_X86_64_32 against .rodata' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: ../../lib/libpcievhost.a(pcie_utils.o): relocation R_X86_64_32 against .rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: ../../lib/libpcievhost.a(ltssm.o): relocation R_X86_64_32S against .data' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: ../../lib/libpcievhost.a(veriuser.o): relocation R_X86_64_32 against symbol veriusertfs' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make: *** [VProc.so] Error 1

Can you give me some suggestions ?

[wyvernSemi]

I'm sorry, it is not clear what you have done. You should not have modified makefile at all, or any other files. If you have then revert them. If you've copied any files from elsewhere, remove them. Better still, move your current clone of vproc to a new name/place and check out a new vproc repository. Then run make clean && make ARCHFLAG=-m64 run 2>&1 | tee sim.log Send me the sim.log file and also, if this still gives issues, do echo $MODEL_TECH and let me know what this is set to (if anything).

…

On Mon, 8 Jan 2024 at 10:53, huy98no2 ***@***.***> wrote: Thank you for your reply. I just checked that comment and deleted define MODEL_TECH in makefile, and now the log file reports that : /usr/bin/ld: ../../lib/libpcievhost.a(codec.o): relocation R_X86_64_32S against .bss' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: ../../lib/libpcievhost.a(mem.o): relocation R_X86_64_32S against .bss' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: ../../lib/libpcievhost.a(pcie.o): relocation R_X86_64_32 against .rodata' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: ../../lib/libpcievhost.a(pcie_utils.o): relocation R_X86_64_32 against .rodata' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: ../../lib/libpcievhost.a(ltssm.o): relocation R_X86_64_32S against .data' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: ../../lib/libpcievhost.a(veriuser.o): relocation R_X86_64_32 against symbol veriusertfs' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status make: *** [VProc.so] Error 1 Can you give me some suggestions ? — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFHTY3Y7HWU72CSJT6HZBVDYNPFZHAVCNFSM6AAAAABBRGPAGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBQG43TGNBQGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[huy98no2]

For some reason, my PC with internet does not install questasim, and my PC with internet does not install questasim; Therefore, I had to copy it manually and caused some unexpected errors. I will continue debugging, thanks for your suggestion :D

[huy98no2]

The problem has been resolved. I edited a few paths in test.vc (../../VProc -> ../../vproc ) and added -fPIC in CFLAGS in the makefile at verilog/test

[wyvernSemi]

Not all the makefiles for pcievhost have ARCHFLAG defined (all the makefile are for the 32-bit ModelSim). Shouldn't need to change test.vc though---works for me under CentOS---but I will update this to broaden compatibility. The -fPIC isn't needed under Ubuntu (the supported Linux platform), so things must be different for CentOS (which pcievhost is not regularly tested under). The redefinition warnings aren't generated either on Ubuntu, but I will add this in anycase, as it doesn't break the compilation for other platforms. I will be updating the makefiles to all have ARCHFLAG, like vproc, and also add a Questa wrapper makefile so the user doesn't require to set variables like ARCHFLAG on the command line.

[huy98no2]

Thank you for your enthusiastic support. Do you plan to do Gen3 PCIe ?

[wyvernSemi]

I have no plans for PCIe Gen3 (or beyond) at this time, though I did look into it some time back. The main difference would be to use 128b/130b encoding in place of 8b/10b, and I did have an idea to have thirteen 10-bit words per 130-bit codeword so that the current ports on the component remain unchanged. I just haven't get around to it, and have no means of verifying it---the original was used to drive an endpoint design which then was verified and worked on platform, so the model has been confirmed as it stands. It is low priority for me at the moment, so don't expect to see anything soon.