Returning to contributing - high speed design tools

[James Jackson]

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.

[Jon Evans]

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

--
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+u...@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.

[James Jackson]

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.

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.

[Jon Evans]

> 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.

To view this discussion on the web visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CAMVX%3DtZojXDuAmtCKotrBwLj3NgJYqjO8ktbZvsR-a53Y4XBFg%40mail.gmail.com.

[Glen English]

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.

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.

[Oleg Endo]

Hi,

On Mon, 2024-02-26 at 19:03 +0000, 'James Jackson' via KiCad Developers
wrote:

>
> 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.
>

You might want to have a look at the net inspector dialog. I needed a
similar functionality a while go to get a design job done, so I rewrote the
net inspector dialog to be non-modal and updating the trace lengths in real-
time as they are being placed (after dragging, not during dragging).
Perhaps it could give you some ideas.

Best regards,
Oleg Endo

[James Jackson]

Hi Oleg - Yep that functionality  is being used as the basis for a new dockable version, with improved searching / grouping.

Glen - Likewise very comfortable with how Altium handles signals, but need to be careful to do things from a 'solving problems' perspective, rather than a 'like this product does'. It's all good information to feed the design process though.

Yours,

James.

--
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+u...@kicad.org.

To view this discussion on the web visit https://groups.google.com/a/kicad.org/d/msgid/devlist/2e03e6de7f488edfa669deadb8aa2281104440d6.camel%40gmail.com.

[Oleg Endo]

Hi James,

> Yep that functionality is being used as the basis for a new dockable version, with improved searching / grouping.

Great! I'm curious to see what you can come up with. In particular w.r.t.
the searching/filtering/grouping, especially the grouping.

The grouping functions that I've put in there are a bit difficult to grasp.
What I needed was effective end-to-end length tuning of 16+ bit bus across
different networks and through some damper resistors. I hope you can come up
with a more user friendly UI for things like that :)

Best regards,
Oleg Endo

On Fri, 2024-03-01 at 07:53 +0000, 'James Jackson' via KiCad Developers

> To view this discussion on the web visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CAMVX%3Dtaii5BAc%3DarQ1WEYFRXhN35AB016pYytt5ZN5XOWLDzEw%40mail.gmail.com.

[James Jackson]

Hi Olag,

So I think the primary source of grouping information will be through integration with DRC constraints. For example, for a wide bus like you describe, one could have a constraint such as:

