TTSQ

The SQ is one of the most foundational concepts in TTPython, and has two essential subclasses, TTSQSync and TTSQExecute for handling the intricacies of synchronization and execution. The Forwarding section is represented using an array of TTArcDestination.

SQs are the core of TTPython programs – they are the nodes of the dataflow graph that encodes the application.

SQs contain a Synchronization (TTSQSync), Execution (TTSQExecute) and Forwarding/Tagging (based on mapping and TTTag/TTTime) portions, hence the organization of the runtime environment into three processes that correspond to each part of the SQ.

SQs are built from ordinary python functions with a decorator (e.g. SQify or STREAMify), which encapsulate the user-level function into a form that handles the boilerplate SQ operations. These functions compose the body of an SQ (i.e., Execution), and are executed when a firing rule (TTFiringRule) is satisifed by the input value-carrying tokens and state of internal clocks. This firing rule is a synchronization barrier, and is ordinarily untouched by the user. In some cases, they may provide parameters to the barrier for the function they are calling with the TTPython program (which is itself a function with a GRAPHify decorator). This is primarily used to dictate behaviors like periodic triggering for stream generation or deadlines/timeouts on synchronization

SQs may also be made stateful (similar to ‘static’ variables in other languages) by declaring ‘global sq_state’ in the SQify’d function. This variable is a dictionary that will persist between invocations of the same SQ, but will not affect any other SQs in the system. Such SQs are given special firing rule mechanisms to enforce chronological processing of data (though some iterations may be skipped)

ticktalkpython.SQ.SQify(function)

Decorator for transforming vanilla Python functions into SQ templates that take in and return TTTokens

Parameters:

function (function) – the function to be @SQify-ed

ticktalkpython.SQ.STREAMify(function)

Decorator for turning a vanilla python function into one that will produce a stream of values. The main difference between this decorator and SQify is that it forces the firing rule to be TTFiringRuleType.TimedRetrigger, which will cause the SQ to run periodically according to meta-parameters provided when calling within the @GRAPHify decorated function. The same function will be rerun for each iteration of the stream. A good use case is sampling a sensor.

To specify the clock domain, periodicity, phase, and data validity interval, use keyword arguments TTClock, TTPeriod, TTPhase, and TTDataValidityInterval with constant valued (or clock variable-named) input to those keyword arguments when calling this in the @GRAPHify -ed function.

Parameters:

function (function) – The function to be STREAMify -ed

class ticktalkpython.SQ.TTFiringRuleType(value, names=<not given>, *values, module=None, qualname=None, type=None, start=1, boundary=None)

An enumeration for the base type of a firing rule. There is a more specification for firing rules in SQSync.TTFiringRule

class ticktalkpython.SQ.TTSQ(astNode, functionASTnode, context, sq_name, input_arcs, constraints, interpreter=TTInterpreter.Python3, firing_rule_type=TTFiringRuleType.Timed, clock_dict=None)

The TTSQ is used to create a node in the graph during the compilation process by analyzing the input symbols (which are arcs in the graph), the abstract syntax tree (AST) for the GRAPHify’d TTPython function AND the SQify’d Python function (including keyword/optional arguments), and the surrounding context.

The TTSQ is broken into two parts for synchronization and execution (Forwarding/tagging is a function of how the program is mapped). Part of this process involves parsing through keyword arguments in the AST’s of the function definition and its usage in the graph; keywords beginning with ‘TT’ are often metasyntax for parameterizing firing rules or control mechanisms. Otherwise, any keyword arguments in the definition and function call are respected in the SQ at runtime (but must be constant valued parameters; not arcs!).

Parameters:

• astNode (ast.AST (may be one of several subtypes, like _ast.Call)) – The abstract syntax tree node (generally, a Call object) from the GRAPHify-cation

• functionASTnode (ast.FunctionDef) – The abstract syntax tree node for the function decorated with SQify or STREAMify

• context (TTSQContext) – The context surround the SQ

• sq_name (string) – The name of the SQ; this should be unique within the graph. This is accomplished during compilation by appending a counter to the end of the function name

• input_arcs (list(TTArc)) – A list of input arcs that represent the symbols or variable defined in the graph

• constraints (list) – Contraints on the mapping of this SQ

• interpreter (TTInterpreter) – An enumerated variable describing the environment that must be used to interpret the SQ’s TTSQExecute portion. Currently, this only supports Python3

• firing_rule_type (TTFiringRuleType) – A desgnator for the type of the firing rule, defaulting to ‘Timed’ (which looks for any amount of overlap in the time interval in the token TTTag)

• clock_dict (dict) – A dictionary of clocks defined in the graph, default to empty ({})

port_number_of_input_symbol(input_symbol)

Determine the port number(s) that an input symbol would arrive on. There may be multiple in case an argument is used multiple times as inputs to the same function (e.g., a Multipy node attempting to square a value)

Parameters:

input_symbol (string) – The name of an input symbol (variable name) from the compilation process. Inlined expressions may generate their own symbols (format $N, for integer N)

Returns:

A list of port numbers that the input symbol will be used at

Return type:

list(int)

set_input_arcs(arcs)

Set the input arcs for this SQ, first checking to ensure they match the expected number of ports

Parameters:

arcs (list(TTArc)) – The set of arcs that feed into this SQ

setup_args(astNode, functionAstNode, firing_rule_type=TTFiringRuleType.Timed, clock_dict=None)

Analyze the arguments in the function and graph, specifically the arguments with default values, as these are not arcs, but parameters (potentially meta-parameters for the TTPython runtime)

Parameters:

• astNode (ast.AST (may be one of several subtypes, like _ast.Call)) – The abstract syntax tree node (generally, a Call object) from the GRAPHify-cation

• functionASTnode (ast.FunctionDef) – The abstract syntax tree node for the function decorated with SQify or STREAMify

• firing_rule_type (TTFiringRuleType) – A desgnator for the type of the firing rule, defaulting to ‘Timed’ (which looks for any amount of overlap in the time interval in the token TTTag)

• clock_dict (dict) – A dictionary of clocks defined in the graph, default to empty ({})

setup_meta_kwargs(astNode, firing_rule_type=TTFiringRuleType.Timed, clock_dict=None)

Analyze the meta keywords (generally starting with ‘TT’) and attach those to the arguments used for the synchronization (firing rule) or execution kwargs instance variable (a dictionary). This will loop through all the keyword args and look only for those we know to check for. Anything generic should already be handled.

Parameters:

• astNode (ast.AST (may be one of several subtypes, like _ast.Call)) – The abstract syntax tree node (generally, a Call object) from the GRAPHify-cation

• firing_rule_type (TTFiringRuleType) – A desgnator for the type of the firing rule, defaulting to ‘Timed’ (which looks for any amount of overlap in the time interval in the token TTTag)

• clock_dict (dict) – A dictionary of clocks defined in the graph

class ticktalkpython.SQ.TTSQContext(name='(no name)', clockspec=None, planB_handler=None, deadline=None, base_context=None, constraints=None)

An SQ Context refers to contextual information that surrounds the SQ, similar to scoping in more traditional sequential programming languages.

The mechanisms within the context are based on TTPython synxtax from ‘with’ constructs, which are used to specify clocks, backup (plan B) callbacks/handlers, deadlines, mapping constraints, etc. Multiple SQs may use the same context

class ticktalkpython.SQ.TTSQPattern(value, names=<not given>, *values, module=None, qualname=None, type=None, start=1, boundary=None)

An enumeration for different types of SQs in terms of their input-output characteristics