[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: Design Flow Roadmap starting point



On Tuesday 03 April 2007 18:36, Magnus Danielson wrote:
> You can strip of many things from VHDL which you will not
> initially need. What you end up with very quickly is a small
> subset which brings much of the properties which gedas
> textual format has. It should be fairly easy to do so.
>
> Hierarchial stuff is trivial.
> Attributes is trivial.
>
> >From this you can then selectively add things from the VHDL
> > standard at need.
>
> What should one cut out or cut down then?
>
> Design entities and configurations (Section 1) - all but
> config (1.3) Subprograms and packages (Section 2) - cut out
> Types (Section 3) - cut down considerably
> Declarations (Section 4) - cut down
> Specifications (Section 5) - most if not all is in
> Names (Section 6) - most if not all is in
> Expressions (Section 7) - initially all cut out
> Sequential statements (Section 8) - initially all cut out
> Concurrent statements (Section 9) - all but 9.5 and 9.6 which
> however is cut down

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.

>
> 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.

> 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.

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

> > 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.

> > 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.


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