🚀 go-pugleaf

In article <1992Nov10.042818.11581@latcs1.lat.oz.au> baragry@latcs1.lat.OZ.AU
(Jason M Baragry) writes:
>[...]
>And alot of people have put in their point of view (including me). In my
>research I have briefly compared SE and EE components however with the number
>of comparisions being made in recent articles I believe it would be a good 
>idea to start a discussion about what people think are the differences
>between SE and EE components. (just to ensure these analogies are reasonable)
>[...]
>	The sort of differences I've noted already include:
>
>- Implementation types: SE has many implementation types (programming languages)
>	which support particular design paradigms. ie: OO design and C++, 
>	rule based design and prolog, etc.
>	EE has only a single SET (ananlog & digital could be considered sep.
>	sets but can be easily connected) of components, which leads to 
>	a single design paradigm (modular).

There is more to electronic design besides designing the electrical
characteristics of the circuit.  There is also the technology used to
construct the circuit, e.g. breadboards, printed circuits, point-to-point
wiring, IC's, etc.  These are not necessarily modular, and include some
aspects of mechanical engineering.

In any case, there are a number of systems in which electronic designers
may design and test their systems.  In the digital world, there are lots
of modelling systems that model a circuit at different levels, e.g. the
gate and cell levels.  There are also transistor models that can be used
in both analog and digital circuits.

In the software world, there are already design tools (or at least
methodologies) supporting OO, ER, and procedural models.

>- Complex Interconnections: SE modules can pass complex abstract data types
>	and can use call be reference and call by value methods. EE modules
>	do not invoke other modules, all modules operate constantly but the
>	inputs which trigger the outputs are simply changed. In addition,
>	the inputs are simple signals not complex data types.

Inputs and outputs do have more complex relationships:  Power supply
voltages, inductive and capacitive loading, impedance of the interconnect,
maximum safe source and sink currents, maximum safe input and output
voltages, maximum rise and fall times, slew rates, delay and hold times,
etc.  The complexity of the interfaces can be quite complex, though that
complexity might somehow be of a different nature than that of software
interfaces.

EE modules pass complex signals.  EE modules have inputs, and outputs that
drive the inputs of other modules.  Propogation delays cause the effects of
each module to become visible at different times, often with undesireable side
effects.  There are other temporal relationships between signals (e.g.
RAS and CAS signals in DRAMs, the relationship between inputs and outputs
of phase comparators in phase locked loops, etc.).

Electrical design and simulator tools are able to somehow model all of these
things, and are able to present some representation of the behavior of a
circuit.  Software simulators are also able to model the inputs and outputs
of functions, the effects on registers and memory, and so on, and present
some representation of the behavior of a program.

>- Predefied components: EE modules are manufactured and mass produced.
>	It is much simpler to purchase a chip with the required functionality
>	than it is to design and construct the chip again. Components which
>	use these chips evolve and develop their own particular functionality,
>	which can also be mass produced on a single chip, etc.

SE modules are gathered into libraries and distributed en-masse.  It is
much simpler to link with a library than to implement similar or equivalent
functionality again.  Components which use these libraries can evolve and
develop their own particular functionality, which can also be gathered into
libraries and distributed.

Chips and libraries (whether distributed in source or binary form) look a lot
alike in this respect, if the libraries are never modified.

>- Families of components: EE components exist in families where the
>	functionality is similar however the implementation characteristics
>	differ. Eg: speed, gain, etc. This helps the designer think in terms
>	of the functionality of the family while designing and then choose the
>	required member during the implementation.

SE components exist in families where the functionality is similar however
the implementation and performance characteristics differ.  E.g.:  speed,
scalability, whether or not range queries can be performed, language bindings,
etc.  This helps the designer think in terms of the functionality of the
family while designing and then choose the required member during the
implementation.

Also, tying in with the implementation types above, the designer may choose
the semiconductor technology that is used when designing circuits:  Selenium
or silicon?  If silicon, then NMOS, PMOS, CMOS, ECL, I^2L (I-squared-L), SOS,
TTL, hybrids, or others?  Each have their advantages and disadvantages.

SE components can be selected based upon capabilities and technology in the
same way that EE components can.

>- Malleability of Components: EE components are mass produced on chips which 
>	are easy (sometimes) to integrate with other components. It is therefore
>	advantageous in terms of money, time, and size to utilize these chips
>	instead of re-inventing the component. Although SE re-use is advantageous
>	in terms of time saved, the components are constructed from words which
>	do not need to be purchased from a manufacturer and the physical size
>	of these 'words' is not an issue. Additionally, it is much easier
>	to take existing code and modify it with a text editor than it is to
>	rip the top of a chip and change a resitor value! 
>	Using existing components is imperative in EE while it is merely
>	advantageous in SE. Consequently, programmers find it easier to modify
>	an existing component or write a new one to meet the design rather
>	than slightly modifying the design to accommodate the component as
>	engineers do.

Good points here that I can't expand upon, other than to note that this
confirms what we already know:  It's easy to change source code to suit
our immediate needs.  Often it's easier to change the libraries than to
wrap them for equivalent functionality.  This sort of flexibility is almost
impossible with circuits unless the designer takes action to provide a way
to tune a circuit.

Although a circuit can't be tuned by prying off the lid of an IC and changing
a resistor value, but many circuits can be tuned.  Designers often provide
special pins that can be used for this; connections for piezoelectric crystals
are an example, as are protection circuits in voltage regulators that limit
the amount of current that can be delivered.  I suggest that software
components can be similarly tuned, via function parameters or structures
that are intended for that purpose, without changing code.

>	Are there any other differences / similarities between SE and traditional
>engineering disciplines that people can think of ? 

One other.  Suppose we consider the "output" of a function to be anything that
is processed by that function that is visible to the outside (global variables
and the return value are typical examples of this).  Well, invocations of
functions are also visible to the outside, in the sense that the called
functions can see them.  Thus, if function fn1 calls function fn2, then the
parameters passed to fn2 from fn1 can be considered to be outputs of fn1.

If we consider each static reference to a function as an instance of that
function, then suddenly we might be able to draw schematic diagrams of our
programs.  Recursive functions look like feedback loops in the schematic.  So
might iteration in some circumstances.  (Well, we knew that recursion and
iteration were equivalent, didn't we?)  Selectors look like, well, selectors.
Variables look like registers.  Tests look like comparators.

Simple schematics would then model low-level functions.  Cell libraries
would model higher-level functions.  And maybe some of these tools that
have been developed for electrical engineering can work for software as
well if code generators are added to the schematic capture and simulation
tools.

I think this type of modelling can work well for procedural and functional
designs.  If functions become messages and the objects receiving the
messages are included as inputs of the messages, then this might work for
object oriented designs as well.  I'd be interested to hear other people's
thoughts about how dynamic storage could be modeled, as that could be a
severe weakness in this scheme.
-- 
Paul M. Sander  (408) 379-7000  |  "If everything were easy, where would be
HaL Computer Systems, Inc.      |   the challenge?"
1315 Dell Avenue                |
Campbell, CA  95008  USA        |