pcb

add route style attributes

Bug #698771 reported by danmc
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gEDA
New
Wishlist
Unassigned
pcb
New
Wishlist
Unassigned

Bug Description

The PCB netlist looks like:

netname [stylename] elname-pinnum elname2-pinnum ...

The optional stylename is used to assign a route style to a net that the autorouter will honor.

It would be good to find a way to enter these route style attributes to the net in the schematic and have the gnet-PCB.scm backend propagate that attribute to the netlist.

If there is an easy way to grab net attributes based on netname in a gnetlist backend, then this should be quite simple.

I'd propose the attribute be called "routestyle".

-Dan

Revision history for this message
Peter TB Brett (peter-b) wrote :

This sounds like the sort of thing that could most easily be implemented in the 'pcbfwd' backend.

Traumflug (mah-jump-ing)
Changed in pcb:
importance: Undecided → Wishlist
Traumflug (mah-jump-ing)
Changed in geda-project:
importance: Undecided → Wishlist
Revision history for this message
Evan Foss (evanfoss) wrote :

Igor2, John Dotty and I were all planning something like this to the gEDA side of things. Attached is what I was thinking this would look like. To me route properties are for the whole net and trace properties are for segments of that net so your netlist format would be an obstacle for me. Is there some compromise we can hit between the two? What do people think of my idea?

http://permalink.gmane.org/gmane.comp.cad.geda.user/47605
http://permalink.gmane.org/gmane.comp.cad.geda.user/47621
http://permalink.gmane.org/gmane.comp.cad.geda.user/47617

Revision history for this message
Vladimir Zhbanov (vzhbanov) wrote :

Evan,
nothing prevents you from doing the pcb backend you want your way
using the variables you want.

As an example, for spice we have two backends in the main geda-gaf
repository and at least one outside it (I mean John Doty's one).

Cheers,
  Vladimir

Revision history for this message
Evan Foss (evanfoss) wrote :

Vladimir,

Can I assume this also means that adding trace and route attributes won't cause a conflict?

Thanks,
Evan

Revision history for this message
DJ Delorie (djdelorie) wrote :

Note that pcb's File->Import uses a different backend which bypasses the netlist format, you might want to peek at that one also (gnet-pcbfwd.scm)

Revision history for this message
Vladimir Zhbanov (vzhbanov) wrote : Re: [Bug 698771] Re: add route style attributes

> Can I assume this also means that adding trace and route attributes
> won't cause a conflict?

Evan,

What conflict do you mean? With developers? Or with the current software
we have? If you mean the former, for sure. If the latter, nobody knows.
Yeah, I'm kidding, sorry :) Seriously, I believe nobody would stop you
from trying your ideas. I, for one, encourage you to use official
repositories to do your work. Just don't merge highly unfinished or
very buggy stuff into the master branch. Minor bugs are welcome if there
are a high increment in functionality :)

Cheers,
  Vladimir

Revision history for this message
Evan Foss (evanfoss) wrote :

Ok thanks. I posted the following in email a minute ago but it should be here so I am going to repost it.

*****

I have the following proposal. Before I start I just want to say : Yes
I know this is not possible yet because we are flattening nets.

We add a route attribute that has a few options for things such as
star - make a star connection (ex star ground)
bus - route as bus keeping all the traces grouped as you move them.
diffpair - route as a differential pair
matchedl - matched length
(we will probably want more later for things like matched impedance,
strip lines, and etc)

It should also let you pass options to those options with [ ] and it
should have scope.

local - this route option applies to the stuff visually connected
page - this route option applies to just the stuff on this page
global - this route option applies to everything in the design
(default because only star )

Scope should not be over ridding you should be able to combined them
so local scope works in that area but the connection to the greater
hole is done via the global definition.

Finally you can stack them with a ;

Some examples

route=star:local
- All the stuff drawn in this area of the schematic (where the nets
are visually connected) are in a star configuration with a center to
be defined in the PCB layout stage or via a more involved mechanism I
will describe later.
route=star[U2:2]:local
- All the stuff drawn in this area of the schematic (where the nets
are visually connected) are in a star configuration with U2 pin 2 at
the center.
route=star[CONN1:1]:page
- This on a trace just before a ground symbol and all the pins
connected to ground on that page get their own trace to a central
grounding point at CONN1 pin 1.
route=star[SCREW1]:global
- Every pin on that net irrespective of the layout on the schematic or
page gets it's own trace to the designated center of the star a plated
through screw hole.
route=diffpair[SR0H,SR0L]
- Since no scope is stated this would be global and it would cause the
two nets SR0H and SR0L to be routed as a differential pair
route=matchedl[D0,D1,D2,D3,D4,D5,D6,D7, RW, RESET]
- Since no scope is stated this would be global and all of the nets
named between the [ ] marks should be routed with matched length
traces

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.