Design of microprocessor-based systems: a knowledge-based approach

Please download to get full document.

View again

of 9
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Document Description
Design of microprocessor-based systems: a knowledge-based approach
Document Share
Document Tags
Document Transcript
  352 IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS, VOL. 41, NO. 3, JUNE 1994 Design of Micromocessor-Based Systems: A Knowledge-Based Approach Raj S. Mitra, Mukul Kumar nd Anupam Basu, Member, ZEEE Abstract-The widespread use of microprocessors in industrial applications such as process control, data logging, monitoring, etc., demand that the design of such systems be automated. Algorithmic methods are inadequate for this task, as knowledge from several sources need to be combined to produce the resulting design. In this paper we present a knowledge-based approach to the design of such systems, which includes the design of the hardware configuration as well as the application software. The knowledge requirements and the functional modules of the design task are elicited, and practical designs are demonstrated. I. INTRODUCTION ODAY, microprocessors are used in a variety of appli- T ations, from data logging and monitoring to complex process control operations. Although the basic principles for designing such application systems are well understood, no effort has yet been made to automate it. The advantages of automating the design of these application systems are manifold: 1) it will facilitate the quick development of prototypes; 2) it will minimize design errors; 3) detection of design errors will be quicker, and less costly, since the design can be evaluated for correctness (by correctness proofs or simulations); 4) it will facilitate rapid technology transfer to user com- munities. In this paper, we present a general framework for designing microprocessor-based industrial application systems. Since the design process is essentially knowledge and experience inten- sive, we propose a knowledge-based approach [l] to design such systems. Knowledge-based approach to design [2] provides several advantages over the traditional approaches to design. The major advantages are: 1) it is easier to make incremental improvements to the system’s capabilities; 2) it is easier for the system to explain what it is doing and why, thus facilitating the automation of generating the design documentation too; 3) it is easier for a human expert to determine what is incorrect or incomplete about the system’s knowledge and explain how to fix it; Manuscript received October 20, 1992; revised April 19, 1993 and Novem- R. S. Mitra and A Basu are with the Department of Computer Science M. Kumar is with the Department of Electrical Engineering, Indian Institute IEEE Log Number 9400222. ber 8, 1993. Engineering, Indian Institute of Technology, Kharagpur 721302, India. of Technology, Kharagpur-721302, India. 4) it is easier to interactively use a human expert’s abilities; 5) it is possible to design new artifacts by altering the design plans of previously designed similar artifacts [3]. These advantages become more evident in domains where the design process is knowledge-intensive (as opposed to processing-intensive, where efficient heuristics may be for- mulated, as in the design of combinational circuits), and the design and domain knowledge are too flexible to be encoded in an algorithm. Such a domain is the design of microprocessor- based application systems. Pioneering work in the field of knowledge-based design of circuits have been done by Mitchell [3] and Tong [4]. Mitchell’s VEXED works in the domain of TTL pass- transistors, and is based on the philosophy that “design = top-down refinement+constraint propagation” [5]. It decomposes the circuit specifications in a top-down fashion, till it is represented in terms of a set of primitive components, and uses constraint propagation to detect conflicts. Tong’s DONTE automates the selection process with the help of heuristics, and its design philosophy is also more complex than that of VEXED. It performs goal-directed planning, that is, it performs an analysis of the goals and plans the optimum way in which the design should proceed. The design of circuits for microprocessor-based applica- tions differs from the methodologies of VEXED and DONTE because of the following reasons: The design of an application system involves the design of both the hardware configuration and the correspond- ing software. Thus the design process is not just the task of designing circuits, but several interacting tasks have to be integrated together for the complete solution. For example, the application determines the algorithm that has to be implemented, which in turn guides the selection of the hardware components; the selection of specific components and their interface requirements determine the software that has to run on the microprocessor. The design of an application involves not only reasoning about the circuit’s specifications and the available com- ponents, but also involves reasoning about the domain in application. For example, the designs of a tempara- ture controller and speed controller are quite different because of the difference in the application domains. A microprocessor can handle many functions together, by properly sequencing them. Its related components too (e.g., Intel 8155 timer + ports) can handle several functionalities together. This is unlike the one-function dedicated components that are handled by VEXED and 0278-0046/94$04.00 0 1994 IEEE  MITRA et al : DESIGN OF MICROPROCESSOR-BASED SYSTEMS: A KNOWLEDGE-RASED APPROACH ~ 353 DONTE. This involves a different approach to function- to-component instantiation, involving search and opti- mization considerations. The task of designing domain-specific software is similar to that of Barstow [6]. However, his system cannot handle a variety of domains, since that requires some changes in the hardware too. A recent work [7] reports on the development of hardwarelsoftware interfaces for microcomputer-based sys- tems. It accepts the list of required components from the user, and prepares valid interfaces between the microcomputer and the components. However, the user is still burdened with the tasks of developing the algorithm and allocating the necessary components. All microprocessor-based systems have more or less the same architecture (e.g., microprocessor, RAM, ROM, I/O ports, U0 devices); depending on the application, one has to design special interface to the VO devices, and an application software that achieves the desired functionality. Our design methodology takes a functional approach-we view the design of microprocessor-based application systems as the design of a process that requires some hardware equipment and their driving software. Hence, instead of designing the circuit and the device interfaces rightway, we first design the process that would achieve the desired functionality of the application. The functional blocks of this process are then mapped to available components, and their interface and addressing details are resolved. This is followed by the generation of the software (from the specifications generated by the previous stages), and the refinements of the circuit. However, there is no strict sequence among the above stages and may require iterative interactions among them. The objective of optimising the number of chips by using available multi-function chips, also may create a lot of backtracking if not handled properly. We handle these issues by following a strategy of least committment [l], and by doing a global requirement analysis before selecting a chip for instantiation. In this paper we present the system Design Expert (DEX), for designing microprocessor-based application systems. The description deals with the knowledge and functional require- ments of the different stages of design. The methodology is illustrated with an example design of “speed controller of dc motor.” We have applied DEX to design a number of applications; two such designs have been presented in the “Results” section. Finally, we elicit the merits of DEX and its possible extensions. 11. DEX-THE DESIGN EXPERT Designing a micro]processor-based system does not only consist of designing a circuit; it involves the design of a complete process-which runs on a microprocessor and drives several accessory units (sensors and actuators) to perform its function. These sensors and actuators are very much dependent on the particular domain for which the application system has to be designed. Hence, first the design specifications have to be acquired iin a suitable language, followed by the task of designing a slkeletal process, i.e., an algorithm, that would achieve the desired function. The next task specifies the USER Specification Algorithm Architecture Fig. 1 Design steps. hardware requirements and how they interact with the process. This constitutes the design of the system architecture. The next task is to refine the interface details between the various units. The configuration of components and devices impose some constraints on how the software should interact with it. These constraints are then used to refine the algorithm to a greater detail. All the above tasks gradually refine the specifications of the software that would have to run on the microprocessor. These specifications are now transformed into a program in a high-level language, which is then compiled into machine code. Finally, refinements are made to the circuit, for address decoding and in order to remove signal mismatches. The relationship and the overall sequencing of the different tasks is shown in Fig. 1. These individual design tasks are described below: A. SpeciJication Acquisition The functional behavior of complex machines can be de- scribed adequately by the statechart formalism [SI, [9]. Briefly, statecharts are hierarchical flowcharts, with the power to represent orthogonality (parallel processes). It consists of a set of functional states, and the transitions between them, based on external (or internal) conditions and events. For a more elaborate description of statecharts, the reader is requested to refer to [SI, which illustrates the power of statecharts with the help of an example specification of a multi-alarm clock, and [9] for the specification of a complex traffic-light controller. Statecharts specify only the behavior of a complex system, in terms of its functional modules and control paths. In order to use this formalism to describe design specifications of microprocessor-based systems, we have augmented it with device descriptions, data paths and constraint relations. We have chosen the statechart language over other procedural specification languages (e.g., [lo]), because of the intuitive appeal of visual descriptions. Fig. 2 shows a specification for an over-current protector. The system is event (interrupt) driven: when the current overshoots a predefined limit, the system wakes up, waits for a time that is dependent on the value of the current, and checks the current again. If the current level is still beyond the limit value, the circuit is tripped. The theory behind this control logic can be found in [ 111, and its implemention in [ 121. In the figure, parallel processes are surrounded by a dotted boundary (see also Fig. 4, for more examples of parallel processes); within each process only one state can be active at a time. Devices are shown as ovals, and functional modules    354 I I I I I Wait Compare I Lookup Set - value Fig. 2. Specifications for interrupt-driven over-current protector. as rectangles. (Devices have internal processes of their own, which are continuously running, i.e., each device is a parallel process. This is not shown explicitly by dotted boundaries.) Control paths are shown by -, data dependencies are shown by o - where each o refers to the appropriate data window (port) of the respective function, and constraints are shown by -. Thus, the compare-signal produced by the comparator, which is always active, fires the transition to the action-states, and the tripping device affects the current (by tripping). The empty box corresponds to the null-function. Attribute descriptions for the different data items are not shown here. With this specification language, the user can specify a design problem at any desired level of complexity. But for routine design problems, the user has an option to specify only the attributes of a state; these attributes guide the refinement of the state into its actual complex representation. A textual version of such an attributed specification is shown below, for the problem of speed-control of a dc motor. This specification consists of only one state-Maintain. Proportional control is to be done, the motor is to be controlled by varying the armature voltage, which in turn is to be done by changing the phase of the thyristor-controlled rectifier, and the desired speed is given by the user through DIP switches. The ratings of the motor are given as the description of a device. (Fn: Maintain Param: speed of part-1 Control-mode: proportional Category: motor Control-param: armature-voltage Vtype: dc (Part: part-1 IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS, VOL. 41, NO. 3, JUNE 1994 caters to the needs of both naive and expert users. The former can take the advantage of known design attributes, and the latter can specify new design strategies. B. Algorithm Design The problem specifications are given as an attributed control and data flow graph (ACDFG), epresented in the statechart formalism. Here, the attributes are associated with the nodes (states) of the graph. The job of the algorithm design task is to refine this ACDFG to a lower level of abstraction, in terms of primitive functions bf’s . A pf is a functional element for which a hardware or a software implementation exists in the knowledgebase. For example, Wait is a pf, since it can be implemented by a delay loop or a timer; AD-Convertor is a pf since it can be implemented by an ADC chip. The refinement of the ACDFG is done by successively applying Transformation Operators on it, till only pf’s are left. Alongwith the stepwise refinement of the ACDFG, a con- straint propagation algorithm is run to transfer constraints along the data-flow arcs of the ACDFG. This is done with a view to gather more details about a function’s input-output signals, in order to guide the selection of the most appro- priate component for instantiation, and to resolve interface mismatches between interacting modules. Fig. 3  shows a partial algorithm generated for the dc-motor specifications given earlier. It first accepts the set value from the switch, computes the tolerance value as a fraction of the set value, feeds starting voltage to the motor, and waits for back-emf to develop. Then, repeatedly it checks the condition: speed = setvalue * hreshold. If this is violated, it generates a proportional control signal. This control signal is limited by an upper bound, so as not to generate too fast a change. For the sake of simplicity, we have not considered fault conditions here (e.g., what happens if the control signal a) s decremented to a negative value?). In a real-life design, these checks have to be present. The major design strategies (rules) used in this example are: Act-mode: Phase-control Ftype: separately excited Set-value: sl Vrange: 220V Tolerance; 5% Srange: 1500 rpm 1 Power: 0.5 HP . (Data: sl ) Descr: User-input (Part: art-2 Source: part-2 Category: DIP-switch Format: binary Size: 8 bits Range: 1000-1500 rpm 1 ) The user enters these specifications, by interacting with a graphical user interface. The system highlights the states whose fields need to be further specified, and the user fills in these fields or refines these states to a greater detail, in terms of substates. Some of these fields have default values; the user has an option to specify them explicitly or accept the system’s default choice. The dual nature of our specification language If the function is to maintain a condition on a world parameter, do: accept the setvalue and the tolerance, setup the condition, then do forever: check the condition, and if found to be false, correct the error; To start a motor, feed initial level of voltage to it, and wait for it to react to the supply; To check a condition z = afb, ompute error: = x- ) and abserror: = abs(error), and check if abserror > b; To perform proportional control, limit the computed error by a threshold, and take control action proportional to the error, by looking up a stored table; If control-parameter is armature-voltage, feed variable armature voltage to the motor armature coil To perform phase-control of voltage, convert from ac- volts by rectifier, and control the rectifier by a pulse signal after proportional delay a) rom zero-crossing point; To measure speed of a rotating body, use a photosensing arrangement coupled to a slotted wheel attached to the rotating body-the number of pulses generated by this arrangement in unit time is the speed.  MITRA et al.: DESIGN OF MICROPROCESSOR-BASED SYSTEMS: A KNOWLEDGE-BASED APPROACH 355 I I I r I I ic III Fig. 3. Partial algorithm generated for speed-control of dc motor. The operations encoded in the last two rules are shown in the statechart formalism, in Fig. 4. These are applied on (Get S) and (Gen V) of Fig. 3, to obtain the final algorithm for the speed controller. The arrows form a partial order among the function nodes; this is converted to a linear order at a later stage. Note that at this stage no specific devices or components have been allocated-this will be done as a part of the next task. After each refinement step, parallel control paths are anal- ysed to detect conflicts in processing requirements. Conflicts are marked for hardware implementation. For example, in the parallel path shown in Fig. 4(a), the Wait module has to be implemented by a timer hardware because otherwise it will take up most of the processing time of the microprocessor. The Counter and Wait of Fig. 4(b) do not pose such stringent constraints-they may be merged and implemented by soft- ware, but a hardware timer, if available, is preferred for the Counter. C. Architecture Design The input to this task is the ACDFG of the pf’s generated by the algorithm design task, and its outputs are the Com- ponent Allocation and Address Allocation Tables, indicating the configuration of hardware components in the system. This task consists of three subtasks. In the first subtask, all the architecture requirements from the ACDFG are collected and a summary report is prepared specifying the architectural pf’s, along with their number, and the constraints imposed on them. I Back I I J - Rect. r 1 Compute c/(n+t.) &I I L ________ (b) Fig. 4. Refinements for some functions of Fig. 3. This collection of all requirements is necessary to find the optimum way of instantiating the components. For example, if the system requires one counter and less than three ports, it is better to instantiate an Intel 8155 (which has a timer, 256 bytes RAM and three ports) rather than an Intel 8253 (which has three timers). This decision assumes that no redundancy of timers is required for future expandibility of the system, and that the cost of 8155 is less than the combined cost of an 8253 and a ports-chip. For the memory requirements, an estimate of the ROM size is determined by summing the code- size estimates of all the algorithmic pf’s in the ACDFG and the sizes of the lookup tables used; an estimate of RAM size is determined in a similar way from the local scratch area estimates of each pf and the sizes of all explicitly mentioned temporary variables. This part of the task is done procedurally. The second subtask uses a heuristic algorithm that accepts the requirement report and allocates available components to each architectural pf It uses knowledge from the component description schemas to know the functionality of the compo- nents and component compatibility information. The latter is used by this algorithm to decide whether extra components are necessary, such as ports for components whose data lines are not microprocessor compatible. In such cases, this algorithm adds these components to the requirements report. Finally, the third subtask heuristically allocates addresses to each component. The component allocation and address allocation tables for the speed-controlled are summarized in Fig. 5.  The devices listed there are assumed to be available in the device library. D. Interface Design A substantial part of the design of microprocessor-based systems is the design of device interfaces. In our approach, a major part of this interface has already been designed by the earlier tasks-a very specific job has been allotted to each device, and its U0 equirements have been specified. To complete the interface, the device may have to be programmed  356 IKANSALIIUNS UN INUUSIKIAL OLOCIKUNlL> UL. 41, NU JUNE LW Devices: Components: 8085, 8253, 2716, 8155 Component Allocation Wait(Fig. 4a) 8253~T0 Sq.Wv.Gen. 8253 TI Counter 8253~T2 ZCD-event RST7.5 Switch.out 8155-PA Zero Crossing Detector Rectifier (Full-wave, Thyristor-controlled) Isolator (for Thyristor gate) Motor Address Allocation: 2716 Mem 0 ~ 2047 8155: RAM: Mem 2048 - 2303 Ports: IO 8 15 8253: IO 0 ~ 3 Fig. 5. Allocation output for speed-controller. for the specific task, and the appropriate data has to be physically sent to (or, received from) the device. For example, when a counter is to be implemented by a 8253 timer, it is required to send control code to the 8253 control word register (to setup the respective counter in Mode Oj, send initial data (FFFFlc) to the respective timer of the 8253, and input the pulse signal to the CLOCK pin of the respective timer. To obtain the count-data from the counter, the count is latched by sending the appropriate control code to the timer, the time value is read, and is subtracted from the initial data. This is done by the present task, with the help of function component mapping operators. These schemas use information from the component and address allocation tables. In addition, this task also resolves conflicting constraints imposed by the components on the algorithm (developed by the algorithm design task), with the help of transformation operators and function semantics knowledge modules. For example, the precision of a data may be restricted by the data bits supplied by a component, and this precision constraint has to be used to interpret the data properly. This is the case, in the above example, where the set-value of the speed is read from a 8- bit switch, thus limiting its range to 256. Since the allowable maximum speed is 1500 rpm, a precision of 8 rpm is imposed as a constraint. (However, if the user had specified precision greater than 8 rpm, then an additional switch and port would have been added to the design.) E. Software Design During the phase of algorithm design, some pf's of the ACDFG is mapped to the microprocessor. This part serves as the specification for software design. The present task refines these pf's further by: merging parallel paths into a single path, by resolving the partial order and performing live-dead analysis of data allocating the required data locations rewriting the pf's in the syntax of a high-level language This high-level program is later compiled to the machine code of the selected microprocessor. The reasons for not generating the machine code directly are: 1) We can generate the software independent of the de- tails of the target machine (e.g., 8085, 68000, etc) and make use of the compilers that are available for these machines. 2) We need not worry about program optimizations (e.g., optimum usage of available registers), since these are handled by the compilers. (C). /* Do the following for the CDFGs of Main Prograrn, and all Interrupt Scrv~ccs I /* Resolve Partial Order in CDFG '/ 1) Reset order-queue, reset stack All nodes are marked NIL , and are assigned an inralid queue-address n := node pointed to by START painter 2) Do forever: 3) If there exists an unmarked node, m. such that there exists a dependrncy (data or control) lrom m to n in the CDFG [i.e. In - or m OJO n , and the arc is not labelled Backarc': 4) 5 Push (n,.B.ACK ) into stack 6) If addr[n] is unassigned, and dependency is by data arc: addrjn] := present position in queue n := select one of there m-nodes, giving first priority to data~arci Insert n in queue Mark n as USED . n CDFG If there exists some unmarked node, m, such that II - n Else 1 end of a backward path, or start of a forward path '/ 7) 8) If there are more than one such m's. n := select one of these rn~riodes Elseif stacktop contains a BACK node: n := pop stack Elsc 1 end of a forward path, try another / If stack empty: Goto 16 Purh(n,'.FORWARD ) into stack 9) 11) 10) 12) 13) 14) Else n := stacklop /* mark should be FOR\VARD */ If there does not exist any urnmarked node, m, aiicli that n : Pop stack Goto 12 15) 16) /* Produce C-code / 17) 18) 19 Else n := sclect one of these m~nodes Adjust entry arcs, from addr artay Replace each node n order-queue, by its software template Remove unnecessary GOTO and assignment statements from code Attach program heders: data declarations and include-files Fig. 6. Algorithm for software generation. Conversion of the pf's into C-code is done by replacing the pf's by C-language templates, available in the Programming Schemas knowledge-base. After the initial program is gener- ated, a peep-hole optimization [ 131 is done, to remove obvious redundancies in the code. The algorithm for generating the software is summarised in Fig. 6, and the program generated for the dc-motor example is shown in Fig. 7.  F. Circuit Design This task performs the interfacing between the allocated components. This includes adding extra circuitry for address decoding, transforming mismatching signals, and connecting the pins of the components. This task is achieved by using the component description schemas and interfacing operators available in the component knowledge-base. These schemas are applied iteratively, till all the pins of the chips are connected consistently, that is, without violating the interface constraints with its neighbors. The extra components that have been added in the example design are ALE, address decoder, and free-wheeling diode. In the architecture design task, estimates of code sizes have been used to determine ROM and RAM sizes. After the actual design of the software, some of the allocated memory chips may be found to be redundant. These are removed by this task. The overall architecture of DEX is shown in Fig. 8, where the data structure and knowledge bases are shown as rect- angles and the processes are shown as ellipses. To design an application system, the user provides the specifications through the user interface. This process converts the statechart figures into an equivalent textual representation, expressed in terms of goals to be solved, and stores them in the partial design data structure. Now, each of the above mentioned tasks are invoked in tum, which take some input from the
Search Related
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks