Sida 1 av 1

Autoroutingproblemet

Postat: 27 augusti 2007, 10:26:14
av SvenW
Jag håller på att studera Autorouting-problemet, dvs att mer eller mindre automatiskt överföra en SCH-representation av en krets till en PCB-dito. Finns det någon som har tips och input att ge?
Litteratur, algoritmer, strategier och metoder på matematisk eller praktisk nivå. Jag är inte intresserad av namn på program som innehåller funktionen, utan vill förstå problemet från grunden.

Postat: 27 augusti 2007, 10:38:48
av limpan4all
Googla på "manhattan routing" och "shaped based routing".
Och för komponentplaceringen "cluster placement".

Vid all normal PCB konstruktion ligger den viktigaste delen i komponentplaceringen och till en viss del i hur grindar/pinnar används. Med en underbar komponentplacering går routandet snabbt och enkelt.
Men komponetplaceringen kräver avsevärt mera kompetens än ledningsdragningen.

Postat: 31 augusti 2007, 10:27:38
av SvenW
Tack för tipset. Har hittat en del, även om många artiklar mest har varumärkesexponering som syfte eller stöder Predikaren i hans ord: --Ingen ände är det på det myckna bokskrivandet, och mycket studerande gör kroppen trött.
Jag laborerar med a-star algoritmen och tänker lägga in den i en stokastisk process, i stil med 'simulated annealing'. Är det så de kommersiella programmen fungerar?
Jag vill ha in autorouting i Hec innan jag fortsätter med crossprobing. Vad gäller komponentplacering tänker jag mig att den ska vara manuell. Just nu har jag bara en termometerskala som visar summan av avstånden pin-pin. Har kommersiella program automatfunktioner för komponentplacering?

Postat: 31 augusti 2007, 21:21:02
av flippy
testa att söka på typ "vlsi routing", när jag letade efter samma sak så fanns det en del bra sidor, hittade även nån bok som verkade bra. Det var nog nåt kapitel om routing, en vlsi bok var det då.

Postat: 2 september 2007, 11:50:15
av SvenW
Tack. Jag hittade en hel del.
Fast de talar ofta om miljoner komponenter, och jag nöjer mig med några dussin. Jag siktar mot mönsterkort för hobbyister, och vem orkar löda miljoner lödpunkter? Men en del grundläggande är förmodligen gemensamt.

Postat: 15 november 2007, 19:28:04
av SvenW
Har nu jobbat med en autorouting-algoritm några månader, och har en dellösning som ser ut att fungera. Det är fascinerande att se hur snabbt den hittar ett bra mönster.

Den testar något tusental varianter per sekund och väljer ut den bästa.

Jobbet är fascinerande, och om någon programmeringskunnig vill prova och kanske förbättra algoritmen så är det lätt för mig att lägga ut den på min webbsida. Eljest håller jag nog på och putsa ett par månader till, innan den kommer med i en ny patch-level av Hec.

Postat: 15 november 2007, 19:47:17
av blueint
Vilken licens har du tänkt dig?
För övrigt kanske algoritmen bör ta hänsyn till crosstalk, differential ledningar, belastning, isolationsavstånd etc..

Postat: 15 november 2007, 20:13:50
av SvenW
Licensen är GPL.
'Crosstalk, differential ledningar, belastning, isolationsavstånd etc...' är postprocessing.
Jag tar inte in detta i algoritmen primärt, men det kommer sedan in som korrektioner. Isolationsavstånd, alias clearance, finns redan rudimentärt.
Man kan för övrigt flytta sin layout till gEDA::pcb och där göra vidareprocessing.
Hec skall bli kompatibelt med gschem och PCB vad gäller filformat. Inte fullt ut ännu, men det går bra att flytta en Hec-konstruktion till gEDA::pcb.

Postat: 15 november 2007, 21:05:41
av blueint
Har hänt mer än en gång att jag skulle vilja skriva en "netlist" direkt med text och ha ett program som gör både schema och pcb av det.
Vore jättebra om du fick det att fungera. Skulle underlätta routing av t.ex. Minimig projektet.

Re: Autoroutingproblemet

Postat: 1 november 2009, 09:17:06
av SvenW
Väcker den här tråden igen efter ett par år.

Jag håller fortfarande på att studera autorouteralgoritmer och vill gärna veta om någon har fler tips.
Mer specifikt:
Hur bygger man idag en PCB-autorouter. Lättläst litteratur i ämnet, gärna på nätet, eller om någon har bra idéer och kan beskriva dem.
Jag har kommit en bit på vägen genom att testa algoritmer i xhec.
Välkommen att testa/kriticera/vidareutveckla den. Eller kanske att testa/presentera helt nya idéer. Just nu har jag lite idetorka.

Re: Autoroutingproblemet

Postat: 9 november 2009, 11:22:48
av psynoise
Söker man på http://www.inspec.org kommer det upp ganska många resultat från tidningen Printed Circuit Design, tyvärr finns den inte på Chalmers bibliotek men det kanske går att beställa hem. Tror även att det finns några datorer på biblioteket som man kommer åt utan att vara student, och där finns det Inspec och IeeeXplore som borde ha mängder med information i ämnet.

Re: Autoroutingproblemet

Postat: 9 november 2009, 12:05:18
av blueint
Kanske är som optimeringsproblemet med plockepin där ett antal pinnar av olika längd efter varann ska kombineras för att få in flest i en ram där längden är begränsad på ett håll (Y), och man ska använda så lite längd åt det andra hållet(X). Enda svaret matteprofessorn kom upp med var trial-and-error. Dvs man får låta datorn prova alla kombinationer tills det passar.

Lite nyttiga länkar:
SvenW hemsida
xhec hemsida

Re: Autoroutingproblemet

Postat: 9 november 2009, 16:56:31
av SvenW
Det var ett tag sedan jag var student, men ett besök på Chalmersbiblioteket vore kanske värt besväret. Antar att allmännheten kommer in, åtmistone för att läsa tidskrifter.

Den autorouter som nu finns i xhec fungerar just efter trial-and-error-principen. Den betygsätter ett valfritt antal lösningar, typisk några tusen, och väljer ut den bästa. Men antalet kombinationer blir astronomiskt när pinnantalet växer. Den optimala lösningen kan man i allmänhet inte hitta, men förhoppningsvis en som är tillräckligt bra.
Det går i alla fall tusen gånger fortare än att pröva sig fram manuellt. Speciellt vid enlagersproblem.

Re: Autoroutingproblemet

Postat: 9 november 2009, 17:07:06
av limpan4all
Efter att faktiskt ha använt autorouters i 15 år för PCB layout.
Gör dina algoritmer massivt parallella, iallafall för varje enskilt seed.
Sedan kan en enkel singelprocess utvärdera vilken lösning som skall gå vidare till nästa seedomgång.
Detta då dagens processorer bara får fler och fler parallella beräkningsenheter, och den rent sekventiella lösningsmetoden faktiskt bara blir långsammare (eller bara blir marginellt snabbare).