======================= Exchangeable components ======================= * **Input component** * :ref:`dev_guide_qa` * :ref:`dev_guide_estimation` * :ref:`dev_guide_search` * :ref:`dev_guide_output` .. image:: ../images/components/component_overview_input.png :alt: Input component overview .. _dev_guide_input: Input component =============== The *Input* (or *FrontEnd*) component pre-processes the input circuit, e.g., removing code annotations to restore valid Verilog code, and extracts information from the circuit, e.g, candidates, to initialize required data structures, e.g., the candidate set. In other words, the *Input* component's role in the approximation process is to create a foundation on which the other components can operate. Functions ========= .. .. todo:: Add links to function documentations ``setup(self, cfg_file: String, input_file: String): None`` ----------------------------------------------------------- The ``setup`` method can be used to initialize the component by storing the configuration and input files and perhaps do some pre-processing such as validation and compatibility checking of the input circuit. The default implementation stores the files and only checks if the input circuit file name is not empty. ``process(self): GeneralInformation`` ------------------------------------- The ``process`` method provides the main functionality of the *Input* component. It is called exactly once at the very beginning of the approximation process and must return a ``GeneralInformation`` instance which is fully set up to be used in the *QUAES* stage. It doesn't matter how a specific implementation accomplishes this goal, as long as the following post-conditions are met: * A ``GeneralInformation`` instance was created * ``CandidateSet``, ``VariantSet``, and ``ApproximatedCircuits`` instances were created and stored in the ``GeneralInformation`` instance * The ``CandidateSet`` instance is filled with the complete set of ``Candidate``\ s to be considered in the approximation process (they don't need to have ``quality_constraints`` or ``approx_methods`` yet. In case of missing information, the default parameter will be filled in later) * The ``CandidateSet`` and ``ApproximatedCircuits`` instances have valid ``path`` attributes, i.e., valid directory paths * There is a ``*.v`` and a ``*.blif`` file storing the original circuit, where ``*`` is the original circuit's name * Following attributes of the ``GeneralInformation`` instance are set correctly: :``top_module``: The name of the original circuit's top level module :``pis`` and ``pos``: Lists of ``Signal`` instances representing the original circuit's primary input and output signals (can be extracted from Verilog code automatically with the provided function ``extractPiPo()``) :``base_directory``: (Optional, default is the directory containing the input file) The root directory under which all directories and files of the framework will be stored :``output_dir``: (Optional, default is the directory containing the input file) The directory in which all output data will be stored The hardest part of this is probably creating the ``CandidateSet``, since the other tasks can be easily done once the set has been created. However, extracting the candidates from the original circuit in a particular manner is the main argument for creating a custom ``FrontEnd`` subclass, so this is the part on which you should focus. The framework and the classes themselves provide many handy utility functions and sensible default values, so make sure to have a look at existing ``FrontEnd`` implementations and the other classes' documentation before you start writing your code. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :ref:`Back to the Developer Guide `