Exchangeable components

Input component overview

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

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 Candidates 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.

Back to the Developer Guide