vrinsd

Sadly (as much of a cynic as this makes me seem) I kinda figured this is exactly what would happen when the Pine people decided to partner/use MediaTek or name any other vendor who doesn't truly embrace or care about open-source. I'd spotlight Chinese SoC vendors here but that's biased, Qualcomm's track record isn't awesome here either, but it's my understanding people inside ARE trying to change that culture.

My high-level observation is the Pine people are basically selling what's effectively a "reference design" built around some questionable hardware under the guise of making an open-source hardware/phone/etc. Whether or not the device actually works as a phone, has good battery life, works reliably is kind of a secondary goal and ends up mostly resting on the shoulders of a community of unpaid software developers.

People here might be too young to remember, but there was a prior attempt at an open-phone called "OpenMoko". Despite using silicon that was more open-source friendy, it didn't really work out. It's REALLY challenging to build custom hardware, get the details right and build it on open-source software unless you're super well funded and very coordinated.

It's however not hard to sell "kits" that give you the idea they'll do something but end up tricking the end-user who doesn't find out until after the money is spent.

Jumping on the bandwagon of this is a pretty ridiculous "article".

If the advice is "learn how things work before using some kind of automation" that's valid guidance but this article seems to assume using an IDE or something like that is a substitute for using your brain, which is pretty bogus. Not everyone who uses an IDE is doing it because they want fancy "code completion" or "AI-enabled write a for-loop for me".

I didn't get the hype around VSCode until I ended up working on a project where I was forced to use a Windows PC but the machines I was interacting with were Linux-hosts.

The "Remote SSH" capability wasn't just "slightly helpful" it was realistically the only way (along with VSCode IDE) to navigate a project that had thousands of files of proprietary, non-open source code (i.e. you couldn't use github or something "offline" to traverse the code base).

Remote SSH enabled me to go from hating life using grep / ripgrep and nano/vim/emacs to figuring out a crazy complex code base to being able to wrap my head around the design thanks to VSCode's "jump to definition" and other really helpful features.

I use VSCodium and open-source plug-ins now for personal work and I'm constantly finding new and useful features.

