Search the Community
Showing results for tags 'ncsim'.
Found 2 results
Hi, While running simulation , i am getting the below mentioned error . Can anyone help me to fix this error. ncsim: *E,IMPDLL: Unable to load the implicit shared object. OSDLERROR: /prj/.../v/_sv_export.so: failed to map segment from shared object: Operation not permitted. ncsim: *W,LIBRUN: Could not load the dynamic library: ./INCA_libs/irun.lnx86.13.10.nc/librun System ERROR: ./INCA_libs/irun.lnx86.13.10.nc/librun.so: failed to map segment from shared object: Operation not permitted. ncsim: *F,NOFDPI: Function main not found in any of the shared object specified with -SV_LIB switchncsim: *E,IMPDLL: Unable to load the implicit shared object. Thanks Sidharth
ljepson74 posted a topic in UVM SystemVerilog DiscussionsWhile I am waiting for an answer from the simulator vendor, I think I can form a non-tool-specific question about my problem. I am running a simulation which dies when I collect functional coverage. I can turn on/off functional coverage collection and when it is on, at the very end of simulation, I get: "ncsim: *F,INTERR: INTERNAL EXCEPTION". It seems to be that while coverage is gathered, the problem occurs. I can run tests which flow thru some channels of the dut and don't have the problem, but thru a specific channel of the dut, I often encounter the problem. question1: What is classified as functional coverage? I'd like to leave functional coverage collection on and comment out all coverpoints/covergroups. (Actually I think I have, or am close, and the error still occurs.) So, I am wondering, what must I grep for to remove to be sure that functional coverage collection has no meaning? My thought is to divide and conquer. Am I not just looking for "coverpoint" and "covergroup", but also "assert" (as some code might have assertion based functional coverage)? Is there anything else? question2: (This is perhaps a bit tool specific.) If the -covdut, or scope of where coverage should be gathered is targetted to a sub-sub-module, would you expect that (possibly bad) coverage code at a higher level (or different area) would have zero affect on the coverage collection? (I've unsuccessfully tried to leave functional coverage collection on, but to move the target-scope to a trival part of the design, to see if the problem goes away.)