|
|
|
| R2012a Documentation → Embedded Coder | |
Learn more about Embedded Coder |
|
| Contents | Index |
| On this page… |
|---|
Embedded Coder software supports DSP/BIOS features as options when you generate code for your target processor. In the following sections, read more about DSP/BIOS, how the Embedded Coder incorporates DSP/BIOS features into your generated code, and ways to use the real-time operating system (RTOS) features of DSP/BIOS in your applications. Follow these links for more information on specific areas that interest you, or read on for more details.
As a part of the Texas Instruments eXpressDSP™ technology, TI designed DSP/BIOS to include three components:
DSP/BIOS Real-Time Analysis Tools — use these tools within Code Composer Studio IDE to view your program as it executes on the target in real time.
DSP/BIOS Configuration Tool — enables you to add and configure any DSP/BIOS objects that you use to instrument your application. Use this tool to configure interrupt schedules and handlers, set thread priorities, and configure the memory layout on your DSP.
DSP/BIOS Application Program Interface (API) — use C or assembly language functions to access DSP/BIOS functions by calling over 150 API functions. Embedded Coder software uses the API to access DSP/BIOS.
You link these components into your application, directly or indirectly referencing only functions you need for your application to run efficiently and optimally. Only functions that you specifically reference become part of your code base. To avoid adding unused code to your project, the software excludes functions you do not reference. After you add DSP/BIOS functions, the configuration tool helps you disable features you do not need later, optimizing your program for speed and size.
For details about DSP/BIOS and what it can do for your applications, refer to your CCS IDE and DSP/BIOS documentation from Texas Instruments.
When you generate code from your DSP model, you can include DSP/BIOS features provided by Embedded Coder software.
Including DSP/BIOS in your generated project adds the following files to your project:
modelname.tcf — a DSP/BIOS configuration file
modelnamecfg.s62 — contains the DSP/BIOS objects required by your application and the vector table for the hardware interrupts.
modelnamecfg.h62 — the header file for modelnamecfg.s62.
modelnamecfg.h — model configuration header file.
modelnamecfg_c.c — source code for the model.
modelnamecfg.cmd — the linker command file for the project. Adds the required DSP/BIOS libraries and the library RTS6201.lib, or the run-time support library for your target processor.
The executable code and source code you generate when you use the DSP/BIOS option are not the same as the code generated without DSP/BIOS included.
Instead of incorporating the DSP/BIOS files manually, as you would with CCS IDE, the Embedded Coder software starts from your Simulink model and adds the DSP/BIOS files automatically. As it adds the files, the support package:
Configures the DSP/BIOS configuration file for your model needs
Sets up the objects you use to analyze your program while it runs on your target
Handles memory mapping to optimize your code based on the blocks in your model
DSP/BIOS projects all have a file with the extension .tcf. The file contains the DSP/BIOS configuration information for your project, in the form of objects for instrumenting and scheduling tasks in the program code. A DSP/BIOS project can include the following files:
Log (LOG) objects for logging events and messages (replace the *printf statements, for instance)
Statistics (STS) objects for tracking the performance of your code
A clock (CLK) object for configuring the clock on your target, and various memory functions
Hardware and software interrupt (HWI, SWI) objects that control program execution
Other objects you use to meet your needs
Your TI DSP/BIOS documentation can provide all the details about the objects and how to use them. In addition, your installed software from TI includes tutorials to introduce you to using DSP/BIOS in projects.
Not all of the DSP/BIOS objects get used by the code you generate from Embedded Coder software. In the next sections, you learn about which objects the targeting software uses and how. You can still add more objects to your code through CCS IDE.
If you add DSP/BIOS objects beyond those provided by the Embedded Coder, you lose your additions when you regenerate code from your Simulink model.
Memory mapping that takes place in the linker command file now appears in the MEM object in the DSP/BIOS configuration file. Your memory sections, such as the DATA_MEM assignments and definitions, move to the MEM object, as do the memory segments. After completing this conversion, the memory assignment portions of your non-DSP/BIOS linker command file are not required in the linker command file.
In non-DSP/BIOS project, the assembly language file vector.asm in your project defines the hardware interrupt vector table. This file defines which interrupts your project uses and what each one does.
When you use DSP/BIOS, the interrupts defined in the vector table move to the Hardware Interrupt Service Routine Manager in the CCS Configuration Tool. With your interrupts defined as Hardware Interrupts (HWI) in the Configuration Tool, your project does not need vector.asm, so the file does not appear in your DSP/BIOS enabled projects.
After migrating your memory sections, segment, and hardware interrupt vector table to the configuration file, building with the DSP/BIOS option creates a compound linker command file. Because DSP/BIOS allows only one command file per project, and your linker file may comprise command options that did not relocate the DSP/BIOS configuration, Embedded Coder software uses compound command files. Compound command files work to let your project use more than one command file.
By starting your original linker command file with the statement
"-lmodelnamecfg.cmd"
added as the first line in the file, your DSP/BIOS enabled project uses both your original linker command file and the DSP/BIOS command file. You get the features provide by DSP/BIOS as well as the custom command directives you need.
While generating code that includes the DSP/BIOS options is straightforward, changes occur between code that does not include DSP/BIOS and code that does. Two things change when you generate code with DSP/BIOS—files are added and removed from the project in CCS IDE, and DSP/BIOS objects become part of your generated code. With these in place, you can use the DSP/BIOS features in CCS IDE to debug your project, as well as use the profiling option in Embedded Coder software to check the performance of your application running on your target processor.
To include DSP/BIOS when you generate code from a model:
The next two figures show the results of generating code without and with the DSP/BIOS option enabled in the Simulation Parameters dialog.
Example — c6713dskwdnoisf.pjt code Generated Without DSP/BIOS. When you create your project in CCS IDE, the folder structure looks like this.
Example — c6713dskwdnoisf.pjt Code Including DSP/BIOS. If you now create a project that includes DSP/BIOS, the folder structure for your project changes to look like the following figure.
Added File | Description |
|---|---|
modelname.tcf | Contains the DSP/BIOS objects required by your application, and the vector table for the hardware interrupts |
modelnamecfg.s62 | Shows all the included files in your project, the variables, the DSP/BIOS objects, and more in this file generated from the .tcf file |
modelnamecfg.h62 | The header file for modelnamecfg.s62 |
modelnamecfg.h | Model configuration header file |
modelnamecfg_c.c | Source code for the model |
modelnamecfg.cmd | The linker command file for the project. Adds the required DSP/BIOS libraries and the library RTS6201.lib or the run-time support library for your target processor. |
Notice that the new folder includes some new files, shown in the next table.
With DSP/BIOS functions enabled for your project, the following files no longer appear in your project.
Filename | Description |
|---|---|
vectors.asm | Defines the hardware interrupts (HWI) used by interrupt service routines on the processor. This file is removed after all of the hardware interrupts appear in the HWI section of the Configuration Tool. |
Original linker command file—modelname.cmd | Assigns memory sections on the processor. This file is removed if the SECTION directive is empty because all of the section assignments moved to the configuration file. Otherwise, include call to the DSP/BIOS command file. |
Some *.lib files | Provide access to libraries for the processor, and peripherals. These files are removed if their contents have been incorporated in the new compound linker command file. |
When you investigate your generated code, notice that the function main portion of modelname_main.c includes different code when you generate DSP/BIOS-enabled source code, and modelname_main.c incorporates one or more new functions.
When you use Embedded Coder software to generate code that incorporates the DSP/BIOS options, you can easily profile your generated code to gauge performance and find bottlenecks.
By selecting Profile real-time execution in the Simulink Coder software options, Simulink Coder software inserts statistics (STS) object instrumentation at the beginning and end of the code for each atomic subsystem in your model. (For more about STS objects, refer to your DSP/BIOS documentation from Texas Instruments.)
After your code has been running for a few seconds on your target, you can retrieve the profiling results from your target and display the information in a custom HTML report.
Code profiling works only on atomic subsystems in your model. To allow the Embedded Coder to profile your model when you build it in Simulink Coder software, you convert segments of your model into atomic subsystems using Create subsystem.
By designating subsystems of your model as atomic, you force each subsystem to execute only when all of its inputs are available. Waiting for all the subsystem inputs to be available before running the subsystem allows the subsystem code to be profiled as a contiguous segment.
To enable the profile feature for your Simulink model, select Simulation > Configuration Parameters from the model menu bar. In the Configuration Parameters dialog box, select Code Generation > IDE Link. Under Code Generation, enable Profile real-time execution.
Nested subsystems are profiled as part of their parent systems—the execution time reported for the parent subsystem includes the time spent in any profiled child subsystems. You cannot profile child subsystems separately.
For models that include multiple sample times, one or more subsystems in your model might not be included in the profiling process. When your model is configured to use single-tasking mode, all atomic subsystems in your model are profiled and appear in the report. When your model uses multitasking (refer to your Simulink Coder documentation for more about multitasking models) profiling applies only to single-rate subsystems that execute at the base rate of your model. This limitation arises because all of the generated code segments must execute contiguously for the profiling timing measurements to be accurate. Setting the Tasking mode for periodic sample times to Auto in the model Configuration Parameters does not necessarily result in contiguous execution for all code segments and subsystems.
Notice two things in your code:
STS objects are added to the generated code
A generated DSP/BIOS configuration gets added to the project configuration file
Embedded Coder software inserts and configures these objects specifically for profiling your code. You do not have to make changes to the STS objects. To see the statistics objects in use, download your generated application to your board, select DSP/BIOS > Statistics View from the menu bar in CCS IDE, and run the board for a few seconds. You see the statistics being accumulated by the STS objects.
The profiling system in Embedded Coder software relies on DSP/BIOS STS objects and the CLK_gethtime() function. CLK_gethtime() returns a high resolution timing counter that enables profiling to measure the instruction cycles the CPU spends executing code segments. To understand profiling, you need to understand how CLK_gethtime() works.
This is how the system determines the value of CLK_gethtime:
CLK_gethtime() return val = CLK_getltime() *PRD0 + CNT0
PRD0 and CNT0 are timer 0 period and counter registers. In code generation, BIOS allocates timer 0 as a system timer and set the timer to generate a timer interrupt every 1ms. CLK_getltime() in turn returns the number of BIOS system timer interrupts. By this logic, PRD0 is set to the number of CPU clock cycles divided by the number of low resolution clock cycles that is equivalent to 1 millisecond in absolute time (8 low resolution clock cycles for C64x processors, for example).
The key point here is that function CLK_gethtime() relies on the CLK_getltime() function which in turn relies on a timer 0 interrupt. If your process globally disables interrupts during code execution for more than 1 PRD0 instruction cycle, one or more timer interrupts can be missed, resulting in a situation where both CLK_getltime() and CLK_gethtime() can be inaccurate.
CLK_getltime() will be inaccurate because it does not report the accurate time value. But it is always positive. The situation is worse for CLK_gethtime() It may report negative timing around code segments where interrupts are disabled:
A = CLK_gethtime();
IRQ_globalDisable();
{
Code segment;
}
IRQ_globalEnable();
B = CLK_gethtime();In this situation, if interrupts are disabled longer than 1ms around the code segment to be profiled, B might be smaller than A since CTN0 might have rolled over. So the count of the instruction cycles computed as (B - A) might be negative.
Correcting Inaccurate Profile Information Due to Timing. One way to solve problems in profiling caused by the disabled interrupts is to set the DSP/BIOS system timer interrupt to occur less frequently. As noted earlier, the timer is set to 1 millisecond by default.
You can change setting manually after you generate code for your project. Here are the steps to use to reset the DSP/BIOS system timer interval.
Right-click CLK Clock Manager to set the properties for the clock manager.
Change the Microseconds/Int value from the default 1000.00 microseconds to something larger, for example, 5000.00 microseconds.
This timing change reduces the chances of missing a system timer interrupt. If you do this and profile the code again, the profiling results are usually accurate. You can verify that if you reduce the system timer interrupt interval further, to perhaps 100 microseconds, you get less and less accurate profiling results, possibly reporting negative timing values.
For a multitasking system, DSP/BIOS STS objects cannot reliably measure the time the processor spends in all tasks. When tasks can be preempted by other tasks (a result of multitasking operation), the profile timing measurements may be inaccurate. For this reason, Embedded Coder software includes profiling instrumentation for atomic systems that run at the base sample rate only.
When you run the same model in single tasking mode, you can get the timing measurements for all the systems in your model for one iteration:
Select Simulation > Configuration Parameters from the model menu bar.
On the Solver pane, set Tasking mode for periodic sample times to SingleTasking.
The program will probably overrun immediately since single tasking mode requires that all tasks complete within the base sample time which usually does not happen. However, all systems and subsystems do run once before the program terminates. This allows you to obtain profiling results for all systems.
When the overrun occurs, click Halt in CCS IDE to stop DSP/BIOS operation.
Then, enter CCS_Obj.profile('report') at the MATLAB prompt to report the statistics measurements.
Now you can view the timing measurements for each subsystem. Keep in mind that the percentages are given relative to the base sample time, so you must do some arithmetic to figure out whether a given system will fit in its available time interval. For instance, if your base sample time is 1 second, subsystem A executes every 3 seconds, the base-rate task takes 0.1 seconds to run, and A takes 2.5 seconds to run, the system should execute without overruns in multitasking mode.
If you change the overrun action option from its default setting of Notify and halt to Notify and continue or None, you can get measurements for multiple iterations of the system. Also, you will be able to request the profile report without first halting the CPU.
To help you measure subsystem performance, Embedded Coder software provides a custom report that analyzes and displays the profile statistics. The report shows you the amount of time spent computing each subsystem, including Outputs and Update code segments, and provides links that open the corresponding subsystem in the Simulink model.
To view the profiling report, enter
profile(IDE_Obj,'report')
at the MATLAB prompt, where IDE_Obj is the handle to your target and CCS IDE, and report is one of the input arguments for profile.
When you generate the report, the Embedded Coder stores the report in your code generation working folder, something like modelname.c6000.rtw, with the name profileReport.html.
If the MATLAB® software cannot find your code generation folder, the profile reports is stored in your temporary folder, tempdir. To locate your temporary folder, enter
tempdir
at the MATLAB command prompt.
Caution Each time you run the profiling process, the software replaces your existing report with a newer version. To save earlier reports, rename and save the report before you generate a new one, or change your destination temporary folder in the MATLAB workspace. |
You must invoke profile after your Simulink Coder build, without clearing MATLAB memory between operations, so that stored information about the model is still available to the report generator. If you clear your MATLAB memory, information required for the profile report gets deleted and the report does not work well. When this occurs, and if you have a CCS IDE project that was previously created with Simulink Coder software, you must repeat the Simulink Coder build to see the subsystem-based profile analysis in the report.
Trace each subsystem presented in the profile report back to its corresponding subsystem in your Simulink model by clicking a link in the report. (The mapping from Simulink subsystems to generated system code is complex and thus not detailed here.) Inspect your generated code, particularly modelname.c, to determine where and how Simulink and Simulink Coder software implemented particular subsystems.
Within the generated code, you see entries like the following that define STS objects used for profiling.
STS_set(&stsSys0_Output, CLK_gethtime());
or
STS_delta(&stsSys0_Output, CLK_gethtime());
This pair of code examples perform the profiling of the code section that lies between them in modelname.c.
In CCS IDE, STS objects show up in the Statistics Object Manager section under Instrumentation in the modelname.tcf file. Double-click the file modelname.tcf in the CCS IDE tree view to open the file and see the sections.
In some cases, Simulink Coder software may have pruned unused data paths, causing related performance measurements to become meaningless. Reusable system code, or code reuse, where a single function is called from multiple places in the generated code, can exhibit extra measurements in the profile statistics, while the duplicate subsystem may not show valid measurements.
Although there are STS objects that measure the execution time of the entire mdlOutputs and mdlUpdate functions, those measurements can be misleading because they do not include other segments of code that execute at each interrupt. Statistics for the SWI are used when calculating the headroom (the difference between the number of CPU cycles your process requires to complete and the number available for the process to complete, which does not include the small overhead required for each interrupt. Note that profiling of multitasking systems does not measure the headroom. In addition, multitasking profiling does not use the SWI statistics.
To measure most accurately the overall application CPU usage, consider the DSP/BIOS IDL statistics, which measure time spent not doing application work. Your DSP/BIOS documentation from TI provides details about the various DSP/BIOS objects in the tcf file.
The interrupt rate for a DSP/BIOS application created by Embedded Coder software is the fastest block execution rate in the model. The interrupt rate is usually, but not always, the same as the codec frame rate. When there is an upsampling operation or other rate increasing operation in your model, interrupts are triggered by a timer (PRD) object at the faster rate. You can determine the effective interrupt rate of the model by inverting the interrupt interval reported by the profiler.
Profiling subsystems that contain "blocking" device drivers, such as the ADC/DAC blocks and C6000 UDP Receive blocks may produce inaccurate and misleading results, raising values for Max time spent in this subsystem per interrupt and Max percent of base interval by many orders of magnitude. To avoid this problem, design subsystems to isolate blocking device drivers from algorithmic and other processing functions, and configure profiling appropriately.
After you have the report from your generated code, you need to interpret the results. This section provides a link to sample report from a model and explains each entry in the report.
Sample of a Profile Report. When you click Sample Profile Report, the sample report opens in a new Help browser window. This opens the sample report in a new window so you can read the report and the descriptions of the report contents at the same time. Running the model c6713dskwdnoisf with DSP/BIOS generates the sample profile report. The next sections explain the headings in the report—what they mean and how they are measured (where that applies).
Report Heading Information. At the beginning of the report, profiling provides the name of the model you profiled, the target you used, and the date of the report. Since the report changes each time you run it, the date can be an important means of tracking model development.
Report Subsections and Contents. Within the body of your profile report, sections report the overall performance of your generated code and the performance of each atomic subsystem.
Report Heading | Description |
|---|---|
Timing Constants | Shows you the base sample time in your model (=1/base rate in Hz) and the CPU clock speed used for the analysis. |
Profiled Simulink Subsystems | Presents the statistics for each profiled subsystem separately, by subsystem. Each listing includes the STS object name or names that instrument the subsystem. |
STS Objects | Lists every STS object in the generated code and the statistics for each. DSP/BIOS uses these objects to determine the CPU load statistics. For more information about STS objects, refer to your DSP/BIOS documentation from TI. |
STS objects that are associated with subsystem profiling are configured for host operation at 4*x, reflecting the numerical relationship between CPU clock cycles and high-resolution timer clicks, x. STS Average, Max, and Total measurements return their results in counts of instructions or CPU clock cycles.
In the following sections, we provide definitions of the entries in the profile report. These definitions help you decipher the report and better understand how your process is performing.
System name. Provides the name of the profiled model, using the form targetnameprofile. targetname is the processor or board assigned as the target, via the Target Preferences block.
Number of Iterations Counted. The number of interrupts that occurred between the start of model execution and the moment the statistics were obtained.
CPU Clock Speed. The instruction cycle speed of your digital signal processor. On the C6713 DSK, you can adjust this speed to one of four values, where 100 MHz is the default—25, 33.25, 100, 133 MHz. If you change the speed to something other than the default setting of 100 MHz, you must specify the new speed in the Simulink Coder software options. Use the Current C6713DSK CPU clock rate option on the TIC6000 runtime category on the Simulink Coder tab.
Set at a fixed 150 MHz, you cannot change the CPU clock rate on the C6713 DSK. You do not need to report the setting in the Simulink Coder software options.
Maximum Time Spent in This Subsystem per Interrupt. The amount of time spent in the code segment corresponding to the indicated subsystem in the worst case. Over all the iterations measured, the maximum time that occurs is reported here. Since the profiler only supports single-tasking solver mode, no calculation can be preempted by a new interrupt. All calculations for all subsystems must complete within one interrupt cycle, even for subsystems that execute less often than the fastest rate.
Maximum Percent of Base Interval. The worst-case execution time of the indicated subsystem, reported as a percentage of the time between interrupts.
STS Objects. Profiling uses STS objects to measure the execution time of each atomic subsystem. STS objects are a feature of the DSP/BIOS run-time analysis tools, and one STS object can be used to profile exactly one segment of code. Depending on how Simulink Coder software generates code for each subsystem, there may be one or two segments of code for the subsystem; the computation of outputs and the updating of states can be combined or separate. Each subsystem is assigned a unique index, i. The name of each STS object helps you determine the correspondence between subsystems and STS objects. Each STS object has a name of the form
stsSysi_segment
where i is the subsystem index and segment is Output, Update, or OutputUpdate. For example, in the sample profile report shown in the next section, the STS objects have the names stsSys1_OutputUpdate, and stsSys2_OutputUpdate.
Before profiling your generated code, you must configure your model and Simulink Coder software to support the profiling features in Embedded Coder software. Your model must use DSP/BIOS features for profiling to work fully.
The following tasks compose the process of profiling the code you generate.
Use profile to view the MATLAB profile report.
To demonstrate profiling generated code, this procedure uses the wavelet denoising model c6713dskwdnoisf.mdl that is included with Embedded Coder demo programs. If you are using the C6713 DSK as your target, use the model C6713dskwdnoisf throughout this procedure. Simulators work as well, just choose the right model for your simulator.
Begin by loading the model, entering
c6713dskwdnoisf
at the MATLAB prompt. The model opens on your desktop.
Recall that you must use DSP/BIOS in your code to use profiling.
To enable the profile feature for your Simulink model, select Simulation > Configuration Parameters from the model menu bar. In the Configuration Parameters dialog box, select Code Generation > IDE Link. Under Code Generation, enable Profile real-time execution.
Profiling your generated code depends on two features—DSP/BIOS being enabled and your model having one or more subsystems defined as atomic subsystems. To learn more about subsystems and atomic subsystems, refer to your Simulink documentation in the Help browser.
In this tutorial, you create two atomic subsystems—one from the Analysis Filter Bank block and a second from the Soft Threshold block:
Select the Analysis Filter Bank block. Select Edit > Create subsystem from the model menu bar. The name of the block changes to subsystem. Repeat for the Soft Threshold block.
To convert your new subsystems to atomic subsystems, right-click on each subsystem and choose Subsystem parameters... from the context menu.
In the Block Parameters: Subsystem dialog for each subsystem, select the Treat as atomic unit option. Click OK to close the dialog. If you look closely you can see that the subsystems now have heavier borders to distinguish them from the other blocks in your model.
To Build and Profile Your Generated Code. You have enabled profiling in your model and configured two atomic subsystems in the model as well. Now, use the profiling feature to see how your code runs and check the performance for bottlenecks and slowdowns as the code runs on your target processor.
Caution Do not click on any other open model while you are profiling your model. Clicking on another open model can cause profiling to fail with an error message like "Invalid Simulink object specifier." |
Select Tools > Code Generation > Build Model.
If you did not use the Simulink Coder software options to automate model compiling, linking, downloading, and executing, perform these tasks using the Project options in CCSv3 IDE.
Allow the application to run for a few seconds or as long as required to execute the model segments of interest a few times. Then stop the program.
Create a link to CCSv3 IDE by entering
IDE_Obj = ticcs;
at the MATLAB prompt.
profile(IDE_Obj,'report')
at the prompt to generate the profile report of your code executing on your target processor.
The profile report appears in the Help browser. It should look very much like the following sample report; your results may differ based on your target and the settings in the model.
The Target Preferences block imports hardware information directly from DSP/BIOS. This feature enables you to create custom Target Preferences blocks for any C64x+ CPU core-based processor or board. You create and reuse these Target Preferences blocks in your models to generate code for your C64x+ processor or board.
To create a custom Target Preferences block for your C64x+ processor or board:
Set the DSP/BIOS installation folder.
For CCS v3.3, enter the setDspbiosFolder command. For example:
>> setDspbiosFolder('(path to DSP/BIOS)\bios_5_33_06');For CCS v4.1, also specify the XDC installation folder. For example:
>> setDspbiosFolder('(path to TI tools)\bios_5_41_02_14',
'(path to TI tools)\xdctools_3_10_05_61')Import all processor / board information from DSP/BIOS:
>> importDspbiosConfig('board', 'all')
>> importDspbiosConfig('proc', 'all')
Open the Simulink Library Browser and search for "Target Preferences". Copy the Target Preferences block from the search results to your model and configure the settings , as described in Target Preferences.
Double-click the Target Preferences block. This action opens the block.
When you open the Target Preferences block, the Embedded Coder software uses the BIOS_INSTALL_DIR environment variable to locate the DSP/BIOS installation folder. The link software then queries DSP/BIOS for a list of processors and boards with C64x+ cores and displays them in the Processor list.
Select your processor from the Processor list.
The Target Preferences block imports settings from DSP/BIOS such as the memory map, cache settings, and CPU clock rate. The block applies the settings to the Memory, Section and DSP/BIOS tabs.
Set the CPU Clock rate for your processor.
To improve the efficiency of your application, you can adjust the L1 and L2 caches values and the compiler sections. The following section provides an example of how to adjust these settings.
Click OK.
To create a library of custom Target Preferences blocks:
In Simulink, create a library: File>New>Library.
Copy any custom Target Preferences blocks from your models to the library.
Relabel individual blocks for the processors they specify: Click the block labels and edit the text.
Save the library to your default current folder. For example, save it as c64xcustomtgtpreflib.mdl in c:\Program Files\matlab\bin.
Later, you can reopen the library by entering the library name on the MATLAB command line.
To create a custom Target Preferences Block for OMAP-L138/C6748 EVM:
Open the Simulink Library Browser and search for "Target Preferences". Copy the Target Preferences block from the search results to your model.
In the Target Preferences: Initialize Configuration Parameters dialog box, set IDE/Tool Chain to Code Composer Studio and Board to OMAP-L138/C6748 EVM.
Open the Target Preferences block.
For Processor, select evmOMAPL138. The block populates the Memory, Section and DSP/BIOS tabs with default values for that processor.
Adjust the cache settings for efficiency. Turn L1 and L2 cache on:
Click the Memory tab. The L1P, L1D, and L2 cache sizes are zero by default.
Set L1D and L1P cache sizes to 32 kb.
When you increase the cache size, decrease the L1PSRAM and L1DSRAM to accommodate memory taken from the high address range of the corresponding L1 memory segments. Because L1PSRAM and L1DSRAM are 32 kb in the OMAP-L138/C6748 processor, change the Length for L1PSRAM and L1DSRAM to 0x00000000. This setting allows you to use the entire L1 memory as level one cache.
Set L2 cache size to 128 kb. Decrease the IRAM length to 0x00020000 (128 kb).
Confirm the following configuration for the Memory tab, and click Apply.
Reassign compiler sections to optimize the efficiency of the generated code. Put .stack, .bios, .hwi, .hwi_vec sections into fast internal memory and assign everything else to external memory. This approach avoids linking errors caused by placing excessive code and data in limited internal memory. It also runs critical sections of the application from internal memory.
Click the Section tab.
In the Compiler sections list, set the Placement of every section, except .stack, .bios, .hwi, and .hwi_vec, to DDR.
Set the Placement of .stack, .bios, .hwi, and .hwi_vec to IRAM.
The final step in configuring the OMAP-L138/C6748 EVM Target Preferences block is to create a heap in external memory. Device drivers from TI use heap to allocate data structures and device driver buffers. Without a heap, integrating device drivers from TI would not be possible.
Click the DSP/BIOS tab.
In the Heap list, select DDR and set the heap size to 0x00100000 (1 MB).
Confirm the following configuration for the DSP/BIOS tab, and click OK.
 | Targeting C6000 DSP Hardware | Using the C62x and C64x DSP Libraries |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
