www.gliwa.com Open in urlscan Pro
2a01:4f8:c17:a2c3::1  Public Scan

Form analysis
0 forms found in the DOM

Text Content

 * Products
   * T1.timing
     * T1.streaming
     * T1.posix
   * T1.accessPredictor
   * T1.stack
   * Supported Processors, etc.
   * License Overview
 * Services
 * Training
 * Book
 * References
   * Success Stories
   * Customer Projects
   * Partner
   * Research
 * Downloads
   * Product Updates
   * Brochures
   * Papers
   * Hacks
   * Standards
 * Company
   * About us
   * History
   * News & Events
   * Careers
 * Contact


 * Products
   * T1.timing
     * T1.streaming
     * T1.posix
   * T1.accessPredictor
   * T1.stack
   * Supported Processors, etc.
   * License Overview
 * Services
 * Training
 * Book
 * References
   * Success Stories
   * Customer Projects
   * Partner
   * Research
 * Downloads
   * Product Updates
   * Brochures
   * Papers
   * Hacks
   * Standards
 * Company
   * About us
   * History
   * News & Events
   * Careers
 * Contact


T1.TIMING

State of the art timing analysis

with industry-hardened methods and tools.


STATE OF THE ART TIMING ANALYSIS...


...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.




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, hours
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
T1.flex
T1.cont
T1.delay
T1.api
T1.diff
T1.mod
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





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 corresponding timing parameters such as min/max/average
core-execution-time (CET), delta-time (DT) and CPU-load.



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.


FOR RTOS-BASED PROJECTS: WHAT IS SUPPORTED BY T1?

For POSIX-based projects, see T1.posix.


SUPPORTED PROCESSORS, COMPILERS

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 VX-toolset
V3.5.x.x (57) V3.6.0.0 TC2xx, TC3xx, TC4x Infineon TC1.8 TASKING SmartCode
V3.5.x.x (90) V3.6.0.0 TC4x Infineon TC1.6.X, TC1.8 HighTec GCC V3.5.x.x (15)
V3.6.0.0 TC2xx, TC3xx, TC4x Infineon TC1.6.X, TC1.8 HighTec TriCore LLVM
V3.5.x.x (91) V3.6.0.0 TC2xx, TC3xx, TC4x Infineon TC1.6.X Wind River V3.1.x.x
(60) on request TC2xx, TC3xx Infineon TC1.6.X, TC1.8 Green Hills V3.5.x.x (73)
on request TC2xx, TC3xx, TC4x NXP/STM e200z0-z4, z6, z7 Green Hills V3.5.x.x
(54) / On Request (65/72) V3.6.0.0 MPC57xx, MPC56xx, MPC55xx, SPC58xx, SPC57xx,
SPC56xx, etc. NXP/STM e200z2, z4, z7 HighTec GCC V3.5.x.x (44) V3.6.0.0 MPC57xx,
MPC56xx, MPC55xx, SPC58xx, SPC57xx, SPC56xx, etc. NXP/STM e200z2, z4, z7 Wind
River V3.5.x.x (56) V3.6.0.0 MPC57xx, MPC56xx, MPC55xx, SPC58xx, SPC57xx,
SPC56xx, etc. ARM ARMv7-R: Cortex-R4, Cortex-R4F, Cortex-R5F Texas Instruments
V2.5.8.0 (39) on request 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) on request 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) V3.6.0.0 TMS570LS02x/03x/04x/05x/07x, TMS570LS11x/12x/21x/31x,
TMS570LC43x, etc. ARM ARMv8-R: Cortex-R52 HighTec CLANG V3.5.x.x (87) on request
ST SR6 Stellar, NXP S32S ARM ARMv8-R: Cortex-R52 Green Hills V3.3.x.x (85)
V3.6.0.0 ST SR6 Stellar, NXP S32S ARM ARMv7-M: Cortex-M3, Cortex-M4 *, Cortex-M7
* GCC V3.5.x.x (82) on request 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.6.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) on request Infineon Traveo-II, LPC17xx, STM32F4xx, Atmel SAM V71,
etc. ARM ARMv7-M: Cortex-M3, Cortex-M4 *, Cortex-M7 * IAR V3.5.x.x (69) on
request Infineon Traveo-II, LPC17xx, STM32F4xx, Atmel SAM V71, etc. ARM ARMv7-M:
Cortex-M3, Cortex-M4 *, Cortex-M7 * TASKING V3.5.x.x (93) on request Infineon
Traveo-II, LPC17xx, STM32F4xx, Atmel SAM V71, etc. Renesas RH850
G3K/G3KH/G3M/G3MH/G4MH Green Hills V3.5.x.x (52) V3.6.0.0 RH850/C1x, RH850/F1x,
RH850/P1x, RH850/E2x, etc. Renesas RH850 G3K/G3KH/G3M/G3MH/G4MH Wind River On
Request (53) on request RH850/C1x, RH850/F1x, RH850/P1x, RH850/E2x, etc. Renesas
RH850 G3K/G3KH/G3M/G3MH/G4MH Renesas V3.5.x.x (92) on request RH850/C1x,
RH850/F1x, RH850/P1x, RH850/E2x, etc. Texas Instruments C66x Texas Instruments
V3.5.x.x (89) on request TMS320C66x, AWR2944, TDA3x

(*) 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** Siemens Capital VSTAR OS Micriμm μC/OS-II** Vector
MICROSAR-OS Amazon Web Services FreeRTOS** WITTENSTEIN high integrity systems
SafeRTOS**

(**) T1 OS adaptation package T1-ADAPT-OS required.


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:TCP, UDP) TCP and UDP can be used, IP-address and port
can be configured. FlexRay FlexRay is supported via the diagnostic interface and
a CAN bridge. Serial Line Serial communication (e.g. RS232) is often used if no
other communication interfaces are present. On the PC side, an USB-to-serial
adapter is necessary. JTAG/DAP Interfaces exist to well-known debug environments
such as Lauterbach TRACE32, iSYSTEM winIDEA and PLS UDE. 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.




NOTHING BEATS PERSONAL CONTACT!

Call us: +49 881 138522-70

Or visit us here:


For other regions click here.




 * Privacy Policy

 * Imprint

 * Quality Policy

 * Distribution Area