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

Re: gEDA-user: Design Flow Roadmap starting point



From: al davis <ad136@xxxxxxxxxxxxxxxx>
Subject: Re: gEDA-user: Design Flow Roadmap starting point
Date: Sun, 18 Mar 2007 01:29:07 -0400
Message-ID: <200703180129.07092.ad136@xxxxxxxxxxxxxxxx>

Al,

(Jumping into the discussion mid-waters)

> I still believe we need an interchange file format, that should 
> be a VHDL derivative.  VHDL has most of the capabilities 
> needed, and is an industry standard.  If something is missing, 
> we can add it, and propose it back to the standards committee.  
> They might even welcome it.

I think that VHDL is a very good boiler-plate. This approach was used for
Boundary Scan files.

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

This is just a swift walk-through of the VHDL standard (using the VHDL-93
that was lying on my desk anyway). Whatever is needed to support AMS infra-
structure (i.e. analog signals), which should not be very much.

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.

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.

Writing up a VHDL equalent format for the geda netlist format should not be
too hard. If you want to go beyond the geda netlist format constrains of today,
it is fairly easy to do.

The one thing which I am not up to date on is how modern character sets is
handled etc.

> gnetlist really needs to be redone, from the ground up.  This 
> VHDL based intermediate format is the way to do 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.

> > *  Similarly, how should gnetlist behave?  A use-case list
> > would be useful.
> 
> Any extraction should preserve hierarchy, in hopes that the 
> target tool also benefits from it.  If it doesn't, you need a 
> separate flattener pass, separate from the translation.

In a gnetlist rewrite, a flattener could be written and called for those
backends that need it.

In the other direction, naming conventions may alow for de-flatenations in
some cases, so support for that may also be considered.

> Regardless, the translation must be 100%, lossless, in both 
> directions.

Indeed.

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

In a future, it is not necessarilly only strings, but it is a good first
assumption.

> 
> > *  Finally, how should PCB behave with a hierarchical
> > schematic?
> 
> Right click on a symbol, select "go inside", and another drawing 
> opens up showing what's inside.  gschem also should act this 
> way.

Indeed.

Cheers,
Magnus


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