(rule "AddressBus"

     (constraint length (min 39mm) (max 40mm) (opt 39.5mm))
     (condition "A.NetClass == 'DDR_Addr' && A.fromTo('IC1-*','IC2-*' )")

The Net Inspector would group all nets matching this constraint. Likewise for skew constraints (although length + skew constraints matching the same criteria I'll aim to display on the same line). There's probably some complexity here with nested constraints (e.g. a net which matches a bulk bus constraint like that above, but which also contains differential pair constraints within), but we'll solve those when we get to them.

I also I intend to leave the option to group by a freetext field searching on netclass and net names, sort of as exists currently, and the option to just group by netclass, for cases where constraints have not been defined.

For signal constraints, it'll be very similar - but signals are currently not really defined at all, so I won't say much more other than I'd expect signals to group by constraints and / or signal name patterns too.

Hope that all makes sense?

Yours,

James.

To view this discussion on the web visit https://groups.google.com/a/kicad.org/d/msgid/devlist/b56852dbf1e445d1ab5e7938e363f940f0cb9b11.camel%40gmail.com.

[Glen English]

But... for a large design we'd end up with pages and pages of rules. Which is fine if they are generally hidden / encapsulated by the user. 

I'm all for the basis of the rule sytsem being all text DRC. But-  I already have  pages of rules with my basic experiments with Kicad. I have suggested elsewhere that rules get broken up into categories, so that the pages of rules can be broken up to reduce the scrolling required...

There also needs to be more fine grained control of what is a batch DRC checked rule, and what is a real time ("online" DRC ) rule (or both)

As for timing. I would suggest : 

 I think text based for defining the point to point rules is fine- that's an acceptable task because for a design that needs such work, writing up the rules in text format will be a very small part of the overall workload.

I think an Xsignals like panel s is excellent for seeing what all those rules and nets are doing in real time. 

[James Jackson]

Hi Glen,

For what it's worth, I do agree that the editability / organisation of rules could do with some evolution. It's definitely a topic of live discussion on the issues! But the tuning tools is orthogonal to whatever does or doesn't happen in that space; the starting premise is that the DRC rules are the source of information for such activities. Evolving the presentation / management of them could happen in parallel if supported.

James.

[Glen English]

Hi James. Yeah I agree text based rule core is a fine way of representing it. 
What we will find is that as the rule base grows, the online DRC functions  will start chewing considerable processor resources- it will likely need to be spun out into another low priority thread.  

Maybe the plain  english rule base language will need to be tokenized in the background to reduce the text parsing  load of rule threads. (maybe it already is I dont know) 

There is a desire by many users to bring more of the rule base into real time "online" space, IE many things I beleive should be examined as the user places tracks, via etc - so that it does not need to be cleaned up later (big productivity issue )  and so how this is done and how efficienctly under the hood will begin to matter.
-glen

On Saturday, March 2, 2024 at 8:

[James Jackson]

Hi Glen,

Yes I've already raised the (potential) issue of the real-time computation cost of the length tuning rules - it's essentially an O(MxN) algorithm (M = number of rules, N = number of PCB items), which does worry me from a scaling point of view as people hopefully develop more complex boards as the high speed tools develop. As you say there are various mitigations to this: worker threads, intelligent caching, pre-computation, etc etc. All stuff to consider.

Yours,

James.

[James Jackson]

Hi Glen,

Yes I've already raised the (potential) issue of the real-time computation cost of the length tuning rules - it's essentially an O(MxN) algorithm (M = number of rules, N = number of PCB items), which does worry me from a scaling point of view as people hopefully develop more complex boards as the high speed tools develop. As you say there are various mitigations to this: worker threads, intelligent caching, pre-computation, etc etc. All stuff to consider.

Yours,

James.

On Fri, 1 Mar 2024 at 21:58, Glen English <gleneng...@gmail.com> wrote:

[Glen English]

and of course, for the 'online DRC' - it doesnt always have to be MxN, since the operation only has to be on what is changing.  Batch DRC, well that is an MxN problem, but can be spun into multi threads if it takes too long. Altium spun the batch DRC (the one you run just before you send it away to be fabbed ) into multi threads a few years ago.  

For timing - Altium spent considerable effort making the Xsignals creation completely GUIable- but I do not think it is worth the effort- compared to users defining signal rules and signal groups  in text format... (do not forget groups since this info is required so that the signal timing analyser  panel wil need to display the group ) 

*What does need to be in there is that if there is a re-annotation of the design, then if designators are specified in the rule text, the designators need to be updated by the tool  to reflect the annotation.*

IE if you define signals from U1-15 to U10-3 ,  now there is an annotation dependency. anyway, you understand. deep inside, altium deals with UUIDS to manage that, bu I dont think that's strictly necessary unless you end up with duplicate designators amongst the timed signal rules !

[James Jackson]

Quite - that's exactly my point about possibilities of optimisation - lots of options for how to do so. But all those require re-architecting of existing underlying 'stuff' to enable it. (Batch DRC already uses worker threads, by the way, for some types of rules, but not currently for the length / skew constraints as they are relatively quick to run, but haven't yet explored them in the interactive context.

For signals, the integration with the DRC is actually going to fairly simple, the smart moves will be in how to integrate them in the schematic capture. I don't think text interface as the primary route for signals makes sense. Whether it ends up as wizard-driven as Altium I couldn't say. Haven't really put a huge amount of thought in to it yet. But some simple way of defining signals will be pretty key.

James.

[Oleg Endo]

Hi James,

On Fri, 2024-03-01 at 13:58 +0000, 'James Jackson' via KiCad Developers
wrote:
>

> So I think the primary source of grouping information will be through integration with DRC constraints. For example, for a wide bus like you describe, one could have a constraint such as:
>
> (rule "AddressBus"
>      (constraint length (min 39mm) (max 40mm) (opt 39.5mm))
>      (condition "A.NetClass == 'DDR_Addr' && A.fromTo('IC1-*','IC2-*' )")
>
> The Net Inspector would group all nets matching this constraint. Likewise for skew constraints (although length + skew constraints matching the same criteria I'll aim to display on the same line). There's probably some complexity here with nested constraints (e.g. a net which matches a bulk bus constraint like that above, but which also contains differential pair constraints within), but we'll solve those when we get to them.
>
> I also I intend to leave the option to group by a freetext field searching on netclass and net names, sort of as exists currently, and the option to just group by netclass, for cases where constraints have not been defined.
>
> For signal constraints, it'll be very similar - but signals are currently not really defined at all, so I won't say much more other than I'd expect signals to group by constraints and / or signal name patterns too.
>
> Hope that all makes sense?
>

Thanks for the explanation. Yes, this sounds good -- establishing net
groups in some rule file. Of course in practice, it all depends on how
complex the "condition" expression is allowed to be.

The support data structures to have those things working fast in/with the
tree view thing can be a bit annoying to figure out, from what I remember...

Best regards,
Oleg Endo