Hi Al. Thanks for the summary. I did some exploration and preliminary stuff.
On Sat, Aug 04, 2018 at 07:57:22PM -0400, al davis wrote: > The devices need to become plugins. The different kind of gates should > be different devices, not variants of a device, so new ones can be > added. this is working. i hacked lang_spice to still use these devices, so the tests do not break away. > The "connectmodule" also needs to become a plugin, so new ones can be > added. done. i moved some of MODEL_LOGIC into BUILTIN_CM which is such a plugin now. BUILTIN_CM is now used in DEV_LOGIC, but also works as standalone connect module, to some extent. more untangling is possible. > A LOGIC base class that inherits from COMPONENT needs to be created. A > CONNECTMODULE base class that inherits from both ELEMENT and LOGIC > needs to be created. Is the separate LOGIC class really necessary? It > can wait. CONNECTMODULE inheriting from ELEMENT works, it dictates the port names and order, i don't know how to fix it, but it seems very minor. LOGIC is not urgent. everything else needs work. > I think the "logic-1" branch is moving in the right direction. in logic-1 i had hacked LOGIC_NODE. i have reverted this (now conn-5), so the new plugins also work with master & develop. they replace the logic, and are incompatible with the current logic devices. looking at verilog-AMS, i think LOGIC_NODE::_family should become the "discipline", but also for non logic nodes. disciplines are actually NODE variants. do we need both? fwiw: verilog-AMS logic (discrete) nodes give access to the drivers connected to it. i don't exactly know where to put it -- pluggable NODEs might be useful. cheers felix _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