Addendum: If you work in languages like Python, the single-step and debug experience in VSCode (haven't tried it in VSCodium) is also really impressive. You're not using some strange Python IDE which has its own ideas about how do "single-step" and "watch variables".

Really cool to see this I hope you're able to continue this work. As others have said, CalDAV / CardDAV are complex standards and getting the nuances right without using some tried/true libraries (sabre-dav) might be a challenge.

Two points:

For just CalDAV / CardDAV there's Radicale, Davical and Baïkal all of which work pretty well and are relatively easy to set up, so this might be a bit of wheel re-invention.

Perhaps you might consider relying on those projects for calendar / contact sync and then add your other pieces (file, photos, etc).

Second point is I think the reason why Nextcloud / Owncloud end up becoming super-slow for file sync is unfortunately the use of WebDAV.

I can't find the thread at the moment but I remember the developers from one of those projects saying that WebDAV itself makes the file-sync super slow and resource heavy.

As a result I think the Owncloud++ or their golang based re-implementation prefers the use of S3-compatible for backend file store.

I'm not saying you should use S3, but if you continue down the path with WebDAV for file-sync you might find it's resource heavy and slow as Nextcloud/Owncloud might be.

I think this is a good thing in the long-run.

Relying on WiFi access points to geolocation was always a bit of a hack and in my experience it's allowed phone manufacturers to roll back on the quality of their satellite-based GPS implementations and worsened phone battery life ; now the phone is constantly scanning for WiFi access points and Bluetooth and shuffling that data back to the mothership(s) on the user's data plan.

My old Samsung S4 could get a GPS lock (sans Internet, WiFI, in airplane mode) in doors usually in < 30s. I had a few different iPhones, 6, 6S, 7 and XS where GPS wouldn't reliably work unless it had "network" (Internet) connectivity due to the reliance on WiFi-geolocation. Similar experience with Pixel 3's, with noticable improvements on Pixel 4s satellite GPS acquisition time.

For Android phone users, if you can use a slightly older version of microG (due to some recent unfortunate change microG made making the use of other backends more difficult), I found this backend to consistently be the best:

https://f-droid.org/en/packages/org.fitchfamily.android.gsml...

The above backend lets you use a database of CELL TOWER IDs to speed up location acquisition. As you might expect, cell phone towers rarely (ever?) move and even without a SIM card or celluar connectivity, a phone can scan for CELL IDs.

The other cool thing about this backend is it can create the database from the phone, or you can do it offline on a PC and push a sqlite.db file to phone. I suggest the PC route, the script is pretty simple to understand and you can filter out countries that might not be relevant to you.

And f** Skyhook.

This might be a US-centric experience so I'm prefacing...

Basic cost of living is : rent, food, utilities. Those three have gone up astronomically, especially in the past 3-years.

A graduate stipend is probably $22K/year, maybe more for a PhD student. 20-years ago that was reasonable, if rent is $1700/mo you're already underwater given you have to pay taxes on that meager $22K.

In my graduate experience, I didn't see most grad students walking around with the latest cell phones, laptops or luxury goods, they struggled with the basics.

A number of graduate students at various universities are going on strike and forming unions and honestly more power to them:

https://www.latimes.com/california/story/2023-01-02/uc-strik...

LLVM/GCC target fixed ISA devices. Even GPUs can be represented in this paradigm of having a core set of instructions and registers for SIMD/SMT. What FPGA or random ASIC could LLVM front-end? How do you go from LLVM-IR to something that can live in an FPGA?

You can either do what most "high-level" or "new HDL" tools do which is emit some form of "RTL" (Verilog/VHDL) or you can stick a place-holder design in the FPGA and then your LLVM-IR is basically emitting instructions for an "overlay" type of design.

And if we are being pedantic you can use Verilog or VHDL to write a purely STRUCTURAL netlist which includes hard instantiating "basic building block" primatives. i.e. have your RTL instantiate an ISERDES or OSERDES block (which I suspect will mean something to you).

But even with a "netlist" based design in RTL you still have to technology map that into building blocks of your hardware and that whole process becomes so complex people have just migrated to writing "behavorial" RTL (or translating to it from some other language, i.e. Vivado HLS).

Lastly, Vivado does support EDIF netlists as do most FPGA tools (whether they advertise it or not) but if you don't have a way to do a technology mapping stage from your high-level RTL into building blocks (which is effectively part of the "synthesis" steps), then what did you accomplish?

Your example about Bjarne says it all -- it was financially more in his interest to leave academia / standards comittee / "hardcore work" for something more financially lucarative.

There's maybe another bigger point here that a lot of "great tools" or "good ideas turned into reality" happened either because the person/people working on it were so motivated and/or they were in the right environment that supported this type of creativity.

Sadly, most hardware-oriented organizations are the exact opposite of creativity or "great ideas" because if they fail the physical cost to fix something is staggering.

In software you can try something, if it doesn't work, call it a learning experience, re-factor, potentially re-use and have another go at it.

In hardware if you do that few people will high five you for a valiant effort.

Historically academia was a place that could "birth" new ideas, help explore them with a pure intent to see how it worked out. These days I think people are dying to finish with school and not live a pauper's life.

I won't get into a debate about semantics, but even your employer is a prime example -- Xilinx profit margin per device is staggering by semiconductor standards but they won't pay what they could. The market doesn't always make that dictation, the company does.

And that's an example but there are other "high-margin" hardware organizations (besides Apple) who still pay HW/EEs lower than SW/SREs.

And if you've been in engineering long enough you'll meet some pretty brilliant people, but their names might not be household or widely known. Lumping engineering into "RTL people" is pretty dismissive.

Claude Shannon, father of information theory, is less widely known for his MS work on 'Shannon Decomposition' which FPGA companies used for a long time to break combinitorial logic functions to multiplexor (MUX) based implementation. That's not "compiler theory" but that's a building block of a type of logic synthesis which compilers used. Shannon isn't a "compiler guy", just a smart dude who's intelligence wasn't bounded by one domain or discipline.

So many insightful comments, I don't know this adds much but "basic cost of living" or "living reasonably" has gone up fairly exponentially in the last 10-15 years. Most people in academia, if they were on the fence at all about going to industry, are probably jumping.

In some not so distant past a family could live on a single-income, one person is an associate professor at a university type arrangement. These days without dual-incomes it's anomalous if you can even afford to buy a home.

It's a circular problem too because the recent waves of "tech boom" + after-shocks from CV19 and associated economic "policy" the slope has become even steeper.

It doesn't help that modern academia, if it was really ever different, at the graduate, post-graduate and doctoral level is basically indentured servitude. There's a reason why most graduate programs are filled with "foreigners", it's no different than H1B abuse in the tech industry -- unversities know they can abuse this work force for peanuts.

So if you just finished your PhD after doing 70-80 hr weeks for the past 4-6 years and you have choice A) Continue the same and hope you can get a crack at your own research team B) Get a job, work ~10hrs/day and afford to buy new clothes, a decent car, eat well and not live in a shack, you'd likely pick choice 'B'.

