Welcome
What's New
View new features for FlowTracer 2025.1.0.
FlowTracer Overview
An advanced mission critical dependency management platform for developing and executing flows.
FlowTracer Tutorials
Discover FlowTracer functionality with interactive tutorials.
Altair FlowTracer User Guide
FlowTracer is a complete system to create, manage, and execute design flows.
Altair FlowTracer Administrator Guide
This manual is aimed at the person who will be the administrator for FlowTracer. This person will be responsible for configuring the network resources, setting up the licensing, and establishing security and access rules for the system.
Altair FlowTracer Developer Guide
- FlowTracer Roles
  When using FlowTracer in large deployments, three main roles emerge: Administrator, Developer and User. In smaller organizations, a given person may have multiple roles, but the duties of each role still exist.
- Environment Management
  To ensure the correct and repeatable behavior of the tools, the environment must be controlled. This chapter explains how VOV supports multiple reusable environments.
- Execute Jobs From the Command Line
- Flowbuilding
  The trace is built using a combination of techniques.
- Flow Description Language (FDL)
- Tool Integration
  - Wrappers
  - Track the Origins of Dependencies
  - Integration by Interception
  - Library-based Interception
  - Integration by Instrumentation
  - VOV Instrumentation Library (VIL)
  - Instrumentation Procedure
  - VILtools
  - Integration by Encapsulation
  - Encapsulation Procedures
    In an encapsulation script, you can use the following Tcl procedures:
  - Capsule Post-Processing
  - Capsule On-the-Fly
  - Capsules for VHDL and Verilog Tools
- Integrate Difficult Tools
- Runtime Change Propagation Control
  The patented technique of Runtime Change Propagation Control (RCPC) provides the ability to stop the propagation of insignificant changes through the flow.
- Flow Library
  FlowTracer captures your design in design flows described by Flow.tcl files. The Flow Library is meant to help users locate and deploy instances of packaged flows bound to their specific design data.
- Files, Equivalences, Exclusions
  The files used in a project reside in one or more directories spread all around your filesystems. Each logical name defined in the equiv.tcl file implicitly declares the root of a workspace. You can browse the workspaces using the browser interface.
- Makefile Conversion
- Advanced Tasker Topics
- Resource Management
  The Resource Map Set represents the collection of resource maps that have been assigned to a project and the constraints associated with such resources.
- CGI Interface
- Events
  Every change in the trace is recorded as an event, which is then sent to all clients that subscribe to them.
- Miscellaneous

View All Altair Accelerator Help

Track the Origins of Dependencies

The dependency engine tracks the origin of dependencies. This can be useful when debugging complex flows. The origin of a dependency can be one of the following:

FDL: this is a dependency described using the Flow Description Language FDL
Capsule: this is a dependency described in a capsule
Interception: this is a dependency captured by intercepting the operating system calls
Instrumentation: this is a dependency captured by calling the VIL or the VILtools
Wrapper: this is a dependency related to the use of a wrapper
Extra: another type of dependency

The origin of a dependency is shown as a set of 7 flags, with the following meaning:


Flag	Description
f--------	FDL
-c-------	Capsule
--r------	Interception (most often seen as --rv----)
---v-----	Instrumentation (VIL or VilTools)
----w----	Wrapper (vw, vov, vrt, ... )
-----x---	Extra dependency
------s--	Sticky flag (normally coming from FDL)
-------o-	Old dependency (orange)
--------n	New dependency (yellow)
---------F	File ready flag
----------W	Wait for input flag

Strictly speaking, the flag 's' for 'sticky' is not really an origin, but is nevertheless an important attribute of a dependency.

The origin of dependencies is now part of the default output of vsx, where the default format (see option -O), includes the keyword "@ORIGIN@"

Any dependency can have multiple origins, for example from FDL and from a capsule. For example, let's start with one line of FDL:

% vovsh -x 'J vw cp aa bb'
% vsx !
000001847 VALID      f---------- aa
  >>>> Node 000076523  INVALID  vw cp aa bb
000001848 INVALID    f---------- bb

In this example, both dependencies for aa and bb are f------ because they are coming from the one line of FDL. After execution of the tool, things change:

% vw cp aa bb
% vsx !
000001847 VALID      fc-----on-- aa
000001851 VALID      ----w---n-- /bin/cp
  >>>> Node 000076524  VALID  vw cp aa bb
000001848 VALID      fc-----on-- bb

Now, the origin for the aa dependency is fc------- meaning that it is coming from both the FDL and from the capsule for the tool "cp". The new dependency for the file /bin/cp is coming from the wrapper vw which always declares the executable as an input.