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

Some else-if branches don't have coverage number associated #727

Closed
veripoolbot opened this issue Mar 26, 2014 · 5 comments
Closed

Some else-if branches don't have coverage number associated #727

veripoolbot opened this issue Mar 26, 2014 · 5 comments
Assignees
Labels
area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: fixed Closed; fixed

Comments

@veripoolbot
Copy link
Contributor


Author Name: Sharad Bagri
Original Redmine Issue: 727 from https://www.veripool.org
Original Date: 2014-03-26
Original Assignee: Wilson Snyder (@wsnyder)


I am using the verilator generated c++ code for tracking how many branches of the code has been reached. From what I understand, Verilator generates coverage number based on number of conditions in the verilog code. Sometimes number of branches in the C++ code may not be equal to the number of conditions in verilog code. In such case, some branches of the C++ code is not numbered. It would be good for my case, if all branches of C++ code is numbered.
This happens when verilog file has if, else if cases.

I am attaching a verilog and its corresponding C++ file formatted a little bit for aesthetics.
In this case branch between 60 and 51 is not numbered. i.e the branch inside and 60 and outside of 51.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2014-03-27T01:40:54Z


When I run the code you provide I get totally different coverage points. Anyhow looking just at the verilog file you provided what is a case/if/else that is not properly covered?

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Sharad Bagri
Original Date: 2014-03-27T19:35:49Z


All the verilog case/if/else statement is properly covered.
Problem is in the C++ code. Using b12.v the cpp file which is generated is attached here. In this, the branch with the following code staring at line 563
if ((1 == (1 & ((IData)(vlTOPp->k) >> 1))))
{
vlTOPp->v__DOT__ind = 1;
vlTOPp->v__DOT__count2 = vlTOPp->v__DOT__timebase;
vlTOPp->v__DOT__sound = 1;
vlTOPp->v__DOT__play = 1;
if ((1 == (IData)(vlTOPp->v__DOT__data_out)))
{
++(vlSymsp->__Vcoverage[51]);
vlTOPp->v__DOT__gamma = 0xb;
}
else
{
++(vlSymsp->__Vcoverage[52]);
vlTOPp->v__DOT__gamma = 0xe;
vlTOPp->nloss = 1;
}
}

has no coverage number inserted. Its child branches have coverage number 51 and 52 but it itself doesn't have any coverage number.
If a coverage number can be inserted in this branch then branch tracking would be more meaningful as each branch would have a unique number.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Sharad Bagri
Original Date: 2014-03-27T19:58:12Z


All the verilog case/if/else statement is properly covered.
Problem is in the C++ code. Using b12.v the cpp file which is generated is attached here. In this, the branch with the code staring at line 562 is attached as line562onwards

This branch has no coverage number inserted. Its child branches have coverage number 51 and 52 but it itself doesn't have any coverage number.
If a coverage number can be inserted in this branch then branch tracking would be more meaningful as each branch would have a unique number.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2014-03-29T15:06:04Z


Thanks for explaining. This is fixed in git towards 3.857.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2014-05-11T21:08:32Z


In 3.860.

@veripoolbot veripoolbot added area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: fixed Closed; fixed labels Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: fixed Closed; fixed
Projects
None yet
Development

No branches or pull requests

2 participants