Timing suite
State of the art timing analysis with industry-harden methods and tools. T1 empowers and enables.
T1 is the most frequently deployed timing tool in the automotive industry, being used for many years in hundreds of mass-production projects.
As a worldwide premiere, the ISO 26262 ASIL‑D certified T1-TARGET-SW allows safe instrumentation based timing analysis and timing supervision. In the car. In mass-production.
Click on one of the topics below to discover more details and read in the Success Stories section what our customers have to say about T1.
- Timing measurement (e.g. max., min., average net execution times)
- Target-side timing verification (supervision)
- Automated timing tests
- Coverage of requirements, which arise from ISO 26262
- Implementation of the AUTOSAR Timing Extensions (TIMEX)
- Timing debugging: quickly detect and solve even awkward timing problems
- Exploration of free capacity, in oder to verify the timing effects of additional functionality before implementation, for example
- Investigation of dataflows and event chains and synchronization effects in multi-core projects
- Tracing of timing and functional problems without halting the target, particularly valuable in multi-core projects where it may be impractical to halt a single core
- T1.stack – a combination of static and measurement based stack-analysis, unique in the world
T1.stack disassembles the executable, typically the ELF file, derives the call-tree and determines the stack-usage of each function.
The result is nicely visualized as the screen-shot shows. Click on it for a full-size view.
Static code analysis is limited in principle and cannot e.g. resolve all kinds of indirect function calls. Indirect function calls are used frequently in automotive software.
Other stack analysis tools based on static code analysis have to rely on manual annotation. These are error-prone since in most projects no developer has access to and knowledge about all parts of the software.
With a few mouse-clicks, T1.stack resolves indirect function calls based on measurements removing the problem of the error-prone manual annotations described above and reducing the effort for annotations significantly.
T1.stack has always unlimited access to all parts of the software.
- New multi-core features Version 2.1 of T1 visualizes cross-core task-activations and shows/analyzes cross-core data flow.
- DPC "Disabled Preemption CET": high precision measurements for small functions
T1 has always deducted the tracing overhead providing top quality measurements results. Context switches introduce an unavoidable loss of accuracy where it is not practical to observe the exact time of the switch in the OS or hardware, for interrupts. This creates a significant impact on the CET (Core Execution Time)
measurement, especially for small functions. For version 2.1, we implemented the DPC feature, which allows you to precisely measure functions with execution times of only a few microseconds and below.
- Improved software-sharing support OEMs and tier-1s mostly provide larger parts of their software as object-code only to their development partners.
The new support allows for the rigourous protection of IP, whilst allowing any partner to trace and analyze the whole system on the level of TASKs and ISRs and their own software components down to the level of single machine instructions.
- Automatic overhead calibration memory and cache configuration, code alignment etc. have an impact on the trace overhead, making it highly project-dependent and even changing from one build to the next.
T1 now measures the tracing overhead; it calibrates itself automatically after every reset, removing the requirement for repeated, manual, calibration cycles throughout the project development.
- Support for more than one ELF file In many projects, the software is divided into multiple ELF files. To reflect this, T1 now also supports such scenarios.
T1 consists of the T1 target software part (T1-TARGET-SW), which runs on the target system, and the T1 host software part (T1-HOST-SW), which runs on the PC.
The T1-TARGET-SW uses highly efficient instrumentation to obtain timing-relevant information and delivers this to the T1-HOST-SW on the PC.
"Highly efficient" can be quantified: in a typical 32-bit automotive application, the T1 instrumentation adds between 0.2% and 0.8% CPU Load.
The target interface can be provided by CAN, FlexRay™, JTAG, or Nexus.
Unlike other solutions, T1 requires very little bandwidth for communication.
This explains how T1 can be used so successfully in mass-production projects, where bandwidth is typically scarce.
When the data, for example scheduling trace, have been transmitted to the PC, they are visualized and analysed.
The generation of reports and the facility to automate all T1 functions enable perfect integration into the testing process.
The target software supports more than just the pure collection of data, however. The target system analyses the data in real-time, for example to detect whether constraints are exceeded.
In this case, environment information may be saved, to allow detailed off-line analysis. In this way, even complex causes of run-time errors can be diagnosed.
T1 consists of several components called plug-ins.
T1.scope – the oscilloscope for your software
Whether during software development, integration or verification, without the
visualization of the real system there is no insight into what is actually
happening on the processor.
T1.scope enables this insight and puts developers, integrators and testers in
the position to be able to verify the timing of their embedded software.
The application is simple: the T1.scope target code collects events pertaining
to the operating system, like the start and end of tasks or interrupts, and
conveys them to the T1.scope component of the host software.
There, the events are displayed over a time axis, just as an oscilloscope would.
User-defined events can be included in the data.
In addition to the graphical representation there is also the quantitative
evaluation, whereby net run-times (core execution time) are calculated for tasks, interrupts,
runnables, selected functions and arbitrary code fragments.
The spectrum of T1.scope features is rounded off with report generation.
T1.cont – on-target timing analysis and supervision
In contrast to T1.scope, T1.cont performs the quantitative evaluation on the
target itself.
All instances of all tasks and interrupts are the subject of unbroken analysis,
so that the computation of minimum and maximum values of timing parameters
includes each occurrence.
Optional Timing Constraints allow the early recognition of violations of
configurable constraints.
For example, a callback can be configured to be called if the net execution time
of a task exceeds a given value.
Combining constraints with the preservation of timing results in
non-volatile memory, such as NVRAM or EEPROM, provides timing verification,
which is, in practise, superior to static scheduling analysis or scheduling
simulation.
These model-based approaches can give an incorrect impression of safety that
overlooks possible disparity between the model and reality.
Like T1.scope, T1.cont supports the collection of results in the form of a
report.
T1.flex – flexible on-target timing measurement
As an extension to T1.scope and T1.cont, T1.flex offers the possibility, without
additional instrumentation, to measure the execution time of functions and even
arbitrary code fragments. The resolution of code fragment selection is one machine
instruction.
The measurement of access frequencies of code and data and the T1 "Data Access
Inspector" (see Screenshots on this page) are performed by T1.flex.
To get to the point: T1.flex enables the selection of measured code or data at
run-time without having to instrument, compile and re-flash the application.
This saves considerable time and money. The measured symbols are simply selected
from the symbol browser and code fragments are selected in the integrated source
code browser.
T1.delay – injection of net execution time
By means of T1.delay, additional net load can be configured at run-time. The places
in the code where the load should occur are defined at compile-time. At run-time, the delay can
be set, exact to the microsecond, and therefore the duration of the injected
code. Of course, numerous such delays can be active at the same time.
In addition, each delay can be periodically increased (e.g. every two seconds),
in order to bring a system slowly and in a controlled way to its (timing)
limits.
This provides an ideal method for the empirical discovery of the "headroom", or
how much spare capacity exists.
T1.test – timing verification at the RTOS and code level
T1.test offers the comprehensive automation of timing measurements. The
connection to the test environment is achieved using XML-based scripts triggered
by a command line or a .NET interface. Integration of timing verification in
existing, functional tests, typically HIL tests, is particular efficient. In
this way, timing verification can be performed in parallel with the functional
tests with virtually no additional test effort.
T1.diff – monitoring timing as a project progresses
In the progress of every software project there are various milestones,
integration levels and software versions. T1.diff supports the comparison of
several software versions, delivering valuable information about how the timing
of the project is developing.
Not only that. T1.diff also supports the specification of thresholds, where a
warning or error should be generated if they are exceeded. For example, an
increase in net run-time of a runnable could be generate a warning at 10% and an
error at 15%. In combination with automated tests and T1.test the development of
the timing of a project can be very efficiently and accurately supervized
without any manual intervention.
To pick a real-world example, more and more projects rely on model-based
software development with automatic code generation. With all the advantages
that this approach brings, there is also one big disadvantage: the resource
requirements of the software become ever more abstract. We have observed
situations where an apparently minor modification of the model multiplies the
execution time of the generated code by ten. This is not a problem, as long as
it can be automatically detected and made transparent, e.g. with T1.diff and T1.test.
T1.mod – on-line data access
During software development, especially with low-level software, there is again
and again the need to read and modify a variable or memory cell of a running
system. We need to avoid stopping the processor, which is usually required when
using a debugger.
T1.mod offers just this simple possibility.
If an ELF file is available, the user can work with symbol names. Direct accesses to
memory addresses are also possible. No A2L file is required.
T1.stack – Stack-analysis
See list of T1 V2.1 features above.
Supported processors, compilers
Silicon/IP Vendor |
Core |
Compiler |
T1.flex also available |
T1.stack Support |
ISO26262 Version available |
Controller Examples |
Infineon | TC1.3.1 | Tasking | Yes | Yes | No | TC1797, TC1767, TC1736 |
Infineon | TC1.3.1 | HighTec GCC | Yes | Yes | No | TC1797, TC1767, TC1736 |
Infineon | TC1.6 | Tasking | Yes | Yes | No | TC1798, TC1793, TC1791, TC178x, TC172x |
Infineon | TC1.6 | HighTec GCC | Yes | Yes | No | TC1798, TC1793, TC1791, TC178x, TC172x |
Infineon | TC1.6.X | Tasking | Yes | Yes | Yes (V2.6.0.0) | TC29x, TC27x, TC26x, TC23x, TC22x, TC21x, TC39x |
Infineon | TC1.6.X | HighTec GCC | Yes | Yes | Yes (V2.6.0.0) | TC29x, TC27x, TC26x, TC23x, TC22x, TC21x, TC39x |
Infineon | TC1.6.X | Wind River | Yes | Yes | No | TC29x, TC27x, TC26x, TC23x, TC22x, TC21x, TC39x |
Infineon | TC1.6.X | Green Hills | Yes | Yes | No | TC29x, TC27x, TC26x, TC23x, TC22x, TC21x, TC39x |
NXP | RCPU | Wind River | Yes | Yes | No | MPC56x, MPC555, MPC53x |
NXP/STM | e200z0-z4, z6, z7 | Green Hills | Yes | Yes | No | MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56 |
NXP/STM | e200z0-z4, z6, z7 | HighTec GCC | Yes | Yes | Yes (V2.6.0.0) | MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56 |
NXP/STM | e200z0-z4, z6, z7 | Wind River | Yes | Yes | No | MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56 |
ARM | ARMv7-R
Cortex-R4
Cortex-R4F
Cortex-R5F
| Texas Instruments | Yes | Yes | No | TMS570LS02x/03x/04x
TMS570LS05x/07x/11x/12x/21x/31x
TMS570LC43x |
ARM | ARMv7-M
Cortex-M3
Cortex-M4 *
Cortex-M7 * | GCC | Yes | Yes | No | LPC17xx
STM32F4xx
Atmel SAM V71 |
ARM | ARMv7-M
Cortex-M3
Cortex-M4 *
Cortex-M7 * | Green Hills | Yes | Yes | No | LPC17xx
STM32F4xx
Atmel SAM V71 |
ARM | ARMv7-M
Cortex-M3
Cortex-M4 *
Cortex-M7 * | Keil | Yes | Yes | No | LPC17xx
STM32F4xx
Atmel SAM V71 |
Renesas | V850E | Green Hills | Yes | Yes | No | |
Renesas | V850E2 | Green Hills | Yes | Yes | No | V850E2/Fx4-L |
Renesas | RH850 G3K/G3M | Green Hills | Yes | Yes | Yes (V2.6.0.0) | RH850/C1x, RH850/F1x, RH850/P1x |
Renesas | RH850 G3K/G3M | Wind River | Yes | Yes | No | RH850/C1x, RH850/F1x, RH850/P1x |
Renesas | RH850 G4MH | Green Hills | Yes | Yes | No | RH850/E2x |
Renesas | SH2A | Renesas | Yes | No | No | SH725x, SH72Ax |
Infineon | C166SV2 | Tasking | Yes | Planned | No | XC22xx, XC23xx, XC27xx |
NXP | CPU12/CPU12X | Metrowerks | No | No | No | HC12/S12/S12X |
Atmel | AVR | GCC | No | No | No | e.g. ATmega32, ATmega64, ATmega128 |
(*) Cortex-M4 adds DSP and FPU to Cortex-M3. Cortex-M7 further adds a 64-bit bus and double precision FPU. T1 uses the shared sub-set of the instruction sets.
Supported RTOSs
Vendor |
Operating System |
GLIWA |
gliwOS |
ETAS |
ERCOSEK** |
Vector |
MICROSAR-OS** |
Vector |
osCAN** |
Delphi |
PharOS** |
Micriμm |
μC/OS-II** |
Elektrobit |
proOSEK |
Elektrobit |
OSEKtime** |
Elektrobit |
EB tresos AutoCore OS |
Elektrobit |
EB tresos Safety OS |
ETAS |
RTA-OSEK |
ETAS |
RTA-OS |
KPIT Cummins |
KPIT** |
ARCCORE |
Arctic Core |
HighTec |
PXROS-HR |
Customer |
Any in-house OS** |
Customer |
No OS scheduling loop plus interrupts** |
(**) T1 OS adaptation package T1-ADAPT-OS required
Supported target interfaces
Target interface |
Comment |
CAN / CAN FD |
Low bandwidth requirement: typically one CAN
message every 1 to 10ms. The bandwidth consumed by T1 is scalable and strictly deterministic.
|
Diagnostic Interface |
The diagnostic interface supports ISO14229 (UDS) as well as ISO14230, both via CAN with
transportation protocol ISO15765-2 (addressing modes 'normal' and 'extended').
The T1-HOST-SW connects to the Diagnostic Interface using CAN.
|
Ethernet (IP/UDP) |
UDP is used, IP-address and port can be configured.
|
FlexRay |
FlexRay is supported via the diagnostic interface and a CAN bridge.
|
JTAG / DAP |
Interfaces exist to well-known debug environments such as Lauterbach TRACE32 and iSYSTEM winIDEA.
The T1 JTAG interface requires an external debugger to be connected and, for data transfer, the
target is halted. TriCore processors use DAP instead of JTAG.
|
In Downloads you can find
more details, such as product brochures, publications and the timing poster
with general information on the subject of timing.
|
HOT TOPICS
Embedded World 2019
Visit us at the Embedded World from February, 26th - 28th, 2019, hall 4, stand 4-570
NEW product T1.accessPredictor
Upset by MPU exceptions in the field? T1.accessPredictor allows you to check for any memory access violations before even flashing the software. It will perform a
static analysis by disassembling the binary, building up the call-tree and identifying r/w memory accesses for each function. No source code required!
T1 supports TC39x
Synchronized traces from 6 cores!
T1 makes it happen. Click
here, to view a screenshot of T1 with 6 synchronized traces and some cross-core communications.
More details on the AURIX 2G can be found in Infineon's official press-release.
Multi-core in minutes
The AURIX based ATdemo comes with a multi-core OS, a demo application and built-in T1 timing analysis. It was never easier to get started with multi-core.
Click here for details.
|  |
|
|