Skip to content
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

$bits for dynamic/runtime usage #1646

Open
veripoolbot opened this issue Dec 18, 2019 · 4 comments
Open

$bits for dynamic/runtime usage #1646

veripoolbot opened this issue Dec 18, 2019 · 4 comments

Comments

@veripoolbot
Copy link

@veripoolbot veripoolbot commented Dec 18, 2019


Author Name: Stefan Wallentowitz (@wallento)
Original Redmine Issue: 1646 from https://www.veripool.org

Original Assignee: Stefan Wallentowitz (@wallento)


I think that $bits currently only works for fixed size expressions. For queues I have not implemented it yet as it may require to iterate all elements when $bits are used. I want to find a good way to implement this, plus check for other expressions if the standard (IEEE 1800-2017, 20.6.2) is properly implemented.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Dec 18, 2019


Original Redmine Comment
Author Name: Stefan Wallentowitz (@wallento)
Original Date: 2019-12-18T06:09:02Z


Wilson, I am wondering what you think about this: One major part of this is strings.

This code

string q[$];
q.push_back("abc");
$display("%d", $bits(q));

only seems to work properly on one commercial simulator. It also seems like a corner case to me, not sure what the exact usage is (serialization?) I have looked at implementing it by adding a bits function to Vlqueue, but we would need to overload or use partial templates (if possible) to work with variable and fixed sized types in queues. It will just return $bits(type)*$size(q) for fixed size types, but needs to sum up element sizes for variable sized.

This assumes that we want to fix $bits for string too, its currently a fixed size.

I am not an SV for verification expert, so maybe you know maybe better how useful this even is. Alternatively I can just make it error (as one commercial simulator also does) an unsupported error. Implementing it seems fun anyhow :)

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Dec 18, 2019


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-12-18T12:18:18Z


Generally given opportunity costs, I'd suggest if one commercial sim bails we can/should bail too.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Dec 19, 2019


Original Redmine Comment
Author Name: Stefan Wallentowitz (@wallento)
Original Date: 2019-12-19T16:43:53Z


I agree, is there some status that keeps it open but doesn't show with other open issues, like for long term work? Otherwise you probably just want to close it and I will put in an unsupported code in the tests, which seems a good way to catch corner cases (or the like)..

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Dec 19, 2019


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-12-19T22:57:41Z


I agree closing after you add the checks is appropriate. You should be able to close the issue out yourself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.