Re: gEDA-user: Blind and buried vias?
On Tue, Sep 29, 2009 at 05:21:16PM +, Kai-Martin Knaak wrote: On Tue, 29 Sep 2009 17:01:23 +, Michael Sokolov wrote: I'm told that the OMAP3430's Package-on-Package configuration requires at least six layers to get all the signals out. Ugh. OK, that explains the need for a lot of layers. But how does the need for blind/buried vias arise? The balls of the BGA occupy most of the real estate available on top layer. If all vias penetrate the hole stack, this occupation maps to all other layers too. Actually most often the top layer looks like a two interlaced grids: - one grid of pads to solder the balls, - one grid of vias that go allow to route the signals to other layers That's as long as you don't use exotic techniques like via-in-pad. Basically the two outermost rings of the BGA can be routed on the top layer (there is room for one trace between pads). The next two rings can be routed to the second copper layer with simple vias. But then every additional ring needs one layer if you don't have blind vias (buried vias are not necessary for BGA exit patterns), since there is only room for one trace between vias. With blind vias it is possible to route 2 rings per layer, and this adds up quite fast for large BGA. Of course there are also sometimes stupid packaging decisions by manufacturers, one example is the Spartan3A in BGA256 package where they decided to put some power connections on the second ring. The worst case: on the first ring it is easy to put a via just outside without blocking the exit for the second ring, from the third ring on you need a via anyway. Spartan2/2E in the same package did not have this stupid pinout. Therefore realistically blind vias for BGA exit patterns are only necessary for 20x20 matrices and larger (the center is often taken by power supplies which are easier to route). Gabriel ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
I'm not sure why it's apparently irrelevant that the accepted predominant workflow is from gschem to pcb So what? What are all those other back ends for? Aren't they important? or that pcb is a member project of the geda project. If member projects and affiliated projects aren't considered part of gEDA then I'm curious as to what you define as gEDA and what topics you define as appropriate for this list. The issue isn't what topics are appropriate. The issue is keeping the interfaces clean and flexible. To do that, you have to remember what the interfaces are. What other backends? Are you referring to netlister and others? Most of them exist to modify schematic files to get it ready for a pcb. Otherwise I guess you could mean spice or other simulators. Either way, other backends are not particularly relevant to the discussion. The discussion was about why others consider pcb to be a part of gEDA. To keep the interfaces clean and flexible you have to remember what the interfaces are? I have no idea what you are trying to say. The OP said: What's the current and planned state of support for blind and/or buried vias in the gEDA system? That's like asking what's the state of support for driving Phillips head screws with a handsaw?. Another patronising analogy. I think last time you used a chainsaw. Pretty much everyone else on this list includes pcb in the geda name, those who don't know that others do. It's obvious from context what the question meant regardless of what your stance is on gEDA termi nology. I think that all things considered, your response was deliberately antagonistic. Currently, the gEDA project offers a mature suite of free softwareapplica tions for electronics design, including schematic capture, attribute management, bill of materials (BOM) generation, netlisting into over 20 netlist formats, analog and digital simulation, and printed circuit board (PCB) layout. I don't know who wrote that. gEDA and PCB are separate, independently developed projects. They have different source trees and conventions. They were not originally designed for each other. That they play well together is a testimony to the power of clean interface design. Let's not forget that, because if we do we will lose that power. It comes from the gEDA front page [1]http://www.gpleda.org/ That they play well is a testament to the fact that the netlister was written specifically for use with pcb and that the pcb project is affiliated with the gEDA project. [2]http://en.wikipedia.org/wiki/GEDA#History From the same wiki article: Loosely speaking, the term gEDA Suite refers to all [3]free software projects and applications that have voluntarily associated themselves with the gEDA Project via the geda-dev/geda-user mailing lists. These include: * gEDA/gaf - gschem and friends (the original project) * PCB - PCB layout program -- take note of this one * Gerbv - [4]Gerber file viewer * ngspice - a port of Berkeley [5]SPICE * GnuCap - A modern [6]electronic circuit simulation program * gspiceui - A [7]GUI front end for ngspice/GnuCap * gwave - An analog [8]waveform viewer * Icarus Verilog - A [9]Verilog simulator * GTKWave - A digital [10]waveform viewer * wcalc - [11]Transmission line and electromagnetic structure analysis Within the gEDA Suite, gEDA/gaf (gaf stands for gschem and friends) is the smaller subset of tools grouped together under the gEDA name and maintained directly by the gEDA project's founders. GEDA/gaf includes: * gschem - A [12]schematic capture program * gnetlist - A [13]netlist generation program * gsymcheck - A syntax checker for schematic symbols * gattrib - A [14]spreadsheet program for editing symbol attributes on a schematic. * libgeda - Libraries for gschem, gnetlist, and gsymcheck * gsch2pcb - Forward annotation from schematic to layout using pcb * Assorted utility programs Anyone who brings up a point about how geda/gaf/pcb could be more useful, more user friendly etc More useful and friendly to *what kind* of user? The kind that would prefer spending an hour mousing around to solve a problem once, or 15 minutes writing a script to solve it for all time? This is the line of argument I really have an issue with. I mean making it easier to use by someone who doesn't want to command line everything. For someone who likes to be able to use the program instead of spending all their time researching non-existent documentation. For someone who would like to have their program to have functions that are accessible, rather than have commands hidden away. You seem to assume that all users of gEDA are capable or want to write a script to solve a problem and that it takes an hour to find anything through a GUI interface. I
Re: gEDA-user: Blind and buried vias?
John Doty wrote: To the man with a hammer, everything is a nail. I can think of three gEDA problems that have resulted from developers being scenario- driven rather than thinking about the general case. Each one has cost me. I'll go into the details in private email if you like. Why in private? If you have evidence (however subjective) that supports your contention, why not air it in public? I for one would be interested to hear it. No matter how you slice it the largest user base of gschem is using it for driving pcb and so it makes a lot of sense to talk about new features in the context of pcb. Prediction is very hard, especially about the future. I don't get what your statement is trying to say. Because it's very hard we shouldn't try to do it? gaf could also benefit a lot from having the power needed to provide tighter simulation integration too. It is really nice to be able to click and plot a node or back annotate dc node voltages or device operating points on a schematic. It doesn't need to be done in a way that forces this work flow and again, no one who is actually writing code for the various tools is proposing that. But complexity *always* bites the user. KISS, especially at interfaces. You're missing the point, John. Integration is not a bad thing /when done correctly/, i.e. when integration is a) implemented using generic, documented interfaces; and b) only an aid to use and not required for it. When implemented in that fashion, 'integration' becomes simply 'cooperation' between related applications. Does it really frighten you so much that gEDA might have a clean, generic interface that allows an external program to specify a net name and have that net highlighted by gEDA? Perhaps it also frightens you that you can double-click a file in your file manager and it will automatically find the correct executable to load and display it. After all, what business does a file manager have knowing about the context of a file? I'm sure you religiously open a shell and execute the command to open each file by hand; in fact I'm sure you've written a script that accepts the filename and loads the correct executable automatically... You might not realise it, John, but you are a fan of integration. It is simply that your preferred method of integration is by scripting and using command-line switches. It is an example of integration done well, but it is not the /only/ way integration can be done well. Many people would prefer tighter cooperation at the GUI level between gEDA and its friends (which includes PCB, whether you like it or not). If that can be done in a clean, generic manner while retaining the power and flexibility of the individual components as a 'toolset' then I whole-heartedly support it. Chris -- Chris Smith cj...@zepler.net signature.asc Description: OpenPGP digital signature ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
On Mon, Sep 28, 2009 at 08:28:19PM +, Michael Sokolov wrote: How about we move this thread back to its original topic of blind and buried vias, not arguments regarding whether or not PCB is part of gEDA. I have some questions out of plain curiosity: completely aside from the question of how they ought to be handled by GNU PCB or any other PCB design tool, I wonder how these blind/buried vias work at a more basic level: 1. How are blind/buried vias made physically? I thought they glued the layers together first, then drilled the holes. By drilling layers before gluing them, although for the external layer, there are other processes like laser etched microvias. 2. How are they represented in the Gerber+drill file set that passes from the PCB design tool to the fab? By several sets of drill files. I was even bitten by what can be considered as a bug in OrCad 15 years ago: I had moved a through hole component to the other side of the board and I had two drill files for the two layer board (the first one was something like drl0-15.ncd and the other one drl15-0.ncd). I sent only one to manufacturing and the holed for the component on the back side was not drilled, I don't know why OrCad thought that a hole going from top to bottom was so different from one going from bottom to top to put them into two different files, but that is what happened. By the way, it was only a double-sided board (on some expensive high frequency laminate from Rogers, signals were up to ~5GHz). Anyway, I managed to screw-up the first batch. I'm asking out of plain curiosity - I hope that I never have to make a board with such vias as I've heard that they add a bit of sadomasochistic flavor to board bringup/debug efforts - but then I guess some boards are so cramped for space that you can't avoid them... Indeed. Although I have never needed them. Regards, Gabriel ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
Gabriel Paubert wrote: I'm asking out of plain curiosity - I hope that I never have to make a board with such vias as I've heard that they add a bit of sadomasochistic flavor to board bringup/debug efforts - but then I guess some boards are so cramped for space that you can't avoid them... Indeed. Although I have never needed them. It isn't always that the board itself is cramped, though that can definitely be a reason. The latest generation of BGA parts have so many pins on the package, packed so tightly together, that it isn't possible to get all the signals out of the chip in two layers and still have the traces large enough to meet specs. A sophisticated chip in an 0.5mm-pitch BGA package, like the OMAP3430, is an example. I have never seen the underside of one of these guys, but I bet it's pretty scary. I haven't had to lay one of these boards out myself yet, thankfully! :) I'm told that the OMAP3430's Package-on-Package configuration requires at least six layers to get all the signals out. Ugh. b.g. -- Bill Gatliff b...@billgatliff.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
Bill Gatliff b...@billgatliff.com wrote: The latest generation of BGA parts have so many pins on the package, packed so tightly together, that it isn't possible to get all the signals out of the chip in two layers and still have the traces large enough to meet specs. [...] I'm told that the OMAP3430's Package-on-Package configuration requires at least six layers to get all the signals out. Ugh. OK, that explains the need for a lot of layers. But how does the need for blind/buried vias arise? MS ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
On Tue, 29 Sep 2009 17:01:23 +, Michael Sokolov wrote: I'm told that the OMAP3430's Package-on-Package configuration requires at least six layers to get all the signals out. Ugh. OK, that explains the need for a lot of layers. But how does the need for blind/buried vias arise? The balls of the BGA occupy most of the real estate available on top layer. If all vias penetrate the hole stack, this occupation maps to all other layers too. ---(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: Blind and buried vias?
Kai-Martin Knaak wrote: On Tue, 29 Sep 2009 17:01:23 +, Michael Sokolov wrote: I'm told that the OMAP3430's Package-on-Package configuration requires at least six layers to get all the signals out. Ugh. OK, that explains the need for a lot of layers. But how does the need for blind/buried vias arise? The balls of the BGA occupy most of the real estate available on top layer. If all vias penetrate the hole stack, this occupation maps to all other layers too. ... and then you've covered all the area that would otherwise be available to run traces through. With a blind via, you can drop down to the next layer and get a little room to navigate. I haven't come across a situation that required a buried via, so I can't comment on that. Can't even guess, actually. b.g. -- Bill Gatliff b...@billgatliff.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
Bill Gatliff wrote: I haven't come across a situation that required a buried via, so I can't comment on that. Can't even guess, actually. That's just a via that has no top or bottom layer impact, only the ones between the layers it connects are consumed. One benefit is the pad stack can be smaller for internal layers making it a smaller transmission line anomaly. Other benefit is parts or traces on the surface don't stop routing underneath them so you can make the highest density PCB with buried vias. I think a side benefit of blind vias, (one side exposed on surface), is they can't wick much solder away from a BGA ball. Is that current practice anyone? Buried vias allow more than one via in the same vertical zone possibly -- not sure? John G ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
El mar, 29-09-2009 a las 09:38 -0500, Bill Gatliff escribió: [snip] The latest generation of BGA parts have so many pins on the package, packed so tightly together, that it isn't possible to get all the signals out of the chip in two layers and still have the traces large enough to meet specs. A sophisticated chip in an 0.5mm-pitch BGA package, like the OMAP3430, is an example. I have never seen the underside of one of these guys, but I bet it's pretty scary. I haven't had to lay one of these boards out myself yet, thankfully! :) I'm told that the OMAP3430's Package-on-Package configuration requires at least six layers to get all the signals out. Ugh. Don't know for 0.5mm and 0.4mm pitch packages. For CUS package (0.65mm pitch) it needs just 2 signal and 2 power layers without blind, stacked or buried vias. See: http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=sprab13 Regards, Carlos ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
I haven't come across a situation that required a buried via, so I can't comment on that. Can't even guess, actually. Boss says All those parts will find in that case, whats the problem with routing the board?. Problem is the Boss doesn't think traces take any physical space. Think pocket pager size case... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
Buried vias allow more than one via in the same vertical zone possibly -- not sure? Yes, with one exception -- If blind and buried vias overlap the same layers. For example, say you have an 8-layer board, and you have blind vias from layers 1-4, and 5-8, and buried vias from 3-6, you are not able to do that since the blind and buried involve the same layers. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
Bob Paddock wrote: For example, say you have an 8-layer board, and you have blind vias from layers 1-4, and 5-8, and buried vias from 3-6, you are not able to do that since the blind and buried involve the same layers. Wow, that means super dense is possible with a fab that is close tolerance... blind vias 1-3, buried 4-5, blind vias 6-8, then maybe add two more layers dedicated to gnd plane pwr plane for a total of ten layers for ultra dense high speed boards like cell phones. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
Wow, that means super dense is possible with a fab that is close tolerance... blind vias 1-3, buried 4-5, blind vias 6-8, then maybe add two more layers dedicated to gnd plane pwr plane for a total of ten layers for ultra dense high speed boards like cell phones. Worst I've heard of is 32 layers in some high speed network switches. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
On Sep 27, 2009, at 5:16 AM, John Doty wrote: Yes, pcb is not part of gEDA. It is a separate (older) development. History aside (and like it or not) PCB *is* currently a de facto member of the extended suite of gEDA programs. Ignoring this, or claiming otherwise, is frankly absurd. I don't know who wrote that. gEDA and PCB are separate, independently developed projects. They have different source trees and conventions. That the extended gEDA suite contains separately developed programs, with separate source trees, does not suddenly mean that one of the programs just doesn't count when somebody asks a question about it. That's a poor excuse. Also: The current developers listed on both projects at sourceforge have 50% overlap. That's not exactly independent. They were not originally designed for each other. Nor were peanut butter and jelly, nor mac and cheese. What's your point? That they play well together is a testimony to the power of clean interface design. Let's not forget that, because if we do we will lose that power. You are implying that continuing to acknowledge PCB as one of the extended suite of gEDA programs will lead to a loss in our valued flexibility. No one is saying that, and it's bad logic. I disagree. The abuse of terminology here is dangerous, because it encourages the delusion that gEDA and pcb would be better if they were more integrated. Integrated tools may be easier to use in some sense, but they don't have gEDA's productivity potential. I think that all that anyone has asked is that you acknowledge the integration that does already exist. From what I can tell, you're reasonably happy with that level of integration-- i.e., not much integration at all. As you've said, it is a separate program with a separate source tree. The discussions of gEDA's shortcomings here are disturbingly short- sighted. Maybe. But probably not as short sighted as your contention that acknowledging PCB is dangerous. -Windell ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
How about we move this thread back to its original topic of blind and buried vias, not arguments regarding whether or not PCB is part of gEDA. I have some questions out of plain curiosity: completely aside from the question of how they ought to be handled by GNU PCB or any other PCB design tool, I wonder how these blind/buried vias work at a more basic level: 1. How are blind/buried vias made physically? I thought they glued the layers together first, then drilled the holes. 2. How are they represented in the Gerber+drill file set that passes from the PCB design tool to the fab? I'm asking out of plain curiosity - I hope that I never have to make a board with such vias as I've heard that they add a bit of sadomasochistic flavor to board bringup/debug efforts - but then I guess some boards are so cramped for space that you can't avoid them... MS ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
Can we put an end to this thread? How about this. PCB is part of gEDA. I'm a developer for both. It is not a part of gaf (gschem and friends) but it is the most popular reason for using gaf. You can argue all you want about exactly how much a part of gEDA PCB is, but it is a part. Some times I work on gaf and PCB totally independently, some times I literally have had one emacs open with gschem source code and another with pcb source code. Integration is not a bad thing but integration when done in a way that precludes using the tools in a non-integrated matter is bad and as far as I know *none* of the actual developers of any of the various tools falling either directly under the gEDA umbrella or in its drip line are proposing integration in ways that preclude the toolkit nature. I also don't think any of the actual developers need constant reminding of this. I will say that there are some very powerful features that you simply can't achieve without integration but that integration can, should, and if we ever get that far, will be done in a more generic way. For example, at one point I had gschem schematic - pcb layout cross probing working. Click on a schematic instance and pcb selects the corresponding layout instance. Click on the layout instance and gschem selects the schematic instance. In fact that code still exists in pcb and gschem as far as I know. The only place where gschem knew about pcb was via a single scheme file which was loaded at run time. All of the other code which was written to make this possible was totally generic and is there to benefit whatever other tool flow is desired. No matter how you slice it the largest user base of gschem is using it for driving pcb and so it makes a lot of sense to talk about new features in the context of pcb. Did I need to use pcb when trying to extend the scheme capabilities of gschem? Of course not, but why not use the vehicle that is likely to see the most use. Besides which, this is a volunteer project and developers are going to use the portions that are useful to themselves as the vehicle. It doesn't mean we don't care about making sure the tools remain flexible. I certainly don't speak for all the gschem developers but I suspect that gschem would have died long ago if it weren't for the pcb user base. I would wager the break down is probably 70% of gschem schematics are to drive pcb, 10% for schematics for papers in school or journals, 15% for simulation, and 5% for everything else. Doesn't mean we don't care about the 5, doesn't mean we need continual reminders of it either. gaf could also benefit a lot from having the power needed to provide tighter simulation integration too. It is really nice to be able to click and plot a node or back annotate dc node voltages or device operating points on a schematic. It doesn't need to be done in a way that forces this work flow and again, no one who is actually writing code for the various tools is proposing that. What I have seen though is numerous arguments of this type turning off some very capable people and actually hurting the progress which is needed to build on the toolkit nature of these tools. Windell H. Oskay wrote: On Sep 27, 2009, at 5:16 AM, John Doty wrote: Yes, pcb is not part of gEDA. It is a separate (older) development. History aside (and like it or not) PCB *is* currently a de facto member of the extended suite of gEDA programs. Ignoring this, or claiming otherwise, is frankly absurd. I don't know who wrote that. gEDA and PCB are separate, independently developed projects. They have different source trees and conventions. That the extended gEDA suite contains separately developed programs, with separate source trees, does not suddenly mean that one of the programs just doesn't count when somebody asks a question about it. That's a poor excuse. Also: The current developers listed on both projects at sourceforge have 50% overlap. That's not exactly independent. They were not originally designed for each other. Nor were peanut butter and jelly, nor mac and cheese. What's your point? That they play well together is a testimony to the power of clean interface design. Let's not forget that, because if we do we will lose that power. You are implying that continuing to acknowledge PCB as one of the extended suite of gEDA programs will lead to a loss in our valued flexibility. No one is saying that, and it's bad logic. I disagree. The abuse of terminology here is dangerous, because it encourages the delusion that gEDA and pcb would be better if they were more integrated. Integrated tools may be easier to use in some sense, but they don't have gEDA's productivity potential. I think that all that anyone has asked is that you acknowledge the integration that does already exist. From what I can tell, you're reasonably happy with that
Re: gEDA-user: Blind and buried vias?
On Sep 28, 2009, at 3:08 PM, Dan McMahill wrote: Can we put an end to this thread? How about this. PCB is part of gEDA. I'm a developer for both. It is not a part of gaf (gschem and friends) but it is the most popular reason for using gaf. You can argue all you want about exactly how much a part of gEDA PCB is, but it is a part. Some times I work on gaf and PCB totally independently, some times I literally have had one emacs open with gschem source code and another with pcb source code. That frightens me. Integration is not a bad thing but integration when done in a way that precludes using the tools in a non-integrated matter is bad and as far as I know *none* of the actual developers of any of the various tools falling either directly under the gEDA umbrella or in its drip line are proposing integration in ways that preclude the toolkit nature. I also don't think any of the actual developers need constant reminding of this. To the man with a hammer, everything is a nail. I can think of three gEDA problems that have resulted from developers being scenario- driven rather than thinking about the general case. Each one has cost me. I'll go into the details in private email if you like. I will say that there are some very powerful features that you simply can't achieve without integration but that integration can, should, and if we ever get that far, will be done in a more generic way. For example, at one point I had gschem schematic - pcb layout cross probing working. Click on a schematic instance and pcb selects the corresponding layout instance. Click on the layout instance and gschem selects the schematic instance. In fact that code still exists in pcb and gschem as far as I know. The only place where gschem knew about pcb was via a single scheme file which was loaded at run time. All of the other code which was written to make this possible was totally generic and is there to benefit whatever other tool flow is desired. That's a good thing. if true. No matter how you slice it the largest user base of gschem is using it for driving pcb and so it makes a lot of sense to talk about new features in the context of pcb. Prediction is very hard, especially about the future. Did I need to use pcb when trying to extend the scheme capabilities of gschem? Of course not, but why not use the vehicle that is likely to see the most use. Besides which, this is a volunteer project and developers are going to use the portions that are useful to themselves as the vehicle. It doesn't mean we don't care about making sure the tools remain flexible. I certainly don't speak for all the gschem developers but I suspect that gschem would have died long ago if it weren't for the pcb user base. I would wager the break down is probably 70% of gschem schematics are to drive pcb, 10% for schematics for papers in school or journals, 15% for simulation, and 5% for everything else. Doesn't mean we don't care about the 5, doesn't mean we need continual reminders of it either. To the man with a hammer, everything is a nail. Yes, the developers do need reminders. gaf could also benefit a lot from having the power needed to provide tighter simulation integration too. It is really nice to be able to click and plot a node or back annotate dc node voltages or device operating points on a schematic. It doesn't need to be done in a way that forces this work flow and again, no one who is actually writing code for the various tools is proposing that. But complexity *always* bites the user. KISS, especially at interfaces. What I have seen though is numerous arguments of this type turning off some very capable people and actually hurting the progress which is needed to build on the toolkit nature of these tools. You think misrepresentations like gEDA can't do buried vias aren't harmful to gEDA? How about gEDA can't do ASIC design? Where did my working video digitization silicon come from, then? Both statements are equally true. gEDA can do neither buried vias nor ASIC design *by itself*, but its biggest strength is working with other 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: Blind and buried vias?
On Sep 26, 2009, at 3:07 PM, spuzzdawg wrote: Jon, You seem to consistently bring up this argument and I really think it's to the detriment of the list. I'm sure that by now, everyone on this list is quite aware that in you're opinion, PCB is not part of gEDA Yes, pcb is not part of gEDA. It is a separate (older) development. and not a single question should ever be asked about it. It would be nice if pcb had its own list, but I don't really mind that either. I'm not sure why it's apparently irrelevant that the accepted predominant workflow is from gschem to pcb So what? What are all those other back ends for? Aren't they important? or that pcb is a member project of the geda project. If member projects and affiliated projects aren't considered part of gEDA then I'm curious as to what you define as gEDA and what topics you define as appropriate for this list. The issue isn't what topics are appropriate. The issue is keeping the interfaces clean and flexible. To do that, you have to remember what the interfaces are. Someone on the list asked for help with blind and buried vias and you're response was pcb is not part of gEDA, I'm sure the OP found this information quite useful. The OP said: What's the current and planned state of support for blind and/or buried vias in the gEDA system? That's like asking what's the state of support for driving Phillips head screws with a handsaw?. It might sound a little harsh to say these things but I've noticed that you do it quite often. I have a thick skin. Anyone who brings up a point about how geda/gaf/pcb could be more useful, more user friendly etc More useful and friendly to *what kind* of user? The kind that would prefer spending an hour mousing around to solve a problem once, or 15 minutes writing a script to solve it for all time? quickly gets shot down by you with the same message, that gEDA is a toolkit, its flexibility is its power and problems with pcb aren't problems with geda. The fact that the handsaw can't drive a screw isn't a problem with the handsaw. Gluing a screwdriver to it would not be an improvement. But a handsaw and a screwdriver can work effectively together, just like gEDA and pcb. You use the line about gEDA being a toolkit to justify any of its shortcoming despite the fact that gEDA itself doesn't even consider itself this way. From the website: Currently, the gEDA project offers a mature suite of free software applications for electronics design, including schematic capture, attribute management, bill of materials (BOM) generation, netlisting into over 20 netlist formats, analog and digital simulation, and printed circuit board (PCB) layout. I don't know who wrote that. gEDA and PCB are separate, independently developed projects. They have different source trees and conventions. They were not originally designed for each other. That they play well together is a testimony to the power of clean interface design. Let's not forget that, because if we do we will lose that power. My point is that your one man war gEDA terminology doesn't help anyone. I disagree. The abuse of terminology here is dangerous, because it encourages the delusion that gEDA and pcb would be better if they were more integrated. Integrated tools may be easier to use in some sense, but they don't have gEDA's productivity potential. It serves only to distract meaningful discussions about gEDA's shortcomings and ways in which it could be improved as well as preventing posters from actually getting their questions answered. The discussions of gEDA's shortcomings here are disturbingly short- sighted. People want prefabricated heavy symbols in a library, not considering how massive the problem is. Too many variables. What we need is an easier way to customize symbols for a particular project. And perhaps better BOM post-processing support, so the user can say I want to use footprint xxx and vendor part number yyy for all 100nF X5R capacitors in this project. gattrib is a nice tool for quick touch up, but not productive when you have hundreds of footprints to change. The biggest hole in the gEDA documentation concerns the scripting that gschem/gnetlist can do using Scheme. There's no real API documentation here, so few are aware of the latent power here, and even fewer know how to harness it. We need to refactor gnetlist: the fact that the front end hides critical information from the scripted layers causes problems and prevents back end development in some directions. But the proposed solution to the most prominent of these problems is to make the front end more complex, and therefore make the needed refactoring harder. And many who find shortcomings in gEDA don't want a toolkit. But I'm extremely grateful that gEDA *isn't* a massive
Re: gEDA-user: Blind and buried vias?
I was going to comment on one point, but once you start writing... On Sun, Sep 27, 2009 at 06:16:42AM -0600, John Doty wrote: More useful and friendly to *what kind* of user? The kind that would prefer spending an hour mousing around to solve a problem once, or 15 minutes writing a script to solve it for all time? I suppose it depends on whether gEDA is only for those who use it for hours every day and thus find the cost of learning to and configuring things to work just the way they want them an obvious net win, or if it's desired for it to be useful to a larger audience. I'd be an example of that - although I have rather enjoyed the work I did about a year ago using gEDA, the fact is that I haven't had occasion to touch it since those boards got sent off. Sure, I have other projects in mind, but they've been stuck on the back burner, and seem likely to stay there for some time yet. Too many todos, too little time. People want prefabricated heavy symbols in a library, not considering how massive the problem is. Too many variables. What we need is an easier way to customize symbols for a particular project. And perhaps better BOM post-processing support, so the user can say I want to use footprint xxx and vendor part number yyy for all 100nF X5R capacitors in this project. gattrib is a nice tool for quick touch up, but not productive when you have hundreds of footprints to change. +1 about gattrib's shortcomings when there's more than a few items to tweak. I would like to add that some of that seems to be a really weird UI - things behave oddly compared to other GUI tools, IMO. OTOH, if there were a rich library of those heavy symbols you dislike, there'd be a lot less need for tweaking things (at least IME). But I have to agree that creating a huge library like that shouldn't be part of gEDA's mission, especially when manufacturer's so often make this stuff available... but in formats gEDA can't use. Yeah, it's hard. The database-driven idea sounds wonderful, but my impression is that it's a hella bike shed - lots of talk about it but little if anything of general interest gets done... or maybe everyone's waiting for one of the personal hacks to be just the color and glossiness they wish for. And it still sounds like a lot of setup work for casual or occasional use. The biggest hole in the gEDA documentation concerns the scripting that gschem/gnetlist can do using Scheme. There's no real API documentation here, so few are aware of the latent power here, and even fewer know how to harness it. +1e6 - not that Scheme is my favorite scripting language, but if there were a documented API it would be a viable option. And many who find shortcomings in gEDA don't want a toolkit. I have very mixed feelings about that, though the above has mostly come down on one side. And I'm not sure I'd call it a toolkit - some of the pieces just don't work together very well. The mess of issues that arise between gschem and PCB are perhaps the most discussed, but all the parts I've had occasion to use feel more like a random collection of tools than a proper toolset - one size Phillips screwdriver, a couple of flat blades but none really small or really large, a hacksaw blade but you have to make your own frame for it... The individual parts are good quality, but... But I'm extremely grateful that gEDA *isn't* a massive time-wasting integrated point and click thing designed for sales So am I, but I don't think that's the only kind of better-integrated thing that *could* be made, even if the commercial EDA toolmakers don't have a clue about it. :-) I hope it stays that way. I hope gEDA can do better, so that I can curse it less next time I reach that stage! -- [the combination of iPod and iTunes is like] buying a 21st-century device to live in the seventies. -- Wes Phillips ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
Guys: And many who find shortcomings in gEDA don't want a toolkit. I have very mixed feelings about that, though the above has mostly come down on one side. Is there a way to strike a balance like cURL did, which is to put a lot of the guts of the code into libraries that can be used as part of single-function, standalone tools or combined to produce an integrated runtime environment? b.g. -- Bill Gatliff b...@billgatliff.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
Martin Maney wrote: +1e6 - not that Scheme is my favorite scripting language, but if there were a documented API it would be a viable option. OT, but Gimp also uses Scheme. b.g. -- Bill Gatliff b...@billgatliff.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
On Fri, Sep 25, 2009 at 11:22 PM, Ineiev ine...@gmail.com wrote: On 9/25/09, Bill Gatliff b...@billgatliff.com wrote: With the onslaught of cool chips in BGA packages that's happening lately, I'm hoping this task gets the attention it deserves. :) Actually, have you tried patch 2011298 (experimental feature enhancement: blind and buried vias) in PCB SF tracker? I just tried to give it a go, lack of blind and buried vias support in PCB is what keeps me from dumping Protel/DXP and using PCB for everything. There was a single failure, in src/draw.c, with a fresh GIT checkout of PCB today (Sept/27/2009): ~/gEDA/gaf20090927/pcb $ patch -p1 ../pcb-20080202-stefan_BA-20080703.diff patching file doc/pcb.texi Hunk #1 succeeded at 282 (offset 2 lines). Hunk #2 succeeded at 296 (offset 2 lines). patching file src/action.c Hunk #1 succeeded at 1004 (offset 5 lines). Hunk #2 succeeded at 1018 (offset 5 lines). patching file src/draw.c Hunk #1 succeeded at 112 (offset -1 lines). Hunk #2 succeeded at 304 (offset -1 lines). Hunk #3 succeeded at 380 (offset -1 lines). Hunk #4 succeeded at 396 (offset -1 lines). Hunk #5 succeeded at 430 (offset -1 lines). Hunk #6 succeeded at 454 (offset -1 lines). Hunk #7 succeeded at 471 (offset -1 lines). Hunk #8 succeeded at 487 (offset -1 lines). Hunk #9 succeeded at 532 (offset -1 lines). Hunk #10 succeeded at 556 (offset -1 lines). Hunk #11 succeeded at 571 (offset -1 lines). Hunk #12 succeeded at 584 with fuzz 2 (offset -1 lines). Hunk #13 FAILED at 608. Hunk #14 succeeded at 758 (offset -5 lines). Hunk #15 succeeded at 773 (offset -5 lines). Hunk #16 succeeded at 799 (offset -5 lines). Hunk #17 succeeded at 809 (offset -5 lines). 1 out of 17 hunks FAILED -- saving rejects to file src/draw.c.rej patching file src/find.c Hunk #1 succeeded at 737 (offset 88 lines). Hunk #2 succeeded at 765 (offset 88 lines). Hunk #3 succeeded at 835 (offset 88 lines). Hunk #4 succeeded at 1000 (offset 88 lines). Hunk #5 succeeded at 1077 (offset 88 lines). Hunk #6 succeeded at 1099 (offset 88 lines). Hunk #7 succeeded at 1124 (offset 88 lines). Hunk #8 succeeded at 1147 (offset 88 lines). Hunk #9 succeeded at 1216 (offset 88 lines). Hunk #10 succeeded at 1235 (offset 88 lines). patching file src/global.h Hunk #1 succeeded at 83 (offset 5 lines). patching file src/hid/common/flags.c patching file src/hid/gerber/gerber.c Hunk #1 succeeded at 493 (offset 21 lines). Hunk #2 succeeded at 531 (offset 22 lines). Hunk #3 succeeded at 539 (offset 22 lines). patching file src/hid/hidint.h patching file src/hid/nelma/nelma.c Hunk #1 succeeded at 710 (offset 1 line). patching file src/hid/png/png.c Hunk #1 succeeded at 882 (offset 359 lines). patching file src/hid/ps/eps.c Hunk #1 succeeded at 324 (offset 1 line). patching file src/hid/ps/ps.c Hunk #1 succeeded at 528 (offset 15 lines). patching file src/hid.h Hunk #1 succeeded at 214 (offset 20 lines). patching file src/macro.h patching file src/polygon.c Hunk #1 succeeded at 683 (offset 159 lines). patching file src/strflags.c Hunk #1 succeeded at 414 (offset 1 line). Hunk #2 succeeded at 522 (offset 1 line). Hunk #3 succeeded at 560 (offset 1 line). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
On Sun, Sep 27, 2009 at 01:45:46PM -0500, Bill Gatliff wrote: Martin Maney wrote: +1e6 - not that Scheme is my favorite scripting language, but if there were a documented API it would be a viable option. OT, but Gimp also uses Scheme. Another app I've never yet attacked from the loadable script direction, although in the case of the Gimp I've heard that other languages can be used, Python in particular. :-) And IIRC GnuCash is full of Scheme (or is it another of the free lisps they used?), and frankly that's an app which I use only because the alternatives have been so bad (by now, there's a lot of momentum and all that data that would need to be migrated adding inertia). Slow and not very flexible, though perhaps the latter is because I don't think I should need to learn to write an extension to do trivial things. Or maybe my notion that one short line of SQL is a fair analog for trivial is a bit off. :-) -- One lesson I've learned from my years as Linux's hood ornament is that there's something worse: some folks can't be content to just take things too seriously on their own. They're not happy unless they can convince others to go along with their obsession. -- Linus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
On Sun, 2009-09-27 at 06:16 -0600, John Doty wrote: People want prefabricated heavy symbols in a library, not considering how massive the problem is. That reminds me to a posting with no single reply: http://archives.seul.org/geda/user/Jan-2009/msg00561.html ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
On Sun, 27 Sep 2009 23:19:16 +0200, Stefan Salewski wrote: That reminds me to a posting with no single reply: http://archives.seul.org/geda/user/Jan-2009/msg00561.html (provide a project based set of rules for attribute defaults) IMHO, this is an excellent idea. ---(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: Blind and buried vias?
On Sep 27, 2009, at 11:40 AM, Bill Gatliff wrote: Guys: And many who find shortcomings in gEDA don't want a toolkit. I have very mixed feelings about that, though the above has mostly come down on one side. Is there a way to strike a balance like cURL did, which is to put a lot of the guts of the code into libraries that can be used as part of single-function, standalone tools or combined to produce an integrated runtime environment? gEDA and pcb are each designed to do this. But the approaches the two projects chose are very different and incompatible. So integrating them is likely to be very difficult. A better solution for those who want an integrated tool might be a PCB plugin that can work directly with gEDA .sch and .sym files in the pcb world. 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: Blind and buried vias?
On 9/27/09, Bob Paddock bob.padd...@gmail.com wrote: On Fri, Sep 25, 2009 at 11:22 PM, Ineiev ine...@gmail.com wrote: Actually, have you tried patch 2011298 (experimental feature enhancement: blind and buried vias) in PCB SF tracker? I just tried to give it a go, lack of blind and buried vias support in PCB is what keeps me from dumping Protel/DXP and using PCB for everything. Thanks; There was a single failure, in src/draw.c, with a fresh GIT checkout of PCB today (Sept/27/2009): I just rebased the patch against current GIT master head here: http://repo.or.cz/w/geda-pcb/dti.git?a=shortlog;h=refs/heads/stefan_ba-blind.and.buried Not sure if it would have been better to communicate with the original author, though; and probably it would be useful to review the testpcb that Bert Timmerman mentioned in order to make it more reliable. Regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
Jon, You seem to consistently bring up this argument and I really think it's to the detriment of the list. I'm sure that by now, everyone on this list is quite aware that in you're opinion, PCB is not part of gEDA and not a single question should ever be asked about it. I'm not sure why it's apparently irrelevant that the accepted predominant workflow is from gschem to pcb or that pcb is a member project of the geda project. If member projects and affiliated projects aren't considered part of gEDA then I'm curious as to what you define as gEDA and what topics you define as appropriate for this list. Someone on the list asked for help with blind and buried vias and you're response was pcb is not part of gEDA, I'm sure the OP found this information quite useful. It might sound a little harsh to say these things but I've noticed that you do it quite often. Anyone who brings up a point about how geda/gaf/pcb could be more useful, more user friendly etc quickly gets shot down by you with the same message, that gEDA is a toolkit, its flexibility is its power and problems with pcb aren't problems with geda. You use the line about gEDA being a toolkit to justify any of its shortcoming despite the fact that gEDA itself doesn't even consider itself this way. From the website: Currently, the gEDA project offers a mature suite of free software applications for electronics design, including schematic capture, attribute management, bill of materials (BOM) generation, netlisting into over 20 netlist formats, analog and digital simulation, and printed circuit board (PCB) layout. My point is that your one man war gEDA terminology doesn't help anyone. It serves only to distract meaningful discussions about gEDA's shortcomings and ways in which it could be improved as well as preventing posters from actually getting their questions answered. On Fri, 2009-09-25 at 11:14 -0600, John Doty wrote: On Sep 25, 2009, at 10:54 AM, Kai-Martin Knaak wrote: On Fri, 25 Sep 2009 10:27:02 -0600, John Doty wrote: but some (perhaps many) of us use gschem/gnetlist with other back ends. Not so many. See the result of last years poll. 3 out of 32 confessed to do the layout with PADS. The rest uses pcb. Hmm, you apparently didn't include *my* response. Did you miss anything else? 32 responses is hardly a large sample, and I'd expect it to be biased toward pcb: this list is predominantly about pcb despite its name... ---(kaimartin)--- -- Kai-Martin Knaak ffentlicher PGP-Schlssel: [1]http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list [2]geda-u...@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user John Doty Noqsi Aerospace, Ltd. [4]http://www.noqsi.com/ [5]...@noqsi.com References 1. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 2. mailto:geda-user@moria.seul.org 3. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 4. http://www.noqsi.com/ 5. mailto:j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Blind and buried vias?
Guys: What's the current and planned state of support for blind and/or buried vias in the gEDA system? I got a few questions on that at the Embedded Systems Conference earlier this week... b.g. -- Bill Gatliff b...@billgatliff.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
On Sep 25, 2009, at 10:09 AM, Bill Gatliff wrote: Guys: What's the current and planned state of support for blind and/or buried vias in the gEDA system? I got a few questions on that at the Embedded Systems Conference earlier this week... Well, of course that's a problem for the layout tool, so choose a layout tool that supports them. pcb is only one of the tools gEDA can export netlists to. Remember, pcb is a separate tool, not part of gEDA. Probably very few pcb users capture schematics with anything but gschem, but some (perhaps many) of us use gschem/gnetlist with other back ends. 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: Blind and buried vias?
Status: Not yet, want it, blue-sky plans available for rent. It's part of the Upgrade of layer and design objects item in the Linux Fund work, number 4 of 5 tasks. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
John Doty wrote: On Sep 25, 2009, at 10:09 AM, Bill Gatliff wrote: Guys: What's the current and planned state of support for blind and/or buried vias in the gEDA system? I got a few questions on that at the Embedded Systems Conference earlier this week... Well, of course that's a problem for the layout tool, so choose a layout tool that supports them. pcb is only one of the tools gEDA can export netlists to. Remember, pcb is a separate tool, not part of gEDA. Probably very few pcb users capture schematics with anything but gschem, but some (perhaps many) of us use gschem/gnetlist with other back ends. Can you suggest a GPL/BSD/equivalent layout tool that can do blind/buried vias? b.g. -- Bill Gatliff b...@billgatliff.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
DJ Delorie wrote: Status: Not yet, want it, blue-sky plans available for rent. It's part of the Upgrade of layer and design objects item in the Linux Fund work, number 4 of 5 tasks. With the onslaught of cool chips in BGA packages that's happening lately, I'm hoping this task gets the attention it deserves. :) b.g. -- Bill Gatliff b...@billgatliff.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
On Fri, 25 Sep 2009 10:27:02 -0600, John Doty wrote: but some (perhaps many) of us use gschem/gnetlist with other back ends. Not so many. See the result of last years poll. 3 out of 32 confessed to do the layout with PADS. The rest uses pcb. ---(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: Blind and buried vias?
John - On Fri, Sep 25, 2009 at 10:27:02AM -0600, John Doty wrote: Remember, pcb is a separate tool, not part of gEDA. But it does fall under the gaf umbrella, and this is the proper mailing lists for things pcb-related. Probably very few pcb users capture schematics with anything but gschem, Hey! Some of us (cough) are still xcircuit partisans! - Larry ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Blind and buried vias?
On Sep 25, 2009, at 10:37 AM, Bill Gatliff wrote: John Doty wrote: On Sep 25, 2009, at 10:09 AM, Bill Gatliff wrote: Guys: What's the current and planned state of support for blind and/or buried vias in the gEDA system? I got a few questions on that at the Embedded Systems Conference earlier this week... Well, of course that's a problem for the layout tool, so choose a layout tool that supports them. pcb is only one of the tools gEDA can export netlists to. Remember, pcb is a separate tool, not part of gEDA. Probably very few pcb users capture schematics with anything but gschem, but some (perhaps many) of us use gschem/gnetlist with other back ends. Can you suggest a GPL/BSD/equivalent layout tool that can do blind/buried vias? I have no knowledge in this area. My point was merely that this is not a gEDA limitation: gEDA doesn't even have a via concept. I think it very dangerous to misidentify pcb as part of gEDA, since gEDA's greatest strength is its ability to play nicely with many other tools and toolkits. 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: Blind and buried vias?
On Sep 25, 2009, at 10:54 AM, Kai-Martin Knaak wrote: On Fri, 25 Sep 2009 10:27:02 -0600, John Doty wrote: but some (perhaps many) of us use gschem/gnetlist with other back ends. Not so many. See the result of last years poll. 3 out of 32 confessed to do the layout with PADS. The rest uses pcb. Hmm, you apparently didn't include *my* response. Did you miss anything else? 32 responses is hardly a large sample, and I'd expect it to be biased toward pcb: this list is predominantly about pcb despite its name... ---(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 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: Blind and buried vias?
On Sep 25, 2009, at 10:57 AM, Larry Doolittle wrote: John - On Fri, Sep 25, 2009 at 10:27:02AM -0600, John Doty wrote: Remember, pcb is a separate tool, not part of gEDA. But it does fall under the gaf umbrella, and this is the proper mailing lists for things pcb-related. Probably very few pcb users capture schematics with anything but gschem, Hey! Some of us (cough) are still xcircuit partisans! Cool! Another flow! Aren't clean, flexible interfaces great? 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