That's because in order to turn your "design" into an ASIC or an FPGA, you need to go from whatever high-level language (insert new-HDL-du-jour) into a netlist compatible with your physical part.

The only scalable/vendor/device-neutral way to do that is to back-end your "new" HDL with Verilog/SystemVerilog/VHDL, especially if you want to simulate your design.

A long time ago people used to design chips and CPLDs/FPGAs in schematic-capture (which actually does have its place) which is basically one-step removed from being a netlist.

Among other challenges if you wanted to change to a new device (say a bigger part) or a part from a different vendor, there wasn't really "neutral" way to do this until HDLs came around.

To really change the status quo, you'd have to own EVERYTHING from the point of design entry to the physical device and all steps between.

Even with both "major" FPGA vendors now with their own synthesis and sometimes simulation capability they can barely and/or reliably make that minimum bar work.

This is a pretty heavy handed statement -- there are plenty of "hardware engineers" who know plenty about compiler theory and/or have contributed significantly to it. A similarly flippant comment might be "if software engineers only understood hardware better we might have smartphones that last a month on a charge and never crash".

The challenge with hardware is that unlike "traditional" software which compiles to a fixed instruction set architecture, with hardware you might literally be defining the ISA as part of your design.

In hardware you can go from LEGO style gluing pre-existing building blocks to creating the building blocks and THEN gluing it together, with everything in-between.

The real crux of the problem is likely our modern implementation of economics -- a CS graduate who has base-level experience can bank roll a crazy salary that some guy who might have a BSEE, MSEE and PhD in Electrical Engineering ("hardware") will be lucky to get a job offer that's even enough to cover costs of education.

Until the "industry" values hardware and those who want to improve it, you'll likely see slow progress.

P.S.

VHDL (a commonly-used hardware description language) is more or less ADA. Personally I think the choice of ADA syntax was NOT a positive for hardware design but the type-safety and verbosity being a very apt fit for software.

This "announcement" is basically a no-op. It's very likely not a new device but taking something like an Artix and just re-branding it and then limiting access to device features via software(Vivado). The same was done for 'Spartan-7' -- it was NOT a new device, just an existing design where they removed the SERDES block.

What made Spartan-6 unique was in addition to having transcievers was the hardened DDR memory controller.

If you read this announcement, DDR support is done via 'soft' memory controller, which chews up a lot of resources and makes meeting timing frustrating, forcing use of Xilinx's MIG IP.

It has little to do with 'ROI' and much more with the way hardware gets made.

Touchpad, touch screens and input devices are actually VERY difficult to get all the details right because you're dealing with material properties, differences that show up in manufacturing and even the geometry of the end user (small hands, big hands, wet hands, etc) among other factors.

Apple takes on the responsibility of their internal hardware (SoCs, all embedded boards, materials) AND software (embedded, OS, drivers, etc). They have a culture of caring about details and do a tremendous amount of R&D on these related details, at the design and manufacturing level, before releasing their product.

In contrast, almost all PCs are made by "integrators" (i.e. Dell, HP, Lenovo, etc) who take mostly off-the-shelf or semi-customized components, "integrate them" (I use it in quotes because often, as we know, products will ship with broken ACPI, EFI, broken drivers, etc) and put it out there. The drivers usually come from a hardware vendor who has little incentive to get "details" right, they will be lightly modified and then the OEM will shoehorn that into a semi-customized OS image and the device ships.

Further, traditional vendors like HP or Dell are under pressure to keep churning out "the next" iteration of their HW, so they don't really go back and improve drivers or firmware unless they are forced to.

On the Linux, FreeBSD and open-source side, you have an army of dedicated volunteers who often take highly sub-par or questionable hardware and work (often in the dark, or through reverse engineering) to make things reliable and add polish. The fact that things work "as well as they do" under modern Linux or *BSD is a miracle and mostly the result of individuals who care. There might be a few individuals at an OEM who care, but by and large the culture is not "we should make the most amazing product and provide documentation and support to the open-source community" and more "if they can get it figured out, good for them".

A more practical detail is the fact most touchpad ICs are made by Alps or Synaptics. And these devices include things like 'palm rejection' and other advanced features that haven't been enabled until somewhat recently because the IC vendor might not have shared the details with the people working on the open-source drivers.

You see nearly the same pattern with Android phones, how long before the next phone gets pushed out? Did they really fix the weird bugs that caused the previous phone to overheat, or the celluar link to drop calls unexpectedly? Fix the fact the satellite GPS doesn't work 1 out of 8 times?

Apple isn't perfect by any means, in fact I find the most current versions of macOS to be VERY user hostile but sadly most OEMs superficially copy Apple (i.e. moving to only ONE or TWO USB-C ports on a modern laptop) and miss the key point of making hardware & software actually working well together and openly supporting something other than Windows.

Hey Jeff,

Can you share what your experience has been like with Nim on embedded targets? Both Nim and Zig are on my wishlist to try out for embedded but I'm doing C and RTOSes for the next few projects.

Ada with Ravenscar seems like another "seems like it solves a lot of common problems intelligently" but I haven't had much time to try it being a simple proof of concept.

The GoboLinux guys really did "intelligently" come up with a filesystem layout that's humanly understandable. I personally find the old-school UNIX conventions we use fairly arcane given we no longer have 8.3 type limits imposed by lack of storage space, >1GB file-size issues, etc.

I ran GoboLinux 012-015 for a few years on a server that I used for hosting version control software and for the most part it kicked ass.

What was a bit of a stumbling point is that if you needed a package that didn't readily exist, you'd have to create the recipe. The language for creating GoboLinux recipes is perfectly understandable, the issue was often one package would depend on a dozen or a few dozen libraries and you'd spend a lot of time chasing that down, getting the versioning for those libraries right, THEN finding a URL for those libraries/packages, and THEN creating the recipe.

I eventually moved over to Debian and I still cringe and config files in "/etc" maybe the binary was put in "/usr/bin" or "/usr/local/bin".

I'm in the camp that finds systemd annoying and kind of like an octopus (you'll often resort to using a find command to locate the associated .service file, you can't rely on them being in once place, the CLI isn't really intuitive) in contrast Gobo had a very simple set of scripts to manage services and it was very easy to work with.

