From: al davis <[EMAIL PROTECTED]> Subject: Re: gEDA-user: Design Flow Roadmap starting point Date: Sun, 18 Mar 2007 01:29:07 -0400 Message-ID: <[EMAIL PROTECTED]>
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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
