On Dec 5, 2009, at 8:26 PM, Dan McMahill wrote: > John Doty wrote: >> Now, gEDA's design isn't nearly as clean as TeX plus LaTeX plus all >> the other stuff. Still, it's *much* better the competition, and can >> be improved. Unfortunately, there's a lot of pressure to make it >> dirtier. >> > > With all due respect, have you actually used any of the high end EDA > tools for IC design?
No. I have used one of them for schematic design for circuit boards on several space missions, though. And some of my university colleagues use one of the big $$ tools (they get a discount, I can't afford it) for VLSI. From what I see it has a few rather trivial extra capabilities: an example is the ability to make a dependency graph for the subcircuits. That wouldn't be a difficult thing to extract from a gEDA design using a script, but I haven't felt it worth the bother to write one. > I'm talking about tools that have significantly > more structure in their schematic capture tool but at the same time > have > considerably more powerful scripting API's that have every bit as much > flexibility as we do. And they have done it in a way that also allows > significantly more powerful and useful features than what we can do > with > our current design. But are you talking about genuine, essential capabilities, or just sugar? An example from the coding world is the ability to single step through code you're debugging. That's pure sugar: you don't need it, it is a monumental waste of time, and the coders who are addicted to it are not productive. Yet they swear it's essential... On the other hand, the ability to come back to a project after a couple of years, make a small change, and have "make" regenerate all of the data products: schematics, netlists, documention, software drivers, etc. is almost priceless. Hurray for gEDA! No need to figure out some elaborate point and click procedure to navigate through all the complexity I've forgotten. Unnecessary GUI is a disaster for a part-timer doing complex jobs. > With the particular tool I'm thinking of, I predict > that I could code up the equivalent of any of our gnetlist backends in > an afternoon, maybe much less. That's about the same amount of > time it > took for the gnetlist backends I've written. OK, I haven't seen one with that capability. But I do know that you can spend $30k-$100k a year for less than what I get from gEDA. You "could". But has anybody actually published a collection of backends for that tool to rival gEDA's? "Could" gets nothing done, but gEDA "can". > >> One place where gEDA is really special is the gnetlist Scheme API, >> which enables gschem to feed a wide variety of downstream flows. >> Rather than changing gEDA into just another sweet, low productivity >> EDA application, we need to build on that strength. > > except that the scheme API is no where nearly complete enough or > powerful enough. And... everytime someone proposed extending it and > making it more powerful, we are accused of making the tool be low > productivity.. No, you have it backwards. Adding special kludges behind the API to grease the skids into a particular channel is *not* making it more powerful, that just makes it harder to really make it more powerful. Adding kludges to cover up problems is *not* making it more powerful, that just makes it harder to really make it more powerful. In particular, the attribute censorship bug in gnetlist should *not* be fixed by a complex formalization of the censorship procedure in the front end, it should be fixed by eliminating the censorship. Let the Scheme side see *all* attributes, not just whatever the front end wants to let it see. Put the default selection in gnetlist.scm where it can be overridden, not in the front end where it can't. Why is this so hard to understand? John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [email protected] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
