New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add more vpi features #588
Comments
Original Redmine Comment Great work! Here's my feedback:
|
Original Redmine Comment Ok, I think I've updated all of that. One remaining issue is the use of vl_fatal in vpi_unsupported. Whilst I can see the value of terminating execution immediately when there has been a vpi programming issue I don't believe you want to do it all the time plus the vpi spec doesn't say to do that anyway. It is long winded to have to write a vpiPLIError callback to reimplement this behaviour so I propose something like
of course, it doesn't have to be a cpp condition, it could be on by default etc. Let me know how you'd like it done. Anyway I need to finish deprecating _VL_VPI_UNIMP and would like to add vpiBinStrVal & friends before submitting patch. I'll need to extend the t_vpi_val testcase further and perhaps add a new one to check the unsupported stuff says it's unsupported? This will also test cbPLIError and vpi_chk_error. Need to test vpi_get_vlog_info somewhere too. |
Original Redmine Comment Either way we might as well do it at runtime rather than compile time as it also allows someone to turn on/off the assertion for just one call if they so desire. Please add a new 'class Verilated' member variable and method for this. Should abort on unsupported be the default or not? I suspect most people are lazy programmers and don't check for errors so lean towards forcing people to set the flag in their code and so know what they're signing up for. |
Original Redmine Comment The abort defaults to on - to keep the old behaviour. I've added a new testcase t_vpi_unimpl for the unimplemented errors and extended t_vpi_var to test the put/get string values. The test is a bit contrived but it did find a few issues I've subsequently fixed. Two things - firstly I notice that the existing put/get code doesn't mask off any upper bits that may be unused by the underlying verilog object, so it is possible to store more bits than actually exist (via vpi put/get). The vpi*Str code does ignore these bits apart from vpiDecStr which doesn't. Does this difference matter? It's trivial to add if we think it's a good idea. Secondly vpiDecStr is only supported to a maximum of 64 bits because it uses sprintf/sscanf and "%u", I think this is upper limit is a realistic bound to how it will be used - I personally would use hex (or binary) format for > 64 bits. Also there are multiple "out" buffers for each of the different vpi_get_value formats - shall we coalesce them into one? You can pull these changes thus ```git pull https://github.com/rporter/verilator.git vpi-features
|
Original Redmine Comment The code should mask off bits in "put" that are not implemented, you'll get very odd results if those bits ever are non-zero as Verilator optimizes some of them as always being zero. "get" can assume they are zero in the interior model. Yes %d is 64 bits out of laziness (er, efficiency). No one has noticed yet, but you're welcome to fix it. I probably would merge "out", helps the dcache. I'll wait for an update before merging unless you think it'll be a while. Some little notes all minor, in general looks great.
|
Original Redmine Comment I've added masking logic to all the vpi_put_value types including the original vpiVectorVal and vpiIntVal which didn't have it either. I've left vpiDecStr at 64 bits max, trying to use a bigger number results in value of -1 and sets all the bits. I would be interested to know what the commercial simulators do, can they use decimal representations > 64 bits? I might have tried harder if there was a standard library that supported arbitrary length integers. Merged "out" into a single buffer, sized for vpiBinStrVal which is the biggest (in char size) representation. Addressed each of the review comments - hopefully acceptable fixes. There were 'issues' with the string enumerations too - added some test coverage in t_vpi_var. Committed & pushed to github. |
Original Redmine Comment Great! Only a few trivial space & compiler warning cleanups. Pushed to git towards 3.845. |
Original Redmine Comment In 3.845. |
Original Redmine Comment Rich, please look at #�, thanks. (Can't forward bugs in this web tool.) |
Author Name: Rich Porter
Original Redmine Issue: 588 from https://www.veripool.org
Original Date: 2012-12-15
Original Assignee: Rich Porter
Hi Wilson,
As mentioned I've added a few more features to the vpi.
Can you review the deltas here please? It's not all there yet but I'd like some feedback on the style and where the right place is to store the product info and argv. Also how to retrieve the PACKAGE_STRING to identify the product, should it get baked into the verilated code? Or does e.g. verilated.cpp need to be preprocessed to drop the values in?
rporter/verilator@d77196f
or you can pull the vpi-features branch from github.com/rporter/verilator
The text was updated successfully, but these errors were encountered: