scottapotamas

7 か月前議論

Agreed. Tooling like this also needs far more careful structuring of the inputs than a thin wrapper like this.

It burnt a bunch of tokens and filled the context reading all datasheet files, whereas documentation should be queried to answer specific details connected to relevant netlist/sch nodes.

scottapotamas

8 か月前議論

I'm your target market - averaging a few dozen board designs a year with complexity ranging from simple interposers to designs at density limits with large US+ FPGAs.

I'm always looking for workflow and automation improvements and the new wave of tooling has been useful for datasheet extraction/OCR, rubber-ducking calculations, or custom one-off scripts which interact with KiCAD's S-Expression file formats. However I've seen minimal improvements across my private suite of electronics reasoning/design tests since GPT4 so I'm very skeptical of review tooling actually achieving anything useful.

Testing with a prior version of a power board that had a few simple issues that were found and fixed during bringup. Uploaded the KiCAD netlist, PDFs for main IC's, and also included my internal design validation datasheet which _includes the answers to the problems I'm testing against_. There were three areas I'd expect easy identification and modelling on:

    - Resistor values for a non-inverting amplifier's gain were swapped leading to incorrect gain.
    - A voltage divider supplying a status/enable pin was drawing somewhat more current than it needed to.
    - The power rating of a current-sense shunt is marginal for some design conditions.

For the first test, the prompt was an intentionally naiive "Please validate enable turn on voltage conditions across the power input paths". The reasoning steps appeared to search datasheets, but on what I'd have considered the 'design review' step it seems like something got stuck/hung and no results after 10min. A second user input to get it to continue did get an output, and my comments:

    - Just this single test consumed 100% of the chat's 330k token limit and 85% of free tier capacity, so I can't even re-evaluate the capability with a more reasonable/detailed prompt, or even giving it the solution.
    - A mid-step section calculates the UV/OV behaviour of a input protection device correctly, but mis-states the range in the summary.
    - There were several structural errors in the analysis, including assuming that the external power supply and lithium battery share the same input path, even though the netlist and components obviously have the battery 'inside' the power management circuit. As a result most downstream analysis is completely invalid.
    - The inline footnotes for datasheets output `4 [blocked]` which is a bare-minimum UI bug that you must have known about?
    - The problem and solution were in the context and weren't found/used.
    - Summary was sycophantic and incorrect.

You're leaving a huge amount of useful context on the table by relying on netlist upload. The hierarchy in the schematic, comments/tables and inlined images are lost. A large chunk of useful information in datasheets is graphs/diagrams/equations which aren't ingested as text. Netlist don't include the comments describing the expected input voltage range on a net, an output load's behaviour, or why a particular switching frequency is chosen for example.

In contrast, GPT5.1 API with a single relevant screenshot of the schematic, with zero developer prompt and the same starting user message:

    - Worked through each leg of the design and compared it's output to my annotated comments (and was correct).
    - Added commentary about possible leakage through a TVS diode, calculated time-constants, part tolerance, and pin loadings which are the kinds of details that can get missed outside of exhaustive review.
    - Hallucinated a capacitor that doesn't exist in the design, likely due to OCR error. Including the raw netlist and an unrelated in-context learning example in the dev-message resolved that issue.

So from my perspective, the following would need to happen before I'd consider a tool like this:

    - Walk back your data collection terms, I don't feel they're viable for any commercial use in this space without changes.
    - An explicit listing of the downstream model provider(s) and any relevant terms that flow to my data.
    - I understand the technical side of "Some metadata or backup copies may persist for a limited period for security, audit, and operational continuity" but I want a specific timeline and what that metadata is. Do better and provide examples.
    - I'm not going to get into the strategy side of 'paying for tokens'. but your usage limits are too vague to know what I'm getting. If I'm paying for your value add, let me bring an API key (esp if you're not using frontier models).
    - My netlist includes PDF datasheet links for every part. You should be able to fetch datasheets as needed without upload.
    - Literally 5 minutes of thinking about how this tool is useful for fault-finding or review would have led you to a bare-minimum set of checklist items that I could choose to run on a design automatically.
    - Going further, a chat UX is horrible for this review use-case. Condensing it into a high level review of requirements and goals, with a list of review tasks per page/sub-circuit would make more sense. From there, then calculations and notes for each item can be grouped instead of spread randomly through the output summary. Output should be more like an annotated PDF.

scottapotamas

9 か月前議論

Enjoyed the paper, thanks.

While there was brief discussion about environmental influence due to temperature and environmental EMI, it would be nice to get an idea of how this approach compares with regards to radiated emissions.

Fast edges and their wide spectral content are one of the earliest things to minimise/eliminate as part of compliance testing - other approaches aren't as active of an aggressor so getting to production may not be as easy given the stated goals for low cost/effort implementation.

The frequency domain data from the MXA shows the output during edge measurement, but there's no discussion about measuring how much these tones leak...

scottapotamas

9 か月前議論

Mostly used for biological targets, laser induced ultrasound is pretty impressive.

scottapotamas

10 か月前議論

For two DRP (dual role) devices connected to each other, I believe in a default case the one that happens to advertise as a source first just becomes one.

The standard allows for a role swap at any point while connected, and if that’s triggered will be dependent on the firmware/config on one or both ends.

There’s probably more nuance hiding in the real world hardware too.

scottapotamas

2 年前議論

As CAD tools go SW is on the lower end of the scale. Though the price increases have been feeling pretty abusive in the recent years.

Creo has come down relative to it's ProE days and is priced similarly to SW(?), and I believe NX still starts at double to triple per seat.

ANSYS (specifically Fluent) and similar simulation tools have eyewatering per-seat prices, though I'm a little out of date to know if they're less horrible about multicore licences etc.

scottapotamas

3 年前議論

I know it's easy to point at Electron specifically for examples of poor performance (and the author acknowledged it) but Spotify isn't a great example - it's the CEF flavour of web based frontend.

Slack on the other hand...

</nitpick>

コメント