ljepson74 Posted April 7, 2014 Report Posted April 7, 2014 What is the easiest way to get my simulation to die upon reaching the first UVM_ERROR? (I suppose the reporting class could be extended and overridden, or something like that, but if it gets too complicated (as this is not smthg I expect to do much), I'll just temporarily change the offending statements to `uvm_fatals....which is what I just did.) Is there a built-in switch or define that I can override at the command line? Quote
tudor.timi Posted April 7, 2014 Report Posted April 7, 2014 There is the +UVM_MAX_QUIT_COUNT plusarg which you can just set to 1. Leave your fatal errors for testbench internal issues and not for DUT errors. Quote
ljepson74 Posted April 7, 2014 Author Report Posted April 7, 2014 Tudor, you rock. Thanks a lot. I was just about to post this....so will anyway. ---- Before anyone spends time on this on, apologies for firing off a question which I barely did any research on. When I have time, I'll see if I can figure it out myself and post an answer here. Context: I was just doing research on a cronjob problem I have (those so often bite me). While looking into it, ran into this article. http://www.catb.org/esr/faqs/smart-questions.html I only skimmed it, but it's a nice read for anyone that spends time on forums. The guilt set in that I had just posted an unresearched question here a bit earlier. Booo ---- Tudor, why do you think that fatal errors should only be for testbench errors? Often, an egregious DUT error makes the remainder of the test worthless. Quote
tudor.timi Posted April 8, 2014 Report Posted April 8, 2014 I would rather have a clear separation of error messages by source. It's easier for someone new to a project to categorize a fail after doing some code changes. Seeing a UVM_FATAL means the testbench is not being used properly, while seeing a UVM_ERROR means you found a bug in the DUT. Depending on what you see you know what person to talk to (TB developer or designer). Specman/e has a clear differentiation when flagging errors: you have dut_errors for checks and asserts (not to be confused with SV asserts) for doing design by contract of your TB. Quote
David Black Posted April 10, 2014 Report Posted April 10, 2014 I don't believe anywhere it states that UVM_FATAL is for internal messages vs UVM_ERROR. Instead, I would assert you should use the tag to indicate "Internal". I believe the main idea between the severity's is that: UVM_INFO - informational/debug text to be used sparingly with appropriate verbosity (almost never UVM_NONE) UVM_WARNING - there is possibly an problem here, but not clear cut and must be interpreted UVM_ERROR - definitely an error, but processing may proceed to allow other errors to be seen UVM_FATAL - definitely an error and further simulation will with high probability produce garbage so exit is appropriate here Not all internal errors are any more certainly fatal than others, so I would use things like: if (internal_error1) `uvm_fatal("configuration - internal","Missing required connection to...") if (internal_error2) `uvm_error("option - internal", "Missing configuration value - defaulting") if (design_error) `uvm_error("configuration", "Invalid register configuration may impact data") if (fatal_power) `uvm_fatal("powerup", "Module failed to powerup") That said, you can limit error using the set_report_max_count (or equivalently +UVM_MAX_QUIT_COUNT as you indicated). Another approach would be to use uvm_report::set_report_severity_action_hier(), which has the advantage you can focus it to a particular part of the hierarchy. You can also use a uvm_report_catcher to reclassify messages, but I would use that as a last resort (e.g. when unable to modify the source code due to encryption or legalities). Shameless plug: We discuss all of this and more in the Doulos UVM Adopters class <http://doulos.com/content/training/systemverilog_uvm_adopter.php>. Quote
ljepson74 Posted April 16, 2014 Author Report Posted April 16, 2014 David, that was much more clearly stated than I had been thinking. re: Shameless plug, .... Doulos material is great. Two thumbs up. Tudor, I find, as I think many do, that the text in the message (tag or body) as opposed to the severity level is the way to go in terms of differentiating error origins. Then, any area of the system can create errors as well as system-stopping fatals. (Unfortunately, with regards to what text I put in which part of the messgae, I've had trouble finding a style that I like, and will stick with. Sometimes I want to filter messages from a certain object or method, somtimes by a certain data-flow which might involve sequences as well as multiple other objects. Invariably, I end up doing a bunch of grep-ing and sed-ing thru log files. But, I am getting a bit more consistent in my style. I'm curious to hear if anyone has settled on a style.) Quote
tudor.timi Posted April 17, 2014 Report Posted April 17, 2014 @David: We've basically been operating on the premise that if one thing in the TB goes wrong there is no point in simulating any further so we flagged a fatal error. Stuff with missing configuration values we just flagged as warnings, though errors are probably more appropriate since some people might just ignore warnings. @ljepson: I do like the idea of filtering based on tag and (maybe if required) body, especially for info messages. This is the kind of thing I usually do in Specman, where I can very easily set different verbosity levels on different hierarchies at run time. I haven't worked that much with UVM, but it seems the plusargs are more powerful than those for OVM w.r.t. setting the verbosity (or I just didn't use the OVM ones properly) and there is also vendor support for doing TCL based UVM sets on the simulator command line these days (something OVM didn't really have) so it's now definitely possible to do this easily in SV as well. What I also like to do for DUT checks is do an immediate assert that I can then tag in my vplan. This is probably a better way of separating TB errors from DUT errors, instead of severity. Thanks a lot for the great input, I'll definitely consider it for my next project! Quote
David Black Posted April 19, 2014 Report Posted April 19, 2014 @Tudor: Many times you are correct that if one thing goes wrong there may be no point in continuing; however, there are failures that are orthogonal to one another. Consider if you add some new IP with associated VIP. The tests in the VIP may reveal some other errors that have nothing to do with your own errors. Hence by letting the simulation go further, you can get twice the opportunity to debug errors. Of course you have to carefully discern this when reading the log file. I agree that many times the simplest approach is to fix one bug at a time. This is more true early in the design cycle of the project. As a product matures, mutiple errors may be worth allowing. This would be a good reason to use set_max_quit_count(). Use a value of 1 early on and relax it later in the project. Quote
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.