ducky64
commented
2 years ago Thinking about the "generators define the block's implementation" a bit more:
- This prohibits multiple generators on a single block (which is probably of dubious value)
- Drawing the boundary of what is available pre-generator and post-generator is the interesting part - and how to make this clean from an engineering standpoint
- For example, should port parameters be available pre-generator?
- What about exports of internal blocks (as commonly used for the above, eg the IC's port defines the application circuit block's voltage limits - note that this breaks the 'internal blocks not available pre-generate'))?
As a concrete example of something that could break (I think - not tested yet):
- Buck converter generator requires the current draw to generate
- Buck converter's output voltage depends on the feedback resistor, which is a internal block AND a generator (but not necessarily the buck converter generator)
- Some block powered by the buck converter requires the voltage to calculate its current draw (for example, a resistor)
- and we get deadlock
Ideas
- The generator is structured in the problem model as a sub-block.
- But there would need to be some syntactic sugar to make this palatable, otherwise generators become cumbersome
- Or perhaps not? Perhaps the buck converter power stage should be its own sub-block?
- Perhaps the right answer is a flattening transform? It's more of an aesthetic issue at this point.
- Interfaces with the containing block must still be declared, eg ports attached to
- Certain parameters must be statically provided to the generator (deadlock manually broken). In the buck converter example, it would take a current draw to size for, instead of deriving the current draw from connected loads.
- Advantage: provides predictability and stability in design, while good error messages and inspection interfaces allow users to quickly correct mistakes.
- How should this be structured? Is there a general philosophy / rule here? For example, should generator outputs only be usable in checks (and not to derive further generators)? Should (can?) this be enforced, or is this more akin to a style guide?
- More general question: what restrictions do we need on parameter dataflow to avoid deadlock or brittle libraries?
- Both of the above?
Currently, links must be fully defined in a generate function or in the base block definition - they can't be split. This makes for some awkward code (though generators are advanced functionality).
One idea to fix this would be to defer link size resolution until all the generators that could attach to a link runs (perhaps sharing infrastructure with #20). Generators would need to declare where they connect, though.
Alternatively, generators could define the block's implementation so the block doesn't elaborate until its generator runs. Which, if it doesn't break any use cases, could be the more elegant solution. This limits to one generator per block.