Re: gEDA-dev: Re: GEDA development ....
On May 8, 2007, at 6:53 PM, al davis wrote: Now you worry me again. Sounds like EDIF. There is good and bad in any design. There is good even in the failures. Most (all??) successes happen because of the failures. Most disasters result from repeating failures. To see places where an intermediate format is used, look at most compilers, and at the pbmplus graphics translation collection. I am sure there are others. It doesn't matter to most users what the intermediate format is. You never see it. If that's true, it's good. If it isn't true, it's a disaster. Only the developers see it. I recommended the use of a format that others are using so we can be compatible with it. Is this bad? For the user, it doubles the number of interfaces and black boxes where if something goes wrong, it is difficult to understand. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [EMAIL PROTECTED] ___ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
Re: gEDA-dev: Re: GEDA development ....
On Tuesday 08 May 2007, John Doty wrote: Most disasters result from repeating failures. Of course, if you do it exactly the same every time. For success, you study why it failed and make appropriate changes. Throwing out the whole thing is a big waste. Actually, too see what is wrong with EDIF, just take a quick look at a file and see what a mess it is. ___ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
Re: gEDA-dev: Re: GEDA development ....
On May 9, 2007, at 7:27 AM, al davis wrote: On Tuesday 08 May 2007, John Doty wrote: Most disasters result from repeating failures. Of course, if you do it exactly the same every time. For success, you study why it failed and make appropriate changes. Throwing out the whole thing is a big waste. Actually, too see what is wrong with EDIF, just take a quick look at a file and see what a mess it is. Did that at the time. Never again. ;-) John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [EMAIL PROTECTED] ___ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
Re: gEDA-dev: Re: GEDA development ....
One of the ideas I have been playing with A spin off of my work on back annotation. I am finishing off a temporary program backnet which loads and runs a scheme script at the start to read in a netlist and another to read in an eco file it builds a page with component and pins from the netlist then it runs one of the standard scheme netlist scripts to write an updated netlist. As I said I consider this to be a temporary implementation until I finish modifying gschem to get the schematics to hold the eco changes. The point being though... that having a scripting fron end for importing files would be a first step in importing other file formats. Steve Meier Stephen Brickles using shaun wrote: snip maybe the ability to use the file formats of some of the comercial eda tools? I haven't heard anyone mentioning OpenAccess on this forum yet... How about an OpenAccess module for gEDA ? The ability to open Cadence schematics from GSchem - yet still use the Cadence/OpenAccess database. Imagine begin able to view a schematic in Cadence Composer that you just modified in GSchem !! That would get people using parts of gEDA if nothing else since the Cadence schematic editor is not the world's best... Of course you'd have to reconcile the licensing agreements of Si2 (keepers of the OpenAccess code) versus the GPL... Stephen Steve Meier wrote: I think, which often causes head ackes geda is not yet competetive to the comercial eda products. companies need tools to get todays job done. would it make sense for large electronics companies to invest into geda again at the risk of hurting my head... i think so. If nothing else it puts preasure on the commercial eda tool providors. what would it take to make the sale to large electronics companies I suspect having some minimum capability and from my perspective geda ain't there yet. What are these minimum requirements?... good question?... maybe where some 30% of a companies designes can readily be implemented with geda? maybe the ability to use the file formats of some of the comercial eda tools? this is just a guess. Steve Meier Stuart Brorson wrote: I was thinking about this one last night On Fri, 4 May 2007, David Cary wrote: Dear gEDA developers, Recently I overheard some people talking about gEDA. One of them brought up all kinds of reasons that gEDA was not usable. [. snip ] Maintainability is at the mercy of the gEDA developers. I'm not going to argue that a business should place development of its critical design tools into the hands of a bunch of hobbiests. I can understand the primal fear which this can trigger in the minds of middle managers (rightly or wrongly). However, it does raise an interesting issue: If you see free software merely as zero cost software -- gettin' sumptin' fer nuttin' -- then, sure, you're at the mercy of the gEDA developers, and must beg and whine for feature requests. However, the other side of the free software coin is that the source is available to you to modify and use as you see fit. Therefore, a design business can certainly *hire* a smart high school or college kid to work on maintaining and extending gEDA. For the $7000 you'd pay for a seat of Protel/Altium/whatever it is these days, you can get much more than a summer job's worth of code customized to meet your *exact* needs. Folks working in electronic design must know somebody with high school kids looking for summer work, right? I don't know why commerical enterprises think they can't become active participants in development of gEDA. Maybe they are so used to being supine receivers of whatever the EDA vendors dish out that they have forgotten how to take control of their own tools? But isn't there some competitive advantage to having control over your own design flow? Stuart ___ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev ___ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev ___ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev ___ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
Re: gEDA-dev: Re: GEDA development ....
On Monday 07 May 2007, Stephen Brickles using shaun wrote: snip maybe the ability to use the file formats of some of the comercial eda tools? I haven't heard anyone mentioning OpenAccess on this forum yet... How about an OpenAccess module for gEDA ? The ability to open Cadence schematics from GSchem - yet still use the Cadence/OpenAccess database. Imagine begin able to view a schematic in Cadence Composer that you just modified in GSchem !! That would get people using parts of gEDA if nothing else since the Cadence schematic editor is not the world's best... It has been mentioned. One big problem: Of course you'd have to reconcile the licensing agreements of Si2 (keepers of the OpenAccess code) versus the GPL... Their license is deliberately incompatible with GPL. Very incompatible. The bit about compatibility of file formats is one reason why I brought up VHDL, the structural subset, a while back. Verilog would work too, but require a hack to work around the missing entity/architecture feature. Unfortunately, most people here don't understand the problem, don't follow leading developments in EDA, and don't see where they are looking to us to lead. If the use of OpenAccess is through a stand alone translator, licensing becomes a non-issue. Just release the translator under a license they approve and don't worry about anything else. There are technical issues too, but if somebody wants to write the translator I won't complain. ___ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
Re: gEDA-dev: Re: GEDA development ....
On May 8, 2007, at 9:31 AM, al davis wrote: The bit about compatibility of file formats is one reason why I brought up VHDL, the structural subset, a while back. Verilog would work too, but require a hack to work around the missing entity/architecture feature. That's what's making me nervous. We have been extremely well served in gEDA by custom open file formats designed for specific parts of the flow. For capturing the abstraction beneath the drawing, gnetlist is a work of genius. Even this old grey haired physicist's rusty, barnacle encrusted Lisp suffices to coax out netlists in any format I've been able to get documentation (or even just an example) for. I have that book you have on order. Maybe next code sprint I'll try to cons up a Verlog-AMS gnetlist back end. I was burned by EDIF back in the 90's. Huge waste of time and money. The *format* was portable, but to use it in practice the tools had to be using identical underlying data models. It worked much better just to translate one tool's netlist into the other's format with an AWK script. So pardon my skepticism. Unfortunately, most people here don't understand the problem, don't follow leading developments in EDA, and don't see where they are looking to us to lead. If where you're leading is a better simulator, I'm interested. If where you're leading is breaking gEDA's flexible modularity to better support your vision of a better simulator, I'm opposed. Remember, your problems are different from my problems. If the use of OpenAccess is through a stand alone translator, licensing becomes a non-issue. Just release the translator under a license they approve and don't worry about anything else. There are technical issues too, but if somebody wants to write the translator I won't complain. Translators are good. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [EMAIL PROTECTED] ___ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
Re: gEDA-dev: Re: GEDA development ....
On Tuesday 08 May 2007, John Doty wrote: On May 8, 2007, at 9:31 AM, al davis wrote: The bit about compatibility of file formats is one reason why I brought up VHDL, the structural subset, a while back. Verilog would work too, but require a hack to work around the missing entity/architecture feature. That's what's making me nervous. We have been extremely well served in gEDA by custom open file formats designed for specific parts of the flow. For capturing the abstraction beneath the drawing, gnetlist is a work of genius. Even this old grey haired physicist's rusty, barnacle encrusted Lisp suffices to coax out netlists in any format I've been able to get documentation (or even just an example) for. I have that book you have on order. Maybe next code sprint I'll try to cons up a Verlog-AMS gnetlist back end. It's almost done. Just add attribute passing to the existing Verilog back end. I was burned by EDIF back in the 90's. Huge waste of time and money. I remember EDIF too. It worked much better just to translate one tool's netlist into the other's format with an AWK script. So pardon my skepticism. With some cleverness, we can get back to having translations simple enough that an AWK script will do it all. Unfortunately, most people here don't understand the problem, don't follow leading developments in EDA, and don't see where they are looking to us to lead. If where you're leading is a better simulator, I'm interested. If where you're leading is breaking gEDA's flexible modularity to better support your vision of a better simulator, I'm opposed. Remember, your problems are different from my problems. The problem with Spice is that it is not flexible enough. It might be flexible enough for you, but lots of people bump against its problems on a regular basis. That's why there are others like Spectre, Touchstone, Hyperlynx, Nano-sim, Rice, and many others. What I want, and the way gnucap is going, is to be more modular, and so more flexible. Gnucap now accepts Spice C models as plug-ins. The current development effort is on language plugins, so it can easily cope with the many formats that come and go. The Spice compatibility won't be just Spice, but several plugins for exact compatibility with several variants of Spice. Since the language is not built into the simulator, you can have language plugins for any language you want. I expect soon to be able to read and write gschem format and pcb format directly. With not much more effort, maybe Touchstone, Spectre, and Qucs formats too, but only after the framework is in place. You will be able to have all this without recompiling, without waiting for another release of the simulator. gnetlist does one kind of translation. .. From gschem out. I was addressing all the others. The concept I proposed is to translate in two steps. In to a common interchange format, then out. That way we need only 2*n translators, instead of n^2. I want to make it easy to support many formats, without adding the baggage of carrying them all. The only thing stopping us from having full board simulations, with parasitics, is the lack of the appropriate translator, between two of our own formats. ___ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
Re: gEDA-dev: Re: GEDA development ....
On May 8, 2007, at 1:24 PM, al davis wrote: The problem with Spice is that it is not flexible enough. It might be flexible enough for you, but lots of people bump against its problems on a regular basis. That's why there are others like Spectre, Touchstone, Hyperlynx, Nano-sim, Rice, and many others. Well, then quit throwing rocks at SPICE and do something better. SPICE may be a klunker, but it's better than vapor. Yes, I know it has problems, I've been working around them for years. But you can't beat something with nothing. I google for Verilog-AMS and 99% of what comes up is hype, not substance. gnetlist does one kind of translation. .. From gschem out. I was addressing all the others. The concept I proposed is to translate in two steps. In to a common interchange format, then out. That way we need only 2*n translators, instead of n^2. I want to make it easy to support many formats, without adding the baggage of carrying them all. Now you worry me again. Sounds like EDIF. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [EMAIL PROTECTED] ___ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
Re: gEDA-dev: Re: GEDA development ....
On Tuesday 08 May 2007, John Doty wrote: Well, then quit throwing rocks at SPICE You are the only one throwing rocks. and do something better. I'm working on it. I even told you what I am doing now, and why. SPICE may be a klunker, but it's better than vapor. Gnucap is not vapor. I never said Spice is a klunker. Gnucap is better than Spice in some ways, not as good in some others. Yes, I know it has problems, I've been working around them for years. To move on, one must study the past, and acknowledge what is good and bad. I never said Spice was bad. It worst, I acknowledged that it is old technology and it is time to move on. Most of the creators of Spice will say the same. I will say the same about my own work of 20 years ago. The idea of free/open-source isn't just that you can read the source. Discussions are open too. Some of it is actually useful. Now you worry me again. Sounds like EDIF. There is good and bad in any design. There is good even in the failures. Most (all??) successes happen because of the failures. To see places where an intermediate format is used, look at most compilers, and at the pbmplus graphics translation collection. I am sure there are others. It doesn't matter to most users what the intermediate format is. You never see it. Only the developers see it. I recommended the use of a format that others are using so we can be compatible with it. Is this bad? ___ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
Re: gEDA-dev: Re: GEDA development ....
John Doty wrote: On May 8, 2007, at 1:24 PM, al davis wrote: The problem with Spice is that it is not flexible enough. It might be flexible enough for you, but lots of people bump against its problems on a regular basis. That's why there are others like Spectre, Touchstone, Hyperlynx, Nano-sim, Rice, and many others. Well, then quit throwing rocks at SPICE and do something better. SPICE may be a klunker, but it's better than vapor. Yes, I know it has problems, I've been working around them for years. But you can't beat something with nothing. I google for Verilog-AMS and 99% of what comes up is hype, not substance. gnetlist does one kind of translation. .. From gschem out. I was addressing all the others. The concept I proposed is to translate in two steps. In to a common interchange format, then out. That way we need only 2*n translators, instead of n^2. I want to make it easy to support many formats, without adding the baggage of carrying them all. Now you worry me again. Sounds like EDIF. Does anyone have a diode and BJT model done in verilog-AMS? ___ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
Re: gEDA-dev: Re: GEDA development ....
On Tuesday 08 May 2007, Russell Shaw wrote: Does anyone have a diode and BJT model done in verilog-AMS? Look here: http://designers-guide.org/VerilogAMS/ Dan said: http://mextram.sourceforge.net/ ___ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
