...with industry-hardened 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.
Read in the
Success Stories
section what our customers have to say about T1.
Use Cases
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
Extensions
T1.timing comes with two extension options. Add-on product T1.streaming provides the
possibility to stream trace data continuously — over seconds, minutes or even days.
Add-on product T1.posix supports POSIX operating systems such as Linux or QNX.
T1 plug-ins
T1.timing comes with a modular concept and several plug-ins which are described in the following. Plug-ins can be easily
enabled or disabled at compile-time using dedicated compiler switches such as T1_DISABLE_T1_CONT. To disable T1 altogether,
it is sufficient to disable compiler switch T1_ENABLE which leaves the system in a state as of before the T1 integration.
T1.scope
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.
Key benefits include:
Intuitive
visualization of what is actually going on in the software
– it has never been easier to
track down the cause of timing issues.
Pure software instrumentation-based approach:
no hardware modification or special hardware required
Minimal
overhead of typically only 0.2% to 0.4% CPU-load
for tracing all tasks and all interrupts in a typical
set-up of an ECU for engine management or chassis control
Detailed profiling: capturing of CPU-load and all kinds of
timing parameters with
min/max/average/distribution information
Constraints: verification of
timing requirements
T1 offers the best insight for any target interface bandwidth:
- Environments with
low bandwidth
(e. g. CAN): snapshots of a few hundred milliseconds
- Environments with
high bandwidth
(e. g. Ethernet): streaming with real-time visualization and
analysis for
seconds, minutes, hours and days through add-on product T1.streaming
Click on image to enlarge
Definition of timing parameters
T1.flex
Who said instrumentation-based tracing is not flexible and requires software compilation when moving
instrumentation points around? Be prepared to see some magic when using T1.flex, the flexible on-target and
at-run-time instrumentation. Select any function or even some lines of code and
immediately see the corres-ponding timing parameters such as min/max/average core-execution-time (CET),
delta-time (DT) and CPU-load.
Click on image to enlarge
Key benefits include:
On-the-fly instrumentation
while the software is executing
Suitable for
functions and code-fragments
(providing min/max/average CET, DT, CPU-load and more)
Suitable also for
data-accesses
(providing min/max data age, access frequency)
T1.cont
Permanent timing analysis and timing supervision
Who or what takes care of the timing when there is no PC connected to the ECU? T1.cont provides timing analysis on
the target with minimal impact on the existing software. What’s more T1.cont not only measures, it can also
continuously supervise the timing – permanently making sure timing requirements are met.
Key benefits include:
Permanent timing analysis and timing supervision
Ideal for profiling
the software (min/max timing parameters for selected tasks, runnables, data ages)
Results can optionally be stored in non-volatile memory –
allowing profiling over weeks
with billions of executions
T1.delay
Test timing-related aspects of future versions of your software today! T1.delay makes it possible by providing
scalable delay routines which consume a specified amount of net-run-time. These can be placed in the schedule at
places where future functionality is to be added.
Other use-cases include determination of “head-room”: an empirical way to find out how much more CET can be
added before the systems is overloaded.
T1.api
Around the world every night hundreds of HILs execute automated timing tests using T1. They collect timing parameters such as
CPU-load, core execution time (CET), response time (RT) etc.; see also figure “Definition of timing parameters” above.
At the same time they ensure no timing constraints are violated — a basis for safe and reliable embedded systems.
T1.api provides a REST API for test automation and thus is easily controllable from virtually any programming language.
In test automation mode, T1 runs as a server in the background listening to commands on a configurable http port.
It also provides a website with interactive documentation meaning that with a target board connected, T1.api commands can
simply be sent from within the documentation. Getting a good grip on an automation interface has never been as easier.
T1.diff
See how timing parameters evolve over the time. Compare different versions of your software with a focus on the timing aspects.
T1.diff provides numerical comparison as well as diagrams showing selected timing parameters for different versions of your software.
It also allows you to configure thresholds for deviations from previous versions. T1.diff e.g. can highlight any parameter
which increases or decreases by more than x% compared to the previous release eliminating the possibility for unwanted
changes to slip through.
T1.mod
A minor but very handy feature allowing reading from and writing to arbitrary memory. The intuitive symbol
browser makes navigating to the data of interest much easier.
Each row in the table below represents one set of T1 libraries specific to a certain processor core and a certain compiler.
Silicon/IP Vendor
Core
Compiler
Availability (Variant ID)
ISO26262 Version Available
Controller Examples
Infineon
TC1.6.X, TC1.8
Tasking
V3.5.x.x (57)
V3.4.0.1
TC2xx, TC3xx, TC4xx
Infineon
TC1.6.X, TC1.8
HighTec GCC
V3.5.x.x (15)
V3.4.0.1
TC2xx, TC3xx, TC4xx
Infineon
TC1.6.X
Wind River
V3.1.x.x (60)
✗
TC2xx, TC3xx
Infineon
TC1.6.X, TC1.8
Green Hills
V3.5.x.x (73)
✗
TC2xx, TC3xx, TC4xx
NXP/STM
e200z0-z4, z6, z7
Green Hills
V3.5.x.x (54) / On Request (65/72)
✗
MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56, etc.
NXP/STM
e200z2, z4, z7
HighTec GCC
V3.5.x.x (44)
V3.4.0.0
MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56, etc.
NXP/STM
e200z2, z4, z7
Wind River
V3.5.x.x (56)
V3.4.0.0
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.5.x.x (78)
✗
TMS570LS02x/03x/04x/05x/07x, TMS570LS11x/12x/21x/31x, TMS570LC43x, etc.
Arm
ARMv7-R: Cortex-R4, Cortex-R4F, Cortex-R5F
HighTec GCC
V3.5.x.x (77)
✗
TMS570LS02x/03x/04x/05x/07x, TMS570LS11x/12x/21x/31x, TMS570LC43x, etc.
Arm
ARMv8-R: Cortex-R52
HighTec CLANG
Short Notice (87)
✗
ST Stellar, NXP S32S
Arm
ARMv8-R: Cortex-R52
Green Hills
V3.3.x.x (85)
V3.4.0.0
ST Stellar, NXP S32S
Arm
ARMv7-M: Cortex-M3, Cortex-M4 *, Cortex-M7 *
GCC
V3.5.x.x (82)
✗
Infineon Traveo II, LPC17xx, STM32F4xx, Atmel SAM V71, etc.
Arm
ARMv7-M: Cortex-M3, Cortex-M4 *, Cortex-M7 *
Green Hills
V3.5.x.x (83)
V3.4.0.0
Infineon Traveo II, LPC17xx, STM32F4xx, Atmel SAM V71, etc.
Arm
ARMv7-M: Cortex-M3, Cortex-M4 *, Cortex-M7 *
Keil (Arm Compiler for Embedded)
V3.5.x.x (84)
✗
Infineon Traveo II, LPC17xx, STM32F4xx, Atmel SAM V71, etc.
Arm
ARMv7-M: Cortex-M3, Cortex-M4 *, Cortex-M7 *
IAR
V3.5.x.x (69)
✗
Infineon Traveo II, LPC17xx, STM32F4xx, Atmel SAM V71, etc.
Renesas
RH850 G3K/G3KH/G3M/G3MH/G4MH
Green Hills
V3.5.x.x (52)
V3.4.0.0
RH850/C1x, RH850/F1x, RH850/P1x, RH850/E2x, etc.
Renesas
RH850 G3K/G3KH/G3M/G3MH/G4MH
Wind River
On Request (53)
✗
RH850/C1x, RH850/F1x, RH850/P1x, 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
Customer
Any in-house OS**
Customer
No OS - scheduling loop plus interrupts**
Elektrobit
EB tresos AutoCore OS
Elektrobit
EB tresos Safety OS
ETAS
RTA-OS
GLIWA
gliwOS
HighTec
PXROS-HR
Hyundai AutoEver
Mobilgene
KPIT Cummins
KPIT**
Mentor
VSTAR OS
Micriμm
μC/OS-II**
Vector
MICROSAR-OS***
FreeRTOS**
(**) 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
Low bandwidth requirement: typically one CAN message every 1 to 10ms. The bandwidth consumed by T1 is scalable and strictly deterministic.
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.
Our brand new videos provide concrete and entertaining insights into the functions and advantages of the various components of the T1 Analysis Suite.
GLIWA providing fundamental knowledge besides outstanding tools
The practice-oriented, book on methodology and analysis of embedded software timing.
Numerous case studies help to avoid tricky problems, facilitate optimal use of processor resources and
give many hints to secure correct runtime behavior.
Edited by Springer. Available as printed edition and eBook. Take a closer look here. Now also available in Korea and China!
Peter Gliwa's coveted book was recently published in Korea and – in cooperation with the highly recognized Tsinghua University of Beijing – will also be available on the Chinese book market.
To find out more about T1 or to arrange a free presentation, just call:
+49 881 138522-70
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.