Re: gEDA-user: Toporouter Changes

[Bill Gatliff <bgat@xxxxxxxxxxxxxxx>]

John Griessen wrote:
> Crosstalk is always a function of which wires, not parallels in general.
>   

Right, so I guess that analysis on a routine basis won't tell you 
much--- so I'll retract that suggestion.

I do think there would be some merit in looking at the statistics of 
trace lengths, though.  But since a circuit only works if all the traces 
are there, that would be a higher priority than trying to minimize trace 
lengths compared to another autorouter.  So that one is probably too 
academic to be of interest right now, too.  Darn, that makes me 
zero-for-two.  I'm going to go console myself with an Oreo.  :)

> What an autorouter that goes to completion can get you that is so valuable is
> a way to generate three what-if cases of the same netlist where you set up
> different constraints in advance to guide the autorouter.  Comparing those and selecting the best
> is highly valuable.  It's a case by case individual thing though.
>   

Understood.  Put another way, there's no substitute to knowing the 
capabilities of your tools, along with how to get those capabilities 
when using them.  And it seems like you only get that knowledge after 
burning good cash on bad layouts.  At least that's been the way for me!

> The next high value thing to do as human input is after a good autorouter run -- you
> push parts of the circuit away based on your knowledge of crosstalk susceptibilities.
> The best way I've seen to do that is with a DRC correct local autorouter that works like
>   a force field that pushes against circuitry in a user-chosen direction and lets it move until it hits
> design rule constraints.
>   

I bet that Anthony's toporouter probably has some hooks already in place 
that could make that possible.  The first trace one puts down on a board 
can go in an infinite number of directions, so he has to know that some 
paths are "better" than others.  Seems like the force-field approach 
just tweaks his "better" definition based on user input and not just the 
board geometrics.

So it's probably, what, ten lines of code or so to implement?  He could 
just throw that in at the same time he's tinkering around with those 
magic "via" things everyone seems so keen on.  :) :)


b.g.

-- 
Bill Gatliff
bgat@xxxxxxxxxxxxxxx



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user