Major Tools
Other Tools
General Info

Issue #1458

Dotted references to type parameters do not have the correct size

Added by Todd Strader 9 days ago. Updated about 12 hours ago.

% Done:



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.


#1 Updated by Wilson Snyder 9 days ago

  • Status changed from New to AskedReporter

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

if (m != foo_inst.baz) begin

Similar for first section. When I remove the extra $bits, and fix the instance pointed to, both pass. Or I'm misunderstanding the problem.

#2 Updated by Todd Strader 9 days ago

Ugh, yup. I think I started with $bits( 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.

#3 Updated by Wilson Snyder 8 days ago

Um, now looks good but fails.

#4 Updated by Todd Strader 8 days ago

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.

#5 Updated by Todd Strader 6 days ago

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.

#6 Updated by Wilson Snyder 5 days ago

  • Category set to WrongRuntimeResult
  • Assignee set to Todd Strader

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.

#7 Updated by Wilson Snyder 5 days ago

  • Status changed from AskedReporter to Resolved

#8 Updated by Wilson Snyder about 12 hours ago

  • Status changed from Resolved to Closed

In 4.016.

Also available in: Atom