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: Vendor Resource File format documentation?
Thanks all. I was looking in the section under File Formats, which might also be a good place for such a link as well. Getting my first gEDA designed (and very trivial) board back from a fab shop tomorrow. I'm excited. I'll need the vendor drill mapping feature for the next one I am working on. --Neil. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnucap development snapshot 2009-09-28
There is a new development snapshot available ...
http://gnucap.org/devel/gnucap-2009-09-28.tar.gz
Optional plugin files:
http://gnucap.org/devel/gnucap-2009-09-28-models-bsim.tar.gz
http://gnucap.org/devel/gnucap-2009-09-28-models-jspice3-2.5.tar.gz
http://gnucap.org/devel/gnucap-2009-09-28-models-ngspice17.tar.gz
http://gnucap.org/devel/gnucap-2009-09-28-models-spice3f5.tar.gz
http://gnucap.org/devel/gnucap-2009-09-28-tools.tar.gz
This file contains the md5sum of the other files, so you can
check for a proper download:
http://gnucap.org/devel/gnucap-2009-09-28.md5sum
This release has changes to the elaboration phase of simulation.
There are three differences you will see ..
1. (Important!)
It fixes a bug that sometimes caused incorrect parameter values
in some cases. The bug would manifest with a certain combination
of subcircuits, models, and parameters.
In particular, something like this would give bad results:
.subckt foo (a k)
.model dio d (is={isat})
dfoo (a k) dio
.ends
...
x1 (1 2) foo isat=1u
x2 (2 3) foo isat=2u
...
.. would have the wrong value of isat.
Circuits that did not have this combination of models, subckt, and params
did not have this problem.
2. (cosmetic)
Taming of redundant warnings that would be printed in the
elaboration phase. Also, bad parameter warnings from
spice models using plugins are now printed, only once,
on readin, instead of multiple times on elaboration.
3. (new models)
The tarball models-bsim includes new models, including
the new BSIM4SOI, released Sep 22 and the new BSIM465,
release Sep 9.
===
As usual, to get started you need only the main package
gnucap-2009-xx-xx.tar.gz .
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnucap development snapshot 2009-09-28
Hi Al,
I have difficulty getting raw file as an output of simulation using
version that is shipped with Fedora 11. Does something changed since
that time? Or how I could get raw file out of simulation? (I'm going to
try big simulation that produces a lot of data)
Thanks,
Alex.
On 09/28/2009 05:04 PM, al davis wrote:
There is a new development snapshot available ...
http://gnucap.org/devel/gnucap-2009-09-28.tar.gz
Optional plugin files:
http://gnucap.org/devel/gnucap-2009-09-28-models-bsim.tar.gz
http://gnucap.org/devel/gnucap-2009-09-28-models-jspice3-2.5.tar.gz
http://gnucap.org/devel/gnucap-2009-09-28-models-ngspice17.tar.gz
http://gnucap.org/devel/gnucap-2009-09-28-models-spice3f5.tar.gz
http://gnucap.org/devel/gnucap-2009-09-28-tools.tar.gz
This file contains the md5sum of the other files, so you can
check for a proper download:
http://gnucap.org/devel/gnucap-2009-09-28.md5sum
This release has changes to the elaboration phase of simulation.
There are three differences you will see ..
1. (Important!)
It fixes a bug that sometimes caused incorrect parameter values
in some cases. The bug would manifest with a certain combination
of subcircuits, models, and parameters.
In particular, something like this would give bad results:
.subckt foo (a k)
.model dio d (is={isat})
dfoo (a k) dio
.ends
...
x1 (1 2) foo isat=1u
x2 (2 3) foo isat=2u
...
.. would have the wrong value of isat.
Circuits that did not have this combination of models, subckt, and params
did not have this problem.
2. (cosmetic)
Taming of redundant warnings that would be printed in the
elaboration phase. Also, bad parameter warnings from
spice models using plugins are now printed, only once,
on readin, instead of multiple times on elaboration.
3. (new models)
The tarball models-bsim includes new models, including
the new BSIM4SOI, released Sep 22 and the new BSIM465,
release Sep 9.
===
As usual, to get started you need only the main package
gnucap-2009-xx-xx.tar.gz .
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
--
Alexander Burinskiy
IC design
San Jose, CA, 95129
(408)230-3458 (cell)
___
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 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: gnucap development snapshot 2009-09-28
On Monday 28 September 2009, A.Burinskiy wrote: I have difficulty getting raw file as an output of simulation using version that is shipped with Fedora 11. Does something changed since that time? Or how I could get raw file out of simulation? (I'm going to try big simulation that produces a lot of data) Gnucap doesn't produce a Spice-style raw file. Instead, the output is in text files that are readable by almost everything else. At some time in the future, probably near future, the output will be pluggable too, and maybe somebody will make a plugin for a new efficient format like HDF5. The spice raw file is kind of a pain because there are several different incompatible versions of it. The version supplied with most distros is the stable version from about 2 years ago. There is a lot of new stuff in the development version. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
