Hi all,
I contributed a bit back before the v6 and v7 releases, but due to a new
job and moving house I had to take a step back from development. I've got
some time available again, and the 8.0.0 release has spurred me on again. I
would like to work on some features for 9.00, primarily around tooling to
support high-speed designs. Having recently been designing some boards with
more complex memory layouts, and some sensitive test equipment design, this
functionality would be hugely useful, and I see it is raised in issues
fairly regularly. This would build on the (excellent) improvements made to
the tuning tools for 8.0.0.
In particular, I'd like to explore (in order):
1. Ability to tune trace length by signal propagation time. To include:
a. A method to define per-layer / per-netclass, pad-to-die, and via
signal propagation speeds. (What about units? Allow ps / mm, ps / mil, and
ps / inch?)
b. New DRC constraints on trace delay and time skew (analogous to those
existing currently for length and length skew)
c. Update tuning tooling to use time-based calculations when relevant
configuration / constraint information is present / when the mode is
selected.
d. Update status bar display to show propagation delay for selected
nets when relevant configuration / constraint information is present.
I've had a look through the current code and that all seems fairly doable.
There are some decisions to be made about whether the tuning tool should
use time-based mode if all relevant data is available, whether it should be
a manual selection, and what the fallback behaviour should be if some data
(e.g. via propagation time) hasn't been set (could revert to length-based
tuning, provide an error, etc - easier for DRC - if the data isn't there to
calculate a defined time-based rule, that's a DRC error in itself!). I also
note there are three places track lengths are calculated:
BOARD::getTrackLength, MEANDER_PLACER::lineLength, and
DRC_TEST_PROVIDER_MATCHED_LENGTH::runInternal; need to determine which is
(or should be) authoritative. Would be good to understand the history of
why the three methods exist, and whether than can (or should) be refactored
to a common piece of code too.
2. A 'tuning inspector' (dockable widget, like the properties inspector)
which shows in real-time the state of any length and / or skew constraints
against matching or chosen nets. This would be particularly useful for
tuning net skews on large collections of nets. For example, I currently run
a hacky python script which queries the board layout every few seconds to
calculate the length of defined nets and displays this in the terminal.
Issues to consider:
a. As far as I can see, the algorithm to match PCB geometry items to a
constraint rule is weaky quadratic (O(Num_Rules * Num_PCB_Geometry_Items)).
Running this in real-time would potentially be a performance killer, so
need to consider some way to choose a set of constraints / matching nets to
watch. Would also need to be updated on DRC rule changes, and need to
monitor items being added to / removed from the board (do hooks exist for
this, or do we need to regularly recompute?). If watching for board changes
is a pain, thoughts include running any processing in a background thread
and re-compute every (for example) 1s.
b. There's a load of follow-on questions here to discuss with DRC
engine experts (can one extract a set of rules for a user to choose from,
or do we need to run the algorithm against all PCB items and show the
matching sets for the user to choose from?)
3. Signals! All of the above but for the signals concept. Lots to explore
there. Much larger project than 1) or 2) so won't pontificate yet.
Clearly there's a fair amount of inter-dependent work to get right to do
this: synchronisation with any other planned development that may touch
these areas, UI choices, integration with constraints engine, defining
propagation delays per layer etc etc. I aim to put together a proposal
document with a roadmap, but to enable discussion for this, I used to be on
the Zulip Chat, but have changed my email address fairly recently. Is it
possible to get a new link please? I would of course welcome any and all
comments on the above thoughts too!
Thanks,
James Jackson.
--
You received this message because you are subscribed to the Google Groups
"KiCad Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to devlist+unsubscr...@kicad.org.
To view this discussion on the web visit
https://groups.google.com/a/kicad.org/d/msgid/devlist/CAMVX%3DtZ4Q8yGJkJe2CVZaMekgHWcL5%3DimNtRc0DJf_%2Bt%2BgVONg%40mail.gmail.com.
