• Download PDF document containing complete details of D-FOM approach and 8051-Microcontroller design with this approach - 175 Kb

D-FOM Analysis of Microcontroller System (MCU) --

-- a case study to develop confidence in the approach:

A Microcontroller may be defined as an application specific schematic combination of ALU, Memory (RAM/ROM), Data buses and Address buses, I/O ports (Serial/Parallel), and Controls. In fact, Microcontroller is a combination of a microprocessor with I/O ports on a single chip.

In my paper "D-FOM: Yet another OOM", I proposed an Object Oriented Model (OOM) that is supposed to be advantageous in designing and VHDL modeling of such chips. Here, I have taken Designing and VHDL Modeling of a Microcontroller System with D-FOM approach as a case study to develop confidence in the approach. Before that, let's recall the concept of D-FOM.

Components of D-FOM:

1. Actor: Something that uses the system.
2. Use Case: Tells how the system is used.
3. Unified Actor: Actor inside the system.
4. Unified Use Case: Use case for unified Actor.
5. Functional Actor: An actor or unified actor.
6. Functional Use Case: A use case or unified use case.

Steps in D-FOM:

1. First step towards analysis:
   • Find Actors
   • Find Use Cases
   • Find Unified Actors
   • Find Unified Use Cases
   • FUCA
2. Prepare FUCM
3. Iterate FUCM
4. Where to end analysis: A rough idea for beginners.
   • When you get no further module inside.
   • Experience may make an earlier end too.
5. Moving forward towards design: Implementation View (Involve Dependencies)
   • One level of tree at a time and integrate for one level up on the path (Bottom-Up)
   • Unified Actors->Class
   • Functional Use Case->Method
6. Iterate and get generalization
7. Get Packages for similar classes
8. Sequence Analysis and Sequence Diagrams
   • Bottom-Up Strategy: Sequence analysis for leaves (statements)->Sequence analysis of one level up (functions)->Sequence analysis for system (Process)
9. Implementation:
   1. Code for leaf-sequence diagram and make functions
   2. Integrate functions to get one level up in the tree
   3. Integrate to get the system-code
10. Deployment Analysis according to the problem in hand as per traditional approach (not really tough because of new systems, networking technologies, and database concepts).

Summarized list of Advantages:

1. Dependent Class identification reduces confusions.
2. New joining member is expected to start working quickly because he/she needs to study and understand FUCM only.
3. Concentrated error prone area.
4. Approach gives a design equally suitable to be implemented in OOPL and HDL. So is applicable to HDL also.
5. Parallel designing of H/W and its simulator made possible.
6. Automation made possible.
7. Reduced Effort and Resource consumption is expected.

Summarized list of limitations:

1. Need a proper FUCA. FUCM needs to be made with in depth knowledge of the system.
2. Over dependent on FUCM.
3. Is not globally acceptable but depends on nature of problem. May not be good for highly complex architectures. (Complexity means to interdependencies of modules, which may create huge integration problems. But the same is the case in traditional approaches too, so nothing exceptional here.)
4. Experience in the field of the project gives better results.

First Stage Analysis of MCU

In the first stage analysis, the Micro-controller system has been divided into four major parts:

1. Decoder
2. Control Unit
3. Arithmetic Logic Unit
4. Memory - RAM + ROM

There may not be a big requirement to go in details of these right now. Just by this much knowledge, we can proceed for now, and later we will explore the details to design for the system-modules and the system. If we see into the functionality of the system, we can summarize it as follows:

Decoder: decodes the input signal to an instruction bit pattern.

This decoder is not the simple ordinary decoder that takes a single line input and provides selective multiple line output. Rather, it is a complex unit in Micro-controller system that has complete information about the instruction set of Micro-controller. This unit takes an input binary word and gathers all information about this word like, if it is a valid command or not, if it is an instruction from the instruction set of the system, how many data values does it need to be executed? It indicates whether the command operates on one/two/three or no operand, how many other (Next) bytes are to be read for complete instruction, and required data information for its execution etc. Finally, all this information is sent to control unit for appropriate action and functioning for the system.

Control Unit: Controls the Signal and Data flow through the components

The control unit is the heart of any Microprocessor or Microcontroller system. As in a human body, the heart takes the responsibility of circulating the blood in the whole body through nerve web; in the same way, in a Microcontroller, the Control Unit is responsible for circulating the control and data signals throughout the system through buses. The brief functioning of control unit may be summarized as:

The control unit takes the direct input command signal from the command generator and processes it to the decoder. The Decoder converts this signal to an Op-Code and gives it to the control unit with different other information as discussed above. Control unit checks if it is some control-operation or arithmetic/logic operation. Arithmetic/Logic op-code is sent to ALU for operation. Control unit sends a Rd/Wr signal to the memory unit. For the response of a Rd signal, the memory allows Control unit to read a required location, and for Wr signal, some information may be entered in it (Memory access). It reads the data from memory and sends it to ALU where it is operated on. Control unit receives results from ALU which is then stored in memory with a Wr signal. It executes all control and data-transfer operations for the system.

So, the Control unit actually controls the flow of data and control signals in the system.

Arithmetic Logic Unit: Covers all Logical and Mathematical Calculations

This is responsible for all Arithmetic and Logic operations required for the system functioning.

Arithmetic Operations: ADD, ADDC, SUBB, INC, DEC, MUL, DIV.

Logic Operations: ANL (AND), ORL (OR), XRL (XOR), CLR, CPL, RL, RC, RR, RRC, SWAP.

Memory: store information for future use

Memory is the device to store the control and data information about (and for) the system. It is a collection of flip-flops that may be addressed with a number of select-lines called address-bus of the chip. A list of functionalities:

• Checks for Rd/Wr signal
• For a Rd signal, it stores the information on its data-bus on a location indicated by its address-bus status.
• For a Wr signal, it puts the same information (binary signal) on its data-bus as is on the location specified by its address bus.

Table-1 shows the Functional Usecase Analysis of the MCU System (FUCM). Figure-1 shows the Functional Use Case Model for Microcontroller, following which Figure-2 shows D-FOM Class Diagram for it. These analysis and diagrams show the first stage analysis of the system, means contribute to the first iteration of the system design. But this analysis is not directly implementable at this stage. As told earlier, the analysis phase goes top-down way. When we reach an adequate level of abstraction where we are able to implement our design, we start implementation in bottom-up way, taking one level at a time. This first iteration analysis then contributes to integration of the system using its components viz. decoder, ALU, control unit, and memory. The first iteration FUCM then contributes to analyze and implement how different components interact with each other. Not only this, but also this system level FUCA gives an idea of next level FUCA for different components individually as we see while preparing a FUCM for decoder unit later in this example.

Table 1: Functional Use Case Analysis of MCU.

Figure 1: FUCM for Microcontroller System.

Figure 2: D-FOM Class Model for Microcontroller System.

(Click on the picture to see enlarged view)

So, this is what we need for our first iteration for analysis of Microcontroller systems. In the next iterations, we will elaborate the subsystems and modules of the same using D-FOM, and will try to go till statement-level where we can implement the system with either OOPS or VHDL as we need without major changes in design. We can see here that, as I specified in my notes, D-FOM works efficiently in a Top-Down manner for a system. Here also, we have started from a top-level abstraction and will move to bottom to statement level.

I will complete implementation of one module with D-FOM to describe the complete process of implementation. Let's take the ‘Decoder’ module for implementation in VHSIC Hardware Description Language (VHDL).

Decoder takes an input from the control unit that is some 8-bit combination of ‘0’ and ‘1’. This unit has the information of structure of all the commands that the system recognizes. As once the control unit gives some 8-bit input to the unit, decoder analyzes as if the input is some valid command for the system or not. If this is not a valid command, the decoder alerts the control unit to give some error code, or alerts the system not to respond for this input. But if the command is a valid one, the decoder looks for its structure and tells the control unit about that.

Here the structure of the command includes the following:

1. What the command is: The decoder tells the control unit the op-code for the input. Decoder tells nothing about the implementation or the operation of the command. It only returns the op-code and not its functionality.
2. How many data bytes needed: The decoder tells the control unit about how many data bytes are required for executing the command and updating the system with the output results. Here again, the decoder tells nothing about how the results are to be calculated or how the system is updated, but only the number of bytes of the data for op-code is told to the control unit. In 8051-specification, a command may need either ‘0’ or ‘1’, a maximum of ‘2’ bytes of data.

Figure-1 shows FUCM for the internal decoder of Microcontroller system as per its specifications, and following Figure-2 shows corresponding D-FOM class analysis of this command decoder of MCU.

Figure 1: Functional Use Case Model for Internal Decoder of MCU System.

It can be noticed here that the above use case analysis is almost a subset of the system level FUCA. From the system level FUCA; we have just pulled out the decoder-FA and its associated FU Cases. Finally, we may add some more use cases or the actors as if required on the basis of our iterations in the analysis process. Here, we have a single functional actor, decoder. Let’s get the class diagram, which will be having only one class Decoder and hence no associations.

Figure 2: D-FOM Class Model for Internal Decoder of MCU System.

Now the functions need to be analyzed in terms of the sequence diagrams. For taking the input, the unit does nothing of efforts but just accepts an input and does not modify it. For this, we may not need to have a special function implementation. So, we may ignore the functional implementation of the method input().

Now, we can make the sequence diagram for each implemental method, if required, to describe its algorithmic sequence of signals. In the in hand case, we can prepare a skeleton in VHDL, using this analysis as follows:

(Note: terms in square-brackets [ ] shown to be replaced by coder team with appropriate values.)

entity decoder 

Now, finally this skeleton-code may be customized as per requirement by the coder team. The final code as we coded comes as follows:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use WORK.definition.all;
--  Uncomment the following lines 

Proceeding Works

In the later proceedings, I will be implementing the other components of the Microcontroller system viz. Memory including internal RAM and ROM, and ALU, and finally, the integrated VHDL Model of the system will be demonstrated.

Reference:

1. Terry Quatrani, Visual Modeling with Rational Rose 2000 and UML, Addison Wesley.
2. James Rumbaugh, Object Oriented Analysis and Design, Prentice Hall, 2002.
3. Martin Fowler, What’s a Model for?
4. Martin Fowler, Who needs an Architect? IEEE Software July/August 2003.
5. Michael A. Ogush, Derek Coleman, Dorothea Beringer, A Template for Documenting Software and Firmware Architectures (Version 1.3, 15-Mar-00).
6. Rational Software, Unified Modeling Language, version 1.1, 1998.