Back

Home Our Services Programming Tools Business Unit Debugger / Simulator Development of peripheral simulation modules

Development of peripheral simulation modules

• Requirements
For one of our Japanese customers required simulation of the peripheral modules of their RISC based core. The peripheral modules should be developed as a DLL which will be dynamically loaded by the IDE. Customer provided us the interface specification for communication between IDE simulator and the peripheral simulation modules. The input / output ports or pins are implemented as virtual registers on the simulation module.

We had so far developed simulation for the following peripheral devices


• Analog to digital converter
• I2C Bus Interface
• Serial Peripheral Interface
• Watchdog Timer
• Serial Communication Interface
• Timer modules

The simulation modules for the above peripheral devices were developed one at a time. The simulation modules were developed for different processors based on the requirement.

• Challenges
• Mapping hardware behavior to software implementation
• Understanding the typical operations of the peripheral modules, it timing diagrams and operating states
• Testing the different modes and states of the peripheral module


• Solution
• Environment

OS	Windows
Language/Platform	C++ MFC based DLL
Tools	CPPUnit for unit tests Numega True Coverage for calculating the test coverage Numega bounds checker to test for memory leaks / memory errors

• Description

The team first concentrated on developing the interface for communication with IDE simulator based on interface specification provided by the customer. The team then created an object oriented design. The modules were designed to have loose coupling and tight cohesion. Abstraction was used make the design suitable for different peripheral devices. The design was gradually refined and it had the following 3 modules:



• Interface module (Reusable)
• Common utility module (Reusable)
• Custom peripheral specific module

Having completed the common reusable portion of the simulation module, the team then focused on simulation of peripheral's features. To develop a simulation module for a peripheral, the prerequisite is to first understand the hardware behavior. The team first studied the typical operations of the simulation module from internet. This provides a first hand knowledge of the peripheral to be simulated. Then the team read the hardware manual of the peripheral device to understand its states, registers, flags, operating modes etc. For each of the peripheral to be simulated, the team prepared a detailed document which covered the following:

• Different states of the peripherals and when the state transition occurs
• Flow for different operating modes
• Conditions for setting / resetting of flags

The above details are sent for customer's approval. This helped us understand the behavior of peripherals unambiguously. It also helped us identify cases where the description in the hardware manual was incorrect.

The project was carried out incrementally. Each of the peripheral simulation modules were delivered in 3 increments. The features of the peripheral simulation to be implemented in each increment were decided based on usage. More common features are placed in initial increments and special features are placed in later increments.

The challenge here was to map hardware behavior to software implementations. Some peripherals to be simulated like ADC took analog input. Most of the peripherals had multiple internal units which operate in parallel. The team discussed implementation for such cases and then checked with the customer on whether the understanding was correct.

During development, unit tests are written using CPPUnit framework. Testing for memory leaks / memory errors were done using Numega bounds checker tool.

To test the simulation module, the team developed a testing framework based on the architecture for which the simulation modules were developed. The testing framework provided handlers to test each of the specific cases and to test the result. The handlers were interrupt service routines. So testing each condition required 2 handlers one to induce a specific condition and one to check the expected results after the operation is complete. The testing framework ensures that the tests were reusable. The testing framework was used for testing all the simulation modules we had developed so far. Test coverage is done using Numega True coverage tool.

Object oriented design and code / test reusability ensured that we saved considerable time on development. All the peripheral simulation modules were delivered on planned schedule. The customer has acknowledged that they are happy with the peripheral simulation modules delivered so far.

Back