© 1997 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE. By choosing to view this document, you agree to all provisions of the copyright laws protecting it.
[ Index | Introduction | Expositive | Demonstrative | Interactive | Practical | Conclusion | References ]
Continuing the methodological classification of learning tools, that represents the skeleton of this paper, it is now time to make clear what we mean with the term "practical" applied to a pedagogical methodology and which are the tools that apply such methodology . The learning tools presented so far are targeted to foster the understanding of concept or to acquire some operational capability. They process, therefore, contents that their developers have built within the tools themselves. The tools belonging to our practical methodology, instead, are designed to process, within a specific field, data that the learner has entered .
In a course of digital electronics, beyond the ability of understanding concepts, methodologies and existing implementations, it is necessary to acquire design capabilities. Conceiving circuits and systems is generally more difficult than understanding and analyzing them and it requires different and complementary skills. It is also difficult to teach, because the solution to a design problem is not unique, and consequently the presentation of just one possible solution is somewhat misleading, while a thorough investigation of many different design alternatives is too time-consuming when carried out only with paper and pencil .
The situation demands the services of a kind of tools that allow the students to process their own data with the final target of designing and testing a system . The use of professional simulators for this process is not recommended because students cannot have the skills and the frame of mind of the accomplished digital designer, for whom the professional tools are made.
We have developed a set of tools to support this approach. They are divided in two groups: local tools and general purpose tools. To the first group belong simple software applications with a limited scope: typical examples are the code-converters, the memory maps generator, tools for Boolean function synthesis and minimization and so on. Local tools are usually developed using the hypertext authoring environment. The second group is composed of three general purpose simulators (digital networks, state machines and microprocessor). They are custom-built applications with approximately the same characteristics of professional CAD tools for electronics, except that their design has been carried out with a strong pedagogical orientation . Their construction has required different software instruments and programming skills.
A typical local tool
(Fig. 16) performs the conversion from a digital number
to the corresponding binary. In the automatic mode it works as a tool:
when the user needs a conversion, may do so by typing the number in the
input box (white in the figure) and clicking on the proper button. In the
manual mode the tool assumes a pedagogical value (interactive methodology)
because all the calculations necessary for the conversion must be executed
by the learner, under the control of the tool (working example).
Another local tool (Fig. 17) has been designed to help the students practicing in the field of memory systems. It provides, as output, the memory map, the chip connections and the decoding circuit of a microcomputer memory system. It takes, as input, the amount and type of the required memory and the size of available chips (working example).
In this paragraph we provide a short description of the three simulators. Given their relative complexity, it is beyond the purpose of this paper to allow the reader to play with working examples, as we did with the learning tools presented before. We plan to do so in another paper, dedicated specifically to the general-purpose tools.
The Digital Circuit
Simulator (DCS) appears to the user as a digital circuits editor (Fig.18),
with the possibility of choosing components from a function library and
to interconnect them with wires. DCS does not reproduce, as many commercial
educational simulators do, the "laboratory metaphor". Real laboratory
instruments are too complicated and distracting for a beginner student.
It is simpler to show a waveform as a timing diagram instead of reproducing
the screen of an oscilloscope to be controlled by a virtual panel full
of knobs . A novel feature of the tool
is the provision to operate at different levels of user competence. As
an example, the number and complexity of the available components are functions
of the level chosen.
The student interacts with the circuit under simulation by flipping the input switches, running the clock generators and observing the resulting changes. An output window shows the timing diagrams of input, output and clock signals. The simulator has two modes of operation: "run" and "step". In the "run" mode the signals are visualized as flowing timing waveforms. In the "step" mode the simulation proceeds by events, to observe in details the circuit behavior. Such mode of operation is especially useful for troubleshooting a network just designed. The digital networks, and the waveforms obtained by simulation, can be stored and used for future sessions, or printed.
In the case of anomalous circuit behavior (such as iteration of unknown states or uncertainty of the final state) the simulator warns the user with messages whose content is function of the competence level described above.
The Finite State Machine
simulator speeds up considerably the process of verifying the design of
an ASM-based FSM. Three main integrated modules compose the FSM simulator:
the graphic editor, the logic simulator and the map synthesizer .
The editor allows the graphical construction of the FSM diagram, according to the rules of the ASM method. In this phase the student is assisted by a toolbox containing the drawing tools, and a window showing the properties of the selected objects. ASM charts are constructed by using the mouse and toolbox’s buttons to insert and to interconnect the appropriate blocks, captions and comments. The properties of the objects inserted in the diagram are defined, examined and modified by a window which content is context-sensitive. A syntactic and semantic corrector identifies the most common mistakes, such as diagram inconsistency, duplication of names and codes, and insufficient number of state variables.
The logic simulator generates the timing waveforms of the FSM state and output variables directly from the analysis of the ASM chart. Time tracing of input, state and output variables takes places in a dedicated window. In this window the student can interact, step by step, with the FSM time evolution by clicking on buttons corresponding to the machine inputs. At the same time, the student can observe the current state involved and the path to the next one, highlighted in the window containing the ASM chart. The resulting effect is of a visual animation of the machine. It is worth to note that this tool, allowing the preliminary simulation of the ASM chart before going to the synthesis, presents the logic of the state sequence without the complication of the network synthesis, as it would be the case using a professional digital simulator.
The last module, the logic synthesizer, provides automatically the next state and output Karnaugh maps from the FSM diagrams. Fig. 19 presents three windows of the Finite State Machine simulator: the state diagram editor with its toolbar (left), the simulation presented as a timing diagram (bottom-right) and the synthesis (top-right).
The microprocessor emulator
(EMUZ80) is a tool to write and run programs for the Z80 microprocessor
(the one presented in the course) . The
emulator places itself between an assembly Z80 program and the computer
under which it runs, by translating the assembly language program into
a code executable by the host computer and running it. For the sake of
simplicity, the microprocessor is initially presented to the learner
in a reduced form (only a subset of its architecture is
used) and the emulator can be successively configured to represent the
complete microprocessor structure using a menu command. Another pedagogical
aspect is the emulation of the memory, that allows students to use properly
ROM (Read Only Memory) and RAM (Random Access Memory) present in the system.
In a professional emulator (as well as in a real system!), programming
or memory allocation errors usually produce system crashes that cannot
be easily understood by the beginner student. Our emulator provides a protection
from most of this kind of errors by inhibiting programs to produce the
operations that would be fatal in a real system: it supplies warning and
information when such errors occur. For example, unlike professional emulators,
the emulator warns the learner when attempting to read a RAM memory location
that has not been previously initialized.
The emulator provides the following functions: program editing, assembling of mnemonic instructions into machine code, code loading in the emulated memory, execution of the code. Because only the first and the last function must be controlled by the user, the intermediate phases are carried out by the emulator in a transparent mode. Program execution may be continuos or step-by-step, with the possibility of setting breakpoints and inputting manually the contents of registers and memory locations (Fig. 20). A complete hypertextual on-line help completes the emulator.
Fig. 16. A decimal-to-binary conversion tool.
Fig. 17. A screen-shot of a tool to build memory systems.
Fig.18. The Digital Circuit Simulator (DCS) with a circuit under simulation and the output window.
Fig. 19. The Finite State Machine simulator: the state diagram editor and its toolbar (left),
the simulation (bottom-right) and the synthesis (top-right).
Fig. 20. The emulator, executing a program in Z80 Assembler, has reached a breakpoint.