Mail Archives: geda-user/2015/02/09/12:36:43
On Feb 9, 2015, at 8:42 AM, John Griessen <john AT ecosensory DOT com> wrote:
> On 02/08/2015 06:52 PM, John Doty wrote:
>> Peter Brett told me he was working on an complete implementation in Scheme, but he apparently never finished.
>
> I've done Scheme/guile/LISP as Cadence branded Skill language before. If we had a document for what the
> overall structure of gschem was,
Hierarchy in gschem is documented. See http://wiki.geda-project.org/geda:gschem_ug:hierarchy.
> and how the desired new features of hierarchy where we can have schematics in schematics,
None required in gschem. For Verilog, there are other things you might like, such as better bus support, but hierarchy is there.
The big impediment right now is the way that gnetlist works. It reads all of the input files, and grinds them into internal data products. If hierarchy expansion is enabled, it expands hierarchy all the way down. Subschematic symbols disappear from the data in that case. It then invokes the back end. It provides views into those data products, well chosen for BOM generation and flat netlisting, but not for other things.
The way to use it for hierarchical netlisting is to disable hierarchy expansion and have the back end handle the subschematic symbols. Gnet-spice-noqsi uses an attribute that looks like "spice-prototype=X? %down Booster” to connect a symbol with a subcircuit.
The symbol also contains source= attributes identifying the schematics for the subcircuit. Gschem useses them for navigating hierarchy, but there’s not much the back end can do with this information.
It would be much handier if gnetlist did its support work functionally, on demand, rather that procedurally up front. Have the back end do (read-design files flags). Control hierarchy expansion (and maybe other things) in flags. Have functions that extract data from the result of this, rather than from global structures. Then, a hierarchical back end could do something like (read-design (locate-sources symbol) flags) when it encounters a symbol for a subcircuit.
> or verilog modules in schematics and specify specific layout variants that go with instances of schematics or modules --
> a big if -- I would take a function and redo it and debug it to work.
>
> We could add working code and keep it in the distributed, tested-by-all code.
> gschem could evolve to be better with two day code sprints per person.
>
> On 02/09/2015 03:08 AM, Chris Smith wrote:> In terms of hierarchical schematics, etc. what do you think is missing? What features would you need and where do you feel the support for them is missing: the file format? gschem? netlister?
>
> The way connectors create a larger flat assemblage is a big gap between what works for large designs or chip designs
> and especially boards with custom logic modules on them which are some of each. What the tools those designers use
> do is keep module instantiations uniquely tagged as to what unique layout corresponds to them. That kind of correspondence
> is used to simulate the final product so you can have a lower risk of success when spending to get it fabbed.
>
> Instances of a module have the same structure as the top level of a design also -- so it can be reused as
> a module later. Netlists can be made that have details of specific layout included for chip simulation purposes,
> or board fabbing oriented netlists can be made that show all part/package as identical. Netlists do not have
> node lists like we have now:
>
> flat-with-hierarchic-names:
> VDDA2: U1-8 U3-10 S1/U1-8 S2/U1-8 S2/S3-U7-10
> where there are no identical instances of anything and S2/S3-U7-10 is just a blob of text where S3 is not for sure separable
> from it.
>
> they will have node lists like:
>
> VDDA2: module1:1/port4 module1:1/module5:1/port2 module1:1/module5:1/port1 module1:1/module5:1/C4
>
> Where the slashes separate hierarchy levels and the colons enumerate instances.
> module5:1 is surrounded by slashes so one knows it is a separate text to parse that has meaning about levels.
>
> VerilogAMS has syntax similar to this and more and it well known, logically consistent, standard, published,
> tested for usabiility, has had millions of dollars bet on it working, etc.
And when it’s supported so that people without deep pockets can use it, it will be interesting. Where is the VerilogAMS equivalent of ngspice? Where is the the equivalent of http://research.kek.jp/people/ikeda/openIP/? Where are the macro models?
> Verilog versions before it
> have had billions of dollars bet on them working.
>
Let Verilog netlists be Verilog. Let SPICE netlists be SPICE. Let Osmond netlists be Osmond. If you really want a *universal* netlist format, do it neutrally, as a table of relations.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
- Raw text -