Re: gEDA-user: Toporouter Changes

[Bill Gatliff <bgat@xxxxxxxxxxxxxxx>]

Anthony Blake wrote:
> Hi All,
>
> Thanks to everyone who sent me boards to play with. The Meggy Jr board 
> helped reveal a rather tricky problem that I've only seen once before.
>
> I've updated the website (http://wand.net.nz/~amb33/toporouter/) with 
> boards from Kai-Martin Knaak, Ben Jackson, and Windell Oskay.
>
> After fixing a few problems this weekend, I'm quite happy with the way 
> the single layer code is working. See
> http://wand.net.nz/~amb33/toporouter/LED-toporouted-before-speccuts.png 
> to compare the current LED board screenshots with the solution from 
> before the weekend.
>   

I had to stare at it a few seconds to see the differences, but the later 
version is much improved!  It might help your case if you could 
highlight some of the differences, to make it easier for others to 
appreciate.  I'm increasingly fascinated by your work, in large part 
because you provide such tangible evidence of it!

I think you should also more clearly mention on your example pages that 
when you say that the toporouter "failed N nets", what you really mean 
is that the toporouter was unable to complete the board _without 
employing additional vias or other strategies_.  Otherwise, you are kind 
of under-selling yourself.  The boards that you didn't finish are really 
close, probably trivial once you add just a few vias.  I'm looking 
forward to that capability!

On the pdhobbs board, the toprouted output shows a failed net at the 
top-left corner of the board that seems like a trivial case.  Funny that 
it would miss that one--- and if it had found it, I think it could have 
completed at least one more net as well.

I'd be curious to see how the total track lengths compare between your 
toporouter output and the geometric autorouter's, and what the 
statistical variation in lengths is between the individual tracks of the 
two boards.  Does your output tend to find shorter paths but with 
occasional outliers, for example?  The answers might be interesting to 
the RF and power guys, and might also help you automate the tests to see 
if toporouter changes improve the test case outputs.

The geometric autorouter's octilinear output reduces the number of long, 
parallel traces that might lead to crosstalk.  Your traces are not 
generally linear so they're even better, but I do still see some long, 
semi-parallel outputs.  I'm thinking that your output should have better 
RF performance, but I'd be curious to see some simulations at some point 
down the road.  Not any time soon, though--- just keep the good code 
coming!  :)


b.g.

-- 
Bill Gatliff
bgat@xxxxxxxxxxxxxxx



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