Timing suite T1

Timing suite T1

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.

Use Cases

New Functions in V3.0

  • Streaming support:

    New add-on product T1.streaming: Streaming of the whole trace during any period of time (minutes, hours, days; e.g. during a test drive). Analysis of the streaming trace during measurement.
  • POSIX support:

    New add-on product T1.posix: Support of the POSIX operating systems like QNX and Linux.
  • T1.cont foreground calculation: Allows the calculation of T1.cont results under extreme CPU load scenarios. Full support of cross-core activations and event-chains.
  • Improved ELF/DWARF-Reader component: Load extreme huge ELF files through highly optimized and lean memory consumption. Fast project load-time.
  • New communication component: Highest reliability of target communication in extreme customer scenarios. Improved diagnosis of target communication problems, simplifies troubleshooting. Fast support of new target interfaces.

New add-on products in V3.0

  • New add-on product T1.streaming: Streaming of the whole trace during any period of time (minutes, hours, days; e.g. during a test drive). Analysis of the streaming trace during measurement.
  • New add-on product T1.posix: Support of the POSIX operating systems like QNX and Linux.

New Features in V2.x

  • New multi-core features

    Version 2.1 of T1 visualizes cross-core task-activations and shows/analyzes cross-core data flow.

    new-features
  • 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.

Descriptions & Screenshots

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.

t1overview t1overview

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.5% 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 Plug-ins

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, RTOSs, target interface

    Supported processors, compilers
    Silicon/IP
    Vendor
    Core Compiler Availability
    (ID)
    T1.stack/
    T1.accessPredictor
    Support
    ISO26262
    Version
    Available
    Controller Examples
    Infineon TC1.6.X Tasking V3.1.x.x
    (57)

    V2.6.0.0 TC29x, TC27x, TC26x, TC23x, TC22x, TC21x, TC39x, etc.
    Infineon TC1.6.X HighTec GCC V3.1.x.x
    (15)

    V2.6.0.0 TC29x, TC27x, TC26x, TC23x, TC22x, TC21x, TC39x, etc.
    Infineon TC1.6.X Wind River Short Notice
    (60)

    TC29x, TC27x, TC26x, TC23x, TC22x, TC21x, TC39x, etc.
    Infineon TC1.6.X Green Hills V3.1.x.x
    (73)

    TC29x, TC27x, TC26x, TC23x, TC22x, TC21x, TC39x, etc.
    NXP RCPU Wind River On Request
    (6)

    MPC56x, MPC555, MPC53x, etc.
    NXP/STM e200z0-z4, z6, z7 Green Hills On Request
    (54/65/72)

    MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56, etc.
    NXP/STM e200z2, z4, z6, z7 HighTec GCC V3.1.x.x
    (44)

    V2.6.0.0 MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56, etc.
    NXP/STM e200z2, z4, z6, z7 Wind River V3.1.x.x
    (56)

    MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56, etc.
    Arm ARMv7-R
    Cortex-R4
    Cortex-R4F
    Cortex-R5F
    Texas Instruments V2.5.8.0
    (39)

    TMS570LS02x/03x/04x/05x/07x,
    TMS570LS11x/12x/21x/31x,
    TMS570LC43x,
    etc.
    Arm ARMv7-R
    Cortex-R4
    Cortex-R4F
    Cortex-R5F
    Green Hills V3.1.x.x
    (78)

    TMS570LS02x/03x/04x/05x/07x
    TMS570LS11x/12x/21x/31x
    TMS570LC43x
    etc.
    Arm ARMv7-M
    Cortex-M3
    Cortex-M4 *
    Cortex-M7 *
    GCC Short Notice
    (82)

    LPC17xx,
    STM32F4xx,
    Atmel SAM V71,
    etc.
    Arm ARMv7-M
    Cortex-M3
    Cortex-M4 *
    Cortex-M7 *
    Green Hills On Request
    (83)

    LPC17xx,
    STM32F4xx,
    Atmel SAM V71,
    etc.
    Arm ARMv7-M
    Cortex-M3
    Cortex-M4 *
    Cortex-M7 *
    Keil On Request
    (84)

    LPC17xx,
    STM32F4xx,
    Atmel SAM V71,
    etc.
    Renesas RH850 G3K/G3M Green Hills V3.1.x.x
    (52)

    V2.6.0.0 RH850/C1x, RH850/F1x,
    RH850/P1x,
    etc.
    Renesas RH850 G3K/G3M Wind River On Request
    (53)

    RH850/C1x, RH850/F1x,
    RH850/P1x,
    etc.
    Renesas RH850 G4MH Green Hills V3.1.x.x
    (52)

    RH850/E2x, etc.

    (*) 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.

    (***) T1 OS adaptation package T1-ADAPT-OS required if 'OS Timing Hooks' are not supported.

    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.

    Additional information

    In Downloads you can find more details, such as product brochures, publications and the timing poster with general information on the subject of timing.