From: al davis <[EMAIL PROTECTED]> Subject: Re: gEDA-user: Design Flow Roadmap starting point Date: Tue, 3 Apr 2007 20:22:34 -0400 Message-ID: <[EMAIL PROTECTED]>
> On Tuesday 03 April 2007 19:38, Magnus Danielson wrote: > > From: al davis <[EMAIL PROTECTED]> > > > 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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user