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 [email protected] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
