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 <j...@craftyjon.com> 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 < > devlist@kicad.org> 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 <j...@craftyjon.com> 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 < >>> devlist@kicad.org> 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 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 >>>> <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 devlist+unsubscr...@kicad.org. >>> 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 devlist+unsubscr...@kicad.org. >> 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 devlist+unsubscr...@kicad.org. > 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 devlist+unsubscr...@kicad.org. 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.
