I don't know if your regulator response was directed at me or someone else, but using that as an example, if you take something like an LM7805/LM317 I think the 'parameterization' you're talking about (i.e. "input_voltage=12V", "output_voltage=3.3V", "accuracy=5%" --> let "tool" solve for resistors, and populate schematics/BOM) sounds cool and would work.
But what if it's something like this (a multi-phase step-down converter):
While it's "annoying" that a designer might have to go study a datasheet to know which resistors to tweak or change what's worse is having a tool or 'abstraction' do it for you, with the potential that it changes significantly underneath you and you don't even know what it did or why.
This is the bane of a lot of EDA tools and more specifically why people rightfully now loathe a lot of FPGA vendor's tools that have things like "abstract IP blocks" configured from the GUI but in each new release of the tool, the underlying "generated" RTL (which comes from some byzantine invokation of scripts and a soup of options) might be different and completely breaks people's designs.
What happens if it's not re-programmable like an FPGA but something physical with resistors, capacitors and traces on a circuit board?
For sure! You've made two super important points; how can I trust it shuffling things under me and how can I justify trusting this thing if it's going in long-lead or production hardware (stuff that's hard to fix)
The first one is super interesting technically because there's a few routes by which engineers can gain trust in something, and in my experience code-generation often isn't the strongest of them.
It's often the case that checking an answer is vastly easier than solving the problem in the first place. Our mid-term roadmap includes scripting tests (~pytest + SPICE in CI) and for a complex chip like that, I first expect that those params will tweak those tests, those tests will fail out of spec and the engineer needs to reconfigure it in that application while understanding the datasheet.
The next level is extremely similar, except the solver is selecting configuration component params based on cost-functions and rules, and this same test suite is validating the solution and providing the confidence needed to manufacture a prototype.
The final and important mechanism though is that you have a lockfile that lockdown the configuration of these discretes unless an engineer opens it up - yielding review as we'd have today.
The other half of this though - how can we confidently deploy this to production, is eased with the rigorous workflows software version control tools (github, gitlab) can enforce. If an engineer tweaks these params, you can use the tool to rigorously enforce review from the domain-specific-experts on the team.
Currently, it's vastly too easy to slip something through (mostly unwittingly) in design review meetings, and these version control tools go a long way towards fixing that.
I don't know if your regulator response was directed at me or someone else, but using that as an example, if you take something like an LM7805/LM317 I think the 'parameterization' you're talking about (i.e. "input_voltage=12V", "output_voltage=3.3V", "accuracy=5%" --> let "tool" solve for resistors, and populate schematics/BOM) sounds cool and would work.
But what if it's something like this (a multi-phase step-down converter):
https://www.analog.com/media/en/technical-documentation/data...
While it's "annoying" that a designer might have to go study a datasheet to know which resistors to tweak or change what's worse is having a tool or 'abstraction' do it for you, with the potential that it changes significantly underneath you and you don't even know what it did or why.
This is the bane of a lot of EDA tools and more specifically why people rightfully now loathe a lot of FPGA vendor's tools that have things like "abstract IP blocks" configured from the GUI but in each new release of the tool, the underlying "generated" RTL (which comes from some byzantine invokation of scripts and a soup of options) might be different and completely breaks people's designs.
What happens if it's not re-programmable like an FPGA but something physical with resistors, capacitors and traces on a circuit board?