But, the convinience of just being able to 'apt get' what you need or 'dpkg -i <blah.deb>' outweighs the much more sane and intelligence behind GoboLinux. These days the number of Linux distributions people support has dropped from the myraid of options it used to be to now almost always including Debian (or Ubuntu) by default so you it's unlikely you can't get a package or some program installed, even if it outside the repositories.

macOS definitely does something similar to GoboLinux and it makes working with macOS on the CLI (at least prior to the current versions which are fairly user-hostile) pretty easy -- your pen drive will be located in /Volumes, configuration files for a program under ~/Library, etc.

This is great to hear. It might be nice to bubble those examples up to your Github page along with some diagrams and logic/resource results after synthesis (i.e. how many LUTs, BRAM, etc).

It's easy for people to do a lot of naysaying, it's a lot harder to try and actually do something evolutionary, let alone revolutionary. Please keep posting with up-to-date results.

Tim Westcott is a great author and this is a solid article.

I'll add, I've been meaning to write up my own "realities of PID", one day I'll get around to it.

What is NOT readily apparent when you look all these treatments of PIDs is what happens with the poles-zeros of your control-loop (PID) and the interplay with the system or plant.

I have consistenly found all these "it's so simple, integrator removes long-term error, differentiation improves response time" ignores the fact that if you don't pay attentions to the poles-zeros of your overall response you get some very puzzling results.

In a nutshell, understanding the s-domain (Bode) view of your plant and control-loop means you can usually use PID to sovle control-loop problems. But most people don't have a model of their plant (like some of the examples DannyBee has listed) which means you can't easily auto-tune a PID or most control-loops.

Examining the step-response is probably the first clue to your plant, assuming you won't physically break something with that stimulus...

I'm always interested in new hardware-oriented DSLs, so great to see effort and work here.

rachitnigam, do you have any example designs of "significant" complexity? I looked over the paper and saw your 2x2 array example -- I'm curious if you make this something like 100x100 or n x m, can that be done in parameterizable way? What about control-structures like bits to enable / disable functionality, etc?

Also, do you provide a way to do things like arbitrary insert pipeline registers and let your tools track that?

One comment when comparing to Vivado HLS, fundamentally HLS breaks all problems down into CSP-style designs (whether you want that or not) and it takes a lot of experimentation with #pragmas to get a more optimal design. Not claiming Vivado HLS will beat your tool, but it's possible with some tuning to get a "better" design.

Background: Have worked at a large number of big-tech hardware / software companies in senior roles.

My observation is that doing a 'good job' is not really measurable the way most companies think about it (it actually is if you talk with your actual end-customers or use your brain) but getting something done 'quickly' or 'in two quarters' makes an easy target people shoot for.

I also notice big companies tend to have goal setting practicies that basically encourage people to game the system by showing 'what they got done' ("implemented feature a") vs. 'how well the job was done'. I haven't seen any of these goal systems including a "look back" or feedback loop where the actual bugs filed against a feature are ever considered.

Quality engineering culture is really culture and has to come from the top down and very likely if people in the upper echelons of management are in their roles because of politics, quality is so far removed from what they care about it really ends up on the shoulders of a few individuals who "care".

No, Irongate was very much internally developed by AMD. AMD was well aware of the "sketchy" nature of ALI/VLI/ULI/SiS and knew it was giving them a really bad rep so they undertook their own designs.

AMD chipsets were not as successful in the marketplace because unsurprisingly the AMD-chipsets cost more than the Taiwanese ones, and motherboard vendors (who are almost all based in Taiwan) stuck with their existing vendors. The dual-socket AMD machines (K7-based) pretty much all had the 760MPX on it because I think only AMD had a multi-socket chipset that was reliable.

AMD also inhereted a lot of DEC engineers, so it was no surprise that K8-era their 'HyperTransport' was really 'Lighting Transport', developed at DEC.

Interestingly, Micron had also developed a chipset for AMD in this era but never released it.

