Re: gEDA-user: gnucap - oscillator example

[Paul Tan <pt75234@xxxxxxx>]

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 <ad151@xxxxxxxxxxxxxxxx>
To: geda-user@xxxxxxxxxxxxxx
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@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user