UI Feature Improvements

Ideas
,
1

Hey all!

I’ve been using Quilter quite a bit during a recent board design project and I’ve tried to upload the board design up to Quilter to see what it does at each phase of the design. This has resulted in me clicking in the UI quite a bit and I have some ideas on things that could be changed or added to make it easier.

Delete All Button for Constraints (Diff. Pairs, Decoupling Caps).

I’ve found that many of my designs fail because the constraints seem to be too tight. Not sure if that’s actually the case, but I’ve found I’ve spent the most “wasted” time in the UI, constantly mashing the delete button to clear out all of one or the other set of constraints that was autogenerated.

Upload or save set of constraints configuration

Since my workflow is something like this:

  1. Finalize schematic
  2. Draw board outline and import footprints
  3. Upload to quilter
  4. See results
  5. Place any components I’ve decided have an “idea” place based on quilter’s ideas
  6. Route critical traces I think should be different than what quilter did
  7. Upload and repeat steps 3 → 7

I find that I’ve spent a lot of time re-setting the configuration for a “run” of quilter. It would be nice to be able to copy the config from a previous run or export /import it in some way so that once I declare: “this decoupling cap is correct for this pin” I don’t have to always recheck that the auto generated decoupling is correct or re-add it.

Explain Why a Job Fails

I’ve been throwing a lot of stuff at Quilter and interestingly, I’ve found that most of my jobs fail. It’s really not obvious to me why generally, but it seems like the time a job took falls in one of a few buckets which would suggest that there are at least broad categories of “why” for failures. I know this is a big challenge for any generative / ML project, but trying to make an effort to explain why, could greatly accelerate usage of quilter.

For example, all of the screen shot below are my runs with one board file. You can see that some of the failures seem to cap at < 2 hours, while some have run up to 8 hours.

Perhaps broad categories could be like:

  • Could not place all components
  • Could not route all traces
  • Could not solve constraints
  • etc

image
image1876×1416 238 KB

Anyway, it’s a very interesting project and looking forward to seeing it grow.

1 Like
2

Thanks a ton for taking the time to share your feedback in the way you did, Keenan—we appreciate it very much! We have a few things already in the pipeline (but not quite ready yet) which hopefully will address some of your points, and we’ll continue factoring in the other points along with some similar feedback we’ve received from others. :bowing_man: :pray: :sparkles:

3

To add a little more detail…

Delete All Button for Constraints (Diff. Pairs, Decoupling Caps).

We’ve got an improvement fix for this that’s been developed and is in review. We’re working to get a big release out the door this week but this is this should get out shortly.

Upload or save set of constraints configuration

This is another suggestion we’ve heard a lot recently. We need to solve the challenge of how to ensure that old constraints are still valid in the context of the new input files (netlist, comps), but this is surely something that would make iteration easier.

Explain Why a Job Fails

Quilter typically has two different failure modes:

  • We returned candidates (total > 0) but couldn’t finish any of them. In this scenario, would a “light DRC report” help surface which parts couldn’t be placed, or which nets couldn’t be routed?

  • We didn’t return any candidates (total = 0), which usually indicates a silent failure internally to Quilter. While we could work to categorize these issues, the reality is that they should never happen – they represent either a bug, or a constraint that we can’t handle that we should have filtered out at the input.

The second bucket requires what is currently undocumented context. Even if it were, they’re edge cases that we shouldn’t expect users to pre-read – things like:

  • We can’t handle differential pairs that terminate in non-adjacent pins
  • We usually can’t handle multi-drop or “fly by” differential pairs
  • We have a higher failure rate on boards with pre-routed traces

So my thinking would be to provide better visibility into bucket 1, and provide better guardrails and messaging on bucket 2.

What do you think?

4

This improvement is now live!

5

Please include Polygon pours for high current traces instead of routed traces