nForce was also not re-licensed from ALI/ULI that I recall but I have far less insight here. nVidia at the time had a 'total system play' in mind so they were attempting to do GPU/audio/network/chipsets for AMD & Intel and got designed into original Xbox (x86-based). Jensen I think used NRE money from MSFT to fund a lot of the nVidia chipset work.

1 point by vrinsd 14 minutes ago | root | parent | next | edit | delete [–]

I won't be as snide as bsder, but I will say Expedition and Allegro let you handle some crazy complex designs, which are much more of a challenge with Altium. Things like DDR3/4/5, 10+ layer PCBs, complex design rules, etc. Personally I think Expedition is much much easier to use than Allegro ; for the curious it was actually created by a company called 'Veribest' that Mentor later acquired.

Having using Altium (all the way back to when it was Protel 98/99SE) it's gained a lot of impressive capability but it never shed a number of weird UI oddities.

I'm really happy to see the direction KiCad is going, having used it circa v3 era, it's MUCH more usable.

Which is weird because modern Zuken tools look really intelligent designed. I haven't tried them since they ran on Sun workstations but CR-8000 looks impressive.

The step backwards you see Altium regarding not being able to freely export/import is the result of a nut job named Henry Potts, who also formerly ruled Mentor with an iron fist. He did not bring about positive change, quite the opposite.

He did the same thing regarding locking down import/export with Expedition circa ~2006 or ~2008(?) specifically to tie people into a Mentor flow, breaking years of tools people had written that enabled footprint / schematic import/export capability.

In an a "Jack Welch" kind of way, somehow he attained industry envy from the other EDA companies and Altium hired him, even though, like Jack Welch, he's not someone who actually did positive things.

Cadence bought OrCAD and kept the schematic editor but the layout is Allegro, not the layout tool that historically was part of OrCAD.

Allegro IMO does have a pretty steep learning curve, I think it's UI is quite archaic, it really hasn't see any serious improvements in over 20-years.

I'd suggest Kicad if you wanted to do anything personal.

The PCI chipsets of this time were really really buggy, that's why.

They got better as time went on but it really took a number of years before people could get reasonably high-performance, reliable PCI implementations. For x86, aside from AMD's Irongate (750/760) chipsets (K7-era) and nVidia (nForce), pretty much only Intel had PCI working reasonably. ALI, VIA and SiS PCI implementations always had weird issues and quirks.

PCI-IDE adapters are another good example -- VIA's PCI IDE had all sorts of issues, if you wanted high performance PCI IDE, it worked best with Intel.

It's not that different with modern PCIe-SATA either (history repeats), Marvell PCIe/SATA adapters have lingering oddities.

The issue is not lack of raw bandwidth, it's getting the hardware, software, drivers and OS "to do the right thing".

PCIe gives you the building blocks of posted transactions and non-posted transactions but doesn't help you use them effectively. There is no coordinated or designated DMA subsystem to help move data between the root-complex("host") and end-point("device)".

So, if you have to design a new PCIe end-point (target in original PCI terms) using an FPGA or ASIC then trying to actually sustain PCIe throughput in either "direction" isn't trivial.

Posted transactions ("writes") are 'fire and forget' and non-posted transactions ("reads") have a request/acknowledgement system, flow-control, etc.

If you can get your "system" to use ONLY posted writes (fire and forget) with a large enough MPS (payload size), usually >128 Bytes, then you can get to 80%-95% of theoretical throughput (1).

The real difficulty is if you need to do a PCIe 'read' this breaks down into a read-request (MRd) and a Completion with Data (CplD). The 'read' results in a lot of back and forth traffic and tracking the MRds/CplDs becomes a challenge (2).

Often an end-point can use 'posted writes' to blast data to the PCIe root-complex (usually the CPU/host) maximizing throughput since a host usually has hundreds of MegaBytes of RAM to make use of for buffers. Unfortunately to transfer data from the root-complex(host) to the end-point(device), the host usually will have the device's DMA controller initiate a 'read' from the host's memory which results in these split transactions since end-points don't often carry hundreds of MB of RAM. This also means bespoke drivers, tying into the OS PCIe subsystems and hopefully not loosing any MSI-X interrupts.

