Re: gEDA-user: wishful UI (was: New icon set and UI changes)
I just read this, and had to think on the UI discussion going on here: [1]http://www.sububi.org/2010/08/18/free-interaction-design-for-your-op en-source-project/ We should also think on the smaller applications beside PCB and gschem. Im sure everyone here could name some programmes in the geda suite which have a gui that (s)he isn't very happy about. -- Stefan References 1. http://www.sububi.org/2010/08/18/free-interaction-design-for-your-open-source-project/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
DJ Delorie wrote: Sure, and the big EDA code based on LISP/Guile also uses syntax for names so a wire with such a name attrib seems to be all that's necessary to define a bus. Putting the syntax netname[0:7] into form netname[0], netname[1], for the backends is fine. Seems to me the common code would still need to be aware of bus nets. I published my paper mostly to get a discussion going on what busses *mean* though, not the implementation details. For example, what does it mean when three busses with different names are connected? D[15:0] ==** D[15:0] || \\ A[1:16] The problems I see with this are: * 2 names for the same bus are probably confusing for a user * if busses of different name are allowed to connect, they should have the same wire layout * if they really shall look like above, the number of wires must be equal and the obvious mapping mechanism must be in place If all this is not for you, would it be possible to make a bus-mapper/connector symbol? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
DJ Delorie wrote: And I want to understand the implications of pins that reflect multiple signals, too - mapping names and numbers, etc. I can only envision 2 cases for a multipurpose pin: a) the generic interface shall be preserved - don't care what the pin means, just pass a wire b) the pin is actually used for something hardwired in the board - it's no longer multipurpose ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
John Griessen wrote: 1) Assign unique refdes value to all netlistable logical symbols in the schematic. If the logical symbol is one of several in a PHYSICAL_package, then assgined refdes to each logical symbol such as Uxx_yy; where yy is the value to identify a particular LOGICAL_SYMBOL among several within a PCB_PACKAGE; and xx value is the ID to differentiate among all PCB_PACKAGE for your design. Uxx is what you want to see in your PCB netlist. maybe I misunderstand something here, but if you want to say '_' in Uxx_yy is actually a separator you should come up with a positive definition of what a standard refdes can be made of. The sloopy way chars get assigned special meanings with all sorts of identifiers in geda really annoys me - and imho bites everyone in the long run. The above example would make another step to: you may not use ':' in blah, unless foo is set to 5, and '-' can bit you in some circumstances. I can assure you that '_' is valid in refdes, unless it's used for a bus in which case... Depending on the phase of the moon, '/' in an identifier can mean either:... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
John Griessen wrote: 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. Sounds like you suggest the autorouter as suplement to propper understanding of layout - I've been struggling and reading for weeks now with this subject. One of the primers I found states: ... The autorouter is a tool to speed up the work of specialists and should be avoided by beginners. It is no replacement for understanding the implications of your layout... My very little experience with autorouters also makes me believe, that an autorouter has even less understanding of EMI issues than I have ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Mon, 2010-08-16 at 11:23 +0200, Armin Faltl wrote: John Griessen wrote: 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. Sounds like you suggest the autorouter as suplement to propper understanding of layout - I've been struggling and reading for weeks now with this subject. One of the primers I found states: ... The autorouter is a tool to speed up the work of specialists and should be avoided by beginners. It is no replacement for understanding the implications of your layout... My very little experience with autorouters also makes me believe, that an autorouter has even less understanding of EMI issues than I have ;-) And an autorouter, which has no idea of the intended layout by the designer, is really not too useful. When we give some hints, the autorouter may become more useful. But in first line the define netclass in schematics proposal was bound to manually routing. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Fri, 2010-08-06 at 17:42 -0700, Andrew Poelstra wrote: Layer groups as I proposed separate the board into different workspaces to keep things organized. I understand your goal, and support it. But I still have problems to imagine how workspaces will work for layout process. At the end all traces and elements must fit on the board, and there space is the limiting factor. Of course I understand more simple concepts, like better support for selections (selecting all elements from one schematic sheet, all elements from a subcircuit like an amplifier or DC-DC-converter,...) or crossprobing. But your desire seems to be beyond that. So am example with a picture may be fine. 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: wishful UI
On Sat, 2010-08-07 at 12:58 -0700, Andrew Poelstra wrote: I agree, but on a high level a net /is/ a relation between two pads/pins. (Well, a net can have many pads/pins. A subnet would be restricted to two, by definition.) No. A subnet, in my mind, is not restricted to two nodes (pin/pad). The +5V net with netname five_volt_positive can contain a high current subnet including DC-DC converter, big capacitor, fuse, high current devices. Just to make this clear. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Mon, Aug 16, 2010 at 01:18:37PM +0200, Stefan Salewski wrote: On Fri, 2010-08-06 at 17:42 -0700, Andrew Poelstra wrote: Layer groups as I proposed separate the board into different workspaces to keep things organized. I understand your goal, and support it. But I still have problems to imagine how workspaces will work for layout process. At the end all traces and elements must fit on the board, and there space is the limiting factor. Of course I understand more simple concepts, like better support for selections (selecting all elements from one schematic sheet, all elements from a subcircuit like an amplifier or DC-DC-converter,...) or crossprobing. But your desire seems to be beyond that. So am example with a picture may be fine. No, that's pretty much it. There are two things I want beyond simply workspaces to hold different tool settings for different functional groups: 1. You can create a view based on anything, not just functional groups, as will be the default. This includes opening components in their own view and editing them, or saving views as components. 2. Functional groups give one more structure to attach DRC rules to, between individual components and the entire PCB. The implementation of functional groups would be to simply add another attribute to each object, functional-block, which would determine which function block(s) each object belongs to. It merely allows one to classify parts, and to search or filter on this classification. As for workspaces: By default, PCB will open the Everything view, as well as a view for each functional group in a layout. However, the concepts of functional group and workspace are actually completely independent, though it may not appear that way to beginners, for simplicity's sake. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Stefan Salewski wrote: On Sat, 2010-08-07 at 12:58 -0700, Andrew Poelstra wrote: I agree, but on a high level a net /is/ a relation between two pads/pins. (Well, a net can have many pads/pins. A subnet would be restricted to two, by definition.) No. A subnet, in my mind, is not restricted to two nodes (pin/pad). The +5V net with netname five_volt_positive can contain a high current subnet including DC-DC converter, big capacitor, fuse, high current devices. Just to make this clear. Just to make it known, a subnet is a point to point connection within a net was the one and only DEFINITION of what a sub net is I found and understood. All other ways I can conceive are generalizations of that, ie. a subnet is a list of 2 or more pins within a net. For lists of 3 or more pins attributes like length or impedance don't make any sense, so this appears to me a bit like sound and smoke. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Armin Faltl wrote: My very little experience with autorouters also makes me believe, that an autorouter has even less understanding of EMI issues than I have ;-) Sure, that's why I made the analogy to Rainman. Routers are autistic. Have to be told what to do with many attribs and usually with some hand routing of fanouts done first. JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Andrew Poelstra wrote: No, that's pretty much it. There are two things I want beyond simply workspaces to hold different tool settings for different functional groups: 1. You can create a view based on anything, not just functional groups, as will be the default. This includes opening components in their own view and editing them, or saving views as components. 2. Functional groups give one more structure to attach DRC rules to, between individual components and the entire PCB. This sounds great! If you save a view as a component, it would be good to have an optional way to backannotate a symbol for it into the schematic. Are you thinking that way? To save a view as a component with pins and busses attached just like a normal component that came from a footprint? John Griessen ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
- John Griessen j...@ecosensory.com wrote: Andrew Poelstra wrote: No, that's pretty much it. There are two things I want beyond simply workspaces to hold different tool settings for different functional groups: 1. You can create a view based on anything, not just functional groups, as will be the default. This includes opening components in their own view and editing them, or saving views as components. 2. Functional groups give one more structure to attach DRC rules to, between individual components and the entire PCB. This sounds great! If you save a view as a component, it would be good to have an optional way to backannotate a symbol for it into the schematic. Are you thinking that way? To save a view as a component with pins and busses attached just like a normal component that came from a footprint? My thinking was to have a flag set for views editing components - which would do things like disable all layers except silk/pins/component, change the Save group to save .fp files instead of .pcb files, etc. That's a secondary plan, of course. Initially I'll just throw a export view as footprint button somewhere, while we work out the details of how views and functional blocks should work. When you click the new button beside the view tabs, you'll get a popup asking if you want to create a: o New functional block o New component (footprint) o Custom view Wherein custom view would allow you to create a filter range as per my DRC rule proposal. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Rick Collins wrote: Why not start with what you are trying to do in the layout, consider what the layout tool needs to make that happen, then trace that back to what is needed in the schematic to support the layout? There are lots of different users of these programs, and they have different goals. You're not going to show up and get your way in a FOSS development community unless your suggestion is obvious and brilliant at the same time. IOW slim and none. When would you want a layout to control impedance on a portion of a net and not the entire net? Who knows? Volunteers making a tool do nothing but your special cases is not going to happen. Volunteers making a tool for controlling impedances when and where told to has a chance of happening. JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Andrew Poelstra wrote: When you click the new button beside the view tabs, you'll get a popup asking if you want to create a: o New functional block o New component (footprint) o Custom view So are you thinking of reusing the layout editor to edit the footprint view? Then we could create pins or pads to get a new footprint with existing footprints inside it. The netlister would need to handle footprints with no package similarly as we handle flattened hierarchy now. Probably you're thinking of saving to the buffer and convert to footprint. the buffer method only allows one level I think, no component within component. I'd be happy to have a simple no hierarchy layout group with no new pads or pins added that is savable. Then no netlister changes would be needed, the group could be handled by flattened hierarchy naming if you wanted to put down repeated instances of it. 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: wishful UI
You're not going to show up and get your way in a FOSS development community unless your suggestion is obvious and brilliant at the same time. or if you're willing to do the work yourself, of course :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
John Griessen wrote: Rick Collins wrote: Why not start with what you are trying to do in the layout, consider what the layout tool needs to make that happen, then trace that back to what is needed in the schematic to support the layout? There are lots of different users of these programs, and they have different goals. You're not going to show up and get your way in a FOSS development community unless your suggestion is obvious and brilliant at the same time. IOW slim and none. JG, in my opinion Rick has a point, that without 100% clear definitions from and for all of those talking here using subnet, the whole discussion has a high chance of getting nowhere and some of the usecases brought in for support of the idea seem to come from Wolkenkuckusheim [1] for him. He's never been insulting and I value the practical view of his writing. As he's less writing, he's probably more routing than me - a reproach I'm making to myself - I just write here, to keep the future tool useful to me and found it hard to follow all the discussion. [1] the term is german and some of the ideas look like from there for me (too) e.g. I make my traces as broad as I see fit or have space in the area, so all the cool design auto blahblah means nothing to me, but a minimum clearance based on voltage is a good feature. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
- John Griessen j...@ecosensory.com wrote: Andrew Poelstra wrote: When you click the new button beside the view tabs, you'll get a popup asking if you want to create a: o New functional block o New component (footprint) o Custom view So are you thinking of reusing the layout editor to edit the footprint view? No, there will be a new new button beside the tabs, like in Firefox. Clicking that will popup the dialog. Then we could create pins or pads to get a new footprint with existing footprints inside it. The netlister would need to handle footprints with no package similarly as we handle flattened hierarchy now. You could create a footprint out of other footprints, but it would probably need to be flattened when saving out. Probably you're thinking of saving to the buffer and convert to footprint. the buffer method only allows one level I think, no component within component. Exactly. I'd be happy to have a simple no hierarchy layout group with no new pads or pins added that is savable. Then no netlister changes would be needed, the group could be handled by flattened hierarchy naming if you wanted to put down repeated instances of it. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Mon, 2010-08-16 at 12:00 -0400, Rick Collins wrote: I think we should try to find a better name for the connection between two nodes in a net, maybe segment? In the layout program I use, a segment is a single section of a PWB route between two points. That is, it is the shortest specified portion of a route. The entire connected entity is a net and a connection between two pins or a T vertex is a trace. The trace is equivalent to what you are trying to describe. True, segment was a bad propose from me. I am not sure if trace is really good, in my mind trace is bound to a special shape... Maybe we should simple say connection between two points/pins/nodes. (I still wonder about the term PWB, a google search does not really help.) A lot of the discussion in this list is conducted as if the functioning of schematics were the only consideration. Why not start with what you are trying to do in the layout, consider what the layout tool needs to make that happen, then trace that back to what is needed in the schematic to support the layout? Indeed, that is what I would do, if I would be alone... Please note, I was not the one who has the idea of specifying attributes on the schematic level. This discussion is really old, at least it existed when Anthony Blake starts with his topological router and we consider how to make that router more smart. And as Kai-Martin told us, this concept is in Protel for ten years. So it is not an idea at all, it is an concept, and the question is, how useful it is. I wrote that down, with a small picture, because my memory is not too good... The whole story started this time with ideas of Andrew Poelstra, and it may start again in a few months... So much of this conversation just seems so disconnected from what might be needed to do real work. This is true -- from time to time we have discussions from new users with great ideas and wishes, but without the skills and time to program that. Sometimes I am one of them. If you want to consider impedance, then lets start with the ways you would want to control impedance and figure out just what that demands of layout and then the schematic? Normally when I am controlling impedance, I am using point to point connections with no branches or stubs. Sure, this is the general and most important case. But if they are kept short, a stub can be used with impedance controlled nets. Likewise, I seldom have more than one receiver on an impedance controlled nets, but I can see where a bus might need to be impedance controlled even with many drivers and receivers. So it seems like in layout you would need impedance on an entire net, not just a trace or subnet. When would you want a layout to control impedance on a portion of a net and not the entire net? Rick I do not really like to discuss all that details now. When we build a new house, it is difficult to predict the final color of the inner rooms. Indeed I think that a net with defined impedance should define that impedance to the whole net, no need for subnets. But I may be wrong. One special case is the example which I mentioned yesterday, when we want to enforce a special shape of a net in the schematic level. But for power supply nets, different attributes for different traces of a net makes sense, and most devices need power supply. 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: wishful UI
Ok, if that is the way this group works. I have been told that these tools can be useful and I assumed that would be the goal of development. I see lot of comments going in all directions with no clear indication of how any of it would be used. But I'm just a practical sort of guy. If you guys are into the idea of what schematic software can be rather than the practical side of what is needed by the guys in the trenches, that's fine. It's your software. This is all new to me. I actually don't use the gEDA tools other than Gerbv which has some issues under Windows. I've used FreePCB and make my small contributions there. But there is only one developer and it is not clear that he wants help. So I can only make suggestions and not able to add to the code itself. I do provide peripheral support by advising newbies and help with the wiki at the moment. If there is anything I can help with here, I'm glad to do so. Have a nice one. Rick At 12:21 PM 8/16/2010, you wrote: Rick Collins wrote: Why not start with what you are trying to do in the layout, consider what the layout tool needs to make that happen, then trace that back to what is needed in the schematic to support the layout? There are lots of different users of these programs, and they have different goals. You're not going to show up and get your way in a FOSS development community unless your suggestion is obvious and brilliant at the same time. IOW slim and none. When would you want a layout to control impedance on a portion of a net and not the entire net? Who knows? Volunteers making a tool do nothing but your special cases is not going to happen. Volunteers making a tool for controlling impedances when and where told to has a chance of happening. JG ___ 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: wishful UI
On Mon, 2010-08-16 at 18:54 +0200, Armin Faltl wrote: JG, in my opinion Rick has a point, that without 100% clear definitions from and for all of those talking here using subnet, the whole discussion has a high chance of getting nowhere This is true -- but the point is not 100% clear definitions but skills and time and will to work and code. Andrew Poelstra has shown at least some of the last mentioned. My fear was, that he moved in a wrong direction, because he is new to EDA and gEDA/PCB. And that he fast turns away from this project again -- without support by some motivating words. I myself -- I guess I will not find much time to learn the internals of gEDA/PCB in the next 12 months, sorry. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
At 12:57 PM 8/16/2010, you wrote: On Mon, 2010-08-16 at 12:00 -0400, Rick Collins wrote: I think we should try to find a better name for the connection between two nodes in a net, maybe segment? In the layout program I use, a segment is a single section of a PWB route between two points. That is, it is the shortest specified portion of a route. The entire connected entity is a net and a connection between two pins or a T vertex is a trace. The trace is equivalent to what you are trying to describe. True, segment was a bad propose from me. I am not sure if trace is really good, in my mind trace is bound to a special shape... Maybe we should simple say connection between two points/pins/nodes. (I still wonder about the term PWB, a google search does not really help.) PWB is Printed Wiring Board. I use PWB for the bare board because often PCB is used for an entire assembly with parts installed. In reality the two terms should mean the same thing, it is a matter of usage. The real problem is that people should call a circuit card assembly an assembly of some sort and not a PCB. Also, if you look up PCB you will find Polychlorinated Biphenyls which have nothing to do with circuit cards and are very undesirable... ;^) As to trace, there is still some advantage to using a term for a special meaning even if that special meaning is not what you first think of when you hear it. A lot of the discussion in this list is conducted as if the functioning of schematics were the only consideration. Why not start with what you are trying to do in the layout, consider what the layout tool needs to make that happen, then trace that back to what is needed in the schematic to support the layout? Indeed, that is what I would do, if I would be alone... Please note, I was not the one who has the idea of specifying attributes on the schematic level. This discussion is really old, at least it existed when Anthony Blake starts with his topological router and we consider how to make that router more smart. And as Kai-Martin told us, this concept is in Protel for ten years. So it is not an idea at all, it is an concept, and the question is, how useful it is. I wrote that down, with a small picture, because my memory is not too good... The whole story started this time with ideas of Andrew Poelstra, and it may start again in a few months... I think adding attributes to schematics is a good idea. But you need a way to convey that to the layout tool, what ever sort of tool that is, ASIC, FPGA, circuit card... No point in adding features to a schematic than can't be sent to or used by layout. So much of this conversation just seems so disconnected from what might be needed to do real work. This is true -- from time to time we have discussions from new users with great ideas and wishes, but without the skills and time to program that. Sometimes I am one of them. I guess I am not thinking that there is a problem with implementation. My concern is value. How are these ideas to be used by... well, the users? After all, this is the geda-user list, no? If getting the work done is the hardest part of it all, then maybe I can help... If you want to consider impedance, then lets start with the ways you would want to control impedance and figure out just what that demands of layout and then the schematic? Normally when I am controlling impedance, I am using point to point connections with no branches or stubs. Sure, this is the general and most important case. But if they are kept short, a stub can be used with impedance controlled nets. Likewise, I seldom have more than one receiver on an impedance controlled nets, but I can see where a bus might need to be impedance controlled even with many drivers and receivers. So it seems like in layout you would need impedance on an entire net, not just a trace or subnet. When would you want a layout to control impedance on a portion of a net and not the entire net? Rick I do not really like to discuss all that details now. When we build a new house, it is difficult to predict the final color of the inner rooms. Indeed I think that a net with defined impedance should define that impedance to the whole net, no need for subnets. But I may be wrong. One special case is the example which I mentioned yesterday, when we want to enforce a special shape of a net in the schematic level. But for power supply nets, different attributes for different traces of a net makes sense, and most devices need power supply. Wow! Impedance was being discussed in the context of it being a property of a trace rather than then entire net. I suggest that it be considered how impedance control is used on the circuit card (or chip or whatever) and you compare that to picking the color of a room when designing a house! I see it as figuring out where you want the rooms and doorways before you plan for the plumbing and electrical.
Re: gEDA-user: wishful UI
- Stefan Salewski m...@ssalewski.de wrote: On Mon, 2010-08-16 at 18:54 +0200, Armin Faltl wrote: This is true -- but the point is not 100% clear definitions but skills and time and will to work and code. Andrew Poelstra has shown at least some of the last mentioned. My fear was, that he moved in a wrong direction, because he is new to EDA and gEDA/PCB. And that he fast turns away from this project again -- without support by some motivating words. I don't expect to move on anytime soon - though we will see how much time I have left when school starts again. Certainly, EDA is filled with exciting computing science problems, while being useful at the same time. Life is much harder if you can't hack the hardware around you :) Also, the gEDA codebase is certainly cleaner and more hackable than typical, and the list much more open-minded. As for going the wrong direction - if we don't ever explore, then how can we learn? Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Mon, 2010-08-16 at 13:55 -0400, Rick Collins wrote: I guess I am not thinking that there is a problem with implementation. My concern is value. How are these ideas to be used by... well, the users? After all, this is the geda-user list, no? If getting the work done is the hardest part of it all, then maybe I can help... Of course, my concern is value too. But what people regard as important is very different. Here in Germany most people related to electronics seems to give visible appearance a very high priority. I have seen many complaints about gEDA/PCB to be ugly. All what does not look like Windows7 or MacOSX is regarded ugly and unusable by that people. (Some Linux users now regard Gnome as ugly too...) So one may consider optical tuning of GUI most valuable? For the concept of defining attributes at the schematic level: You may know my DSO board. Doing that layout took me 500 hours of carefully work. That is OK. A smart layouter may need less time, maybe only 300 hours with PCB. I think that layouter will take 50 $ per hour, so I have to pay 15000 $. Or I have to do next layout again myself. But that layout will be more complicated, it will contain fast differential signal pairs and BGA footprints. Should be more than 500 hours for me. I think attributes can support my work, so I will need only 350 hours. Maybe much less with autorouter support. That would make me happy. Some of our users may want a nice shiny toy with a colorful GUI. That is OK, and may be useful for very small hobby projects. Some users may be more interested in better support of larger designs. Of course, transferring the attribute stuff from schematics to the PCB layout tool is difficult in many points: It concerns gschem, gnetlist and PCB. And we have to ensure that we do not break something and do it in a clean, professional way. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
I looked at your DSO project. That is pretty impressive. Are you looking for any help? That is right up my alley! Rick At 02:56 PM 8/16/2010, you wrote: On Mon, 2010-08-16 at 13:55 -0400, Rick Collins wrote: I guess I am not thinking that there is a problem with implementation. My concern is value. How are these ideas to be used by... well, the users? After all, this is the geda-user list, no? If getting the work done is the hardest part of it all, then maybe I can help... Of course, my concern is value too. But what people regard as important is very different. Here in Germany most people related to electronics seems to give visible appearance a very high priority. I have seen many complaints about gEDA/PCB to be ugly. All what does not look like Windows7 or MacOSX is regarded ugly and unusable by that people. (Some Linux users now regard Gnome as ugly too...) So one may consider optical tuning of GUI most valuable? For the concept of defining attributes at the schematic level: You may know my DSO board. Doing that layout took me 500 hours of carefully work. That is OK. A smart layouter may need less time, maybe only 300 hours with PCB. I think that layouter will take 50 $ per hour, so I have to pay 15000 $. Or I have to do next layout again myself. But that layout will be more complicated, it will contain fast differential signal pairs and BGA footprints. Should be more than 500 hours for me. I think attributes can support my work, so I will need only 350 hours. Maybe much less with autorouter support. That would make me happy. Some of our users may want a nice shiny toy with a colorful GUI. That is OK, and may be useful for very small hobby projects. Some users may be more interested in better support of larger designs. Of course, transferring the attribute stuff from schematics to the PCB layout tool is difficult in many points: It concerns gschem, gnetlist and PCB. And we have to ensure that we do not break something and do it in a clean, professional way. ___ 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: wishful UI
On Mon, 2010-08-16 at 15:27 -0400, Rick Collins wrote: I looked at your DSO project. That is pretty impressive. Are you looking for any help? That is right up my alley! Rick Indeed I was hoping for some support during the last two years, but there was not much interest, some people with very limited skills in electronics area contacted me, hoping for a very cheap device. But of course I can not build large quantities, so costs can not be smaller than similar commercial tools from china, so people are disappointed. I do understand that. No, currently I do not need help, I have done schematics and layout very carefully, learned VHDL, started design of a GTK GUI. And I wrote my own USB firmware some years ago. Currently I am doing some final checking of schematics and layout, with minimal modifications. I indent to order parts and two PCB prototype boards in harvest and intend soldering the first prototype before end of this year. If that prototype works, than there may be again room for support, for example for optimizing the VHDL code, board firmware and communication with the PC, and finally optimizing the user interface. I will tell on my homepage and on this list when there is the first working prototype -- hopefully before the end of this year. 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: wishful UI
Stefan Salewski wrote: But what people regard as important is very different. Here in Germany most people related to electronics seems to give visible appearance a very high priority. On the other hand, the ugly duckling who calls itself eagle enjoys quite some user base in Germany. Bartels AutoEngineer is not exactly pure eye candy, either. ---)kaimartin(--- -- 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
Re: gEDA-user: wishful UI
Stefan Salewski wrote: I have to do next layout again myself. But that layout will be more complicated, it will contain fast differential signal pairs and BGA footprints. Should be more than 500 hours for me. I think attributes can support my work, so I will need only 350 hours. Maybe much less with autorouter support. That would make me happy. Tony's topo router is going to be good when we test it enough to handle existing layout and complete it. And we have to ensure that we do not break something and do it in a clean, professional way. Yes, we need a unit test with a topo router example to make sure it keeps on working as much as it does. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Hi John Doty, On Aug 14, 2010; 02:45pm; John Doty wrote: No. It can happen whenever you have multiple symbols with the same refdes, regardless of the back end. Slotting is a particular case of this, but not the only one. It's a pure gnetlist problem, having nothing to do with pcb. That is the problem, whenever you have multiple symbols with the same refdes, as I suspected and mentioned in my previous post. You might already know, other backends such as Verilog, VHDL, etc do not have this problem, because they all expect unique refdes value for each symbol instance. Gnetlist frontend algorithm expects unique refdes from the schematic file to give you the correct result. This is reasonable, because the Gnetlist frontend treats refdes attribute value in .sch file as unique ID for LOGICAL_SYMBOL; instead of for PCB_PACKAGE which may contain variable numbers of LOGICAL_SYMBOLs. The final PCB netlist wants to see PACKAGE_refdes instead of LOGICAL_SYBOL_refdes. So one of the solution is (as I stated before and expalin here): 1) Assign unique refdes value to all netlistable logical symbols in the schematic. If the logical symbol is one of several in a PHYSICAL_package, then assgined refdes to each logical symbol such as Uxx_yy; where yy is the value to identify a particular LOGICAL_SYMBOL among several within a PCB_PACKAGE; and xx value is the ID to differentiate among all PCB_PACKAGE for your design. Uxx is what you want to see in your PCB netlist. 2) Your backend Scheme code should strip the _yy from Uxx_yy when outputing your PCB's PACKAGE_refdes Uxx. If this solution is not what you want, there are others I can suggest. Yes, ofcourse, you can fix it at the Gnetlist frontend, in which case, that fix should not affect other backends which require unique refdes for symbol instance. Best Regards, Paul Tan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Stefan Salewski wrote: On Sat, 2010-08-14 at 18:57 -0400, Paul Tan wrote: On Aug 14, 2010; 10:34am, Andrew Poelstra wrote: Otherwise, certain nets (such as power or ground nets), which often have vastly different characteristics in different sections, would be difficult to describe. I think he cares about touching net segments, same as I, see for example http://ssalewski.de/gEDA-Netclass.html.en the Power and Bypass segment. I think John Doty got it: Yes, gschem is where blocks/sets/groups of net segments need to be defined as having certain attributes first, then related to attributes on physical layout objects such as vias and traces and pads. In the layout, each object needs the full list of attached attributes, since it is individually editable in the layout program, (yes any layout program works that way). 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: wishful UI
DJ Delorie wrote: Also, my proposal is to have the busses converted to multiple independent nets in the common parts of gnetlist, so that you don't have to tweak every single backend to add support for them. You can still support magic net names that the backends understand, if you want, but it seems to me a common concept like bus should be done in common code and be consistently applied across all the backends. Sure, and the big EDA code based on LISP/Guile also uses syntax for names so a wire with such a name attrib seems to be all that's necessary to define a bus. Putting the syntax netname[0:7] into form netname[0], netname[1], for the backends is fine. Seems to me the common code would still need to be aware of bus nets. John -- ex Cadence and Mentor layer outer among other things... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Sure, and the big EDA code based on LISP/Guile also uses syntax for names so a wire with such a name attrib seems to be all that's necessary to define a bus. Putting the syntax netname[0:7] into form netname[0], netname[1], for the backends is fine. Seems to me the common code would still need to be aware of bus nets. I published my paper mostly to get a discussion going on what busses *mean* though, not the implementation details. For example, what does it mean when three busses with different names are connected? D[15:0] ==** D[15:0] || \\ A[1:16] With nets, it breaks if you do that. I would want DRC to complain to - it's a real error to give one signal two names. Do we need a separate bus thing in order to apply different rules? And I want to understand the implications of pins that reflect multiple signals, too - mapping names and numbers, etc. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Paul Tan wrote: That is the problem, whenever you have multiple symbols with the same refdes, as I suspected and mentioned in my previous post. . . . The final PCB netlist wants to see PACKAGE_refdes instead of LOGICAL_SYBOL_refdes. So one of the solution is (as I stated before and explain here): 1) Assign unique refdes value to all netlistable logical symbols in the schematic. If the logical symbol is one of several in a PHYSICAL_package, then assgined refdes to each logical symbol such as Uxx_yy; where yy is the value to identify a particular LOGICAL_SYMBOL among several within a PCB_PACKAGE; and xx value is the ID to differentiate among all PCB_PACKAGE for your design. Uxx is what you want to see in your PCB netlist. This is a good way to think how to implement busses. A way to be backwards compatible might be to take any refdes with that form and create an old style short one and another attrib for the unique PCB_PACKAGE identifier. Existing libraries could be processed to change them that way also. John Griessen ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
One of the things we need for pin/gate swapping in pcb is a UUID for each logical symbol in the schematic set. Refdes is not unique enough :-( ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Hello Paul, On Aug 15, 2010, at 4:08 AM, Paul Tan wrote: Hi John Doty, On Aug 14, 2010; 02:45pm; John Doty wrote: No. It can happen whenever you have multiple symbols with the same refdes, regardless of the back end. Slotting is a particular case of this, but not the only one. It's a pure gnetlist problem, having nothing to do with pcb. That is the problem, whenever you have multiple symbols with the same refdes, as I suspected and mentioned in my previous post. You might already know, other backends such as Verilog, VHDL, etc do not have this problem, because they all expect unique refdes value for each symbol instance. The data from multiple symbol instances with the same refdes is combined in the front end, regardless of the back end. This can therefore occur with any back end, I think. You can, for example, split a SPICE vcvs into two symbols if you wish to in gEDA, using either of the SPICE gnetlist back ends. The power of orthogonal design. Gnetlist frontend algorithm expects unique refdes from the schematic file to give you the correct result. Except that many of us split components into functional blocks (not necessarily slots). An extreme example is my pins2gsch script (http://www.gedasymbols.org/user/john_doty/tools/pins2gsch.html). This is reasonable, because the Gnetlist frontend treats refdes attribute value in .sch file as unique ID for LOGICAL_SYMBOL; instead of for PCB_PACKAGE which may contain variable numbers of LOGICAL_SYMBOLs. The final PCB netlist wants to see PACKAGE_refdes instead of LOGICAL_SYBOL_refdes. So one of the solution is (as I stated before and expalin here): 1) Assign unique refdes value to all netlistable logical symbols in the schematic. If the logical symbol is one of several in a PHYSICAL_package, then assgined refdes to each logical symbol such as Uxx_yy; where yy is the value to identify a particular LOGICAL_SYMBOL among several within a PCB_PACKAGE; and xx value is the ID to differentiate among all PCB_PACKAGE for your design. Uxx is what you want to see in your PCB netlist. 2) Your backend Scheme code should strip the _yy from Uxx_yy when outputing your PCB's PACKAGE_refdes Uxx. But it's an issue that affects all back ends, not just the pcb back end (which I never use). If this solution is not what you want, there are others I can suggest. Yes, ofcourse, you can fix it at the Gnetlist frontend, in which case, that fix should not affect other backends which require unique refdes for symbol instance. A front end function gnetlist:get-all-symbol-attributes would make a pretty decent primitive factor here. It could return a nested list like: ( ( ( refdes U1 ) ( device 7400 ) ) ( ( refdes U1 ) ( device 14pwr ) ( footprint dip14 ) ) ( ( refdes C1 ) ( device CAPACITOR ) ( footprint 0805 ) ( value 0.1uF ) ) ... ) In this example, a 7400 is broken into two functional blocks, logic and power, an example of a rather common practice. Then, several gnetlist primitives could be eliminated: gnetlist:get-package-attribute gnetlist:vams-get-package-attributes gnetlist:get-slots gnetlist:get-unique-slots These would become convenience functions in gnetlist.scm, using the common primitive above. Existing front ends need them, and they're fine functions to have. They just aren't sensible as primitives. 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: wishful UI
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. I may add some documentation to the schematic in the form of notes, but they are just that, notes, not design info that I expect to be conveyed in the netlist. 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. For example, I have a part which can use the same voltage for I/Os that it uses for the core Vcc. But a different version of the part uses a much lower core Vcc. So the two Vccs are separate nets and I use a jumper symbol to connect them. In layout I have a choice of how to implement that jumper, as a two pin header, a zero ohm resistor or a two pin device that is nothing but a PWB copper connection between the two pins. How would you make use of subnets that would be useful that you can't do with just nets? Rick At 01:34 PM 8/14/2010, you wrote: On Sat, Aug 14, 2010 at 03:17:42AM -0400, Paul Tan wrote: ...In fact, I would like to see that gEDA can process ANY attributes attached to a net in similar fashion as it process ANY attributes attached to a symbol currently. I agree, but I'm not sure this would be useful until we find a way to split nets up into subnets - which is a much more complicated change. Otherwise, certain nets (such as power or ground nets), which often have vastly different characteristics in different sections, would be difficult to describe. Andrew ___ 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: wishful UI
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. 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. John Griessen -- Ecosensory Austin TX PS What I called select-and-add-attributes is an imaginary function not existing in gschem. Yet... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
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
Re: gEDA-user: wishful UI
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
Re: gEDA-user: wishful UI
John Griessen wrote: Rick Collins wrote: How would you make use of subnets that would be useful that you can't do with just nets? After my last post, I saw you could argue, You can do that with just nets., and I see your point that from a schematic view a net is a net, and most of the use of the concept of subnets is in layout. In case you mean How would you make use of subnets in the schematic view?, here's another case: A net is a net, except when it is connected to something... Suppose we want to tell an autorouter to make certain pins, capacitor pins, routed closely? You could define a subnet by tagging a net like VCC partially like this: Use select-and-add-attributes to tag one pin of a cap and one pin of a chip with a name unique to the schematic, and with attribute route-priority-closest, then go to another cap also connected to VCC and do likewise. There you have two subnets doing something very useful for automation on a schematic alone. No need to define physical regions on a layout to have a meaning. And we see that a net isn't a net everywhere. At each end, (and nets can have any number of ends, not just two), the part where it connects to something else is always different from the rest. The layout correspondence is pin or pad at the ends of the net, and trace everywhere else. Sure, Im talking about obvious stuff, but it's not to suggest anyone's slow on this list, just that autorouters and other automatons are slow on the uptake, even if they're faster at counting than Rainman. Subnet definitions would be most valuable for slow witted but speedy and cheap-to-hire autorouters. John Griessen ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Stefan Salewski wrote: And I can not imagine that commercial EDA tools do not support the layouter in a similar way as we now consider. By the way, protel99SE did so more than 10 years ago... ---)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: wishful UI
Hi John Doty, On Aug 15, 2010; 08:18am; John Doty wrote: A front end function gnetlist:get-all-symbol-attributes would make a pretty decent primitive factor here. It could return a nested list like: ( ( ( refdes U1 ) ( device 7400 ) ) ( ( refdes U1 ) ( device 14pwr ) ( footprint dip14 ) ) ( ( refdes C1 ) ( device CAPACITOR ) ( footprint 0805 ) ( value 0.1uF ) ) ... ) Yes, that is another solution, and it does not affect other backends, since that is a new function gnetlist:get-all-symbol-attributes which no backends called. Although there are other Gnetlist frontend solutions which have less impact on memory footprint and performance, if you can get Ales to approve it, I am for it. Then you need to find out who is going to implement it. Moreover, to fix the PCB's netlist whatever problem, who is going to implement all the changes needed in PCB backends? Best Regards, Paul Tan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Hello, Paul. On Aug 15, 2010, at 3:34 PM, Paul Tan wrote: Hi John Doty, On Aug 15, 2010; 08:18am; John Doty wrote: A front end function gnetlist:get-all-symbol-attributes would make a pretty decent primitive factor here. It could return a nested list like: ( ( ( refdes U1 ) ( device 7400 ) ) ( ( refdes U1 ) ( device 14pwr ) ( footprint dip14 ) ) ( ( refdes C1 ) ( device CAPACITOR ) ( footprint 0805 ) ( value 0.1uF ) ) ... ) Yes, that is another solution, and it does not affect other backends, since that is a new function gnetlist:get-all-symbol-attributes which no backends called. Although there are other Gnetlist frontend solutions which have less impact on memory footprint and performance, if you can get Ales to approve it, I am for it. Then you need to find out who is going to implement it. That's the rub. Moreover, to fix the PCB's netlist whatever problem, who is going to implement all the changes needed in PCB backends? No changes are required in the back ends. Somebody would have to rewrite gnetlist:get-package-attribute and perhaps gnetlist:vams-get-package-attributes in Guile, so that they would use the new interface. I'd volunteer to do that. 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: wishful UI
Hi All, We can all agree that the current gEDA(Gschem/Gnetlist) need to accomodate more than just the netname attribute attached to a net. In fact, I would like to see that gEDA can process ANY attributes attached to a net in similar fashion as it process ANY attributes attached to a symbol currently. And that Gnetlist front end will present similar functions to the backend Scheme procedures, so that different backends (Verilog, VHDL, Spice, GnuCap, SystemC, PCB, etc) Scheme procedures can decipher net attributes particular to that backend. Note that I stress the ANY word above, because one of the most powerful features of gEDA is its architectural capabilities of supporting ANY attributes as ANY backend dictates. How the symbol and net attributes are handled should be up to the particular backend's Scheme procedure. I am familiar with the gEDA codes (both the C and Scheme). I can see that it is not too difficult to add the ANY net attributes feature., since it fits similar pattern as processing of symbol's ANY attributes. It is on my list of TO DO for gEDA, but we just don't have the time to do it yet. I am hoping someone will beat me to it. Best Regards, Paul Tan -Original Message- From: John Doty j...@noqsi.com To: gEDA user mailing list geda-user@moria.seul.org Sent: Fri, Aug 13, 2010 5:09 pm Subject: Re: gEDA-user: wishful UI On Aug 13, 2010, at 5:49 PM, Stefan Salewski wrote: On Fri, 2010-08-13 at 19:28 -0400, DJ Delorie wrote: I guess it would be no great deal for smart (but very busy) people like Peter C. and DJ, to implement the basic concept. For people not familiar with the internals of gschem and PCB like me it may take very long... I'm quite willing to teach people PCB internals, if it means having more PCB developers. In my opinion writing some basic documentation about the internal work of PCB would be really a good idea. (I can remember that I looked at the PCB source code about two years ago: I was very positive surprised about the fact that the code was very compact, but I was not able to see the basic concepts...) The same problem applies to gschem/gnetlist. Unfortunately, some of our developers take the attitude that dumbing down the (almost supernaturally productive) UI is the way to attract more developers. But from where I sit, the real problem is that the internals of gschem, gnetlist, and especially libgeda are poorly documented. This is especially problematic at the guile scripting interface (code for guile functions in C is pretty obscure). I've nibbled at this from outside, deducing function from behavior and writing some of my findings up, but it would really help if the experts would put in some effort here. Developers who'd be attracted by a dumbed-down UI are exactly the folks I do not want to see working on gEDA. 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: wishful UI
On Fri, 13 Aug 2010 18:09:08 -0600, John Doty j...@noqsi.com wrote: Unfortunately, some of our developers take the attitude that dumbing down the (almost supernaturally productive) UI is the way to attract more developers. Who? This is especially problematic at the guile scripting interface (code for guile functions in C is pretty obscure). I've nibbled at this from outside, deducing function from behavior and writing some of my findings up, but it would really help if the experts would put in some effort here. As I've said before, the Guile API in gschem is fundamentally broken, due to the way that the invisible state is stored and accessed. It has inconsistent naming and calling conventions, and it's possible to write perfectly valid code that leaves the gschem instance in an inconsistent state. This is partly because it was initially introduced just as a convenient way to specify options, keybindings and menu layout in a declarative manner, but has had some extra things bolted on in an organic manner. I've made a start on trying to build a more consistent Guile API, but it's been pretty hard going, and unfortunately for a number of reasons I don't have a huge amount of time for gEDA at the moment. I don't know about the Guile API for gnetlist, but last time I checked it suffered from *some* of the same problems, but not nearly to the same extent. There's some problems with gnetlist backends -- for example, some of them are written in a non-tail-recursive style, which causes stack exhaustion on large designs, but that's not too difficult to fix. Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Paul Tan wrote: Hi All, We can all agree that the current gEDA(Gschem/Gnetlist) need to accomodate more than just the netname attribute attached to a net. In fact, I would like to see that gEDA can process ANY attributes attached to a net in similar fashion as it process ANY attributes attached to a symbol currently. And that Gnetlist front end will present similar functions to the backend Scheme procedures, so that different backends (Verilog, VHDL, Spice, GnuCap, SystemC, PCB, etc) Scheme procedures can decipher net attributes particular to that backend. Note that I stress the ANY word above, because one of the most powerful features of gEDA is its architectural capabilities of supporting ANY attributes as ANY backend dictates. How the symbol and net attributes are handled should be up to the particular backend's Scheme procedure. I am familiar with the gEDA codes (both the C and Scheme). I can see that it is not too difficult to add the ANY net attributes feature., since it fits similar pattern as processing of symbol's ANY attributes. It is on my list of TO DO for gEDA, but we just don't have the time to do it yet. I am hoping someone will beat me to it. Best Regards, Paul Tan agree 100% ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Aug 14, 2010, at 1:17 AM, Paul Tan wrote: Hi All, We can all agree that the current gEDA(Gschem/Gnetlist) need to accomodate more than just the netname attribute attached to a net. In fact, I would like to see that gEDA can process ANY attributes attached to a net in similar fashion as it process ANY attributes attached to a symbol currently. And that Gnetlist front end will present similar functions to the backend Scheme procedures, so that different backends (Verilog, VHDL, Spice, GnuCap, SystemC, PCB, etc) Scheme procedures can decipher net attributes particular to that backend. Note that I stress the ANY word above, because one of the most powerful features of gEDA is its architectural capabilities of supporting ANY attributes as ANY backend dictates. Yes, yes, yes! How the symbol and net attributes are handled should be up to the particular backend's Scheme procedure. Remember that there's also a middle layer (gnetlist.scm and gnetlist-post.scm). It would be good if we made better use of it. Right now, the primitives are at too high a level, giving back ends access to specific design data, but not all of it. This simplifies back ends when it's the right thing, but it's a barrier when the back end needs more. Having these interfaces in the middle layer, based on lower level primitives (a primitive that returned a list of every object with its properties and attributes would be a great foundation), would increase our flexibility without impacting existing back ends. A back end writer would then be able to exploit the simplifying assumptions behind the middle layer interface, but would not be bound by them. I am familiar with the gEDA codes (both the C and Scheme). I can see that it is not too difficult to add the ANY net attributes feature., since it fits similar pattern as processing of symbol's ANY attributes. Except that it's slightly broken in the symbol case. Symbols are looked up by refdes, but a component may be represented by multiple symbols with the same refdes. Also, there may be more than one attribute with the same name, but the code only finds one at most. The code in gnetlist:get-package-attribute apparently looks in the the first matching symbol it finds for the first matching attribute (if any). This problem would be worse for nets, since multisegment nets are very common, and multiple attributes of the same name would be a reasonable way to express multiple net properties. It is on my list of TO DO for gEDA, but we just don't have the time to do it yet. I am hoping someone will beat me to it. I'm hoping you'll find time. You'll do it right. 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: wishful UI
On Sat, 14 Aug 2010 10:01:44 -0600, John Doty j...@noqsi.com wrote: Not important. The quick fix (make the stack bigger) is known and should be incorporated in the distributed system-gnetlistrc. The problem is a consequence of dropping a functional language into a procedural culture: it will continue to crop up as we get additional contributions of back ends (and hopefully plugins). The quick fix may be unaesthetic, but it doesn't cause additional problems. I'm sorry, but I think we're going to have to agree to disagree on this point. I believe that we should actually fix the problems, and enjoy the increased performance, rather than whack band-aids on them and pretend they're not there. In my opinion, gnetlist backends and (eventually) plugins that get accepted into the gEDA repository should be written to work on arbitrarily large designs. If that means that contributors need to learn how to think functionally, so be it. There are plenty of excellent resources on the web to help with programming efficiently in Lisp-like languages. I'd never seen Lisp-like syntax before I started hacking on gEDA, and if a Bear of Very Little Brain like myself can learn it, why shouldn't others be able to? Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Sat, Aug 14, 2010 at 03:17:42AM -0400, Paul Tan wrote: ...In fact, I would like to see that gEDA can process ANY attributes attached to a net in similar fashion as it process ANY attributes attached to a symbol currently. I agree, but I'm not sure this would be useful until we find a way to split nets up into subnets - which is a much more complicated change. Otherwise, certain nets (such as power or ground nets), which often have vastly different characteristics in different sections, would be difficult to describe. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Aug 14, 2010, at 10:51 AM, Peter TB Brett wrote: On Sat, 14 Aug 2010 10:01:44 -0600, John Doty j...@noqsi.com wrote: Not important. The quick fix (make the stack bigger) is known and should be incorporated in the distributed system-gnetlistrc. The problem is a consequence of dropping a functional language into a procedural culture: it will continue to crop up as we get additional contributions of back ends (and hopefully plugins). The quick fix may be unaesthetic, but it doesn't cause additional problems. I'm sorry, but I think we're going to have to agree to disagree on this point. I believe that we should actually fix the problems, and enjoy the increased performance, rather than whack band-aids on them and pretend they're not there. If you're going to make that argument, you need to be quantitative: how much increased performance? There isn't much to be had, I think. For my current large design (24 top level schematics plus 14 hierarchical schematics), gnetlist with the drc2 back end needs the increased stack to avoid crashing. Even so it only takes 2.2 seconds, while with efficient back ends it needs 1.4 seconds (on my MacBook). So with this large design, the time to be saved is at most 0.8 seconds per drc2 run. In my opinion, gnetlist backends and (eventually) plugins that get accepted into the gEDA repository should be written to work on arbitrarily large designs. I agree, but I think they already do for all practical purposes. It seems to me that the only barrier to doing designs with hundreds of schematic pages is my limited human capacity. If that means that contributors need to learn how to think functionally, so be it. There are plenty of excellent resources on the web to help with programming efficiently in Lisp-like languages. I'd never seen Lisp-like syntax before I started hacking on gEDA, and if a Bear of Very Little Brain like myself can learn it, why shouldn't others be able to? There is a specific problem with tail recursion in Guile: its optimization only works in certain special cases. To be sure, these are pretty common cases, but the user needs a bit of extra knowledge to guarantee that tail recursion will actually be optimized. The point of scripting is to put the power of the toolkit in the hands of those with specific problems to solve. You as a developer cannot accurately anticipate what these problems are. Some users already perceive Guile to be a barrier here: do we really want to put extra unnecessary restrictions on their use of it? A big stack isn't a problem. 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: wishful UI
On Aug 14, 2010, at 11:34 AM, Andrew Poelstra wrote: On Sat, Aug 14, 2010 at 03:17:42AM -0400, Paul Tan wrote: ...In fact, I would like to see that gEDA can process ANY attributes attached to a net in similar fashion as it process ANY attributes attached to a symbol currently. I agree, but I'm not sure this would be useful until we find a way to split nets up into subnets - which is a much more complicated change. Not so much. We already draw nets as segments, and attributes are actually attached to segments, not nets. Might need to modify the segment merging rules, but that's about it. And one could argue that the automatic segment merging is already a case of the tool inappropriately trying to outsmart the user. 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: wishful UI
On Sat, Aug 14, 2010 at 12:14:58PM -0600, John Doty wrote: On Aug 14, 2010, at 11:34 AM, Andrew Poelstra wrote: On Sat, Aug 14, 2010 at 03:17:42AM -0400, Paul Tan wrote: ...In fact, I would like to see that gEDA can process ANY attributes attached to a net in similar fashion as it process ANY attributes attached to a symbol currently. I agree, but I'm not sure this would be useful until we find a way to split nets up into subnets - which is a much more complicated change. Not so much. We already draw nets as segments, and attributes are actually attached to segments, not nets. Might need to modify the segment merging rules, but that's about it. And one could argue that the automatic segment merging is already a case of the tool inappropriately trying to outsmart the user. I see. We do do this in gschem - but not in pcb, nor in the .net file coming out of gsch2pcb. So PCB would need a breaking change in its .net and .pcb formats, no? Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Hi John Doty, On Aug 14, 2010; 08:49am, John Doty wrote: Except that it's slightly broken in the symbol case. Symbols are looked up by refdes, but a component may be represented by multiple symbols with the same refdes. Also, there may be more than one attribute with the same name, but the code only finds one at most. The code in gnetlist:get-package-attribute apparently looks in the the first matching symbol it finds for the first matching attribute (if any). Is the case you mentioned above relates to the problem of slotting in PCB? I don't design PCB myself, but occasionally I was curious about the slotting problems people complained about it here. As I remember, a year ago, it occurred to me, by briefly looking at how the PCB backend processes the packages (the term used in gEDA Scheme code), I suspected that the solution might be in how the packages are interpreted by the PCB backends. Correct me if I am wrong here (I only briefly looked at the PCB backend codes and I don't know what PCB's requirements are) : The PCB backend could have interpreted the package item in Scheme functions not directly as the final PCB's refdes, but a prefixed refdes for a logical symbol in the Gschem, such as Uxx_yy, where Uxx is the final PCB_refdes and the Uxx_yy is the logical refdes assigned to a logical symbol by the users or hook script in Gschem. The yy number may refer to a pinnumber or pinseq of a PCB's physical package, or from the slot definition, which the user or auto refdes hook can use to auto assign them in Gschem. If what I suspected is true, then it is not necessary to make changes to the Gnetlist frontend C codes to solve the problem, but just fix it in the PCB Scheme backend code. Not sure if this is the exact case for the PCB's netlist problem though, just a thought. This problem would be worse for nets, since multisegment nets are very common, and multiple attributes of the same name would be a reasonable way to express multiple net properties. Could be. If absolutely necessary, I might expose some forms of parsed NETLIST's nid or even the OBJECT's sid, with appropriate prefix, to the Gnetlist generic backend. Best Regards, Paul Tan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Well, as you suggest below, Groups are essentially a way of tagging different parts, so they would be completely independent of the physical layers - and the connectivity checker. ** Confusingly, PCB already has layer groups, which consist of multiple layers. A layer group is what ends up physically as a plane of copper in your produced board. Your terminology reverses the meaning, with a layer group consisting of logically grouped parts spanning multiple physical layers. I presume you intend to get rid of PCB's existing layer group functionality (good riddance IMO), however it would be less confusing to pick a new name. Perhaps logical group. Yes, absolutely! But I cannot think of a good name :) logical group is too long and ambiguous. Right now I am using Group, but that's even less useful. First I thought functional group would be good, but what you describe - a construct of functional interdependence spread on several layers in mechanical CAD is in many cases called a block or module. The concepts of layers + layer groups (hierarchical layers in mech-CAD) is orthogonal to blocks. E.g. you can turn visibility on and off for each independently. For the sake of visual collision detection in the case of EDA 3 levels of visibilty as suggested may be in order: coloured/saturated, greyed out and invisible. Esp. useful I envision the possibility to grey out blocks one does not work on while they stay visible. Being able to reuse a block independently of the layout it was created it, like in mechanical CAD would be very welcome here as well (did I miss something?) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Sat, Aug 14, 2010 at 10:28:09PM +0200, Armin Faltl wrote: Well, as you suggest below, Groups are essentially a way of tagging different parts, so they would be completely independent of the physical layers - and the connectivity checker. ** Confusingly, PCB already has layer groups, which consist of multiple layers. A layer group is what ends up physically as a plane of copper in your produced board. Your terminology reverses the meaning, with a layer group consisting of logically grouped parts spanning multiple physical layers. I presume you intend to get rid of PCB's existing layer group functionality (good riddance IMO), however it would be less confusing to pick a new name. Perhaps logical group. Yes, absolutely! But I cannot think of a good name :) logical group is too long and ambiguous. Right now I am using Group, but that's even less useful. First I thought functional group would be good, but what you describe - a construct of functional interdependence spread on several layers in mechanical CAD is in many cases called a block or module. The concepts of layers + layer groups (hierarchical layers in mech-CAD) is orthogonal to blocks. E.g. you can turn visibility on and off for each independently. For the sake of visual collision detection in the case of EDA 3 levels of visibilty as suggested may be in order: coloured/saturated, greyed out and invisible. Esp. useful I envision the possibility to grey out blocks one does not work on while they stay visible. Being able to reuse a block independently of the layout it was created it, like in mechanical CAD would be very welcome here as well (did I miss something?) Thank you! Unless someone objects, I will run with block. Your idea of saving blocks independently is interesting - I was planning this, sort of. My idea was to make components and blocks convertable between each other, so that editing and saving components would be more intuitive. Another idea would be for PCB to recognize identical blocks - so that if you selected a group of components for a GPIO, say, it would recognize other GPIOs and offer to create more blocks and link them such that any re-arrangements of one would be reflected in the others. There a lot of things we could do if we could structure PCBs as groups of blocks. For now I am working out what such a structure would look like - as well as learning the PCB source. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
John Doty wrote: On Aug 8, 2010, at 4:51 PM, kai-martin knaak wrote: No it is not. Even simple things like footprint names have a pretty rigid syntax to adhere to. The workflow breaks in cryptic ways if they are not obeyed. This is a pure pcb limitation, not a gEDA limitation in general. Isn't a chain as strong as it's weakest link ? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Aug 14, 2010, at 3:29 PM, Armin Faltl wrote: John Doty wrote: On Aug 8, 2010, at 4:51 PM, kai-martin knaak wrote: No it is not. Even simple things like footprint names have a pretty rigid syntax to adhere to. The workflow breaks in cryptic ways if they are not obeyed. This is a pure pcb limitation, not a gEDA limitation in general. Isn't a chain as strong as it's weakest link ? It's not a chain. gEDA can export design data to a wide variety of tools, a major strength. 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: wishful UI
On Sat, 2010-08-14 at 23:29 +0200, Armin Faltl wrote: Isn't a chain as strong as it's weakest link ? There is no chain! gschem - ... - PCB is one workflow, amongst multiple. OK, maybe the one most people use currently. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Aug 14, 2010, at 2:18 PM, Paul Tan wrote: Is the case you mentioned above relates to the problem of slotting in PCB? No. It can happen whenever you have multiple symbols with the same refdes, regardless of the back end. Slotting is a particular case of this, but not the only one. It's a pure gnetlist problem, having nothing to do with pcb. Here are two minimal files that demonstrate the problem. Don't bother opening them in gschem: they contain no graphics. But they each contain a single component, represented by two embedded symbols with the same refdes. The only difference is the order of the two symbols. [Hikyuu:/tmp] jpd% gnetlist -g partslist1 foobar.sch Loading schematic [/private/tmp/foobar.sch] [Hikyuu:/tmp] jpd% cat output.net .START ..refdesdevice value footprint quantity thing unknown unknown unknown 1 .END [Hikyuu:/tmp] jpd% gnetlist -g partslist1 barfoo.sch Loading schematic [/private/tmp/barfoo.sch] [Hikyuu:/tmp] jpd% cat output.net .START ..refdesdevice value footprint quantity thing unknown unknown horse 1 .END Note that in the case of foobar.sch the footprint is unknown, while in the case of barfoo.sch, the footprint is horse. 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: wishful UI
Oops, forgot the attachments! barfoo.sch Description: Binary data foobar.sch Description: Binary data On Aug 14, 2010, at 3:45 PM, John Doty wrote: On Aug 14, 2010, at 2:18 PM, Paul Tan wrote: Is the case you mentioned above relates to the problem of slotting in PCB? No. It can happen whenever you have multiple symbols with the same refdes, regardless of the back end. Slotting is a particular case of this, but not the only one. It's a pure gnetlist problem, having nothing to do with pcb. Here are two minimal files that demonstrate the problem. Don't bother opening them in gschem: they contain no graphics. But they each contain a single component, represented by two embedded symbols with the same refdes. The only difference is the order of the two symbols. [Hikyuu:/tmp] jpd% gnetlist -g partslist1 foobar.sch Loading schematic [/private/tmp/foobar.sch] [Hikyuu:/tmp] jpd% cat output.net .START ..refdes device value footprint quantity thing unknown unknown unknown 1 .END [Hikyuu:/tmp] jpd% gnetlist -g partslist1 barfoo.sch Loading schematic [/private/tmp/barfoo.sch] [Hikyuu:/tmp] jpd% cat output.net .START ..refdes device value footprint quantity thing unknown unknown horse 1 .END Note that in the case of foobar.sch the footprint is unknown, while in the case of barfoo.sch, the footprint is horse. 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 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: wishful UI
On Aug 13, 2010, at 7:51 PM, kai-martin knaak wrote: The utter failure of early efforts to base AI on classification of objects should surely have taught that to us. The success of mathematics and biology to conquer their vast fields with hierarchical classification is telltale. Just as often it causes unnecessary controversy and balkanization of knowledge. Why do we inflict the silly OBAFGKM classification on astronomy students? The physical variable here is simply temperature: why don't we use it? Sloppy and stupid. Why was the recent removal of planet status from Pluto so controversial? Pluto's still there, with the same mass, composition, orbital elements, etc. as it had before. The classification has no meaning: changing it did nothing to change our understanding of Pluto's nature. 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: wishful UI
Hi Andrew Poelstra, On Aug 14, 2010; 10:34am, Andrew Poelstra wrote: On Sat, Aug 14, 2010 at 03:17:42AM -0400, Paul Tan wrote: ...In fact, I would like to see that gEDA can process ANY attributes attached to a net in similar fashion as it process ANY attributes attached to a symbol currently. I agree, but I'm not sure this would be useful until we find a way to split nets up into subnets - which is a much more complicated change. Otherwise, certain nets (such as power or ground nets), which often have vastly different characteristics in different sections, would be difficult to describe. If the split nets means BUS, such as addrBus[63:0] which can be split into addrBus[12:0], addrBus[15], etc; or even the notion of Compound BUS such as addrBus[63:0],ALE,CTRL, it can all be done with the backend scheme code. It really depends on the particular backend netlister implementation. gnet-verilog.scm is the Verilog netlister, which already handle merging and splitting busses, and hierarchy. An example schematic files with generated Verilog netlist can be found in the attached zip file at: http://archives.seul.org/geda/user/Jan-2009/msg00056.html As you can see from the example, the Verilog netlister (gnet-verilog.scm, Gnetlist backend for Verilog, and the helper shell script) takes advantage of lots of the powerful features presented by the gEDA Gnetlist frontend C/SCM functions, and it is able to do much more than other backends in the area of BUS and non-flatten Hierarchy. Hope the above helps. Best Regards, Paul Tan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Sat, 2010-08-14 at 18:57 -0400, Paul Tan wrote: Hi Andrew Poelstra, On Aug 14, 2010; 10:34am, Andrew Poelstra wrote: Otherwise, certain nets (such as power or ground nets), which often have vastly different characteristics in different sections, would be difficult to describe. If the split nets means BUS, such as addrBus[63:0] which can be split into addrBus[12:0], addrBus[15], etc; or even the notion of Compound BUS such as addrBus[63:0],ALE,CTRL, it can all be done with the backend scheme code. It really depends on the particular backend netlister implementation. I think he cares about touching net segments, same as I, see for example http://ssalewski.de/gEDA-Netclass.html.en the Power and Bypass segment. I think John Doty got it: Not so much. We already draw nets as segments, and attributes are actually attached to segments, not nets. Might need to modify the segment merging rules, but that's about it. And one could argue that the automatic segment merging is already a case of the tool inappropriately trying to outsmart the user. John Doty ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Aug 14, 2010, at 4:57 PM, Paul Tan wrote: If the split nets means BUS, such as addrBus[63:0] which can be split into addrBus[12:0], addrBus[15], etc; or even the notion of Compound BUS such as addrBus[63:0],ALE,CTRL, it can all be done with the backend scheme code. It really depends on the particular backend netlister implementation. No, the issue here is that different segments of the same (single conductor) net may have different properties. Power nets are especially troublesome here. The segment between an IC and its bypass capacitor needs to be short. The segment at the output of the power regulator needs high current capacity... Combining busses with net segment properties is probably beyond comprehension... 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: wishful UI
On Aug 14, 2010, at 4:57 PM, Paul Tan wrote: gnet-verilog.scm is the Verilog netlister, which already handle merging and splitting busses, and hierarchy. An example schematic files with generated Verilog netlist can be found in the attached zip file at: http://archives.seul.org/geda/user/Jan-2009/msg00056.html You and DJ need to talk. He has his own proposal (http://www.delorie.com/pcb/bus-pins.html). But I like your use of the power of the existing tools. 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: wishful UI
I just looked through Paul's examples, and it looks just like what I'm proposing except for the GUI details and where in the flow they're converted. Paul's examples even look like mine. I reused the existing BUS graphic to represent a bus, so that the NET graphic could remain a net, where Paul used the NET graphic for both nets and busses, and the BUS graphic still does nothing. If you reuse nets for busses, you still must use a bus graphic to connect the nets, because connected nets have to have the same name, which means you *must* name all the nets - the connection to the bus doesn't provide a default name. In my proposal, it's possible to have an unnamed bus as long as all the bus pins have the same number of nets. While I applaud his results (yay!) I think it would be better if a bus were a bus and a net were a net, so that DRC and gnetlist could be a little smarter about detecting errors and resolving conflicts. One example: a single-signal net with two name attributes is an error, but a multi-signal bus with two name attributes is intentional, as long as (in my examples) there's at least one N2-way intersection between them. Also, it means that you can have an unfettered syntax for net names, and a separate fettered syntax for nets that are in busses. I think it would also be useful to the user if single-signal nets and multi-signal busses were visually distinct. It would help them understand the schematic faster. Also, my proposal is to have the busses converted to multiple independent nets in the common parts of gnetlist, so that you don't have to tweak every single backend to add support for them. You can still support magic net names that the backends understand, if you want, but it seems to me a common concept like bus should be done in common code and be consistently applied across all the backends. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Hi ALL, On Aug 14, 2010; 04:33pm, DJ wrote: While I applaud his results (yay!) I think it would be better if a bus were a bus and a net were a net, so that DRC and gnetlist could be a little smarter about detecting errors and resolving conflicts. One example: a single-signal net with two name attributes is an error, but a multi-signal bus with two name attributes is intentional, as long as (in my examples) there's at least one N2-way intersection between them. Also, it means that you can have an unfettered syntax for net names, and a separate fettered syntax for nets that are in busses. I think it would also be useful to the user if single-signal nets and multi-signal busses were visually distinct. It would help them understand the schematic faster. Yes, the Gnetlist frontend has passed all the relevent info to the Gnetlist backend, what the backend needs to do with those info is up to the backend. A visual NET or BUS in Gschem can be assigned any attributes and be presented to the backends, it is up to the backends to decide what is legal or not, and warn user appropriately. I fully agree that a common backend can be used to share functions among similar backends. Nothing should prevent us from having mutiple common backends, each of which can be applied for different CAE/CAD disciplines, such as Verilog AMS, CASE, Mechanical, etc. where a visual BUS or NET could mean different things. As long as we try not to put contraint in Gschem and Gnetlist frontend C code (except plug-in), then we are safe. Best Regards, Paul Tan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Mon, 2010-08-09 at 10:59 -0600, John Doty wrote: Remember, pcb isn't the only layout path we support. Yes. But I think the addition of net classes will not really break something. Of course it will increase the code size, which is not really nice. And it may decrease the working speed of PCB program. I have written a short summary of this idea: 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
Re: gEDA-user: wishful UI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 13.08.2010 23:23, schrieb Stefan Salewski: On Mon, 2010-08-09 at 10:59 -0600, John Doty wrote: Remember, pcb isn't the only layout path we support. Yes. But I think the addition of net classes will not really break something. Of course it will increase the code size, which is not really nice. And it may decrease the working speed of PCB program. I have written a short summary of this idea: 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 Stefan, I looked at your suggestions about netclasses and I like them. What I would like to add (and this adds complexity, too), is the notion of differential pair (two wires should be same length, but the actual length basically is a don't care) or busses and control signals (industry standard SDRAM's etc where you have delay constraints of an entire bus vs. a single control signal). Furthermore I have a little objection towards No chance for unskilled people or autorouters, I agree with unskilled people, but at least a subset of the requirements can be translated to autorouter attributes, e.g. impedance easily translates to geometry for a defined layer stack (including base material, copper width ... ) while other attributes you suggest (short) would only be applicable to an autoplacer (or skilled people). I know that the target to add net classes AND to support them with auto[route|place|...] is very challenging, but nevertheless I think that it's worth a try/start a discusssion. - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxly8wACgkQn22l+QvEah1zVACfQP5orxgMpJCvjbT3bPuxJUjZ UFYAn3//FoLemiNGwqa75SmMw4HZYn3H =qvlC -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Sat, 2010-08-14 at 00:48 +0200, Dietmar Schmunkamp wrote: Stefan, I looked at your suggestions about netclasses and I like them. Indeed currently I am still looking for a good reason against that proposal. My best candidates: It is not too useful for small projects, and it is some work to implement. What I would like to add (and this adds complexity, too), is the notion of differential pair (two wires should be same length, but the actual length basically is a don't care) or busses and control signals (industry standard SDRAM's etc where you have delay constraints of an entire bus vs. a single control signal). Sure! I tried to mention that type short by writing: More or less related to this problem are attributes defining pairs of traces for differential signals: Maybe we can assign attributes like s...@1 and s...@2 indicating the pair, which should have a defined trace separation and equal length on PCB board. (A similar notation may be useful to indicate buses and allow pinswap in the schematic). I have to admit that I do not know much about differential pairs now, but it is very important... Furthermore I have a little objection towards No chance for unskilled people or autorouters, I agree with unskilled people, but at least a subset of the requirements can be translated to autorouter attributes, e.g. impedance easily translates to geometry for a defined layer stack (including base material, copper width ... ) while other attributes you suggest (short) would only be applicable to an autoplacer (or skilled people). I know that the target to add net classes AND to support them with auto[route|place|...] is very challenging, but nevertheless I think that it's worth a try/start a discusssion. I agree. I guess it would be no great deal for smart (but very busy) people like Peter C. and DJ, to implement the basic concept. For people not familiar with the internals of gschem and PCB like me it may take very long... 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: wishful UI
I guess it would be no great deal for smart (but very busy) people like Peter C. and DJ, to implement the basic concept. For people not familiar with the internals of gschem and PCB like me it may take very long... I'm quite willing to teach people PCB internals, if it means having more PCB developers. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
So why not just have properties, and sets of properties. A set of properties *is* a class, if you apply the same set of properties to many nets. Why not let the user pre-define such classes, to make their work easier? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Aug 13, 2010, at 5:39 PM, DJ Delorie wrote: So why not just have properties, and sets of properties. A set of properties *is* a class, if you apply the same set of properties to many nets. Why not let the user pre-define such classes, to make their work easier? I suggested that. I also suggested considering a set of properties to be a property, not a class. Or did you not understand flattened union. Maybe that was too obscure. 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: wishful UI
On Fri, 2010-08-13 at 19:28 -0400, DJ Delorie wrote: I guess it would be no great deal for smart (but very busy) people like Peter C. and DJ, to implement the basic concept. For people not familiar with the internals of gschem and PCB like me it may take very long... I'm quite willing to teach people PCB internals, if it means having more PCB developers. In my opinion writing some basic documentation about the internal work of PCB would be really a good idea. (I can remember that I looked at the PCB source code about two years ago: I was very positive surprised about the fact that the code was very compact, but I was not able to see the basic concepts...) more PCB developers. Unfortunately here in Germany most people concerned with electronics are very lazy, stupid and do not really care about FOSS. Some weeks ago I visited the kicad developer mailing list -- not much activity from german people also... Sorry. Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Ben Jackson wrote: I'll answer internals questions on geda-dev from anyone who wants to ask. Unfortunately, only approved developers are allowed to ask on geda-dev. ---)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: wishful UI
On Fri, 2010-08-13 at 17:48 -0600, John Doty wrote: On Aug 13, 2010, at 5:39 PM, DJ Delorie wrote: So why not just have properties, and sets of properties. A set of properties *is* a class, if you apply the same set of properties to many nets. Why not let the user pre-define such classes, to make their work easier? I suggested that. I also suggested considering a set of properties to be a property, not a class. Or did you not understand flattened union. Maybe that was too obscure. In my simple mind I consider a set of properties a class. But of course we can call it again a property. Or we can use no sets at all, just single properties. So instead of class/propertyset power one has to specify width25mil, clearance=12mil, color=blue, This is OK, but I think sets/classes make it easier for users and may save space in data files, and may make changes easier. (I know that we can currently assign attributes to nets in gschem, but my impression is that all touching line segments are one net, so we do not have subnets. Which we should have. And we should have color support, a way to see fast which nets segments are High Current... So some internal modification of gschem is necessary.) Indeed, all which we do is assign a special name/label to some subnets, like power_class or bypass_class. We do not have to define inside of gschem what this really means, like tracewidth=25mil and clearance=12mil. We can define this only in PCB. But I think it is more intuitive and practical if we can define such sets already in gschem and transfer that information to PCB (where we may change it if necessary). 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: wishful UI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 14.08.2010 01:13, schrieb Stefan Salewski: Indeed currently I am still looking for a good reason against that proposal. My best candidates: It is not too useful for small projects, and it is some work to implement. I don't think that this is a good argument against it as long as you don't force small projects to use it. I would see it as an extension to the current gschem - pcb flow. If you don't specify anything, you get the default net attributes as defined in PCB. I have to admit that I do not know much about differential pairs now, but it is very important... If you go high frequency it's getting important. Related to that are termination requirements of a given net, carefully select whether the termination needs to be close to the driver or close to the receiver. Typically this is a problem a tool can't handle. I guess it would be no great deal for smart (but very busy) people like Peter C. and DJ, to implement the basic concept. For people not familiar with the internals of gschem and PCB like me it may take very long... I second that, and I read the response from DJ: You don't know how hard it can be to teach a hardware guy software concepts :-) . Best regards Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxl47UACgkQn22l+QvEah0pJwCgjcFzsqJqGpl0/vcJ99+HThne brUAn35r4OvjEO8a1TdakafoPPw8l4/A =xfvV -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Aug 13, 2010, at 6:13 PM, Stefan Salewski wrote: In my simple mind I consider a set of properties a class. But of course we can call it again a property. It's the difference between ending at class, or being able to compose properties from properties without limit. 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: wishful UI
John Doty wrote: It's the difference between ending at class, or being able to compose properties from properties without limit. What do you think, the terms subclass and superclass refer to? ---)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: wishful UI
On Aug 13, 2010, at 6:54 PM, kai-martin knaak wrote: What do you think, the terms subclass and superclass refer to? Classes in OO aren't like classes in any other context. The concept of class is superfluous and misleading here, since only one concept is needed: property. Much simpler and clearer. 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: wishful UI
But property is such a nice, clean, simple building block. Why pollute it by adding more functionality and making it more complex? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
John Doty wrote: What do you think, the terms subclass and superclass refer to? Classes in OO aren't like classes in any other context. Biology, astronomy, algebra, set theory and database theory all use the concept of subclasses. ---)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: wishful UI
On Aug 13, 2010, at 7:04 PM, DJ Delorie wrote: But property is such a nice, clean, simple building block. Why pollute it by adding more functionality and making it more complex? Because then you can extend the concept without limit. It's like function in mathematics. You can construct functions from functions. But if such constructs were no longer functions, you'd get stuck. 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: wishful UI
On Aug 13, 2010, at 7:07 PM, kai-martin knaak wrote: John Doty wrote: What do you think, the terms subclass and superclass refer to? Classes in OO aren't like classes in any other context. Biology, astronomy, algebra, set theory and database theory all use the concept of subclasses. But I've worked in astronomy for decades without ever encountering the term superclass. Nor are classes in astronomy associated with methods. 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: wishful UI
But property is such a nice, clean, simple building block. Why pollute it by adding more functionality and making it more complex? Because then you can extend the concept without limit. It's like function in mathematics. You can construct functions from functions. But if such constructs were no longer functions, you'd get stuck. To abuse your analogy, our properties is like constants in mathematics. Classes would be functions. A property is like width = 5 or impedance = 50. A class is a collection of properties, which could include a collection of classes or whatnot also. Creating a single object that has to act as both a name-value pair *and* an arbitrary container is not a good idea. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
John Doty wrote: Biology, astronomy, algebra, set theory and database theory all use the concept of subclasses. But I've worked in astronomy for decades without ever encountering the term superclass. Nor are classes in astronomy associated with methods. read again: Did I write superclass? Your statement was, that classes do not contain classes anywhere but in OO. I gave five disjunct areas where classes can indeed contain classes. ---)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: wishful UI
On Aug 13, 2010, at 7:20 PM, DJ Delorie wrote: But property is such a nice, clean, simple building block. Why pollute it by adding more functionality and making it more complex? Because then you can extend the concept without limit. It's like function in mathematics. You can construct functions from functions. But if such constructs were no longer functions, you'd get stuck. To abuse your analogy, our properties is like constants in mathematics. Classes would be functions. Except in the proposal, classes cannot be composed of other classes. A property is like width = 5 or impedance = 50. A class is a collection of properties, which could include a collection of classes or whatnot also. OK, so now you have two entities where one suffices. How is this simpler? Class is a misleading term in this context. Nets (at best) have properties: classification is sloppy thinking. The utter failure of early efforts to base AI on classification of objects should surely have taught that to us. Creating a single object that has to act as both a name-value pair *and* an arbitrary container is not a good idea. You offer no reasoned support for this opinion. 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: wishful UI
On Aug 13, 2010, at 7:27 PM, kai-martin knaak wrote: read again: Did I write superclass? Your statement was, that classes do not contain classes anywhere but in OO. Read again: did I write classes do not contain classes anywhere but in OO? I wrote: Classes in OO aren't like classes in any other context. I gave five disjunct areas where classes can indeed contain classes. 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: wishful UI
On Aug 13, 2010, at 7:27 PM, kai-martin knaak wrote: read again: Did I write superclass? Yes. You wrote: What do you think, the terms subclass and superclass refer to? 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: wishful UI
A collection of constants is a structured constant and a class is not (only) a constant - well at least to me a structured property sounds less missleading than the name class. Why doesn't a class include net topologies, parts etc.? - That's what a true analogon of a class would be - actually a (sub-)schematic and it's display methods. Why is the container function arbitrary - could a structured property contain other things than simple or structured properties? DJ Delorie wrote: But property is such a nice, clean, simple building block. Why pollute it by adding more functionality and making it more complex? Because then you can extend the concept without limit. It's like function in mathematics. You can construct functions from functions. But if such constructs were no longer functions, you'd get stuck. To abuse your analogy, our properties is like constants in mathematics. Classes would be functions. A property is like width = 5 or impedance = 50. A class is a collection of properties, which could include a collection of classes or whatnot also. Creating a single object that has to act as both a name-value pair *and* an arbitrary container is not a good idea. ___ 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: wishful UI
On Fri, Aug 13, 2010 at 07:32:30PM -0600, John Doty wrote: On Aug 13, 2010, at 7:20 PM, DJ Delorie wrote: But property is such a nice, clean, simple building block. Why pollute it by adding more functionality and making it more complex? Because then you can extend the concept without limit. It's like function in mathematics. You can construct functions from functions. But if such constructs were no longer functions, you'd get stuck. To abuse your analogy, our properties is like constants in mathematics. Classes would be functions. Except in the proposal, classes cannot be composed of other classes. That's a trivial change: jumping from a class as a collection of properties to a class as collection of properties/classes is an easy mental jump, and conceptually makes sense. Jumping from a property as a name-value pair to a property as a name-value pair -and- collection of properties, is a big conceptual change. ... Creating a single object that has to act as both a name-value pair *and* an arbitrary container is not a good idea. You offer no reasoned support for this opinion. You're using one word - property - to express two entirely different concepts. Not only is this difficult to think about, it would be almost impossible to program without separating the two behind the scenes. The word class is usually a synonym for set, which is a concept that invites recursion. Property, however, is usually a synonym for attribute, something that isn't recursive. That's a very important distinction. You talk about object-classification failing as a method of AI - but what you mean is that it fails for /general/ AI. The specific AI we are talking about - autorouting and autoplacing - already works by classifying its objects (as vias, traces, components, nets, etc). Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
John Doty wrote: Class is a misleading term in this context. Nets (at best) have properties: classification is sloppy thinking. No, it is structured thinking. The utter failure of early efforts to base AI on classification of objects should surely have taught that to us. The success of mathematics and biology to conquer their vast fields with hierarchical classification is telltale. ---)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: wishful UI
John Doty wrote: I wrote: Classes in OO aren't like classes in any other context. Your key point is that class is not an appropriate term, because classes can't contain classes. If this is not, what you wanted to back-up with the OO statement. Why did bring OO into play? I gave five disjunct areas where classes can indeed contain classes. Can you give five disjunct areas where class cannot contain classes. ---)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: wishful UI
On Friday 13 August 2010, John Doty wrote: Developers who'd be attracted by a dumbed-down UI are exactly the folks I do not want to see working on gEDA. Just to clarify .. one example of a dumbed-down of the type JD is referring to is LaTeX. After all, LaTeX is just a dumbed- down interface to TeX, which itself is a dumbed-down alternative to troff. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
John, It seems still to be unimplemented in 1.6.1. Or do I simply not understand how it works? I don't use it: the file you saw was notes for documentation, not a bug report. The patch is from my private git repository and is not implemented in any downloadable gnetlist version. I know that you send notes describing the gnetlist commands and not a but report. The guile procedure isn't very useful. At least now it gives a reasonable return value. Bas -- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Aug 12, 2010, at 1:50 PM, Bas Gieltjes wrote: John, It seems still to be unimplemented in 1.6.1. Or do I simply not understand how it works? I don't use it: the file you saw was notes for documentation, not a bug report. The patch is from my private git repository and is not implemented in any downloadable gnetlist version. I know that you send notes describing the gnetlist commands and not a but report. The guile procedure isn't very useful. At least now it gives a reasonable return value. OK, core developers. How do we get this into 1.8? 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: wishful UI
OK, core developers. How do we get this into 1.8? Upload it to the sourceforge patch tracker to prevent that the patch gets lost. Bas -- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Fri, 06 Aug 2010 17:19:25 +0200 Stefan Salewski m...@ssalewski.de wrote: Maybe your grouping concept should occur in an early stage in gschem? One of the commercial PCB program I worked with had the feature of defining color for nets. Such as D? is red, A? is blue. It was very good to work with. So a regular expression engin would be fine. Levente -- Kovacs Levente leventel...@gmail.com Voice: +36705071002 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
John Doty j...@noqsi.com wrote: but pcb is apparently almost completely = dependent on gnetlist. No, it isn't. PCB defines its netlist input format; the schematic capture folks like gEDA then adapt to it, in gEDA's case by way of a gnetlist back-end. My OSDCU board through which the characters of this message pass on their way from my keyboard to your screen (well, from my mail server to the list) has been laid out in PCB, yet the netlist has been loaded from uEDA rather than gEDA. -MS, who otherwise generally sides with John Doty in this perennial argument. Ahh, if I only had an aerospace-like budget for my retrocomputing projects... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Sat, 2010-08-07 at 11:33 -0600, John Doty wrote: On Aug 6, 2010, at 6:42 PM, Andrew Poelstra wrote: On Sat, Aug 07, 2010 at 12:51:34AM +0200, Stefan Salewski wrote: The current status of my mind: Having net classes in gschem would make all much easier. Nothing new needs to be added to gschem: you can attach arbitrary attributes to net segments already. The place where you need a new capability is gnetlist: a gnetlist back end cannot currently query a net segment for its attributes. Indeed, for my proposal of net classes defined in gschem clean modular design should still work. For this case flow of information is from gschem to PCB. But we should teach gschem that a large net can consist of multiple connected subnets, for example a 3.3V net, with width traces from DC/DC-Converter to FPGA, and narrow traces to some other devices. Then we have to teach gnetlist to process this, and to teach PCB program to understand it. I think, if that concept is really useful, then we should try to implement it. Painting my house is fun, and it will look really nice. But I think I should repair the broken roof first, and improve thermal insulation. But I may need (support of) a craftsman. Best regards Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
