Hi James, I think there are a number of people working on things in this area so it will be important to coordinate. I don't think working on time-based tuning should be started until some other overhauls to the existing length-based system are farther along.
I would suggest that if you are looking for something to work on in the short term, your number 2 is a good place (the UI). Nobody has started on this part. We already have a dialog that provides some of this (the Net Inspector) but it could use an overhaul, and converting it from a dialog into a dockable panel is a good idea. I would go this route rather than making a new thing. It has filter functionality which helps with the update speed thing. I am not sure what your 2b means. Why would the user need to choose from a set of rules? > 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? Please contact me off-list, the list hides your email address. Best, Jon On Mon, Feb 26, 2024 at 2:03 PM 'James Jackson' via KiCad Developers < [email protected]> wrote: > 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 [email protected]. > 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 > <https://groups.google.com/a/kicad.org/d/msgid/devlist/CAMVX%3DtZ4Q8yGJkJe2CVZaMekgHWcL5%3DimNtRc0DJf_%2Bt%2BgVONg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CA%2BqGbCBZ2vskDb9EjSrrZu61K_SyUhJ-NJ_rvjYzK8ZRK2kPxA%40mail.gmail.com.
