The CAD tool is based on a software Bayesian network solver. It is written in Java in such a way that it can be extended to perform other Bayesian network-related tasks as necessary. At the core of the tool is a network class which represents an entire network. It parses an XML file that describes a Bayesian network, storing each variable in a variable class and each function in a function class. The variables and functions are then stored in separate hash tables in a network class, which may then be modified, solved, or used to generate a SPICE netlist.
The choice to use XML to specify the networks was due to the strength of existing XML parsers and their ability to check the validity of the document. The syntax that was chosen for the document is similar to the XBN format developed by the DTAS group at Microsoft Research [15]. Java was chosen because of its portability and general ease of use.
Many full-featured solvers are already available, both commercially and in open-source formats [16]. One notable full-featured Java implementation is called JavaBayes--it is capable of using two different algorithms to compute marginal distributions and has a GUI for simple creation and modification of the networks [1]. Bayesian networks are also used as tools for making decisions based on observed data in several Microsoft products. The office assistant, featured in the Microsoft Office suite, relies on a Bayesian network and observations of the user's actions to assist users with their work.
The syntax of the XML document that is used to describe a network is important because it is the primary source of information for the solver, and in turn is where the user will spend most of their time. The document is based on the XBN format from Microsoft Research [15], and is divided into three parts: a section that contains a description of each of the variables, a section that describes the structure of the network, and a section that contains a discrete function for each of the variables in the first section (See Appendix B).
For each variable, the user must provide a name, a description, and the names of the on and off states. In the case of an alarm, the on state would be ``ringing," and the off state ``not ringing." These fields are not crucial for the operation of the solver, but are used to make the user interface more palatable.
While internally, the tool represents the network as a factor graph, the XML syntax is that of a Bayesian network. There are several reasons for this. Because the tool is a Bayesian network solver and not a factor graph solver, the user need not know that the internal workings of the solver involve factor graphs. Both Bayesian networks and factor graphs are used to represent a series of events that happen in logical order and are interrelated in a specific mathematical way, but Bayesian networks, which are directed graphs, provide a more intuitive platform for this as one event clearly causes another. Finally, because the tool must solve a network, and also emit SPICE netlists that perform the sum-product algorithm, the internal structure of the solver must facilitate sum-product message passing. The structure of choice for this type of message passing is a factor graph with separate variable and function nodes.
Because Java is an object-oriented programming language, the structure of the tool is naturally modular. It is divided into a set of menus which all extend a generic menu class, a set of objects that define a network, and a few helper classes that parse the XML file and generate a network. The tool is text-based, so the menus are the user interface. Each menu knows how to print itself and how to execute each of its options.
The XML parser has three pieces. The first piece knows nothing of the structure of the network, and is simply an interface between the DOM XML parser from Apache and the solver. The second piece knows how to parse the XML document, but does not know how create a network. It uses the first piece to perform its duty of extracting specific pieces of information from the raw XML. The highest-level knows how to create a network object, but relies on the second piece to get the data it needs.
The function and variable objects extend a generic node object. The node knows how to send and receive messages, but not how to make them, as the marginalization step is different for the different types of nodes as explained in section 4. Messages are passed in a message object that stores the name of the sender and the simple probability data that is contained in a message. The core object, the network itself, is a collection of nodes with a particular structure that knows how to print and solve itself.
A separate set of classes is dedicated to SPICE3 netlist generation. These include a transistor class, current mirror class, and differential pair class, which are incorporated into a SPICE node class, which is extended to be a SPICE function or a SPICE variable, similar to the nodes in the solver's core. The task of generating a SPICE netlist that represents a network is a simple one-to-one mapping from the objects that define the network to the objects that generate SPICE code.
The interface to the tool is menu-based. Users can select from several different menus, each of which contains various commands. In a typical interaction with the tool, a user would create an XML file based on the DTD provided, start the tool, and use the file menu to load the XML file. They would then be presented with a variety of options including the ability to modify the structure of the network and print out various parts of it. Once the structure and distributions were correct, they could use the solve menu to observe one or more variables to be of some value, and then solve the network. A final step would be to have the software emit a SPICE3 netlist that could be used to simulate the network as an analog CMOS circuit.