Re: gEDA-user: Subnets
kai-martin knaak k...@familieknaak.de writes: Larry Doolittle wrote: All the cutting, sed-ing and pasting of the subcircuits to multiple instances, with replication of later changes on all copies is pretty unflexible. Agree 100%. +1 Cloning, referencing, or whatever we may call it, would need a fair amount of programming. Given that nobody has stepped up yet to implement it, this may be pie in the sky. For now I ask to just keep this use-case in mind for the future, while new concepts are developed that partition a PCB layout now. In the meantime, a more powerful copy procedure could reduce the effort: Imagine, the copy-buffer action would accept a string parameter that it adds to the refdes property of every footprint before actually pasting to the layout. If this string matches the string gnetlist attaches to subsheet symbols, the copied block of layout would fit the netlist. On copy, other footprints with the same refdes should be automatically removed. This solves the part of making the replication, which has been solved in various ways before, more or less conveniently. The maintanance part is not addressed, where existing solutions require the pcb-scripting cpapabilities of a DJ. I do not like the part about removing footprints on copy. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
Stephan Boettcher wrote: I do not like the part about removing footprints on copy. Maybe you like it better, if I call it move existing footprints to the location indicated by the buffer ;-) ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
Larry Doolittle wrote: All the cutting, sed-ing and pasting of the subcircuits to multiple instances, with replication of later changes on all copies is pretty unflexible. Agree 100%. +1 Cloning, referencing, or whatever we may call it, would need a fair amount of programming. Given that nobody has stepped up yet to implement it, this may be pie in the sky. In the meantime, a more powerful copy procedure could reduce the effort: Imagine, the copy-buffer action would accept a string parameter that it adds to the refdes property of every footprint before actually pasting to the layout. If this string matches the string gnetlist attaches to subsheet symbols, the copied block of layout would fit the netlist. On copy, other footprints with the same refdes should be automatically removed. Extension of this concept is obvious -- Add numeric parameters that are interpreted as coordinates relative to the current origin. An integer parameter for multiple copies. An angle parameter for incrementally rotated blocks... ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
kai-martin knaak wrote: In the meantime, a more powerful copy procedure could reduce the effort: Imagine, the copy-buffer action would accept a string parameter that it adds to the refdes property of every footprint before actually pasting to the layout. If this string matches the string gnetlist attaches to subsheet symbols, the copied block of layout would fit the netlist. That's a great idea for low-effort/high-value. At least for those of us who array things on mere boards instead of chips... John -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
That's a great idea for low-effort/high-value. At least for those of us who array things on mere boards instead of chips... http://www.delorie.com/pcb/renumberblock.c ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
DJ Delorie wrote: That's a great idea for low-effort/high-value. At least for those of us who array things on mere boards instead of chips... http://www.delorie.com/pcb/renumberblock.c Hmm... looks like that would work good for things I can select easily. Does what's pasted from the buffer stay selected? If so, then things that aren't rectangular could be renumbered as you paste. Can't stop and run it and see right now though. Next week. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
Does what's pasted from the buffer stay selected? Yes. I used it with a pcb script on the powermeter board. Each renumber adds 10 to whatever's in the buffer... LoadFrom(Layout,powermeter-blank.pcb) LoadFrom(LayoutToBuffer,channel1.pcb) # left upper, first one already there # First is at 200,0 PasteBuffer(ToLayout,0,3) RenumberBuffer(0,10) PasteBuffer(ToLayout,0,8) RenumberBuffer(0,10) PasteBuffer(ToLayout,0,13) RenumberBuffer(0,10) PasteBuffer(ToLayout,0,18) # Now skip 300 more for the next five RenumberBuffer(0,10) PasteBuffer(ToLayout,0,28) RenumberBuffer(0,10) PasteBuffer(ToLayout,0,33) RenumberBuffer(0,10) PasteBuffer(ToLayout,0,38) RenumberBuffer(0,10) PasteBuffer(ToLayout,0,43) # Other side pastebuffer(Rotate,2) RenumberBuffer(0,10) PasteBuffer(ToLayout,29,11) RenumberBuffer(0,10) PasteBuffer(ToLayout,29,16) RenumberBuffer(0,10) PasteBuffer(ToLayout,29,21) RenumberBuffer(0,10) PasteBuffer(ToLayout,29,26) # skip RenumberBuffer(0,10) PasteBuffer(ToLayout,29,36) RenumberBuffer(0,10) PasteBuffer(ToLayout,29,41) RenumberBuffer(0,10) PasteBuffer(ToLayout,29,46) RenumberBuffer(0,10) PasteBuffer(ToLayout,29,51) djopt(splitlines) # Teardrops() LoadFrom(Netlist,djtest.net) SaveTo(LayoutAs,djtest.pcb) Quit() ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
Thanks for that script. I like the way you load the netlist and save. So, whenever you think of a little change to the repeated cell, just remake the board with the script, then run DRCs on it, and output. That's what I did. I had one .pcb that was one channel, and one that was everything except the 16 channels. The script merged them. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
John Griessen j...@ecosensory.com writes: It's not pie in the sky. Some of these ideas to use sets and lists and groups are the easiest kind to implement... Zones in layout are an easy part of what it already does, when we have more layers for intermediate calculations. net attribs plus layout zones get us far on the way to autorouting success. If there is work put into partitioning a layout, can't we please have hierarchical layout instead? -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
On Mon, 2010-08-16 at 10:09 +0200, Stephan Boettcher wrote: John Griessen j...@ecosensory.com writes: It's not pie in the sky. Some of these ideas to use sets and lists and groups are the easiest kind to implement... Zones in layout are an easy part of what it already does, when we have more layers for intermediate calculations. net attribs plus layout zones get us far on the way to autorouting success. If there is work put into partitioning a layout, can't we please have hierarchical layout instead? I have still problems to understand the goals and benefits of partitioning hierarchical layout on PCB board level. Can you give an example, when possible with a picture? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
Stephan Boettcher wrote: John Griessen j...@ecosensory.com writes: net attribs plus layout zones get us far on the way to autorouting success. If there is work put into partitioning a layout, can't we please have hierarchical layout instead? They are independent enough that it's not a choice of either or. Both are possible. JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
Stefan Salewski m...@ssalewski.de writes: On Mon, 2010-08-16 at 10:09 +0200, Stephan Boettcher wrote: John Griessen j...@ecosensory.com writes: If there is work put into partitioning a layout, can't we please have hierarchical layout instead? I have still problems to understand the goals and benefits of partitioning hierarchical layout on PCB board level. Can you give an example, when possible with a picture? I usually have hierarchical schematics with multiple instances of the same subcircuits referenced from the main page. The deepest until now were three layers of hierarchy. All the cutting, sed-ing and pasting of the subcircuits to multiple instances, with replication of later changes on all copies is pretty unflexible. Hierarchical sub-cells (like with ASIC layouts) would allow to make and maintain such circuits much easier. What I am asking for here is, when you now talk about layout zones/partitions/whatever it's called in the end, please consider the application of the concept for this kind of hierarchy. Maybe the new concepts can be easily applied for that as well, with a little vision into that direction. Maybe it is trivial to allow multiple copies of a layout zone on a board, with a common netname/refdes prefix substituted on the copies. When you edit the layout of any copy, all instances follow the change. My eagle-using colleagues envy me for the hierarchical schematics that I can draw in gschem. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
Stephan Boettcher wrote: Stefan Salewski m...@ssalewski.de writes: On Mon, 2010-08-16 at 10:09 +0200, Stephan Boettcher wrote: John Griessen j...@ecosensory.com writes: If there is work put into partitioning a layout, can't we please have hierarchical layout instead? I have still problems to understand the goals and benefits of partitioning hierarchical layout on PCB board level. Can you give an example, when possible with a picture? I usually have hierarchical schematics with multiple instances of the same subcircuits referenced from the main page. The deepest until now were three layers of hierarchy. All the cutting, sed-ing and pasting of the subcircuits to multiple instances, with replication of later changes on all copies is pretty unflexible. Hierarchical sub-cells (like with ASIC layouts) would allow to make and maintain such circuits much easier. What I am asking for here is, when you now talk about layout zones/partitions/whatever it's called in the end, please consider the application of the concept for this kind of hierarchy. Maybe the new concepts can be easily applied for that as well, with a little vision into that direction. Maybe it is trivial to allow multiple copies of a layout zone on a board, with a common netname/refdes prefix substituted on the copies. When you edit the layout of any copy, all instances follow the change. Using blocks in mechanical CAD has some issues with this. In principle there are 2 ways to use a block: a) copy and paste b) reference Naturally the edit one modify all can only work with referencing. Sometimes in a single construction this is not desired, so when duplicating one has the choice between reference and copy. With mechanical constructions this goes as far as changing the appearance of a referenced block, when when an external block is changed independently. This can be useful, if the interface of the block is well understood. With pcb-layouts I strongly advise against this procedure: if a block gets inserted in a layout, a local copy has to be made (that is positioned nowhere) and references to this comprise the physical instances. Any attempt to modify a block with backpropagation to external data that is used in other boards will almost certainly break those layouts. When modifying a reference/instance of the (local) block one must get asked if opening the block is meant to change all instances or copy on write shall be used. About refdes-usage in this scenario: I find it hard to see an application of a block without using a corresponding sub-schematic. I would btw. like to be able to see only the basename of a refdes on the silk layer if it is made like schematic_name/schematic_local_identifier. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
On Mon, Aug 16, 2010 at 07:32:23PM +0200, Stephan Boettcher wrote: I usually have hierarchical schematics with multiple instances of the same subcircuits referenced from the main page. The deepest until now were three layers of hierarchy. I make do with two, but that's how I work also. All the cutting, sed-ing and pasting of the subcircuits to multiple instances, with replication of later changes on all copies is pretty unflexible. Agree 100%. Hierarchical sub-cells (like with ASIC layouts) would allow to make and maintain such circuits much easier. What I am asking for here is, when you now talk about layout zones/partitions/whatever it's called in the end, please consider the application of the concept for this kind of hierarchy. Maybe the new concepts can be easily applied for that as well, with a little vision into that direction. Maybe it is trivial to allow multiple copies of a layout zone on a board, with a common netname/refdes prefix substituted on the copies. When you edit the layout of any copy, all instances follow the change. I don't know about the trivial adjective, but I assert that's the goal, and would give me (and I suspect many others) a dramatic improvement in productivity and usability. The old get an electic circular saw after years of only using a hand saw analogy. My eagle-using colleagues envy me for the hierarchical schematics that I can draw in gschem. I do this in xcircuit, but at some point I may move to gschem. My biggest motivation, believe it or not, will be the better BOM support. - Larry ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: subnets
Using blocks in mechanical CAD has some issues with this. In principle there are 2 ways to use a block: a) copy and paste b) reference Naturally the edit one modify all can only work with referencing. Sometimes in a single construction this is not desired, so when duplicating one has the choice between reference and copy. With mechanical constructions this goes as far as changing the appearance of a referenced block, when when an external block is changed independently. This can be useful, if the interface of the block is well understood. Asic synthesis has a step called uniquification where you create a module and instantiate it multiple times. Uniquify will create a new module for each instance that can be modified independently from the others. You can also modify the master to change all the instances. It can get a little messy in that once you modify an instance then you can no longer touch the master or else all changes to the instance are lost. John Eaton ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: subnets
Ouabache Designworks wrote: Asic synthesis has a step called uniquification where you create a module and instantiate it multiple times. Uniquify will create a new module for each instance that can be modified independently from the others. You can also modify the master to change all the instances. Just a use case note: Although I am far from asic projects I would would have loved to have such a feature in the quiver. The project required eleven identical subcircuits. They had to be connected differently, though. So, a simple copy-paste would not do. I addition, I don't like projects with deliberately broken netlists. There is a similar technique in vector graphics apps like inkscape, coreldraw and illustrator. They call it cloning. It can get a little messy in that once you modify an instance then you can no longer touch the master or else all changes to the instance are lost. Sometimes, this is actually a useful feature. No need to cycle over all instances if some via needs to be enlarged. ---)kaimartin(-- @Rick: Is this posting any different? -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Subnets
At 01:16 PM 8/15/2010, you wrote: Rick Collins wrote: And what will these subnets translate into in a layout tool? How would that translation be handled in the net list? A net is a net in my designs. . . . If I really want to designate portions of a net that need to be separated by some PWB feature, I draw them as separate nets and then connect them with a part that is used to connect them in the layout. That's a simpler definition of schematic and that's fine for you to use that flow, completely separating layout from anything you consider in detail, letting someone else or an autorouter handle that. How would you make use of subnets that would be useful that you can't do with just nets? Make definitions of trace width quickly on a schematic by select-and-add-attributes, so an autorouter can run to completion with medium current handling traces routed DRC close to each other and other traces.\ I don't follow. How/why are you using subnets in the context? You can specify trace width without using subnets. If you mean you are specifying a portion of the net to have a different width, how is that conveyed to the autorouter? Is the subnet concept supported in a netlist format somewhere? In your work flow, English words convey duties to hired layout persons. In my example, I only hire the autorouter. Sounds very useful. Especially for open hardware projects and hobbyists, and bottom line oriented business folk. Maybe, but I am still not getting how it is actually used. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Subnets
I don't see anything in your post that actually addresses a need for subnets. Or maybe I don't understand what a subnet is. From the context used I figured it meant a portion of a net which had special attributes separate from the rest of the net. If you simply are talking about adding layout attributes to a schematic, well sure, that's not a bad idea. BTW, I still can't read your posts, they are all run together. I could read this one because I knew which part I wrote and which part you replied. Rick At 01:42 PM 8/15/2010, you wrote: Rick Collins wrote: How would you make use of subnets that would be useful that you can't do with just nets? Of course you can do everything manually in the layout app. Just like you can do any layout without a schematic in the first place. But the schematic serves as a convenient way to memorize all the necessary connections. For more than a dozen parts the convenience becomes a necessity. Same with net attributes. It is easy and intuitive to assign different rules in the schematic. The layout tool will automatically read from the netlist which net should be made fat to accommodate high current. Other may need extra spacing because of high voltage. This relieve the brain during manual routing. DRC will tell you when you err. An autorouter might also benefit if it knows about different minimum rules for different nets. IMHO, this feature would be a great leap forward. ---)kaimartin(--- -- Kai-Martin Knaak Ãffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Subnets
I see we are talking about two different things. I was responding to Andrew's post about splitting nets into portions with different properties. In my way of thinking if they have different properties, they should be separate nets. I see that your example of Power/Bypass we are talking about one net with different properties. Ii think it will be hard to convey the intricacies of power supply bypassing to an autorouter. One thing I find interesting is how in an example you say the two subnets can only join at P1. How do you define P1? To me this is the point between two separate nets... which is really what you are describing. The power net might be the copper plane layer of a PWB while the Bypass net would be the short trace between a chip pin and the cap. But where is P1? I have seen any number of discussions on whether it is best to put the cap between the power plane via and the chip or vice versa or if the power plane via can go between them. Does P1 get defined in the schematic somehow or is this left to the layout tool/person? This can be discussed in theory, but until it can be mapped to concrete examples of day to day use, I don't see the value. Do the autorouters make use of any attributes like this? Is this something that needs to be added to autorouters? Rick At 01:46 PM 8/15/2010, you wrote: On Sun, 2010-08-15 at 12:36 -0400, Rick Collins wrote: And what will these subnets translate into in a layout tool? How would that translation be handled in the net list? A net is a net in my designs. If I have a subnet that I want handled differently from the rest of the net, that is not something that is added to a schematic because it is not related to the schematic. It is a layout issue and I address it in layout. This is old workflow. You can go on using it, our indented changes will allow it still, of course. It is fine for small boards, for low speed design, for layouters who love to work hard and carefully... For my 1000 parts DSO board I was not really happy with this strategy. And I can not imagine that commercial EDA tools do not support the layouter in a similar way as we now consider. How would you make use of subnets that would be useful that you can't do with just nets? Maybe you missed some postings, and maybe my proposal: http://ssalewski.de/gEDA-Netclass.html.en ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
On Sun, 2010-08-15 at 14:10 -0400, Rick Collins wrote: I see we are talking about two different things. I was responding to Andrew's post about splitting nets into portions with different properties. In my way of thinking if they have different properties, they should be separate nets. I see that your example of Power/Bypass we are talking about one net with different properties. Ii think it will be hard to convey the intricacies of power supply bypassing to an autorouter. One thing I find interesting is how in an example you say the two subnets can only join at P1. How do you define P1? To me this is the point between two separate nets... which is really what you are describing. I have to admit that I do not know much about how all that netlist stuff is handled in gEDA/PCB. For the example of Power/Bypass subnets and Point P1: The intention is to have (enforce) a short, low impedance connection from OpAmp power pin to a pin of the bypass capacitor. A good layouter will always ensure this. My idea was to split the whole 5V-plus net in segments or subnets (with same netname, but different attributes/class). For my picture P1 is a common point of these subnets. One restriction is: This subnet with property bypass shall be short, low impedance. For this case it is a connection of only two points, which makes it very simple. A human layouter can understand it, and we should be able to transfer this information to PCB program, so that DRC can verify correctness. I can imagine more difficult cases. One is the Short net from capacitor pin to GND symbol. GND symbol does not really define a pin. One interpretation may be to translate it to a short trace to a ground polygon. An other problem is a subnet with property short which is built of multiple segments -- how will we define trace-length6mm for this case. Maximum distance of pairs of pins for this net? All this are details, which we can define later. Maybe a more difficult problem is to make nets compatible, so that a minor net is allowed to connect at an arbitrary point to a mayor net. For example a net (default net class) carrying a plain +5V signal to some static logic input should be allowed to connect at an arbitrary point to the fat +5V net. We do not need these concept of compatible nets, but is would be nice to have. (compatible in this case means compatible in only on direction. We have the fat traces from the DC_DC converter to big fat capacitor and high current devices (DRC will check if all these connections are of class/attribute fat), but other low order nets with same netname can connect at arbitrary points.) Of course, all this is not easy. But interesting, and we have some really smart people on this list... Best regards, Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
On Sun, 2010-08-15 at 21:03 +0200, Stefan Salewski wrote: attributes/class). For my picture P1 is a common point of these subnets. One restriction is: This subnet with property bypass shall be short, low impedance. Sorry, I forgot: Points which connects subnets will be always pads or pins on PCB board (pins of devices). By physical design we always define properties for traces between device pins, it makes no sense to change trace properties somewhere between device pins (if it makes sense, then that is a special case, like antennas, which is beyond our proposal). So location of point P1 is well defined, in schematic, and in layout. (But there is no need to call it P1, or give it a special name, it is simple a common node of two subnets with same netname.) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
At 03:03 PM 8/15/2010, you wrote: On Sun, 2010-08-15 at 14:10 -0400, Rick Collins wrote: I see we are talking about two different things. I was responding to Andrew's post about splitting nets into portions with different properties. In my way of thinking if they have different properties, they should be separate nets. I see that your example of Power/Bypass we are talking about one net with different properties. Ii think it will be hard to convey the intricacies of power supply bypassing to an autorouter. One thing I find interesting is how in an example you say the two subnets can only join at P1. How do you define P1? To me this is the point between two separate nets... which is really what you are describing. I have to admit that I do not know much about how all that netlist stuff is handled in gEDA/PCB. For the example of Power/Bypass subnets and Point P1: The intention is to have (enforce) a short, low impedance connection from OpAmp power pin to a pin of the bypass capacitor. A good layouter will always ensure this. My idea was to split the whole 5V-plus net in segments or subnets (with same netname, but different attributes/class). For my picture P1 is a common point of these subnets. One restriction is: This subnet with property bypass shall be short, low impedance. For this case it is a connection of only two points, which makes it very simple. A human layouter can understand it, and we should be able to transfer this information to PCB program, so that DRC can verify correctness. I can imagine more difficult cases. One is the Short net from capacitor pin to GND symbol. GND symbol does not really define a pin. One interpretation may be to translate it to a short trace to a ground polygon. An other problem is a subnet with property short which is built of multiple segments -- how will we define trace-length6mm for this case. Maximum distance of pairs of pins for this net? All this are details, which we can define later. Maybe a more difficult problem is to make nets compatible, so that a minor net is allowed to connect at an arbitrary point to a mayor net. For example a net (default net class) carrying a plain +5V signal to some static logic input should be allowed to connect at an arbitrary point to the fat +5V net. We do not need these concept of compatible nets, but is would be nice to have. (compatible in this case means compatible in only on direction. We have the fat traces from the DC_DC converter to big fat capacitor and high current devices (DRC will check if all these connections are of class/attribute fat), but other low order nets with same netname can connect at arbitrary points.) Of course, all this is not easy. But interesting, and we have some really smart people on this list... Best regards, Stefan Salewski First, I want to say that power supply bypassing is probably not a good example to use since there are a number of ways to layout such things and many people will disagree about the optimal way of doing it. Perhaps a more general example can be used? You are talking about everything in the context of what you would like to see in the schematic editor. But none of this is useful unless the autorouter handles it. I would suggest that it would make sense to figure out just what autorouters can do in terms of specialized routing of portions of a net, then see what info the autorouter needs to be told of specialized routing. Only then does it make sense to consider how to specify specialized routing/layout information within the schematic data base. It is a great idea to have all design info in one file. But I am doubtful that this can be done in a useful way without involving the layout tool. I have been in a discussion in the FreePCB and TinyCAD areas about making them smart enough to know each other's data file formats. Then information could be updated in both files when common data is changed in one application. That way the information that is unique to each can be separate while the common information can be kept in step. So far there is not much interest from the developers in such a linkage. They seem to be very happy working through net lists in one direction only. At 03:25 PM 8/15/2010, you wrote: Sorry, I forgot: Points which connects subnets will be always pads or pins on PCB board (pins of devices). By physical design we always define properties for traces between device pins, it makes no sense to change trace properties somewhere between device pins (if it makes sense, then that is a special case, like antennas, which is beyond our proposal). So location of point P1 is well defined, in schematic, and in layout. (But there is no need to call it P1, or give it a special name, it is simple a common node of two subnets with same netname.) That is an interesting idea. In the schematic, how do you indicate the pin being used as P1? I have seen ground subnets that are to be connected at a single point
Re: gEDA-user: Subnets
On Sun, 2010-08-15 at 15:43 -0400, Rick Collins wrote: First, I want to say that power supply bypassing is probably not a good example to use since there are a number of ways to layout such things and many people will disagree about the optimal way of doing it. Perhaps a more general example can be used? No. The basic idea of our proposal was to define attributes/classes for nets in the schematic. Subnets are only a special case, which makes much sense in the case of power supply. OK, one more, but very special case, where subnets may be useful: We can have nets of 3 nodes, where we want a linear shape, not a T or star shape. For this case we may define one subnet from pin 1 to 2, and one more from 2 to 3. We make these two subnets not compatible, so they are allowed to touch only at pin 2. So we can enforce the shape of the layout on the schematic level. You are talking about everything in the context of what you would like to see in the schematic editor. But none of this is useful unless the autorouter handles it. No. It would be fine if the autorouter can access this information. But all these attributes/classes are a great benefit for manually routing. For details see the related posting in this list... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
At 04:27 PM 8/15/2010, you wrote: On Sun, 2010-08-15 at 15:43 -0400, Rick Collins wrote: First, I want to say that power supply bypassing is probably not a good example to use since there are a number of ways to layout such things and many people will disagree about the optimal way of doing it. Perhaps a more general example can be used? No. The basic idea of our proposal was to define attributes/classes for nets in the schematic. Subnets are only a special case, which makes much sense in the case of power supply. OK, one more, but very special case, where subnets may be useful: We can have nets of 3 nodes, where we want a linear shape, not a T or star shape. For this case we may define one subnet from pin 1 to 2, and one more from 2 to 3. We make these two subnets not compatible, so they are allowed to touch only at pin 2. So we can enforce the shape of the layout on the schematic level. You are talking about everything in the context of what you would like to see in the schematic editor. But none of this is useful unless the autorouter handles it. No. It would be fine if the autorouter can access this information. But all these attributes/classes are a great benefit for manually routing. For details see the related posting in this list... Maybe you are missing my point. What value does the subnet have if the layout TOOL doesn't know about it? What do the routing tools know at this point? If the answer is nothing, then why push from the schematic end? Wouldn't it make more sense to push from the layout end? Then add to the schematic program what is needed to support the layout. I've never heard of a layout tool that knew anything about subnets. Why invent something that can't be used with the layout tool? The other attributes are fine. Trace width, max length, etc. But how do you convey that info to an arbitrary layout tool? Is there a netlist format that supports such extra info? This pie-in-the-sky stuff is fine, but I can see much more utility coming from more mundane developments. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
On Sun, 2010-08-15 at 16:43 -0400, Rick Collins wrote: At 04:27 PM 8/15/2010, you wrote: On Sun, 2010-08-15 at 15:43 -0400, Rick Collins wrote: For details see the related posting in this list... Maybe you are missing my point. What value does the subnet have if the layout TOOL doesn't know about it? What do the routing tools know at this point? If the answer is nothing, then why push from the schematic end? Wouldn't it make more sense to push from the layout end? Then add to the schematic program what is needed to support the layout. I've never heard of a layout tool that knew anything about subnets. Why invent something that can't be used with the layout tool? The other attributes are fine. Trace width, max length, etc. But how do you convey that info to an arbitrary layout tool? Is there a netlist format that supports such extra info? This pie-in-the-sky stuff is fine, but I can see much more utility coming from more mundane developments. Rick Yes, I am fool. A tired fool now. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
Rick Collins wrote: First, I want to say that power supply bypassing is probably not a good example to use since there are a number of ways to layout such things and many people will disagree about the optimal way of doing it. I think it's an OK example. There's no need to assume any way of doing bypass caps other than short distance. I'm not saying a hard coded make-bypass-cap-connection would ever get into gschem or pcb, it's just that top down schematic driven design has lots of value and plenty of fans. The example is fine if you don't worry about it being more than a first cut at why you want subnets in a net. I would suggest that it would make sense to figure out just what autorouters can do in terms of specialized routing of portions of a net, then see what info the autorouter needs to be told of specialized routing. After seeing some of Tony's topologic router output, and my time doing chip layout and exposure to high dollar tools, my gut says, we're onto something. Why do it only after proven ways exist? That's too late for planning purposes. I have seen nets that need to be routed with some ordering of the pins. e.g. in ECL the driver is at one end of the net, the terminator at the other and the receiver is in between, near the terminator. There are similar issues with routing LVDS and high speed signals. Can this be conveyed using subnets? Yes, that is a good example of subnets being valuable. Flags for it? Kinda complicated, but there's going to be a way. John Griessen -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
Stefan Salewski wrote: OK, one more, but very special case, where subnets may be useful: We can have nets of 3 nodes, where we want a linear shape, not a T or star shape. For this case we may define one subnet from pin 1 to 2, and one more from 2 to 3. We make these two subnets not compatible, so they are allowed to touch only at pin 2. So we can enforce the shape of the layout on the schematic level. That's a good example. I bet it has some counterpart in Tony's topological router algorithms John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
Rick Collins wrote: This pie-in-the-sky stuff is fine, but I can see much more utility coming from more mundane developments. It's not pie in the sky. Some of these ideas to use sets and lists and groups are the easiest kind to implement... Zones in layout are an easy part of what it already does, when we have more layers for intermediate calculations. net attribs plus layout zones get us far on the way to autorouting success. John Griessen ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
