On Dec 7, 2007, at 12:40 PM, Steve Meier wrote: > > I am particularily interested in being able to output netlists for > simulation wich support hierarchical references.
Right now, the big problem is that gnetlist will insist on expanding all references via source= itself, so you wind up with a monstrous and very repetitive file. It's not what the layout folks want to see. The way I deal with that is to avoid using source= (which means Hd doesn't work, but it's easy enough to open the source schematic manually as needed). I assemble the complete SPICE netlists by concatenating the subcircuit netlists with "cat". > > I am not an expert at spice and advice, test cases, expected results > will only make my work in that direction more likely to be > successfull. > But if there isn't open willing support I probably should re- > prioritize > my efforts. > >>> Also as part of this process I am striving to create a well >>> documented scheme interface into the library review of that >>> interface >>> and suggestions on what is needed to achieve the desired spice, >>> vhdl, >>> verilog output files would also be apreciated. If you really feal >>> like >>> it then once the scheme interface is deffined you could take a >>> shot a >>> writting/modifying the spice output format macro. >>> >> >> The issue at hand is how the databases that drive this should work. >> Various people have various visions. I have no strong preference as >> long as the result retains gEDA's flexibility. But I don't know how >> to evaluate Al's suggestion, as it's just "wave the magic Verilog >> wand, and all will be well". >> >> > No the database is built into the strucure of the library. verilog, > vhdl > and spice are just reflections of that internal database. That's your vision. But Al wants "the structural subset" of Verilog to be the database. > >>> Later on today I will send out the latest scheme interface >>> document it >>> still mostly (almost exclusively) is about getting data into the >>> library >>> structures but I am about to turn my attention towards basic netlist >>> generation control (page level and as specific command to >>> flatten the >>> page nets/buses into a single page as a specific command) and >>> schematic, >>> symbol, bom and netlist exporting functions. Actual netlist >>> generation >>> both page and flattening functions already exists in the library as >>> does >>> the scheme interface at least for the flat netlist but these scheme >>> functions havn't made it into my document yet. >>> >> >> I know well that right now you just have to experiment with modifying >> other netlisters. >> >> > Actualy two points one I got so wrapped up I forgot to publish my > latest > scheme interface doc and two I think what I have doen is rewrite an > existing netlister... since I have built a board that has two channels > of a flat bandwidth of 4Khz to 450 Mhz feeding into a system of a/d > converters sampling at 500 Msamples sper sec and then into some fpga's > which then process the data and then hook into an existing piece of > equipment. Board built, fpga's programed embeded linux running, real > time processors running array processors taking over more and more of > the signal processing... I think we are past experimenting. > >>> Then with an eye towards the future I am starting to think about >>> how one >>> could embbed files other then schematics into symbols. As well as >>> spice >>> models these could include hardware description languages such as >>> verilog and vhdl and??? >>> >> >> Why embed? References are good things. Directories are good >> containers. File utilities are handy for reshuffling the pieces. >> Files are good publishable objects. People who don't know what to do >> with a .sch often can handle a SPICE netlist... >> > > Is a schematic which is referenced via a source= attribute embedded? That's not our terminology. "Embedded" means present as a complete object in the schematic file. > That is what I ment. Similarily to have an attribute which reads vhdl= > or verilog= or spice= and then pulling the code or a reference to the > code and includding that into the final netlist embedded or just > refferenced... We have file= for SPICE already. But it would make more sense to have a SPICE-specific attribute. Also, pinseq= is confusing. > > > Thanks, > > Steve Meier > >> >>> Thanks, >>> >>> Steve Meier >>> >>> >>> John Doty wrote: >>> >>>> On Dec 6, 2007, at 3:13 PM, Steve Meier wrote: >>>> >>>> >>>> >>>>> John, >>>>> >>>>> The beauty of geda and its scheme capabilities is that any file >>>>> format >>>>> that is reasonably well deffined can be supported. >>>>> >>>>> >>>> Indeed. Give me a well defined format with a clear use, I might >>>> even >>>> help. >>>> >>>> >>>> >>>>> Instead of railing at at Al start helping to nail doen the >>>>> deffinitions >>>>> on the formats your prefer. >>>>> >>>>> As I have said my short term goals are to provide output >>>>> support for >>>>> verilog, vhdl and spice. >>>>> >>>>> >>>> But that can mean many things. Al keeps talking about Verilog as an >>>> internal format, not an export format. But it's impossible to >>>> understand what he means by that. >>>> >>>> >>>> >>> >>> _______________________________________________ >>> geda-user mailing list >>> geda-user@moria.seul.org >>> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user >>> >> >> John Doty Noqsi Aerospace, Ltd. >> http://www.noqsi.com/ >> [EMAIL PROTECTED] >> >> >> >> >> _______________________________________________ >> geda-user mailing list >> geda-user@moria.seul.org >> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user >> >> > > > > _______________________________________________ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [EMAIL PROTECTED] _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user