Joachim Schlosser: Development and Verification of fast C/C++ Simulation Models for the Star12 Microcontroller
This section wants to give a brief impression of the Motorola Star12 V1.5 Core; therefore the major features were summarized from [Mot00].
The Star12 is a 16-bit processing core that uses the 68HC12 instruction set architecture, allowing 68HC11 source code directly as assembler input for the Star12 CPU. The core contains sub-blocks for interrupt (INT), module-mapping control (MMC), multiplexed external bus interface (MEBI), breakpoint (BKP) and background debug mode (BDM). The core is structured to be easily integrated into SoC designs. The Star12 allows instructions with odd byte counts, including many single-byte instructions for more efficient use of program memory space. A three-stage instruction queue buffers program information for more efficient CPU execution.
The set of indexed addressing capabilities include:
The Star12 core provides 2 to 122 I bit maskable interrupt vectors, 1 X bit maskable interrupt vector, 2 nonmaskable CPU interrupt vectors and 3 reset vectors, and a register may configure the highest priority I bit maskable interrupt.
There is on-chip memory and peripheral block interfacing with internal memory expansion capability and external data chip select, additionally configurable system memory and mapping options. For connection to the rest of the SoC, it provides an external bus interface (8-bit or 16-bit, multiplexed or non-multiplexed).
For debugging, there is hardware breakpoint support for forced or tagged breakpoints with two modes of operation: either dual address mode to match on either of two addresses, or full breakpoint mode to match on address and data combination. A single-wire background debug system is implemented in on-chip hardware, and additionally there exists a secured mode of operation.
The Integrated Peripherals (IP) Bus and its interface, defined by the Motorola Semiconductor Reuse Standards (MSRS), connect the Star12 core to the system peripherals. The core communicates with the on-chip memory blocks either directly through the Core interface signals or via the STAR bus.
Also available special features of the Star12 core were not used for model implementation.
The Barracuda Integration Platform is a package of models developed by a Motorola division named Global Software Group (GSG). The platform is a pilot project for the Full Chip Simulation initiative; it also serves as a starting point for development of a Barracuda full chip simulator. Some of the models are developed for reuse in other simulators. Especially interesting for the thesis project is the usage as the base platform.
The Barracuda Integration Platform consists of a Star12 ISS, accompanied by a Star12 integration model, which connects the core to Octopus, referring to [WLvH01]. This is necessary because the CPU model was originally not developed for usage with Octopus. The integration model is designed especially for the usage with the specific debugger for the processor. This was a major drawback when trying to apply another simulator interface adaptation layer to Octopus, because the integration model occupies the simulator interface of Octopus and so prevents it from attaching another one. This was the reason, why no CPU could be used for testing the Simulink interface, as explained in section 3.2 on page 221. Of course the integration model itself has a reason: The Star12 ISS serves as the master of the simulation by the means it controls the simulation loop. As Octopus can only “serve” to one master, it is controlled by the integration model, which itself provides the interface for the debugger.
Several Octopus models build the second part of the Barracuda Integration Platform. To support the programmable memory map, the Barracuda has, the Module Map Control model can decode the 16-bit Star12 addresses into the Octopus address space, and additionally recognize misaligned transactions. It implements the actual memory mapping and a configurable module size.
The IP bus interface (IPBI) model implements features like input ports for peripheral interrupts and the real-time interrupt, conversion from high-active into low-active interrupts, packaging information into a token and sending it to the interrupt controller.
The clock and reset generator (CRG) model implements a COP watchdog and the real time interrupt generator, but no clock signals, not the start-up counter nor the oscillator and crystal monitor.
The generic memory model is used to realize EEPROM and Flash memory arrays, extending the capabilities of the Octopus memory model. The two memories are split up into two models each: the actual memory array, and an associated controller. A command token, generated by the controller, is able to either program, erase or retrieve cells of the array. The controller checks the alignment and the access size of the program command and cares about timing specifications. Details of the Flash and EEPROM models can be omitted here.
For the interrupt controller model there is not much to say, it implements all features mentioned in the specification.
As an interesting feature, the Barracuda platform supports banked memory, which are pages within the Flash memory. In the real hardware, the software cannot access the memory banks directly, the PPAGE register in the Star12 CPU must be used to switch between the different memory banks. The platform exactly models this behavior, in order to grant that in the software engineering process, the generated applications in linked form can directly be loaded to the target hardware without changing anything in memory access.