diplomacy: change name generation strategy

[terpstra]

This PR changes how LazyModules find their names.

Consider:
val foo = LazyModule(new MyModule)
This creates a Chisel instance 'foo' of a Chisel module named MyModule.

You can override still override the instance name using .suggestName on the LazyModule.

Disambiguation is punted to Chisel. This means if you create a sequence like:
val foo = Seq.tabulate(4) { LazyModule(new MyModule) }
all four instances will want to be called 'foo' and Chisel will disambiguate them to foo, foo_1, foo_2, foo_3. Since the disambiguation of instances is done in a namespace local to their shared parent, this policy seems perfectly acceptable in a large design. Code changed elsewhere in the design will not affect the instance path name.

However, disambiguation of module names as performed by Chisel is quite problematic. If you have 100 TLFragmenters in your design and you add a new one, chances are that half of the existing modules will get renamed. That means code changed in a completely unrelated part of the design can cause names to change. Unfortunately, LazyModules get the majority of their parameters from diplomacy, which is itself non-local. Thus, depending on these parameters for your name is also not ok. I don't have a good answer yet, and we need one.

[mwachs5]

This sounds reasonable/ the same as how it works for regular modules. I think the disambiguation of the other module names can, as you say, be tackled in a different PR.

[mwachs5]

is the "busName" distinction no longer necessary due to new hierarchy? Because I'd be annoyed if I end up with port_fixer and port_fixer_1 instead of these named port_fixers.

[terpstra]

These are now created as children of a module called busName already.

[hcook]

and are as of #1190 created under further coupler submodules, e.g.: busname.coupler_to_port_named_x.fixer

[terpstra]

If you changed the logic in a module, you will have to recompile it. This Therefore, I think it is ok for a module's name to depend on it's contents. Changing one part of the design won't then change the names of modules in another part. So a first suggestion might be to take a hash of all the wires inside the module and append a few digits to the Module name. To prevent this change from causing modules to get renamed all the way to the top, the hashcode should not include the names of child modules.

This is IMO better than using the constructor arguments of a Module, because those arguments capture very little of the things which might affect the generated circuit.

[terpstra]

This hash code renaming could also happen later, in firrtl.

We might also want to let a Module decide on the name conflict resolution scheme. Options like:
1- Fail to compile if there are two instances
2- Do the brittle x, x_1, x_2 policy
3- Always append a hash code
4- Only append a hash code once there are more than one of the module
5- Hash your pathName

[mwachs5]

And of course modules should always be able to specify their own Module Name (presumably based on parameters, as is done for the SynchronizerShiftReg. But those aren't lazy anyway so I assume don't really apply to this discussion?)

[hcook]

Consider introducing this API change now to keep things aligned while we await a solution for Chisel module disambiguation

[hcook]

#1159

[hcook]

Closing as it was subsumed by #1190, ongoing issue tracked in #1259