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
Dotted references to type parameters do not have the correct size #1458
Comments
Original Redmine Comment For the second commented section, it refers to baz is a parameter set to a $bits. $bits is by IEEE a 32-bit return value, therefore $bits(baz) should be 32, which is what Verilator says (that is you're saying m != $bits($bits(bar)). I suspect you didn't want the $bits(foo_inst.baz) and instead wanted
Similar for first section. When I remove the extra $bits, and fix the instance pointed to, both pass. Or I'm misunderstanding the problem. |
Original Redmine Comment Ugh, yup. I think I started with $bits(foo_inst.bar) before I added baz. In any case, this fixes the commented portions of the test: Or if you think that is redundant with the checking via bar_size, we can just rip out the comments. Whatever you think is best here. |
Original Redmine Comment Um, now t_type_param.pl looks good but t_type_param_collision.pl fails. |
Original Redmine Comment Sigh, this issue isn't working out well for me. So #1456 isn't totally fixed then. I'm getting AstBasicDTypes in paramValueNumber() for this, but the left() and right() are always evaluating to zero even though I see that they should not be zero. I'll have to investigate some more. |
Original Redmine Comment OK, so I actually ran all the tests this time: The problem was that by the time we got to paramValueNumber() with the type parameter, the type's range had not yet been constified. So when I tried to get left() and right(), I always ended up with "[0:0]". This meant all the keys were the same for any width range of the same type which caused the collision error. I wasn't sure if there would be any issue with additional levels of param indirection so I added a wrapper module to the test to force some additional elaboration steps. |
Original Redmine Comment Golden, thanks. Looks like one of those sort of patches which requires hours of thought to result in just one patched line ;) Fixed in git towards 4.015. |
Original Redmine Comment In 4.016. |
Author Name: Todd Strader (@toddstrader)
Original Redmine Issue: 1458 from https://www.veripool.org
Original Assignee: Todd Strader (@toddstrader)
See the commented out portions of t_type_param.v. Perhaps this shouldn't even be allowed since it can cause elaboration-time loops. However, we currently do not get any errors or warnings at compile-time.
See Issue #1456 for background.
The text was updated successfully, but these errors were encountered: