Synthesizer of analog circuit topologies in the domain of small signals and low frequencies

1. BATS software architecture

The software that is used to demonstrate a partial operation of the desired capabilities in the behavior-driven design method called BATS. This software is written using the Visual C++ programming language. The reason for choosing this language is its high execution speed and its proximity to low-level languages while still having object-oriented features. Without features such as object-oriented programming and the ability to create a powerful user interface, such programs are difficult to implement and use. 

This software receives the problem statement from the user using menus in the domain of small signals and low frequencies and delivers the response, which contains the final topologies, in two formats: Schematic and Netlist. During the solution process, the generated topologies of each stage are presented to the user, allowing them to apply constraints such as removing the continuation of a branch from the problem. Only the topologies that are granted permission by the user proceed to the next stages of the solution. The use of menus for defining the problem and software settings has greatly simplified working with it.

The software architecture of BATS is shown in Figure 1. The Topology Generation component is the main engine of the system, which performs the task of generating topologies from the high-level behavioral model using algorithms and stored knowledge. The contents of the knowledge base are introduced in Chapter 3.

Figure 1: Software Architecture of BATS

2. Features of BATS Software

1-2. Utilizing Visual Features for Simpler User Interaction

The method of receiving user inputs, providing responses, and the overall visual interface of the program play a crucial role in establishing a simple and efficient communication with the user. In BATS software, the user does not need to learn a new language with its specific syntax rules, and they will encounter minimal communication issues with the software. The familiar and standardized appearance, commonly seen in programs written using visual programming languages, also facilitates faster and effective communication between the user and the software. Creating a unified and cohesive interface for the software allows for easy addition of new components and software expansion while maintaining the current appearance, simply by completing the inactive sections. The user does not need to know how to work with input and output files, as file management and their connection with the core of the program are handled by the software itself.

2-2. Limitations of the Solution Process in BATS Software

As mentioned, the solution space for any problem within the domain of linguistic constraints is infinite, meaning that by considering an unlimited number of elements in the generated topologies, it is practically possible to obtain an infinite number of valid solutions that satisfy the problem conditions. For example, if there is only one resistor in a topology, an infinite number of topologies can be considered by arranging the resistors in series, which are equivalent to the initial topology. By addressing this issue, the need to restrict the range of generated solutions becomes apparent. Predicting the non-repetition of a problem more complex than the problem itself in the higher-level behavioral model can act as a limitation to the solution space and prevent the generation of excessively complex behavioral models. Additionally, the approach employed in BATS software to prevent the generation of undesired solutions and excessive solution space is based on user decision. In this way, the generated topology at each stage is presented to the user, and the solution process continues only if the user chooses to proceed with solving the problem in the current incomplete topology path. The user can prevent the continuation of the problem-solving process in the current path at any stage and pursue the problem-solving in another branch of the solution paths.

3-2. Tree-Based Problem Solving and Minimizing Memory Usage in Data Structures

In the algorithms discussed in Chapter 3, solving a problem in multiple stages of algorithm execution leads to branching and creating multiple paths. The behavioral model of each branch in the solution path is generated and maintained for subsequent stages. At any given moment, only one of the possible paths is being processed. To determine which level of the hierarchical solution path the current behavioral model belongs to and from which previous behavioral model it originated, a name consisting of a certain number of Latin alphabet letters is assigned to each behavioral model at each level. With each progression in the hierarchical levels, a letter is added to this name. For example, a behavioral model named 'abb' indicates that this behavioral model is at the third level of the hierarchy (as indicated by the number of letters in its name), and the behavioral model from which it branched off had the name 'ab'. This naming scheme ensures that the breadth of solution paths at each hierarchical level is limited to a maximum of 26 branches. In the algorithms, it is anticipated that if the number of branches exceeds 26 (which is unlikely due to the small size of the library of elements), the 26 branches with higher matching weights will be selected to continue the path. The selection of a behavioral model for solving is done based on the name of each model, considering the largest existing name. Names with longer lengths are considered greater, and among names with equal lengths, their greater or smaller value is determined by comparing the first letter from the left and, subsequently, the second letter, and so on. In the output file of each stage of the solution, the name of the behavioral model is included. When behavioral models at a new hierarchical level are created based on a hypothetical behavioral model named 'adc,' the 'adc' behavioral model itself will be removed from the system memory. This action results in further memory optimization. Consequently, if we consider the solution paths as branches of a tree structure, only the main branches are stored in the system memory. The data structure used in this software generates strings of the required length, and no data with a greater length is pre-allocated in the system memory. When necessary, memory is allocated to accommodate the required data, and at the end of the process, this memory is automatically freed.

4-2 Output Netlist/Schematic

The output of each stage of the solution is provided as a file containing a generated netlist and a schematic window displaying the generated topology. If the topology is still incomplete, meaning it has unknown structural units, the user is given the option to continue or stop the solution path based on the acceptance of the current topology. If the displayed topology does not have any unknown structural units, it represents one of the final topologies produced by the software. In this case, by accepting this topology, the user allows the continuation of the solution path in the largest branch after the current branch.

Since the generated topology is presented to the user at each stage, and the decision to continue or stop the solution path in this branch is the responsibility of the user, drawing the circuit diagram based on the netlist speeds up the user's decision-making process in accepting or rejecting the generated topology and significantly increases the speed of working with the software. It should be noted that the presentation of the generated topology in schematic form is not performed in other software and is one of the unique features of the BATS software.

5-2 Ease of Adding New Elements to the Element Library

To add a new element to the element library, the following steps are sufficient:

• Describe the set of algebraic equations representing the element's behavior using the provided algorithm for generating the set of algebraic equations from the descriptive equation set presented in Chapter 3. Add this set of algebraic equations, which is a simple text file, to the algebraic equation set file.

• Add the small-signal constraint table and the set of large-signal constraints for the element to the constraint set file, which is a text file.

• Add the circuit diagram of the element to the topology drawing section.

All of the above steps are easily performable, and by adding an element to the element library, the set of desired solutions can be expanded. Since the selection of an element from the library is based on constraints and using the constraint set assigned to the library, in cases where there is a need to work with a more limited set of elements, simply removing one or more elements from the library's constraint set is sufficient. This way, the element will be removed from the selectable elements. 

Developed/Documented by Farshid Farhat