On Jan 9, 2008, at 2:38 AM, a r wrote: > Hi Al, > > I have read all the comments and, sadly, they were mostly as I > expected. > > The reason why I have drifted toward this topic is that I hoped you > would be interested in needs of ASIC industry engineers, so you could > improve some of gschem characteristics and make it more popular in > this environment.
Since some of us design ASICs with gEDA, I don't see how you can complain that we don't understand the needs of ASIC design! > From this discussion, however, I have got an > impression that you are trying to teach all ASIC engineers how to use > EDA tools your way, rather than to listen to their needs. Every toolkit has its logic. gEDA's is driven by transparency, versatility, portability, and openness. Other tools have different goals. If you're going to use the tool, it makes no sense to fight against its logic. > Nevertheless, it is all your software and you decide where you want to > take it. > > Again, what I would like gschem to have is: > - a coherent design database, preferably with an API for a script > language (scheme is fine), make > - parametrized device symbols ready to use with typical ASIC flows, What a "typical ASIC flow" is depends on where you sit in this gigantic industry. There aren't many symbols for ASIC design in the library: you have to make them. But that's where all the symbols come from: somebody made them. In my not too copious spare time, I'm working on a symbol library for OpenIP (http://research.kek.jp/people/ikeda/), and maybe I'll have it done in a month or so. But maybe you wouldn't consider Professor Ikeda's approach a "typical ASIC flow". > - strong support for hierarchical designs, Works for me. Minor annoyances, but hardly serious time wastage. > - responsive UI (retained-mode canvas etc), Works for me. > - sane defaults (autonumbering instances etc) I think most are sane. And you can change them. > > What I don't care about (and preferably I would like not to be exposed > to when using ASIC flow) is: > - all the PCB related features, What features? gschem is pretty generic. But then in my "typical ASIC flow" the next thing after finishing the ASIC is the test board. And the next is an application board. So it's very nice to just keep using the same familiar tool. > - multi-page schematics You like giant unreadable schematics? gschem can make those if you want, but I prefer nice simple modular schematics that are readable when assembled in a binder. > and slotted device, So don't use slots. > - inherited connections, global grounds&supplies, Some flows use them, some flows don't. I think they actually make more sense for ASIC design than PCB, but that, of course, reflects what I consider "typical". OpenIP uses them, so gEDA is a good match for that VLSI flow. But if you don't want them, don't use them. > > Finally, I consider gschem a fine program, assuming your target users > are component-level electronics designers in an academia environment > or electronics geeks. That's one set of applications, yes. But gEDA is flexible: it's not designed for anyone's specialized corner of electronics. > For industry, gschem lacks features. For > mainstream PCB designers, it has too steep learning curve. Commercial tools have steep learning curves, too. But one of the nice things about gEDA is that it works with lots of PC board tools. One customer uses Calay, so they get Calay netlists. Another uses Osborne, so they get Osborne netlists. gEDA works well in lots of flows, not just what you happen to consider "typical". > > Regards, > > -r. > > > _______________________________________________ > 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/ [EMAIL PROTECTED] _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user