This release note covers the changes between v3.5r1 and v4.0r1 of the TASKING VX-toolset for TriCore.
Support for TC1100, TC1115, TC1161, TC1162, TC1163 and TC1165 have been removed.
Prior to v3.0, the tools were fully aware of the relation between core and CPU. This was built-in in the tools. Starting with version v3.0 the IDE was made fully aware of the relation between core and CPU. This awareness was also built-in in the control program. This is not hardcoded, but is done by means of the processors.xml file. This gives a higher flexibility of adding and removing core and CPUs.
With the end of support of core TC1.2 and several derivatives, changes were needed in all the tools, because of the hardcoded intelligence. It is easy to change the processors.xml. Any new core and CPU was only added to the processors.xml file. Because now the hardcoded parts in the tools are running out of sync, we have decided to remove the hardcoded intelligence from the tools.
The only tools that are aware of the relationship are therefore the IDE (Eclipse) and the control program(s). This means that when you do not use the IDE and control program, you should use both --core and --cpu on command line (for compiler, assembler and linker).
For the single core CPUs (prior AURIX), we strongly advise to use the control program instead of invoking the tools one by one.
By default, the compiler will generate FPU instructions. The --fpu-present has become obsolete. Because only TC11iB does not have an FPU on board, the default of the complete toolchain has been changed. Instead of telling the tools there is an FPU available, for this particular CPU it must be specified that there is no FPU. The new option is --no-fpu.
The compiler will no longer generate the assembler control $FPU. Instead when the option --no-fpu is used, the compiler will generate the assembler control $NO_FPU.
Schedule before register allocation when speed is more important than size. This gives the scheduler more freedom. This is especially useful for targets with a dual-issue pipeline, because this improves the interleaved scheduling of independent instruction sequences. When scheduled after register allocation, interleaved scheduling may not be possible anymore, because the same registers might be used. Scheduling before register allocation is only done for -t0 and -t1, because code compaction is disabled for these tradeoff settings. This change may result in several percents better performance (only in case of -t0 and -t1).
By default, the assembler would set the macro __UM_USER_1__ when the user mode --user-mode=user1 was used at the command line. With --user-mode=kernel, the macro __UM_KERNEL__ should be set, but also the __UM_USER_1__ macro was set. This is not correct. Therefore, in case of --user-mode=kernel only the macro __UM_KERNEL__ is set. The sibug include files sibug_divide_after.inc and sibug_divide_before.inc for the assembler have been extended to check both macros instead of just the __UM_USER_1__.
This section gives an overview of the most important new features and improvements in v4.0r1. See the sections with fixed issues for a complete list.
With this release the very first implementation for the multi-core AURIX family (TC1.6.X) is available. The AURIX core consists of 3 TriCore cores and 4 MCS (Multiple Channel Sequencer) cores. There is no PCP available anymore.
The 3 TriCore cores are divided into an E (i.e. Efficient) and P (i.e. Performance) variant. The main core (CPU0) is always a TC1.6E. The TC2D5T has 2 P cores and 1 E core, while the TC27X has 1 P core and 2 E cores. The E and P cores are based on the TC1.6 TriCore. The P variant has a longer pipeline and several faster instructions (less cycles than the E variant).
The DSPR and PSPR for the 3 internal TriCore cores are at different memory locations for these devices. The TC2D5T has PSPR for CPU0 at segment 0xc8, CPU1 at 0xc9, CPU2 at 0xcA and DSPR at segment 0xd8, 0xd9, 0xdA, while the TC27X has them respectively at 0x7, 0x6, 0x5 and 0x701, 0x601, 0x501.
The demonstrator TC2D5T does not have LMU / shared memory. This means that the global/shared variables for this device must be either __far or the compiler option -N0 (near threshold is 0) and linker option --non-romable must be used .
The Infineon DAS drivers v4.05 included with this release are qualified to work with AURIX boards. When you install this DAS manually, you should use argument 'hitex' when you want to use the DAS server using the "JTAG over USB Box" connection.
Note: when installing DAS, depending on your machine, it might take several minutes while configuring the registry. This issue has been reported to Infineon.
Besides simulator support this release also has board support for the AURIX TC2D5T derivative.
Although the tools support the new AURIX core TC1.6.X, the pipeline of the TC1.6E is not supported yet. The pipeline schedular of the TC1.6 core is used instead. Therefore, performance and efficiency for TC1.6.X executables may not be as expected.
The AURIX core supports several new instructions. These instructions are implemented in the assembler. The compiler will not generate them though, but intrinsics are available: __crc32(), __cmpswapw(), __swapmskw(), __wait(). Running the TriCore compiler with option --help=i shows all available intrinsics. Important note: the instructions cmpswapw and swapmskw need a word aligned address.
In the new AURIX architecture, there are 3 TriCore cores. This required an extension in the compiler to specify on which core the code and data should be allocated. That is, to which core is the code and/or data associated (private), or is the code and/or data associated to all cores (share). By default the code and data has to be available to all cores (thus shared between the cores). To be able to do so, new pragmas, qualifiers and options have been introduced:
#pragma <code|data>_core_association <share|private{0|1|2}|clone>
__share, __private{0|1|2}, __clone
--<code|data>-core-association=<share|private{0|1|2}|clone>
The association clone means that code and/or data will be available only once (reducing the footprint size), but will be copied to all cores at flash-time. The addresses will be the same. The benefit is that the private core code can access this cloned code/data in the most efficient way (run-time speed optimization). One may think of cloning library functions and vector tables.
These new pragmas, qualifiers and options are only available for the AURIX multi-core family TC1.6.X.
For making it possible to assign the execution of an interrupt function or trap function to one or more cores, the new qualifer __vector_table(<nn>) must be used. While the core association pragmas/qualifiers/options work on the function itself, the __vector_table() only affects the vector table entry destination. This will be in the vector table of one or more cores. One may use 0, 1 and 2 for <nn>, comma separated. This qualifier is not required when the code core association private is used.
Refer to the user manual for a detailed description.
The original section names for the vector table entries used to be like .text.inttab.vec.xxx. With multi-core it is required that the linker is able to identify for which vector table the entry (the section) is meant. This is done by extending the section as follows: .text.inittab{012}.vec.xxx. This will only be done in case of multi-core.
The new compiler pragmas for core association result in an extension of the section name. This is neseccary for the linker/locator to be able to locate the code and data for the correct core, using the new multi-core lsl files. The section naming for AURIX is as follows:
.<prefix>.<share|private{0|1|2}.clone>[.<module_name>][.<symbol_name>]
(.<prefix> is e.g. .text and .data)
The toolset provides an SFR file for the TC2D5T (regtc2d5t.sfr/def), TC27X (regtc27x.sfr/def) and TC27XB (regtc27xb.sfr/def). They have been built from the MIRA files supplied by Infineon. The MIRA files hold only the necessary SFR definitions to be able to start a development.
All CSFRs (of the AURIX derivatives) have been made available by their structure (as normal SFRs) and have been duplicated for each core and prefixed with CPU<n>_. Each define CPU<n>_ has the required core base address.
The startup code for multi-core has been split up in 3 startup sources, cstart.c, cstart_tc1.c and cstart_tc2.c and 3 init sources, cinit.c, cinit_tc1.c and cinit_tc2.c. These are to be used resp. for core0, core1 and core2. On reset of the AURIX chip, core0 is started while core1 and core2 are set into halt. The first thing the startup for core0 does is starting the other 2 cores by setting the PC (start address) and removing the halt flag. Also a semaphore is available that is used in each startup code. After initializing the vector tables etc. each startup code will set its core-id bit (0,1,2) in the semaphore. It then waits for this sempahore to get the value 0x07, meaning all cores are ready. Then they will all call the one and only main() function. In this main function you can use a state-event mechanism and/or switch on CORE_ID to a dedicated private function.
In Eclipse for each cstart there is a separate edit-tab available. Several settings can be made specific for that core.
A very first starting point to get familiar with the AURIX architecture is to use the "TriCore C/C++ example" blink_aurix. This example shows the different startup codes for the 3 TriCore cores including the GTM and interaction between them.
In this release there is a separate simulator for the TC2D5T, the tsim16p_e_demonstrator, and a separate simulator for the TC27X(B), the tsim16p_e. This is due to the different memory layout and different number of E en P cores. Within Eclipse, the correct choice of simulator can be made.
With the AURIX support, there is support for the MCS core as well. The MCS has its own instruction set. The memory it occupies is segment F (previously occupied by PCP).
The assembly files can be assembled by the MCS assembler (asmcs) and linked with the TriCore objects, using the TriCore linker. Alternatively the MCS objects can be linked into an .out file, which on its turn can be linked with the TriCore objects. Since there are multiple (4) MCS cores available in AURIX, it is required to link MCS objects together that belong to one MCS core. Thus several MCS .out files can be linked with TriCore objects into one elf-file. To be able to link MCS objects or .out files with TriCore objects, the linker option --new-task needs to be used. See the MCS example mentioned below.
To obtain the best performance of the MCS, data and code are to be located in their own MCS memory page. To ensure the memory pages are fully used, the code and data should be located in opposite direction towards each other. This is done via the following LSL:
section_layout mpe:mcs<nn>:mcs (direction=high_to_low)
{
group (contiguous)
{
select ".mcstext";
select
".mcstext.*";
}
}
section_layout mpe:mcs<nn>:mcs (direction=low_to_high)
{
group (contiguous)
{
select
".mcsdata";
select
".mcsdata.*";
}
}
Just like PCP, MCS has its own directory in the installation path called cmcs, and holds all tools and files needed for MCS development, for example: assembler asmcs, archiver armcs, mcs linker lmcs.
The first assembler for the MCS was based on GNU and developed by BOSCH. To be able to support existing assembly files in Bosch assembly format, a Perl conversion script is available in the MCS bin directory, named cnvba2ta.pl.
The script converts one file per invocation. The script is started as follows: perl cnvba2ta <asm-file>. The output is written to screen (stdout), and thus it should be redirected into a new file.
There is an example available in the ./mcs/examples directory of the installation. The example (4 projects) must be imported in Eclipse as MCS project. The example will run on the demonstrator hardware and it will give you an overview of how MCS can be used in combination with TriCore, including the usage of the linker option --new-task.
The MCS core configuration of each MCS project must be set via Properties->Global Options->Core Configuration. When the settings of each MCS project are opened, you can see the Core Configuration preset in the example.
Each MCS link-task (--new-task) will produce an .elf file with debug information only. The MCS code and data is in the main .elf file and gets copied (via the copytable by CPU0) to the appropriate MCS memory.
To be able to access external MCS data, a new qualifier is introduced: __mcsram. Global MCS RAM variables can only be defined in the MCS application. Only types with a size of 32-bit can have the keyword __mcsram, because only 32-bit types are supported by the MCS in the MCS RAM space.
When a global variable defined in a MCS is
referenced externally by the TriCore, the qualifier will instruct the
compiler to prefix the symbol
(variable) with _lc_s
(like PCP). For example: extern
volatile int __mcsram count; will end up in symbol _lc_s_count.
To be able to use the TriCore control program to link TriCore with MCS, a new option is added, named --mcs-tasks. This option has the following syntax: --mcs-tasks=mcs<nn>,<outfile|object>[,...][:mcs<nn>,<outfile|object>[,...]]
The mcs<nn> identifies the MCS core on which the code must run, which is created from the comma separated <outfile|objects>.
Please see the MCS Example for details.
With this release full multi-core support is availble in the IDE. The options for the compiler --data-core-association and --code-core-association are available (default is set to none).
MCS software support is fully integrated. Per MCS project a .out file is generated.
When linking TriCore with MCS .out files, the project references must be made from the TriCore. Besides this, the MCS core configuration of each MCS project must be set via Properties->Global Options->Core Configuration. There are currently 4 MCS cores that can be chosen from. There may be only one of each (thus max. 4) during the TriCore link phase.
When linking an AURIX TriCore project in Eclipse the option "--core=mpe:vtc" will be added to the linker automatically and the MCS projects will be passed to the Control Progam with the new --mcs-tasks option of the control program.
With multi-core data and code core association option share, there was a conflict with the existing __share qualifier for referencing PCP objects from TriCore. This __share has been renamed: to reference global PCP objects form the TriCore an external reference must be qualified with the symbol attribute __share_pcp instead of __share.
A warning is generated when symbol qualifier __share
is used for non TC16X core, and automatically replaced with __share_pcp.
This makes it possible to compile existing code for PCP (which
is
not available in the AURIX architecture). The warning is issued to
inform you that you better update your source and write __share_pcp
instead.
The linker now creates a copy table per core. Initially the linker creates one table. It then splits the table into 3 parts, each ending with the NULL pointer. Part one holds all shared entries, MCS entries and private0 entries (linker label _lc_ub_table). The second part holds only private1 entries (linker label _lc_ub_table_tc1) and the third part only private2 entries (linker label _lc_ub_table_tc2). The three tables still make up one big table (linker label table).
Up to v3.5r1, the simulator was started by default with core specific configuration files (MConfig and DConfig). With the multi-core derivatives the memory configuration between the derivatives are too different. Thus the simulator needed to be started with dedicated configuration files. In the etc/tsim_config directory in the installation path of the TriCore ctc directory, the target specific configuration files are located in the core directory. E.g. the configuration files for the TC27X can be found in <install-path>/ctc/etc/tsim_config/tc16x/tc27x.
It is a known issue that the linker, when linking for multi-core, needs more time. When performing an evaluation of the multi-core implementation and it is requireed to only check the result of section locations and sizes for one TriCore core, the special tc27x_singlecore.lsl can be used.
This section gives an overview of the most important new features and improvements in v4.0r1. See the sections with fixed issues for a complete list.
There is also a specific simulator for TC1.3.1 derivatives, the tsim1311. This simulator can also be chosen in Eclipse.
With the introduction of the new multi-core instructions in
the
assembler, it has become clear that the order of the operands of
the swap instruction was implemented incorrectly. The order
should be in reverse. The compiler swap intrinsic will now generate the
order as originally described by Infineon (swap
[A-reg], D-reg). However, to stay backwards compatible,
the assembler will accept both formats. The assembler will issue a
warning in case the old format is used.
There has been a small update from Infineon for the SFR files for the TC1724 and TC1728.
With this release debug support for the TriCore triboard TC1387 is made available.
All ontrol programs (cctc, ccpcp, ccmcs) have the new option --cpu-list. This option shows all supported CPUs (resp. of TC, PCP, MCS) which can be used with the -C/--cpu option..
The EDG front-end in the C++ compiler has been updated to v4.2. STLPort libraries and user guide are updated accordingly.
Major changes include:
| --auto-type | allow "auto" to be used as type specifier |
| --c++0x-sfinae/--no-c++0x-sfinae | enable/disable the C++0x SFINAE rules |
| --c++0x-sfinae-ignore-access --no-c++0x-sfinae-ignore-access |
allow/disallow access errors in C++0x SFINAE that make deduction fail |
| --check-concatenations | check the result token of macro concatenations |
| --compound-literals | allow compound literals in expressions |
| --default-nocommon-tentative-definitions | do not place tentative definitions in common storage |
| --defer-parse-function-templates --no-defer-parse-function-templates |
enable/disable deferral of prototype instantiations until first actual instantiation |
| --no-exceptions | disable exception handling support |
| --no-extended-variadic-macros | disallow extended variadic macros |
| --no-lambdas | disable support for C++0x lambdas |
| --no-nullptr | disable support for the C++0x "nullptr" keyword |
| --no-rvalue-refs | disable support for r-value references |
| --no-stdarg-builtin | disable special treatment for the stdarg.h header |
| --no-variadic-macros | disallow variadic macros |
| --nonstd-default-arg-deduction | retain default arguments as part of deduced function types |
| --nonstd-instantiation-lookup | use C++98 rules for name lookup in template instantiations |
| --nullptr | enable support for the C++0x "nullptr" keyword |
| --rvalue-ctor-is-not-copy-ctor | do not treat an r-value constructor as copy constructor |
| --rvalue-refs | enable support for r-value references |
| --template-typedefs-in-diagnostics | replace typedef names in template diagnostics |
| --uliterals | enable support for U-literals |
| --unsigned-bitfields | treat "int" bit-fields as unsigned |
| --vla | enable support for variable length arrays |
This release comes with the new Eclipse CDT named Indigo. There are no visible changes compare to the previous version of Eclipse, Helios. For a complete overview of changes, please refer to Eclipse .
The Indigo release of Eclipse is equiped with a static code analyzer, named CODAN. This analyzer is run automaticlly when a file is opened. However, it has been proven that this new feature is not yet fully working, because some semantic errors are given which are not valid. These errors can be neglected when compiling the project. For new projects CODAN is enabled by default. For the examples, CODAN has been disabled.
Next to the normal run-time library librt and libfp(t), libraries named librtd and libfp(t)d have been included. These libraries are so called 'duplicate' libraries. The function of these libraries is that the run-time function are flagged with the init attribute. This will make them to be part of the copy-table and get copied during initialization. This makes it possible to create code that is copied from ROM to RAM, while located for flash, and call a run-time function.
Enabling this in the c-code has to be done by using #pragma runtim_prefix=__DUPLICATE__. This will instruct the compiler to prefix any run-time function with __DUPLICATE__ which it generates after the pragma. During linking you should then (next to the normal run-time libraries) also link the duplicate variant.
With this release support for TC1791, TC1793 and TC1798 is implemented.
The CPUs TC1736,
TC1767
and TC1797
of the core TC1.3.1 did
have
their
own protected libraries. Since all Silicon Bugs for these CPUs
are the same, the CPU protected libaries have been removed and
a protected library for the core is added (directory lib/p/tc131).
The compiler option -F contradicts with EABI. When the -F option with --eabi-compliant is used, when calling the compiler, the compiler will give an error.
The compiler will automatically define a macro for the core and CPU used on command line. In case --core=<name> is used, then the macro __CORE_<NAME>__ will be available; e.g. --core=tc1.6 defines macro __CORE__TC16__. For the --cpu=<name>, the macro __CPU_<NAME>__; e.g. --cpu=tc1796b defines macro __CPU_TC1796B__. If the option --core is not defined, then macro __CORE_TC131__ is defined. If the option --cpu is not used, then no macro is defined.
The __TC<xx>__ macros have become obsolete.
The assembler will automatically define a macro for the core and CPU used on command line. In case --core=<name> is used, then the macro __CORE_<NAME>__ will be available. For the --cpu=<name>, the macro __CPU_<NAME>__. If the option --core is not defined, then macro __CORE_TC131__ is defined. If the option --cpu is not used, then macro __CPU_TRICORE__ is defined.
The __TC<xx>__ macros have become obsolete.
The TriCore compiler and PCP compiler will generate three (3) new directives to the .src file: .compiler_name, .compiler_version, .compiler_invocation. The assemblers will translate these into an ELF note-section. Besides these the assemblers (including MCS assembler) will add their own information in the note-section too.
This information is only available in the .o files. The linker strips them off. In a future version, this information will be parsed by the linker and will be available after linking and locating too.
The information can be retrieved from the object file by an object dumper like hldumptc or elfdump.
The tool elfpatch can be useful when objects come from a third party and need to be changed to fit in your own environment. One may think of multi-core objects build for CORE2 but should run on CORE1.
The tool requires a command-file. Currently the only allowed command to use is rename_section( "<section-in>", "<section-out>" ). The <section-in/out> may hold wildcard "*".
E.g. rename_section( ".*.private2.*", ".*.private1.*" ). // rename all private2 to private1 sections
A dedicated C compiler for the HSM unit of the AURIX is available to license holders of the Professional and Premium Edition of the VX-toolset for TriCore. Initially this compiler is available through an add-on installation to the v4.0rx release, but at a later stage the compiler will be included in the binary distribution of the TriCore package (v4.1rx).
If you are a license holder of the Professional Edition or the Premium Edition and the C compiler for the HSM is not included in your product delivery, you can request a copy of the compiler by sending a request to iwantacompiler@tasking.com.
Support for the special function registers (SFR) of the HSM is available through a separate installer. For security reasons related to the HSM, Altium will verify the possible availability of the SFR installer to an enduser with Infineon. Once Infineon gives Altium permission to release the SFR installer, we will make it available through a secure FTP location.
The list of open issues for v4.0r1 can be found on the internet.
For a quick start, just start the TASKING VX-toolset for TriCore from the start menu. This will start the Eclipse based development environment. You will be asked to select a workspace. In case you used Eclipse before it is recommended to select a new workspace. After clicking OK, you will see the 'Welcome' view. On this view you will see icons that link to specific information. You can, for example, select the 'Samples' icon and import the TriCore project examples, PCP project examples and/or the MCS project examples.
Another icon on the Welcome page, the 'First Steps' icon, links to the 'TriCore Getting Started', 'PCP Getting Started' and the 'MCS Getting Started' documents. This is a good starting point for exploring the capabilities of the environment and the tools.
All TASKING products include the industry standard FLEXlm license management software. In order to be able to run this toolset, you will need a license key. You can only obtain a license key if you have purchased this product.
To
obtain a license key, you can start the License Administrator from the
program group of your installed TASKING toolset. In case you still need
to install the toolset, you can start the License Administrator by
setting a check mark at the end of the setup/installation process. The
wizard of the License Administrator will guide you through the steps to
obtain your license key.
Once you have received your license key from Altium, you can install it
on your system by running the License Administrator again.
Alternatively you can simply save the license key as the file
'license.dat' in the C:\FLEXLM folder on your PCs hard disk.
More information is available on http://www.tasking.com/support/flexlm. On this page you also find assistance to setup a floating network license, or for installation on Linux or Sun systems.
Altium's TASKING VX-toolset for TriCore is available as Standard, Professional and Premium Edition. At installation time all tools are installed, no matter what bundle you purchased or want to evaluate. However, each tool is protected with its own unique key. After your purchase you will release a license key - specific for the bundle - to unlock the appropriate tools.