Hi, I've gone through the schematic format, verilog netlist format and the notes on how to translate. I've updated the wiki page about that at [1].
'net' is not identified as an implicit model by gnucap. Does that mean a 'net' module is to be defined in each case? A simple ideal net module can be module net(pin1,pin2); resistor #(.r(0)) rnet (.p(pin1),.n(pin2)); endmodule > Instead there are parameters, name=value pairs. Even a resistor > can have more than just resistance. There is temperature > coefficient, tolerance, power rating, capacitance, inductance, > and more. I can't, you can't, list them all in general. > Rather, support the syntax and pass it on. Yeah right.. I'll just pass on the parameters. What should they be named? For example in case of a resistance, how should the tolerance parameter be named in verilog? Same as what it is in other formats (eg: gschem)? resistor #(.r(),.tol()) r1 (.p(1),.n(2)); or resistor #(.r(),.tolerance()) r1 (.p(1),.n(2)); or some other way? How are these parameters incorporated into the models of components? > > After getting the model name, in order to use in the > > analysis, the parameters of models are needed. > > Does this mean that the models should be stored? (loaded as > > plugins?) > > The same device has different views depending on what you are > doing. It has symbols for schematic, footprints for layout, > models (subckt, model, module, whatever) for simulation. You > might want different models depending on what you are doing > today. Preliminary pre-layout simulation ignoring parasitics? > How about post-layout simulation with IBIS models, where the > nets are first class objects? Ok, I get the idea. The parser should create a netlist for the schematic. Now what we do with the netlist and how we model the components in it is secondary. That's depending on our use, right? [1] : gnucap.org/dokuwiki/doku.php?id=gnucap:user:language_plugin_for_gschem -- Savant Krishna | Sophomore | Electrical Engineering | IIT Bombay _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
