@h.generator
def Big(params: Params) -> h.Module:
@h.module
class Unit:
# Unit cell, used a handful of times in `Big` below.
# The important part: *also depends on `params`*
# E.g.
p = h.Port(width=params.width) # Or any other parameter dependency
@h.module
class Big:
# Thing that instantiates several instances of `Unit`
p = h.Port(width=params.width) # Or any other parameter dependency
units = params.how_many * Unit(p=p)
return Big
In short:
There's a generator function
It produces a "top-level" module
Inside, it also produces some smaller modules, which that "top-level" instantiates
The problem case: those smaller modules depend on its params
This may look like a contrived example, but is pretty common in e.g. a DAC.
When and why is this a problem?
Generated modules get unique names per their parameters
That unique-naming gets applied to the return value of each generator
The @generator machinery never "sees" anything that doesn't get returned, such as Unit above.
Note this only becomes a problem if there is more than one call to Big with different parameters. Both its internal Unit modules would get the same non-uniquified name (Unit).
What could be done:
The Module constructor would have to peek at some global Generator state
Conveniently Generator now includes a call-stack of currently-executing generators
Naming would get resolved... it's not entirely clear when.
Could be at the end of the generator function, as it is now
Could be as the Module is being constructed
Could be "on-demand", in case the "base name" gets changed after generator execution
Example:
In short:
This may look like a contrived example, but is pretty common in e.g. a DAC.
When and why is this a problem?
generator
@generator
machinery never "sees" anything that doesn't get returned, such asUnit
above.Note this only becomes a problem if there is more than one call to
Big
with different parameters. Both its internalUnit
modules would get the same non-uniquified name (Unit
).What could be done:
Module
constructor would have to peek at some globalGenerator
stateGenerator
now includes a call-stack of currently-executing generatorsNaming would get resolved... it's not entirely clear when.
Module
is being constructedImportant thing is, all those should work.
Also - there are workarounds. Namely:
Unit
agenerator
itself, orUnit
a unique-name "manually"