Re: gEDA-user: Design Flow Roadmap starting point

[Magnus Danielson <cfmd@xxxxxxxxxxxx>]

From: al davis <ad136@xxxxxxxxxxxxxxxx>
Subject: Re: gEDA-user: Design Flow Roadmap starting point
Date: Tue, 3 Apr 2007 19:08:27 -0400
Message-ID: <200704031908.27671.ad136@xxxxxxxxxxxxxxxx>

Al,

> All that is needed is the basic framework.  It is really simple.  
> Most of everything is out, but by picking a standard language 
> there is a pre-determined way to add later if we need it.

Certainly. My point with the exercise was to show just how much of VHDL that is
not going in.

> > What we need is:
> >
> > Entity declaration (with generics and ports).
> > Architecture.
> > Instantiation of other entities.
> > Assignment of attributes and generics.
> > Assignment of signals.
> > UREF's could be converted into labels.
> 
> Not even all of that.

Maybe not. This was a very quick and coarse subset exercise.

What is needed is a somewhat large subset of VHDL than the current gnetlist
VHDL backend generates. You can actually take that subset and extend out from
that until you have the features you need. I beleive the relevant comments is
still there to help guidance through the VHDL LRM. :-)

> > This is not complex stuff and it should be fairly easy to
> > generate parser and dumper in C or C++, especially if one
> > uses PCCTS/ANTLR.
> 
> I was thinking of using the gnucap "CS" parser class, and doing 
> it like everything else in gnucap, as a language plugin.  I am 
> guessing that VHDL will be about 50 lines of code, Verilog will 
> be about 50 lines of code, Spice will be about 2000 lines of 
> code, pcb about 100 lines, not sure about gschem.

Need to look at the gnucap parser class stuff. Otherwise I agree.

> The idea is a common framework that gets them all.  It must be 
> able to both parse it and generate it.

Certainly. However, many formast have their quirks and limits, so in the end
you will find that many formats will be hard to fully support.

> > > gnetlist has served us well so far, but we have learned a
> > > lot by doing it and using it, and it is time to move on.
> >
> > Indeed.
> 
> There is  lot of old stuff like that.  That is my opinion of 
> Spice, too.  It has served us well, time to move on.  At least 
> a few of its creators think so too.

Certainly. With "modern" things like VHDL and XML you can take a fresh start,
gain a little and loose a little. I've never been a fan of XMLizing things for
its own sake thought.

> > > gschem attributes need to have types.  The type is just a
> > > string, but important.  That way one type can be those
> > > passed to a simulator, another can be those passed back
> > > from the simulator, etc.  Since the type is just a string,
> > > new types can be added at any time.  An attribute should be
> > > able to have multiple types.
> >
> > Your uses of types confuses me here.
> 
> The idea here is that if attributes have types it is easy to 
> filter out or select all attributes of a given type.  It also 
> is easy to make translators.

Certainly, but for a sufficiently complex thing, type filtering isn't helping
unless you can construct new types out of the old and name them as you like.
Compound types of various sort comes to mind after some time and ka-bang
things got a bit complex again. Filtering on attribute names is probably a
better appoach most of the times.

Cheers,
Magnus


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