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

Find UNUSED and UNDRIVEN components in structs #850

Open
veripoolbot opened this issue Nov 26, 2014 · 7 comments
Open

Find UNUSED and UNDRIVEN components in structs #850

veripoolbot opened this issue Nov 26, 2014 · 7 comments
Labels
area: data-types Issue involves data-types area: lint Issue involves SystemVerilog lint checking effort: hours Expect this issue to require roughly hours of invested effort to resolve type: feature-non-IEEE Request to add new feature, outside IEEE 1800

Comments

@veripoolbot
Copy link
Contributor


Author Name: Jeremy Bennett (@jeremybennett)
Original Redmine Issue: 850 from https://www.veripool.org


At present Verilator cannot detect unused bits or fields within a struct, due to their representation by nested @AstSeL@ nodes in the AST. I have written a patch to add support for this. It includes a new regression test case.

At present this just reports the bits affected in the flattened struct. In the long term it would be good to be able to report the field names of these parts of the struct. However by the time we get to V3Undriven, this information is gone from the AST. The solution will be either to run this pass earlier, or to carry struct field information forward.

Please review and pull the code from branch unused-structs at https://github.com/jeremybennett/verilator

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Jeremy Bennett (@jeremybennett)
Original Date: 2014-11-26T15:08:12Z


Some further testing indicates that this doesn't get nested packed multidimensional arrays right. It often seems to report the entire array as undriven, when it is not the case. I'll investigate further, but if you can see what I have got wrong that will be useful.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2014-11-26T22:03:36Z


Per variable I think you should make an ordered map which contains a <lsb,width> pair, as you need to handle finding bits in any order. You should not use a vector or map per bit as it will be too memory intensive.

When something is used lookup the newlsb and match if within the range of the entry that is found (foundlsb <= newlsb <= foundlsb+width-1 ) or immediately proceeds it (foundlsb <= newlsb <= foundlsb+width-1). If not found, look at any entry before the hit and possibly extend its width (if foundlsb+width==foundlsb then foundwidth++), or look at the next sequential entry and (if lsb=found+1 decrement foundlsb and increment the foundwidth).

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-10-18T00:06:41Z


Not currently being worked on.

@veripoolbot veripoolbot added area: data-types Issue involves data-types area: lint Issue involves SystemVerilog lint checking effort: hours Expect this issue to require roughly hours of invested effort to resolve type: feature-non-IEEE Request to add new feature, outside IEEE 1800 labels Dec 22, 2019
@chrisrandall21
Copy link
Contributor

I'm seeing this warning incorrectly, is there a fix in the pipe line -- I notice nothing's happened since 2014.

@jeremybennett
Copy link
Contributor

@chrisrandall21 I'm not currently working on it. It is on my huge list of things I would like to work on when I have time :-(

@chrisrandall21
Copy link
Contributor

chrisrandall21 commented Dec 15, 2020 via email

@jeremybennett
Copy link
Contributor

@chrisrandall21 It's 6+ years since I looked at this code. The patch doesn't seem that big (commit d50daa4b). However it looks like I was too simplistic in handling of arrays. So maybe it's a good starting point, but remember it is based on Verilator as it was in 2014!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: data-types Issue involves data-types area: lint Issue involves SystemVerilog lint checking effort: hours Expect this issue to require roughly hours of invested effort to resolve type: feature-non-IEEE Request to add new feature, outside IEEE 1800
Projects
None yet
Development

No branches or pull requests

3 participants