On Tue, 08 Jul 2008 13:07:26 -0400, al davis wrote: > I prefer to interact with the simulator directly. Most people > who interact through menus or only the schematic are light > users.
Most people, including me, who have worked with the "Schematic Driven" technology that are employed by most of the advance state-of-the-art EDA tools vendors, might think differently. To quote from Synopsys' CosmosLE tool: http://www.synopsys.com/products/mixedsignal/cosmos/cosmosle_ds.html "CosmosLE uses core capabilities of Enterprise and "schematic-driven" layout (SDL) to place and route full-custom circuits and is a perfect complement to CosmosSE’s "schematic-based simulation and analysis". The designer controls the level of layout automation, ranging from automated layout to full-featured, handcrafted layout. Intelligent layout automation in CosmosLE results in LVS- and DRCcorrect cell and macro layouts." I think "Schematic Driven" is the way to go. Best Regards, Paul Tan -----Original Message----- From: al davis <[EMAIL PROTECTED]> To: geda-user@moria.seul.org Sent: Tue, 8 Jul 2008 10:08 am Subject: Re: gEDA-user: gnucap - oscillator example On Monday 07 July 2008, Paul Tan wrote: > if you already have a Gschem schematic ready, that will > save me some time. Do you use spice-sdb gnetlist to > generate your netlist or do you use gnucap gnetlist ? No. I typed it in with a text editor. Gnucap lets you type it in directly if you want, but I usually like to start with an editor. Gnetlist, spice-sdb doesn't always do a complete translation. It only supports a subset, and only goes one way. Netlist translation is an area in big need of work. If you really want to make a big contribution, this is the place. The spice format has problems. The only reason to keep it is for backward compatibility with legacy tools. I would really like it if someone would make a gschem plugin and PCB plugin for the gnucap translator system. That would enable back-annotation and post-layout simulation, which we don't have yet. I might end up doing it myself, but I think it is better to get more people involved so I can concentrate on making gnucap better in general. > Once a generic Gschem/Gnucap Tools script submenu > is made, it could be apply to most Gschem/Gnucap flow > situation. Then all we have to populate are the > examples folders and a README file to explain > to the users the flow. I prefer to interact with the simulator directly. Most people who interact through menus or only the schematic are light users. In general, I prefer direct interaction with the tools, not through anything that hides the real interface. This means the real interface must be good, which often it isn't. > It would save me time if you already have in > mind certain tools flow in shell script form,even if > it is specific to an example. When I make gnucap examples, the intent is to demonstrate gnucap, and to minimize requirements of other stuff. I will bring in other stuff to demonstrate the interaction. There is a requirement with gnu tools to not promote any non-free software. I agree with this requirement. Any official gnucap documentation will only promote free tools. Of course, gschem, PCB, and others here all qualify. On the geda site, there should be examples demonstrating the interaction of the tools .. gnucap and gschem working together. It shouldn't just be my preference, but it should show the many ways the tools can be used together. _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