To re-iterate in the modern "Intel way" the CPU houses the PCIe root complex but does not house ANY DMA controller. So to get "DMA" working means each PCIe end-point's implementation has some kind of DMA "controller" which is different than the DMA controller of all other end-points, rather than Intel having spec'd out an "optional" centralized a DMA controller in the root complex.

1: https://cdrdv2-public.intel.com/666650/an456-683541-666650.p...

2: https://www.intel.com/content/www/us/en/docs/programmable/68...

Intel also had quite a few issues (as usual) getting their own PCI standard working.

Almost all of the early Intel PCI chipsets (i.e. Mercury, Neptune ) had serious bugs. Intel actually used DEC PCI chipsets or licensed their designs to actually get a more robust PCI implementation (IIRC Triton). Until then VLB was still a better choice.

PCIe retains a lot of "weirdness" that PCI introduced which includes a lack of a unified or "properly architected" device-to-host and host-to-device centralized DMA agent or broker.

Even today it's still a challenge to extract more than 50-60% of the theoretical bandwidth PCIe offers without a lot of tuning and mental churn.

I agree with every comment robomartin has posted on this thread.

I'll add: I HAVE worked on schematic designs with 10-20 people working on an overall schematic design at the same time. Usually one or more engineers own some sub-section of the design ; i.e. for a mobile device, one or a few people own the "power" part of the schematic, the camera team owns the camera portion(s) of the schematic, etc.

Mentor (DxDesigner / Design Capture) and Cadence (Concept) support this flow, but with the oddly more popular but OrCad this can be a nightmare.

Glad you're open to feedback.

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?

At the risk of sounding pretty negative to someone who wants to make the world of EDA better, this really seems like a re-discovery of a text netlist with the idea of making it 'easier' to create schematics but I feel like it's DOA for anything non-trivial.

Most PCB tools have the user create the schematics graphically, but the actual 'design' is usually a text netlist already or the tools let you export the netlist to an industry format such as EDIF.

SPICE netlists (for example) are also purely text-based, and while many of my EE professors could actually "think in SPICE" (i.e. go from a schematic of a circuit to directly writing in SPICE) for me and pretty much everyone else it was unbelivably painful to modify a SPICE netlist as you went from a simple inverter to something even "basic" as a two-transistor BJT current-mirror. You want to now copy+paste the design six times? Now you have 6x netlist re-naming fun.

One of the reasons why non-trivial schematics are done graphically is you can more easily grasp the intent of the design and make "complex" designs very clear. In my opinion, it's a reason why a well designed block diagram is worth 10x access to the "design" whether it's RTL or C -- you get an understanding WHY someone did something not just the what.

Example, you might put resistors in-series on a bus to provide termination (best done at the source/driver) ; what would that look like in this new text-based schematic language? What if I have series termination resistors on the bus, thevenin termination on the far-end and then a pull-down strapping resistor as well? The block of text will grow quickly without much clarity. I don't doubt it will be functional, but there will be no mental model of what this is supposed to look like, and further why all of these components are there. A well drawn schematic* will make this overt.

Another simple example might be a single-supply op-amp which usually has a few resistors to bias the signal correctly. It will easily end up being MANY lines of text and it won't all together be clear which lines of text associated with the op-amp correspond to an intent.

I have about 20-years of doings electronics, FPGAs, boards, C/C++, SoC architecture and DevOps with a formal education in both HW+SW. I could be an example of "the old guard" but in my career I've usually been the one to champion newer/smarter better tools and applicable domain-specific-languages so much so I pivoted my career in this very area for a number of years.

*Most schematics, and reference designs are a jumbled mess of wires and symbols. While highly subjective, a good schematic breaks logical function into symbols by function, groups related components intelligently and employs a good number of notes on the schematic.