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 20:22:34 -0400
Message-ID: <200704032022.34816.ad136@xxxxxxxxxxxxxxxx>

> On Tuesday 03 April 2007 19:38, Magnus Danielson wrote:
> > From: al davis <ad136@xxxxxxxxxxxxxxxx>
> > > 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 line count is a guess.  My point is that VHDL and Verilog 
> are about the same.  Spice is the worst one of all.  Others are 
> between.  The fact that VHDL and Verilog are so regular makes 
> the parsers and generators small.  The Spice parser and 
> generator is huge because the language is so irregular.  It 
> seems every component is different.

Index finger to thumb measures are fine. :)

The point about irregular languages is indeed a good one.

> > 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.
> 
> That is way too complicated.  The type is just a name, used to 
> group things, so they can be filtered as groups.

I was talking about type as in integer, real, string, bit etc. Thus the
confusion.

>  Without 
> changing anything, it is possible to just use a naming 
> convention and partial matching to select.  I am thinking of 
> groups like simulation parameters, the hidden attributes that 
> make gschem work, layout stuff, data coming back from a 
> simulator.  The names cannot be determined in advance.  Strings 
> like what we do now for things like spice sources is not the 
> way to go long term.  To store it, it would need to be able to 
> be encoded as a single string anyway, so it might make sense to 
> just do that and forget doing anything special.
> 

Thus, the only type you initially intend to support is string.
However, many named constants/attributes/generics of the type string is in
there.

I forsee alot of other side-information that follows along. We might need
different architectures depending on which simulator is going to handle things.
A simulation model for one form may not have the same names as another etc.

You would also like attributes to propagate out of devices, so that we can
have for a signal the shortest rise and fall times, which is immensly usefull
for SI and EMC work, just to name one.

If you take a few steps back, there are more of these things.

Cheers,
Magnus


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