Re: gEDA-user: gschem: directly connecting two nets?
On 27 January 2011 00:00, Stephen Ecob silicon.on.inspirat...@gmail.com wrote: So there are several use cases for treating copper as non-connecting: * low value resistors * fuses * low value inductors * aerials * contacts for solder switches (eg SPDT in solder) * Transmission lines ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On Mon, 2011-01-24 at 07:48 -0800, Ouabache Designworks wrote: The special symbols is supposed to fuse netnames as issued on the netlist, not labels on the schematic. --- If you are also fusing the copper on the board then I would kind of like to see that when I am viewing the schematic. You want to give the user a choice. If I pull up a component view then I want to see the signal names from the original designer. If I am traversing a hierarchy and open an instance view then I want to see the signal names that match the names in the parent instance. John Eaton For a loop antenna, for example, the solution needs to be in PCB.. allow footprints / functional groups which implement RF components by placing copper on some layer. For me, this raises a very interesting design question: How do I go from abstract inductor / transmission line / (capacitance even?) representations on a schematic, to correctly DRC'd board layout? The inductor will end up as a shaped piece of copper tracking, and at this point, you realise that net is a very DC term! We would need to have some way to demarcate the start and end of the inductor in PCB, or to draw it on a layer, or with an attribute which causes the copper making up the component to be disjoint from either net connecting to that section. That piece of board layout becomes a component, not an interconnect between components. One might imagine a similar method being useful to join two hierarchically shorted nets together... have a link component which joins AGND and DGND, which is implemented by copper drawn on the board between those two power planes. This would then allow preservation of important DRC checks such as making sure the correct plane / return path is used for signals. Regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
I was thinking it would be easy to add a notcopper or ignore_me flag to element pads, but it wouldn't be as easy to make everything else work nicely with it. Tedious, mostly. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
Peter Clifton pc...@cam.ac.uk writes: On Mon, 2011-01-24 at 07:48 -0800, Ouabache Designworks wrote: The special symbols is supposed to fuse netnames as issued on the netlist, not labels on the schematic. --- If you are also fusing the copper on the board then I would kind of like to see that when I am viewing the schematic. You want to give the user a choice. If I pull up a component view then I want to see the signal names from the original designer. If I am traversing a hierarchy and open an instance view then I want to see the signal names that match the names in the parent instance. John Eaton For a loop antenna, for example, the solution needs to be in PCB.. allow footprints / functional groups which implement RF components by placing copper on some layer. For me, this raises a very interesting design question: How do I go from abstract inductor / transmission line / (capacitance even?) representations on a schematic, to correctly DRC'd board layout? This will probably require an additional tool. The tool needs to extract the properties of the wiring from the layout via some techology file that describes the properties of the board materials (layer stack, etc). The schematic will have attributes on nets that spec what to check for. IMHO, net segments should be explicitly marked with the short-symbol that was discussed. A gnetlist backend will provide a netlist to the verification tool that includes the attributes and net segments. The PCB gnetlist backend merges the net segments. How to split out the net segments during extraction is probably not easy. The inductor will end up as a shaped piece of copper tracking, and at this point, you realise that net is a very DC term! The inductor could be a subschematic with shorted pins via two short symbols, with a net in between that asks for an inductance check of some sort. We would need to have some way to demarcate the start and end of the inductor in PCB, or to draw it on a layer, or with an attribute which causes the copper making up the component to be disjoint from either net connecting to that section. That piece of board layout becomes a component, not an interconnect between components. The DRC could be told to treat certain layers in a group as component copper. One might imagine a similar method being useful to join two hierarchically shorted nets together... have a link component which joins AGND and DGND, which is implemented by copper drawn on the board between those two power planes. This would then allow preservation of important DRC checks such as making sure the correct plane / return path is used for signals. Regards, -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On 1/26/2011 12:34 PM, Stephan Boettcher wrote: Peter Cliftonpc...@cam.ac.uk writes: On Mon, 2011-01-24 at 07:48 -0800, Ouabache Designworks wrote: The special symbols is supposed to fuse netnames as issued on the netlist, not labels on the schematic. --- If you are also fusing the copper on the board then I would kind of like to see that when I am viewing the schematic. You want to give the user a choice. If I pull up a component view then I want to see the signal names from the original designer. If I am traversing a hierarchy and open an instance view then I want to see the signal names that match the names in the parent instance. John Eaton For a loop antenna, for example, the solution needs to be in PCB.. allow footprints / functional groups which implement RF components by placing copper on some layer. For me, this raises a very interesting design question: How do I go from abstract inductor / transmission line / (capacitance even?) representations on a schematic, to correctly DRC'd board layout? This will probably require an additional tool. The tool needs to extract the properties of the wiring from the layout via some techology file that describes the properties of the board materials (layer stack, etc). The schematic will have attributes on nets that spec what to check for. IMHO, net segments should be explicitly marked with the short-symbol that was discussed. A gnetlist backend will provide a netlist to the verification tool that includes the attributes and net segments. The PCB gnetlist backend merges the net segments. How to split out the net segments during extraction is probably not easy. The inductor will end up as a shaped piece of copper tracking, and at this point, you realise that net is a very DC term! The inductor could be a subschematic with shorted pins via two short symbols, with a net in between that asks for an inductance check of some sort. We would need to have some way to demarcate the start and end of the inductor in PCB, or to draw it on a layer, or with an attribute which causes the copper making up the component to be disjoint from either net connecting to that section. That piece of board layout becomes a component, not an interconnect between components. The DRC could be told to treat certain layers in a group as component copper. One might imagine a similar method being useful to join two hierarchically shorted nets together... have a link component which joins AGND and DGND, which is implemented by copper drawn on the board between those two power planes. This would then allow preservation of important DRC checks such as making sure the correct plane / return path is used for signals. I guess I am missing something significant with this. Why wouldn't the inductor just be a component on the schematic and a component in layout just like any other inductor? The only difference is that the footprint defined for the component would be the copper that makes up the antenna. It would have a pad on each end for the signal connection. Is arbitrary copper in a footprint not supported? As to DRC, I would think design of an antenna would be a pretty complex thing to analyze automatically. A 3D field solver comes to mind. Is any of that capability currently interfaced with these tools? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
the footprint defined for the component would be the copper DRC sees that as a short circuit, not an element. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On 1/26/2011 1:42 PM, DJ Delorie wrote: the footprint defined for the component would be the copper DRC sees that as a short circuit, not an element DRC will complain if pads are touching? Can you create arbitrary shaped pads? But they can't touch each other Do you have a way of creating jumper components, two through pin pads connected by narrow copper? I use these often in my projects. Default is connected, but as an option the trace can be cut. Once the narrow trace is cut, a jumper block can be added and the pads reconnected if needed. The antenna could work the same way. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
Sure, you can use pads to make arbitrary traces in your element. But, you must also connect the two pins in the schematic, or DRC will complain about a short circuit. Once the nets are shorted in the netlist, it's not always easy to figure out which connections go to which side of your antenna. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On 1/26/2011 1:55 PM, DJ Delorie wrote: Sure, you can use pads to make arbitrary traces in your element. But, you must also connect the two pins in the schematic, or DRC will complain about a short circuit. Once the nets are shorted in the netlist, it's not always easy to figure out which connections go to which side of your antenna Then I think the answer is no, at least I really wouldn't want to do that. I've never seen a layout package that checks for connectivity between pins *inside* a footprint. Actually, I guess the stuff I use doesn't check copper for shorts. It will not let you make trace connections between nets. Then it also checks the DRC spacings of traces, clearance around copper areas, etc. But I don't think shorts are checked exactly and I know pads within a part are not checked for spacing. I would think the pads of a footprint would not be checked against one another with the same rules as traces. Is that what you are saying? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
I would think the pads of a footprint would not be checked against one another with the same rules as traces. Is that what you are saying? No, I'm saying some pads in a footprint can be marked to be ignored just for connectivity checking. You still want to do the rest of the DRC checks to make sure the board can be manufactured. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
you must also connect the two pins in the schematic, or DRC will complain about a short circuit. Ive had good luck giving multiple coppper pins and pads the same number in the footprint file. This only works for pins/pads that overlap. If not PCB will only enforce a connection to one copper item. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On Wed, 2011-01-26 at 18:34 +0100, Stephan Boettcher wrote: The inductor will end up as a shaped piece of copper tracking, and at this point, you realise that net is a very DC term! The inductor could be a subschematic with shorted pins via two short symbols, with a net in between that asks for an inductance check of some sort. I considered this briefly, but dismissed it with the thought that is a fairly abusive model of the component. We don't usually, model inductors on the board as short-circuits, even if a crude ohm-meter might view them as such when they are placed. The DRC could be told to treat certain layers in a group as component copper. I would like to move away from layer groups, as it is a non-physical way of considering the board, and a nightmare from a rendering / DRC point of view. Semantic tagging of objects within a layer is IMO the way forward. We could still provide distinct colouring if that was useful to people. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On Wed, 2011-01-26 at 13:33 -0500, rickman wrote: I guess I am missing something significant with this. Why wouldn't the inductor just be a component on the schematic and a component in layout just like any other inductor? The only difference is that the footprint defined for the component would be the copper that makes up the antenna. It would have a pad on each end for the signal connection. Is arbitrary copper in a footprint not supported? Not currently supported. PCB would also need to treat that copper differently in its own connectivity scanning code, otherwise it would merrily extract the whole DC-connected netlist (shorting either side of the inductor). As to DRC, I would think design of an antenna would be a pretty complex thing to analyze automatically. A 3D field solver comes to mind. Is any of that capability currently interfaced with these tools? Perhaps I was going a bit far to suggest full DRC for the actual antenna design. What I really meant was not loosing information for net connectivity checking leading up the antenna. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
Perhaps I was going a bit far to suggest full DRC for the actual antenna design. What I really meant was not loosing information for net connectivity checking leading up the antenna. Thinking longer term, why not support DRC checking of inductance and resistance for specially tagged traces ? Of course most nets can simply be thought of as perfect conductors, but if we introduce the concept of a resistive and/or inductive trace it would be very helpful for making small inductors and resistors directly out of copper. My current design implements resistors of 2.5mOhms up to 0.25 ohms purely with copper. PCB's DRC doesn't understand and highlights these resistors in orange, but I can imagine a future PCB where I specified that a particular trace should have a resistance of (say) 10 mOhm and DRC would handle it gracefully. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On Thu, 2011-01-27 at 08:32 +1100, Stephen Ecob wrote: Perhaps I was going a bit far to suggest full DRC for the actual antenna design. What I really meant was not loosing information for net connectivity checking leading up the antenna. Thinking longer term, why not support DRC checking of inductance and resistance for specially tagged traces ? Of course most nets can simply be thought of as perfect conductors, but if we introduce the concept of a resistive and/or inductive trace it would be very helpful for making small inductors and resistors directly out of copper. My current design implements resistors of 2.5mOhms up to 0.25 ohms purely with copper. PCB's DRC doesn't understand and highlights these resistors in orange, but I can imagine a future PCB where I specified that a particular trace should have a resistance of (say) 10 mOhm and DRC would handle it gracefully. That is exactly the sort of use-case for this feature I was looking for. A similar track is component scenario: PCB fuse track - a dirty trick I've seen in some Honywell boiler controllers.. where a deliberately thin trace is used to act as a fuse. Other cases which require net tagging: Computing current density for thermal reasons for a PCB trace. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
A similar track is component scenario: PCB fuse track - a dirty trick I've seen in some Honywell boiler controllers.. where a deliberately thin trace is used to act as a fuse. That certainly is a dirty trick! (But on a very tight budget it could make sense). So there are several use cases for treating copper as non-connecting: * low value resistors * fuses * low value inductors * aerials * contacts for solder switches (eg SPDT in solder) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On 1/26/2011 7:00 PM, Stephen Ecob wrote: A similar track is component scenario: PCB fuse track - a dirty trick I've seen in some Honywell boiler controllers.. where a deliberately thin trace is used to act as a fuse. That certainly is a dirty trick! (But on a very tight budget it could make sense). So there are several use cases for treating copper as non-connecting: * low value resistors * fuses * low value inductors * aerials * contacts for solder switches (eg SPDT in solder) Similar to the last is a jumper location that is connected by copper by default to be cut if an open is needed. Consider this to be a 1 bit PROM. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
Similar to the last is a jumper location that is connected by copper by default to be cut if an open is needed. Consider this to be a 1 bit PROM. Rick Yes, they're useful. I use them a lot on early revision boards when the design is still subject to change in some areas. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On 1/26/2011 3:50 PM, Peter Clifton wrote: On Wed, 2011-01-26 at 13:33 -0500, rickman wrote: I guess I am missing something significant with this. Why wouldn't the inductor just be a component on the schematic and a component in layout just like any other inductor? The only difference is that the footprint defined for the component would be the copper that makes up the antenna. It would have a pad on each end for the signal connection. Is arbitrary copper in a footprint not supported? Not currently supported. PCB would also need to treat that copper differently in its own connectivity scanning code, otherwise it would merrily extract the whole DC-connected netlist (shorting either side of the inductor). As to DRC, I would think design of an antenna would be a pretty complex thing to analyze automatically. A 3D field solver comes to mind. Is any of that capability currently interfaced with these tools? Perhaps I was going a bit far to suggest full DRC for the actual antenna design. What I really meant was not loosing information for net connectivity checking leading up the antenna. I agree 100%. Having to combine nets in layout that are not combined in the schematic netlist sounds like a bad idea to me. I don't plan on designing any antennas in the near future (or the far future), but I often use the trace connected jumper positions. I would like to be able to do that without mucking about the netlist. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
2011/1/24 DJ Delorie d...@delorie.com: Perhaps we need a concept of net with more than one name ? We'd have to define rules for DRC to follow. Multiple names for a single wire - this sounds like a good solution. Each gnetlist backend could then provide a net-unification function to map multiple input net names to single/multiple output netnames. DRC will be tricky, yes :) -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
I like the multiple names solution. I hadn't run into this issue until I came across gEDA symbols with hardcoded nets. Not a big issue, I tend to modify symbols now on a per project basis - so the need to have two net names for a single wire is much reduced. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
John Doty j...@noqsi.com writes: On Jan 24, 2011, at 11:57 AM, Kai-Martin Knaak wrote: Steven Michalske wrote: We would also need a way to force the chosen name of the net to choose when merging nets. e.g. When you merge a net named power with a net named 3v3_power, who wins? If a two pin symbol mediates the fusion, this would be determined by the connections to the symbol. The symbol would comprise a win-pin and a loose-pin. The winner would be the net that is connected to the win-pin. Works for the simplest case: net1 net2 ---(WP,LP) The combined net would be net1. But a little more complicated: net1 net2 net3 ---(WP,LP)(LP,WP)- Is this net1 or net3? At some point the user looses for his own stupitity. I'd just require a well defined topology, and tell the user if the resolution is not unique, then he has to accept arbitrary results, based on the random order of evaluation of the shorts. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
The special symbols is supposed to fuse netnames as issued on the netlist, not labels on the schematic. --- If you are also fusing the copper on the board then I would kind of like to see that when I am viewing the schematic. You want to give the user a choice. If I pull up a component view then I want to see the signal names from the original designer. If I am traversing a hierarchy and open an instance view then I want to see the signal names that match the names in the parent instance. John Eaton ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
Ouabache Designworks z3qmt...@gmail.com writes: The special symbols is supposed to fuse netnames as issued on the netlist, not labels on the schematic. --- If you are also fusing the copper on the board then I would kind of like to see that when I am viewing the schematic. PCB requires all connecting copper to be the same net(name). gnetlist needs to resolve merged nets to a single net. That happens now for hierarchy, except when a subcircuit shorts two higher-level nets. This could probably be fixed, with a warning and some arbitrary choice how the net is named. You want to give the user a choice. If I pull up a component view then I want to see the signal names from the original designer. If I am traversing a hierarchy and open an instance view then I want to see the signal names that match the names in the parent instance. There is no instance view in gschem. John Eaton NB, when resolving hierarchy, gnetlist keeps the netname of the outer level. Sometimes I'd wish it would keep the subcircuit netname. This would also resolve the case when a subcircuit shorts two outer nets. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gschem: directly connecting two nets?
Sometimes I would like to directly connect two nets. There are a number of different specific cases in which I would like to do this for simplicity in the schematic. For instance, I might have an input port component (e.g., input-1.sym) on a connector pin with net VLCD, and then somewhere else in the schematic want to show that VLCD is connected to +3.3V. However, after some investigation as to why I wasn't getting the right rats in 'pcb' after a gsch2pcb import, I realized that connecting two nets in gschem (using a power symbol and/or an I/O port symbol connected with a net line) does not create that connection in the netlist! I think the gnetlist drc did emit a warning due to this, but I did not understand the cause... Is there any correct way to show two nets are directly connected in a schematic? e.g., connecting two I/O ports or two power symbols directly. Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
Colin D Bennett co...@gibibit.com writes: Sometimes I would like to directly connect two nets. There are a number of different specific cases in which I would like to do this for simplicity in the schematic. For instance, I might have an input port component (e.g., input-1.sym) on a connector pin with net VLCD, and then somewhere else in the schematic want to show that VLCD is connected to +3.3V. However, after some investigation as to why I wasn't getting the right rats in 'pcb' after a gsch2pcb import, I realized that connecting two nets in gschem (using a power symbol and/or an I/O port symbol connected with a net line) does not create that connection in the netlist! I think the gnetlist drc did emit a warning due to this, but I did not understand the cause... Is there any correct way to show two nets are directly connected in a schematic? e.g., connecting two I/O ports or two power symbols directly. Hmm, yes. You need to invent some 2-pin symbol with some special attributes, and teach the pcb gnetlist backend(s) to interpret those attributes as a net-unification bridge. There should also be a convention how that net should be named in the output. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On Sun, Jan 23, 2011 at 09:25:53AM -0800, Colin D Bennett wrote: However, after some investigation as to why I wasn't getting the right rats in 'pcb' after a gsch2pcb import, I realized that connecting two nets in gschem (using a power symbol and/or an I/O port symbol connected with a net line) does not create that connection in the netlist! I think the gnetlist drc did emit a warning due to this, but I did not understand the cause... This sounds like related to this bug and its duplicates: https://bugs.launchpad.net/geda/+bug/698395 -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On Jan 24, 2011, at 5:51 AM, Kai-Martin Knaak wrote: Stephan Boettcher wrote: You need to invent some 2-pin symbol with some special attributes, and teach the pcb gnetlist backend(s) to interpret those attributes ^^^ If there is a way to mark two net-names as physically the same net, then each and every backend should act accordingly. By default, yes, I agree completely. It would be an invitation for nasty surprises if some back-ends would support the fusion and others don't. This calls for an interpretation by the frontend. The problem is that each downstream tool potentially has its own model of connectivity, so the default model in gnetlist must address the lowest common denominator here. I think that would require that gnetlist simply merge the nets, choosing a common name. But that's probably not good enough for users of specific tools with advanced capabilities. Therefore, these semantics should not be in the front-end. They should be in the middle layer (gnetlist.scm), where a plug-in or back-end can modify the semantics as needed for the downstream tool. Putting them in the front-end will case trouble similar to that we now experience with slotting, where the front-end model doesn't fit simulation flows. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On Sun, Jan 23, 2011 at 6:30 PM, John Doty j...@noqsi.com wrote: On Jan 24, 2011, at 5:51 AM, Kai-Martin Knaak wrote: Stephan Boettcher wrote: You need to invent some 2-pin symbol with some special attributes, and teach the pcb gnetlist backend(s) to interpret those attributes ^^^ If there is a way to mark two net-names as physically the same net, then each and every backend should act accordingly. By default, yes, I agree completely. It would be an invitation for nasty surprises if some back-ends would support the fusion and others don't. This calls for an interpretation by the frontend. The problem is that each downstream tool potentially has its own model of connectivity, so the default model in gnetlist must address the lowest common denominator here. I think that would require that gnetlist simply merge the nets, choosing a common name. But that's probably not good enough for users of specific tools with advanced capabilities. Therefore, these semantics should not be in the front-end. They should be in the middle layer (gnetlist.scm), where a plug-in or back-end can modify the semantics as needed for the downstream tool. Putting them in the front-end will case trouble similar to that we now experience with slotting, where the front-end model doesn't fit simulation flows. We would also need a way to force the chosen name of the net to choose when merging nets. e.g. When you merge a net named power with a net named 3v3_power, who wins? Steve John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ 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: gschem: directly connecting two nets?
Steven Michalske wrote: We would also need a way to force the chosen name of the net to choose when merging nets. e.g. When you merge a net named power with a net named 3v3_power, who wins? If a two pin symbol mediates the fusion, this would be determined by the connections to the symbol. The symbol would comprise a win-pin and a loose-pin. The winner would be the net that is connected to the win-pin. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
We would also need a way to force the chosen name of the net to choose when merging nets. e.g. When you merge a net named power with a net named 3v3_power, who wins? Steve The worst thing that you can do is to simply pick one and change all the others names to match. Imagine accidently connecting net FOO to a power grid and having every one of the power labels turn to FOO. This is one case where not allowing it might be the safest choice. John Eaton ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On Jan 24, 2011, at 11:57 AM, Kai-Martin Knaak wrote: Steven Michalske wrote: We would also need a way to force the chosen name of the net to choose when merging nets. e.g. When you merge a net named power with a net named 3v3_power, who wins? If a two pin symbol mediates the fusion, this would be determined by the connections to the symbol. The symbol would comprise a win-pin and a loose-pin. The winner would be the net that is connected to the win-pin. Works for the simplest case: net1 net2 ---(WP,LP) The combined net would be net1. But a little more complicated: net1 net2 net3 ---(WP,LP)(LP,WP)- Is this net1 or net3? John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
Ouabache Designworks wrote: The worst thing that you can do is to simply pick one and change all the others names to match. Imagine accidently connecting net FOO to a power grid and having every one of the power labels turn to FOO. The special symbols is supposed to fuse netnames as issued on the netlist, not labels on the schematic. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
John Doty wrote: But a little more complicated: net1 net2 net3 ---(WP,LP)(LP,WP)- Is this net1 or net3? Or an even more pathological case where nets are fused in a circle... I'd say, take whatever comes first and issue a warning during netlist. DRC might check for this ambiguity, too. The designer is responsible to use the netfuse symbols in a way that yields a non-ambiguous winner. Anyway, it most likely won't be detrimental to the following tools. After all, netnames are just that: names. A back-end might need fixed net names for special purposes. But since this would be a corner case of a corner case, a warning should be ok. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On Mon, Jan 24, 2011 at 3:56 AM, Stephan Boettcher boettc...@physik.uni-kiel.de wrote: You need to invent some 2-pin symbol with some special attributes, and teach the pcb gnetlist backend(s) to interpret those attributes as a net-unification bridge. There should also be a convention how that net should be named in the output. Most netlist formats have some sort of short devices: - spice - 0V voltage source, - verilog - assign (unidirectional) - LVS (Calibre) - VIRTUAL CONNECT NAME - LVS (Assura) - joinNets Perhaps PCB backend should have something like this as well? I think it is best to deal with these issues explicitly by adding an appropriate device to the schematics. Otherwise the only universally working way of fixing this is flattening the design (or playing some tricks with overwriting ports of hierarchical blocks) at netlist time. Just for the record, many other tools flag this kind of a direct pin-pin connection as an error (a short), refusing netlisting such schematics altogether. This may seem like a bit over-restrictive way of dealing with the issue but (1) quite often these connections *are* unintended shorts, (2) the tool itself relies on the fact that there are no cycles in the connectivity (otherwise any find a net type of operation would require an exhaustive search of the whole design space, rather than simple a descend down the hierarchy). Andrzej ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On Mon, 24 Jan 2011 13:31:28 +0900 John Doty j...@noqsi.com wrote: On Jan 24, 2011, at 11:57 AM, Kai-Martin Knaak wrote: Steven Michalske wrote: We would also need a way to force the chosen name of the net to choose when merging nets. e.g. When you merge a net named power with a net named 3v3_power, who wins? If a two pin symbol mediates the fusion, this would be determined by the connections to the symbol. The symbol would comprise a win-pin and a loose-pin. The winner would be the net that is connected to the win-pin. Works for the simplest case: net1 net2 ---(WP,LP) The combined net would be net1. But a little more complicated: net1 net2 net3 ---(WP,LP)(LP,WP)- Is this net1 or net3? Although I don't foresee using this feature myself, I'd say to do this: Logically sort the symbols first by connection order, then by instantiation order. Whatever symbol last had a connection made to it would be the symbol which takes precedence, unless there are two or more symbols that share that honor. In that latter case, jusr use the winner/loser pins from the most recently-instantiated symbol. So in the above, if the two symbols are added left-first, then the right-most symbol would govern the connection, and the winner would be net3, since that net falls on the second symbol's winner pin. In the circular path KMK mentioned, the first and last symbols added to the circuit would end up getting connected together at the same moment by a single net, so those two would share the last connection made status. So, the last one before the loop repeats would govern the connection, since it was the last one to be instantiated. -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://starbase.globalpc.net/~ezekowitz Vanessa Ezekowitz vanessaezekow...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
Perhaps we need a concept of net with more than one name ? We'd have to define rules for DRC to follow. I'm thinking the connector net (net with more than one name) can connect to any of the singleton nets with the same names as one of its names, but cannot be considered when checking connectivity for each of the singleton nets. I'm not sure how to identify those copper bits for the connector net, though. Detail to be worked out later :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
