Have you guys looked how Altium does with with Xsignals ? anyone looked at my posts about this in the kicad forum.?
it's a pretty good template. On Tue, 27 Feb 2024 at 09:34, Jon Evans <[email protected]> wrote: > > The question is which groups of geometry items to show the total length > for in the dialog - do we should entries for any set of items which matches > a length / skew DRC rule, or let the user select which they'd like to have > displayed? > > Why would the answer not be "all routed geometry on the given net"? > > > I think there's an issue of how to calculate these efficiently in > real-time during PCB routing due to the O(N*M) nature of the current > algorithm. > > I would want to see that it's a problem before assuming that it's a > problem. We currently can show lengths in real-time. > > > My question is can we do this before we start routing the board (i.e. > query the DRC data structures for some human-readable list of length / skew > rules)? We could then only run these constraints against the board during > routing to potentially reduce the O(N*M) burden by making the contribution > of rules shorter... > > What do you mean by "during routing"? If you mean frame-by-frame for the > currently-routed net, we already do query for more specific constraints up > front. If you mean "after every editing action", it would make more sense > to me to update all lengths rather than just a few. > > On Mon, Feb 26, 2024 at 5:16 PM 'James Jackson' via KiCad Developers < > [email protected]> wrote: > >> Hi Jon, >> >> I thought that might be the case - no worries syncing up with whatever >> else is in train. Happy to start with Number 2 for now. >> >> Sorry, I'll try and explain my train of thought better, which might >> invalidate the premise. The question is which groups of geometry items to >> show the total length for in the dialog - do we should entries for any set >> of items which matches a length / skew DRC rule, or let the user select >> which they'd like to have displayed? >> >> In either case, I think there's an issue of how to calculate these >> efficiently in real-time during PCB routing due to the O(N*M) nature of the >> current algorithm. In any case, if we go for the 'let the user select which >> constraint sets they'd like length / skew info displayed for), this led to >> the 2b question: >> >> Take this ruleset as an example (from >> https://gitlab.com/kicad/code/kicad/-/issues/17079): >> >> (rule "length_DDR_CMD_FPGA_To_IC13" >> (constraint length (min 42.5mm) (max 43.5mm) (opt 43mm) ) >> (condition "A.NetClass == 'DDR4_CMD' && A.fromTo('IC14-*','IC13-*' )" ) >> ) >> >> (rule "length_DDR_CMD_IC13_To_IC5" >> (constraint length (min 16.5mm) (max 17.5mm) (opt 17mm ) ) >> (condition "A.NetClass == 'DDR4_CMD' && A.fromTo('IC13-*','IC5-*')" ) >> ) >> >> We can't rely on just the NetClass to select items to count for a given >> entry in the dialog, we need to enumerate items against the rule to produce >> the sets we can display total lengths / skews for - which is my inference >> from the current DRC code which runs these checks. My question is can we do >> this before we start routing the board (i.e. query the DRC data structures >> for some human-readable list of length / skew rules)? We could then only >> run these constraints against the board during routing to potentially >> reduce the O(N*M) burden by making the contribution of rules shorter... >> >> Jon's kindly sorted me out with a link so all good there. >> >> Yours, >> James. >> >> >> >> On Mon, 26 Feb 2024 at 21:45, Jon Evans <[email protected]> wrote: >> >>> 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 >>> <https://groups.google.com/a/kicad.org/d/msgid/devlist/CA%2BqGbCBZ2vskDb9EjSrrZu61K_SyUhJ-NJ_rvjYzK8ZRK2kPxA%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/CAMVX%3DtZojXDuAmtCKotrBwLj3NgJYqjO8ktbZvsR-a53Y4XBFg%40mail.gmail.com >> <https://groups.google.com/a/kicad.org/d/msgid/devlist/CAMVX%3DtZojXDuAmtCKotrBwLj3NgJYqjO8ktbZvsR-a53Y4XBFg%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%2BqGbCChVs8%2BSR%2B3v2Zc9_2fwtGpY6oGRWetkCsFLbEb2xd%2BZA%40mail.gmail.com > <https://groups.google.com/a/kicad.org/d/msgid/devlist/CA%2BqGbCChVs8%2BSR%2B3v2Zc9_2fwtGpY6oGRWetkCsFLbEb2xd%2BZA%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/CAEuX16u_69wiNqNULf%2B238TrczG6%3DS3FYf7v3pbZTPoxpio24A%40mail.gmail.com.
