R_C1363912821 Posted April 11, 2011 Report Share Posted April 11, 2011 Hi All, Internal prints from UVM library are not in Sync with other prints. e.g. the UVM_ERROR print in log below (For Questa 10.0a running on windows) is out of sync as it displays the complete path of file from which print comes (that too without '/'): # UVM_ERROR C:Users # RCDocumentsUVMuvmsrc/base/uvm_phases.svh(1860) @ 1000: reporter [PH_TIMEOUT] Phase timeout of 1000 hit, phase 'run' ready to end # UVM_WARNING @ 1000: run [OBJTN_CLEAR] Object 'common.run' cleared objection counts for run Is there to way to modify the display so that all prints look alike. Thanks, RC Quote Link to comment Share on other sites More sharing options...
jadec Posted April 18, 2011 Report Share Posted April 18, 2011 If you have C code, printing directly to the console or standard error. You could modify it to call a dpi exported SV function and print those messages through UVM as well. This would fix the synchronization and allow you to take advantage of filtering and counting in UVM. Quote Link to comment Share on other sites More sharing options...
R_C1363912821 Posted April 18, 2011 Author Report Share Posted April 18, 2011 Jadec, can you please provide example or steps required for this? Quote Link to comment Share on other sites More sharing options...
jadec Posted April 18, 2011 Report Share Posted April 18, 2011 package my_pkg; import uvm_pkg::*; `include "uvm_macros.svh" import "DPI-C" context function void c_hello(); export "DPI-C" function my_uvm_report_info; function void my_uvm_report_info( string src, string msg, int line=0, string file="" ); uvm_report_info( src, msg, line, file ); endfunction endpackage #include "svdpi.h" void c_hello() { my_uvm_report_info( "c_hello", "Hello World!", __LINE__, __FILE__ ); } Calling c_hello from UVM gives: UVM_INFO @ 0: reporter [RNTST] Running test my_test... UVM_INFO /export/home/jadec/test/uvm/dpi_msg/c_hello.c(0) @ 0: reporter [c_hello] Hello World! UVM_INFO @ 0: uvm_test_done [TEST_DONE] All end_of_test objections have been dropped. Calling global_stop_request() Quote Link to comment Share on other sites More sharing options...
R_C1363912821 Posted April 20, 2011 Author Report Share Posted April 20, 2011 Hi Jadec, Thanks for providing the example, the issue is that i dont have a C compiler so i get error "# ** Fatal: (vsim-7019) Can't locate a C compiler for compilation of DPI export tasks/functions." is there any other solution? Quote Link to comment Share on other sites More sharing options...
jadec Posted April 20, 2011 Report Share Posted April 20, 2011 The assumption was that you were already using DPI. What are you doing that generates those other non-UVM messages? Quote Link to comment Share on other sites More sharing options...
R_C1363912821 Posted April 20, 2011 Author Report Share Posted April 20, 2011 There is nothing like non UVM, the prints that are out of sync are from the UVM library # UVM_ERROR C:Users # RCDocumentsUVMuvmsrc/base/uvm_phases.svh(1860) @ 1000: reporter [PH_TIMEOUT] Phase timeout of 1000 hit, phase 'run' ready to end The issue is that it does not display the path properly (i.e. path is without '/') Quote Link to comment Share on other sites More sharing options...
jadec Posted April 20, 2011 Report Share Posted April 20, 2011 So the problem is just that filename in your UVM messages is incorrect? One possible issue is that backslashes(\) may be handled incorrectly. Quote Link to comment Share on other sites More sharing options...
R_C1363912821 Posted April 20, 2011 Author Report Share Posted April 20, 2011 yes thats the only problem. I am running simulation on windows (Questa 10.0a), can this be a reason? Quote Link to comment Share on other sites More sharing options...
jadec Posted April 20, 2011 Report Share Posted April 20, 2011 Windows uses backslashes for the path, but most tools will let you use forward slashes instead (which may provide a workaround). UVM internally just uses `__FILE__ macro so this is probably an issue with how the simulator handles the filename. You can also disable the filename display entirely using defines: UVM_REPORT_DISABLE_FILE_LINE or UVM_REPORT_DISABLE_FILE during UVM compile. Quote Link to comment Share on other sites More sharing options...
Bart Posted April 21, 2011 Report Share Posted April 21, 2011 Hi R_C Seems like a possible bug in the UVM report_server that can't handle windows path separators.. If jadec's option to exclude the filename is not sufficient, you could try replacing the default report server with a custom implementation. This would allow you to detect & convert any problematic data for the report print.. class custom_server extends uvm_report_server; static bit initialized = init(); static function bit init(); uvm_report_global_server glob = new; custom_server mysrv = new; glob.set_server(mysrv); endfunction virtual function string compose_message( uvm_severity severity, string name, string id, string message, string filename, int line); uvm_severity_type sev = uvm_severity_type'(severity); return { "# ", sev.name(), " (", filename, ") ", name, ": [", id, "]: ", message }; endfunction endclass Note that the static init() function is enough to set the mysrv instance of custom_server as the global report server. All reports will now use the compose_message() function to create a string to be used in the report. The code in this example is simple - take a look at the default implementation in uvm_report_server.svh under src/base for a better example - but you should be able to use basic string processing to get the output you need.. Quote Link to comment Share on other sites More sharing options...
jadec Posted April 21, 2011 Report Share Posted April 21, 2011 You can pass a filename directly to UVM: uvm_report_info( get_type_name(), "build", UVM_MEDIUM, "my\\bad\\nfile", 123 ); // NOTE: SV syntax requires escaping the backslash UVM prints it correctly: UVM_INFO my\bad\nfile(123) @ 0: uvm_test_top [my_test] build So the filename string is likely getting corrupted before that. Quote Link to comment Share on other sites More sharing options...
uwes Posted April 27, 2011 Report Share Posted April 27, 2011 hi, you need a c-compiler to use DPI (even on windows you can get gcc) and link the result into the simulator. Quote Link to comment Share on other sites More sharing options...
uwes Posted April 27, 2011 Report Share Posted April 27, 2011 yes thats the only problem. I am running simulation on windows (Questa 10.0a), can this be a reason? the issue is that in sv a backslash is a special character. the windows filename "c:\foo\some\name" is just "c:" + "\f" + "oo" + "\s" + "ome" +"\n" + "ame". which results only for "\n" in a line break the other escape like sequences are ignored (are just "f" "s"). module test78; initial $display("c:\foo\some\name"); endmodule ncsim> run c:foosome ame ncsim: *W,RNQUIE: Simulation is complete. btw: java for instance checks and allows only some characters to be prefixed by "\" Quote Link to comment Share on other sites More sharing options...
jadec Posted April 27, 2011 Report Share Posted April 27, 2011 But in this case UVM, isn't including the filename directly (nor is the user), it's using `__FILE__ macro. Special characters in the filename should be properly escaped so the resulting string is correct (especially ones common for the OS). Quote Link to comment Share on other sites More sharing options...
uwes Posted April 29, 2011 Report Share Posted April 29, 2011 so this finally boils down to a simulator issue and not to an UVM issue. as `__FILE__ and `__LINE__ are being defined by the compiler the compiler should take care of the correct string encoding on that platform. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.