From: gsulliva@enuxha.eas.asu.edu (Glenn A Sullivan)
Subject: Re: Can engineering be automated?
Summary: Is this a formal model of engineering automation
Organization: Arizona State University
Date: Fri, 31 Jul 1992 08:37:04 GMT

In 1983 I began exploring methods for design automation.
I have 30+ years electronics, been paying the bills that way for 20+ years.
In 1982 I began studying Computer Science/Artificial Intelligence, at Arizona
State Univ. In the summer of 1983, I took the proverbial blank piece of paper
(actually the reverse side of a computer listing) and began writing the
"rules" to "design" electronic amplifiers. It became pretty obvious that
THOUSANDS of rules would be needed to handle a broad slice of electronic
design. 

So I have developed non-rule methods to describe design knowledge.


I had success, for a 1986 MSCS, implementing a LISP program intended from the 
start to be extensible, to be an archive, to support redesign by changing the
specs. Generates a design tree, actually numerous trees, but only one is
fully expanded. Each tree node is a "TEMPLATE", that is, something to flesh
out with details. I decided not to use rules, because of the need to provide
hiding of variable names (e.g. several levels of 'voltage-gain'). Thus a
template is intended to be a home for all knowledge about a concept.

At that time, there was one supervisory template, supporting multistage
AC-coupled amplifiers. There are several leaf templates, including
transformers, attenuators, cascode & CE/CC/CB gain stages.
If the design task demands 'power-gain' then ACSS would, non-optimally,
prune the attenuator and the transformer.

The supervisor template MANAGES DESIGN BEHAVIOR by RECOVERING from LOCAL
DESIGN FAILURE. During extensive experimenting with knowledge representation,
I tried having independent expert LISP functions (not templates) guess how much
amplification a template might be able to provide, for a given design task.
But I found this really messy, and was obviously violating the localization
of knowledge. So I decided to demand all the gain from each candidate template,
and let each template prepare a FAILURE REPORT.

Usually local failure did result, due to marginal biasing, or a negative
emitter resistor, or very low input impedance. So the supervisory template
would reduce the demanded gain; this raises the input impedance, (more 
resistance in the emitter, and less Miller capacitance) and 
improves the energy transfer between adjacent stages.

Designing a gain-of-10000 (80 dB) amp for 100KHz to 100MHz, with 4 stages,
took 90+ seconds, on a VAX 11-780 running Berkeley Franz LISP (dynamically
scoped). 

The most fun design, suggested by Dave Hill, was a hifi amp, with phono input
to be amplified, providing 2 watts to an 8 ohm speaker. The synthesis
process failed [not that I expected success] because there were no RULES to
upgrade transistors ( a 2N2222 can't linearly provide 2 watts), and the 
middle stage, out of 3, was very marginally biased. But the circuit would
have been debuggable, and DID SOLVE THE MAJOR CONSTRAINT, that being LOTS
of CURRENT GAIN to interface between the 47000 ohms of a phono pickup and
the 8 ohm speaker. The first and last stages were compound CB-CC, with the
CC portion providing essential buffering. Very pleasing behavior, for a
program.

Note that I did not validate these designs via SPICE, since I did not
have models for such as the MRF901, a 2+GHz device.

At present, I am extending this LISP system, ACSS, Analog Circuit Synthesis
System, to handle RF system and detailed synthesis of Receivers, as part of
focusing on PhD research in design/planning with Dr Rao Kambhampati.

Allen Sullivan		gsulliva@enuxha.eas.asu.edu
Designing RF/video circuits for Go-Video
CS PhD student Arizona State Univ

So is ACSS an object-oriented database?






Newsgroups: sci.engr