On Monday 14 May 2012, [email protected] wrote: http://gnucap.org/dokuwiki/doku.php?id=gnucap:user:language_plugin_for_gschem
(I need to make shorter URLs) ... It looks like you are making good progress. I am pleased with what I see. a few comments .. Mapping of geda "device" to verilog ... All you can do is pass it on. There is no way of knowing info such as the symbol says "VOLTAGE_SOURCE" and Verilog needs "vsource". All you can do is pass it on. The symbol needs to be corrected, or there could be some way of mapping that is user controlled. It could be as simple as "`define", but sometimes there could be node and parameter mapping as well .. macromodule RESISTOR (\1, \2); resistor (.r(r)) R1 (\1, \2); endmodule Note that I called it "macromodule" instead of "module". For now, they are the same, but it is supposed to be that a "macromodule" is flattened, but a "module" preserves hierarchy. There are reasons for preferring one or the other. Use of "place" ... You cannnot rely on names (device names or node names) having any meaning. They are just strings. So (for example) the relation between "placeR1" and "R1" cannot be relied on. This is why in my proposal http://gnucap.org/dokuwiki/doku.php?id=gnucap:user:netlist_import_and_export I made the "place" locate the nodes, not devices. A "place" connects to a node, and has locations as parameters. So, even if the names change it stays located. I did not locate devices, only nodes. The devices would float and place themselves reasonably between the nodes, which are explicitly located. Back to the names .... As I said, the names are just strings to the computer, but they do have meaning to humans. I used a convention that nodes on the same net share the name of the net as the prefix, so a human reader can see that "n1" and "n2" are really the same net "n". I thought that convention would be easier to comprehend for users who are accustomed to the spice notion that a net and node are the same. _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
