Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@toddstrader
Copy link
Member

Re: #6589 / #6135

Assigning function call results to intermediate variables when used for expression coverage means that we don't care if functions are pure or not from the perspective of expression coverage. Functions will get called the same number of times so expression coverage won't perturb state when impure functions come into play. And we'll record the results for use in calculating expression coverage.

The problem is that system functions calls are not FuncRefs. So as I see it there are two choices:

  1. I can teach the expresion-coverage-intermediate-variable logic about a bunch of different system functions and what their return types are.
  2. I can do the isPure(bool verilogOnly = false) thing I mentioned in Intermediate variables for function calls + expression coverage #6589 .

I think I'll try number two when I can pick this up again next week. But please let me know if there are other options I should consider.

@wsnyder
Copy link
Member

wsnyder commented Oct 24, 2025

I can teach the expresion-coverage-intermediate-variable logic about a bunch of different system functions and what their return types are.

After V3Width all of the system call expressions have proper dtypep()'s, so I'm not understanding the issue is knowing the return types. It's true there's no current way to know what was a system call, you could add a AstNode virtual method to determine that.

@toddstrader
Copy link
Member Author

Yeah, I'm sure I just didn't look hard enough for the dtype. An AstNode parent would probably be cleaner than my other idea. I can give that a shot.

@wsnyder
Copy link
Member

wsnyder commented Oct 24, 2025

We can't have a common AstNode parent as some are AstNodeBiOps or otherwise, you need a virtual method.

@toddstrader
Copy link
Member Author

Oh sorry, I misunderstood. Thanks for the clarification.

@toddstrader
Copy link
Member Author

I have something ready for this now but it depends on #6589. I'll update once that lands.

@toddstrader toddstrader marked this pull request as ready for review October 30, 2025 11:58
@toddstrader toddstrader changed the title Expression coverage cleanup Intermediate variables for system calls during expression coverage Oct 30, 2025
@toddstrader
Copy link
Member Author

@wsnyder I think this one should be good to go now.

Copy link
Member

@wsnyder wsnyder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How was the list of Ast's getting isSystemFunc determined, e.g. why no AstFOpen?

@toddstrader
Copy link
Member Author

How was the list of Ast's getting isSystemFunc determined, e.g. why no AstFOpen?

Grepping around, cross-referencing the LRM and a little bit of Claude. That one should definitely be on the list. I'll do another pass.

I couldn't find a simple list of system functions as opposed to tasks. The lists in 20 and 21 sometimes say a group is just functions or tasks but sometimes it's tasks and functions. I haven't found one yet, but do you know of any place where a complete list of just system functions exists?

@toddstrader toddstrader force-pushed the cover_expr_sys_funcs branch 2 times, most recently from 4253b6b to 6ee5540 Compare November 4, 2025 15:27
@wsnyder
Copy link
Member

wsnyder commented Nov 4, 2025

All I can suggest is look at the system function list in verilog.y/verilog.l.

@toddstrader
Copy link
Member Author

Yeah, for better or worse those files also combine tasks and functions. I went through 20 + 21 again and think what I've got now is correct or at least much closer to it.

@wsnyder
Copy link
Member

wsnyder commented Nov 4, 2025

Thanks, ideally we'd get code coverage on all of these new functions so we have a chance at correctness, but I can appreciate that might be too much work and am willing to waive it.

@toddstrader
Copy link
Member Author

Taking a look at a quick and dirty test to exercise more of these methods. But I'm not getting expression coverage for:

    if (($time != 0) && foo) bump <= bump + 1;

where foo is a logic. Gonna put this in draft while I figure out if there's something else that needs to be sorted out here.

@toddstrader toddstrader marked this pull request as draft November 4, 2025 17:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants