Development of simulator debugger for 8-bit CISC processor

Requirements

One of our Japanese customers required an instruction set simulator for CISC processor to test the compiler. The processor already had a development board based debugger. But it was too slow.

So the requirement was to develop an instruction set simulator whose execution speed is better than current development board based debugger. The simulator should also have a GUI interface with basic debug functionalities. The simulator should support batch mode execution so that large volume of compiler test cases could be tested in batch mode. The simulator had to support the following object file formats:

1. IEEE-695
2. Intel Hex
3. Motorola S type

Challenges

• Forming product concept with minimum requirement inputs
• Providing easy to use interfaces/GUI
• Execution performance

Solution

• Environment

  OS	Windows
  Language/Platform	Object oriented design with implementation in C++ GUI using MFC (VC++)
  Development model	Incremental development model
  Quality validation tools	Numega Dev Partner Studio to check for memory errors and memory leaks QAC for static analysis of code

• Features

  • Object File: The following object file formats are supported:
    1. Absolute file (Toshiba original format based on IEEE-695 format)
    2. Intel Hex files (*.h16, *.h20)
    3. Motorola S-Type files (*.s16, *.s24*, *.s32)
  • Disassembly & Instruction Simulation for all the instructions
  • Breakpoints
  • Debug commands
    1. Single stepping
    2. Reload
    3. Restart
    4. Go
    5. Stop
    6. Restart and Go
  • Graphical user-interface
    1. Disassembly window
    2. Memory window
    3. Register window
    4. Output window
    5. Script console window
    6. Symbol window
    7. Breakpoint window
    8. Trace window
  • Script Commands covering all the simulator functionalities

• Description

  Since the requirements given to us were brief, we needed form the specifications by ourselves. So we decided on a prototype development to demonstrate the simulator interfaces and get the feedback from the customer. Based on the feedback from the customer on the prototype, the specifications were formed.

  Initially we had 2 options of whether to develop the application using C++ or Java. Since execution speed was the main objective of the project Java was dropped and the development was carried out in C++. GUI was developed using MFC (VC++).>

  The GUI modules were built as independent reusable modules. This gave a cleaner interface in addition to reusability. Since execution speed was important, the decoding logic for instruction set was design such that instructions are decoded with minimum number of tries.

  Since the simulator required match mode execution, we developed a console window which is similar to a command prompt inside the debugger. The simulator could execute individual commands or take a script file and execute it or execute nested scripts. The simulator could also take the script file from the command-line and save the execution logs as a disk file. This allows automation of the testing process.

  The project had six phases in which features were added to the simulator incrementally. All the deliveries we completed in the planned schedule and the product was delivered in time and to the satisfaction of the customer.