getWidth on a Bundle type does not return the right value in a tester(PeekPokeTester) about chisel-testers HOT 9 CLOSED

Anyone could reproduce it at least?

from chisel-testers.

I have reproduced it. Not sure what's going on. For some reason the internal iteration through the elements is missing a field when the bundle is defined with PeekPokeTester

from chisel-testers.

The root of the problem is that when the bundle is declared in a subclass of PeekPokeTester instead of a Module there is a problem in the lazy assembly of the bundle's elements field.

• It iterates over the public elements of the field.
• It invokes each element and sees if the return value of the invoke has been seen before
• It uses a set seen of the return values to do this.
• When created in a PeekPokeTester the hashCode of these returned elements are zero
  • This is because the trait HasId overrides hashCode and numbers on based on state saved in the Builder DynamicVariable.
  • This is not properly set up when called from PeekPokeTester
• So it confuses additional fields as ones already seen.
• This does not happen when Bundles are instantiated within a Module

RECOMMENDATION:
I think this is a Bug, but fixing it requires some delicacy. The issue of Chisel components being instantiated outside of a Builder context has come up before. My inclination would be to defer this to the next release. It may be that we can tackle this along with Bundle literals #417 and #77

from chisel-testers.

This is a really tough one. This has come up before and is why in my opinion, there should not be a default dynamic context in chisel3, it should just fail if you try to construct things outside of a Chisel run.

from chisel-testers.

The primary reason why bundles need to be instantiated inside the context of Chisel is that the order that the ids are assigned gives order to the fields of the Bundle. It looks like we might be able to do this better with scala reflection (https://stackoverflow.com/a/22478436/2483329). We will have to be super careful in fixing this though because Chisel uses these ids for lots of stuff so "fixing" this could have some very gnarly unintended consequences. Definitely going to require some thought.

from chisel-testers.

I agree with both comments, except that I think it's a reasonable presumption that within a PeekPokeTester one is, in fact, in a chisel context. Perhaps PeekPokeTester can take on some trait that gets it there.

from chisel-testers.

Might be fixed by bundle literals

from chisel-testers.

I think is best answered in the near term with chisel-testers2.

from chisel-testers.

I just retested this using chisel-testers and it seems to work properly now.
In addition, bundle literals now work and also seem to have the correct behavior

from chisel-testers.