Multi-Core Semantics on Simulator

Multi Core Semantics on Simulator

 

The Code composer studio v4 supports s number of multi-core simulator configuration. TCI6487, C6472 are to name a few.

For a multi-core simulator configuration, the CCS v4 IDE provides an per-core view to the user. A per-core view contains the disassembly window, register-window, memory window etc.

This document helps user to understand few multi-core related semantics and the simulator behavior in the presence of them. this document contains the following 3 sections.

1. Debugger commands and properties
2. Simulator semantics
3. FAQ

---

 

Debugger Commands and Properties

Debugger Commands

The Code composer Studio IDE provides the following commands to control the simulation execution.

1. Target Run
2. Target Halt

Target Run: The simulator starts executing the loaded program when this command is issued. The simulator will continue executing the loaded program until one of the following occurs a) User issues a 'Target Halt' command b) The loaded program reached the end of execution c) The simulator encounter an Instruction breakpoint supplied by the user. The Target Run command is, typically, issued to a CPU core. In single-core configuration, the target run is issued to the only core. In multi-core configuration, the target run can be issued to a particular core, or a selected set of cores or to all the cores.

Target Halt: The simulator stops executing the loaded program when this command is issued. The simulator should be 'running' for the user to issue a 'Target Halt' command. The Target halt command is, typically, issued to a CPU core. In single-core configuration, the target halt is issued to the only core. In multi-core configuration, the target halt can be issued to a particular core, or a selected set of cores or to all the cores.

Debugger Execution Modes

For a multi-core simulator configuration, user may choose to run all or few of the cores together. Based on the user selection, the IDE supports the following execution modes

1. Synchronous Execution Mode
2. Asynchronous Execution Mode

Synchronous Execution Mode: In Synchronous execution mode, all the CPU core's in the multi-core simulator configuration are run in a lock-step fashion. In Code composer studio v4, the Synchronous execution run can be done in 2 ways

1. Enable the 'Synchronous mode execution enable' property and issue a debugger run command
2. Select all the cores in the system and issue a debugger run command

Asynchronous Execution Mode In asynchronous execution mode, the user chosen cores (one or more, but not all) CPU cores in the multi-core simulator configuration are run in a lock-step fashion. In Code composer studio v4, the asynchronous execution run can be done in the following way

1. Select the desired cores in the system and issue a debugger run command. The 'Synchronous mode execution enable' property should be disabled in asynchronous execution mode.

Debugger Properties

User can set the following properties in the Code composer Studio IDE to control the simulation execution

1. Global Breakpoint Enable
2. Synchronous Mode Execution Enable

Global Breakpoint Enable: Global-breakpoint enable is a property selected by the user to convey the fact that all the ‘running core’ will halt when one of them halts. A running core might halt as a result of occurrence of one of the following a) User issues a 'Target Halt' command b) The loaded program reached the end of execution c) The simulator encounter an Instruction breakpoint supplied by the user d) an error occurred in the simulation

Synchronous Mode Execution Enable 'Synchronous mode execution enable' is a property selected by the user to convey the fact that any Debugger Execution commands are to be treated as synchronous mode execution.

The following picture highlights the Debugger commands (Run, Halt) and properties (Enable Global breakpoint, Enable Synchronous mode) as seen in the Code Composer Studio v4

Note: For more detail on multi-core debugger check the wiki link

---

Simulator Semantics

TBD

---

Multi-core debugging FAQs

1. Q: The CPU code misses few interrupts when there are printf statements in the ISR. The CPU code recieves all the interrupts if the printf are removed.

The CCS v4 IDE applies implicit-breakpoints (to a label C$$IO$$, that is defined in the C6X RTS Library) to handle breakpoints. These implicit breakpoints are hit when printf/scanf/fprintf/fscanf functions are executed. The IDE does a host of memory reads/writes on detecting the implicit breakpoint being hit, without user knowing it. During these operations, the concerned CPU is put in halt-state whereas the other CPU’s and the rest of the system continue to get clocked. This pattern of one CPU halted and others running leads to missed interrupts, when the interrupts are sent to the halted-CPU. Hence you notice that few interrupts to the CPU’s are missed and the test case fails.

This observation is true in the case of the emulator as well. In-fact the observation may me more pronounced in the case of emulator, because the ratio of emulator speed to IDE’s breakpoint handling operation is the higher in the case of emulator.

The recommendation is to avoid printf/scanf/fprintf/fscanf kind of statements during interrupt-sensitive part of your code. You could book-keep the status and print them at the end of your program, instead of printing them in the interrupt-sensitive part of your code.

Please change your application to handle this accordingly.

1. Q:The CPU cores do not halt at the same PC even though the same program is loaded on all cores and a break point is applied on one core with global break points enabled on all cores. 

                      The simulator synchronizes all the cores at a fixed quantum of few 10s of instruction cycles. The core that hits the break point would correctly halt at expected PC while the other running cores would come to halt at their respective quantum boundaries. Hence we see this skew that other cores do not halt at the exact same PC or cycles. The skew as mentioned would be in the range of few 10s of CPU cycles.

                      

---