Odyssey Description

In Odyssey, framework responsibilities are handled in a layered manner, as shown in Figure 1. The bottom layer consists of the raw tools and data files "resources" used in design. Above this is the Cyclops Resource Management layer, which uses encapsulation to provide a uniform view of resources to the higher layers. The Hercules Task Management layer builds on this abstraction to provide services for creating and executing CAD tasks, such as "synthesize a netlist and estimate performance using circuit simulation." The designer can interact directly with Hercules to manage tasks, or Hercules can provide its services to the Minerva Design Process Management layer. The designer gives problem specifications and goals to Minerva, and Minerva helps the designer break the problem into sub-problems, map sub-problems onto tasks, and iterate as necessary.

Figure 1: Abstraction levels of Design Management Services in Odyssey

Cyclops

Cyclops maintains a database which maps abstract "design entities" onto concrete resources. This mapping may be as simple as the name of a data file, or as complex as all the information needed to run a tool. In some cases, the database itself can hold the resource data (e.g., a set of tool parameters), in which case the mapping is trivial.

Hercules

The designer interacts with the Hercules User Interface to build a task tree which shows the dependencies among the tools and data of the task. An example is shown in Figure 2. In this task, a performance entity depends on a circuit simulator entity and a synthesized netlist entity, and the synthesized netlist entity depends on a specification entity and a synthesizer entity.

Hercules maintains its own database of design entities, to keep track of design history. The entities are organized in a class hierarchy (e.g., the class of circuit simulators). A task schema represents all the dependencies among all the classes. Hercules uses the schema to guide the designer in task tree construction. A simple schema, suitable for creating the task above, is shown in Figure 3. In this schema, the netlist entity (base) class is specialized into two sub-classes, synthesized netlist and edited netlist, to capture the two methods for constructing netlists. The edited netlist entity has an optional data dependence on the netlist class, indicating that the netlist editor can either be used to create a new netlist or to edit an existing netlist. Note that that the netlist editor does not care how the netlist was created, so the dependence is on netlist. This is true in general -- dependencies are always on base classes.

Minerva

The designer interacts with the Minerva User Interface to define and solve design problems. The designer only has to deal with the creative aspects of design, being able to explore different alternatives in the solution of these problems. Minerva works in the so-called problem-solving cycle. With Minerva, the designer formulates a problem, and then Minerva can help by providing information about ways to solve it (tools to be used and order to be followed, for example). The designer can then choose to execute one or several of these approaches. When the execution finishes, the designer may reject the result, in which case he/she can backtrack to any previous design state. In any case, another design problem may be selected right after that, which restarts the cycle.

Minerva can also manage complex design constraints relating multiple domains within a large design team. This is achieved through an automated and fully configurable methodology for constraint generation, propagation, and violation notification.