2.7.2. Runtime Reconfigurable Options
When you use Runtime Trigger mode, you can change certain settings in the .stp without requiring recompilation of the design.
|Runtime Reconfigurable Setting||Description|
|Basic Trigger Conditions and Basic Storage Qualifier Conditions||Change without recompiling all signals that have the Trigger condition turned on to any basic trigger condition value|
|Comparison Trigger Conditions and Comparison Storage Qualifier Conditions||
All the comparison operands, the comparison numeric values, and the interval bound values are runtime-configurable.
You can also switch from Comparison to Basic OR trigger at runtime without recompiling.
|Advanced Trigger Conditions and Advanced Storage Qualifier Conditions||Many operators include runtime configurable settings. For example, all comparison operators are runtime-configurable. Configurable settings appear with a white background in the block representation. This runtime reconfigurable option is turned on in the Object Properties dialog box.|
|Switching between a storage-qualified and a continuous acquisition||Within any storage-qualified mode, you can switch to continuous capture mode without recompiling the design. To enable this feature, turn on disable storage qualifier.|
|State-based trigger flow parameters||Refer to Runtime Reconfigurable Settings, State-Based Triggering Flow|
Runtime Reconfigurable options can save time during the debugging cycle by allowing you to cover a wider possible range of events, without requiring design recompilation. You may experience a slight impact to the performance and logic utilization. You can turn off runtime re-configurability for advanced trigger conditions and the state-based trigger flow parameters, boosting performance and decreasing area utilization.
To configure the .stp file to prevent changes that normally require recompilation in the Setup tab, select the Allow Trigger Condition changes only lock mode above the node list.
This example illustrates a potential use case for Runtime Reconfigurable features, by providing a storage qualified enabled State-based trigger flow description, and showing how to modify the size of a capture window at runtime without a recompile. This example gives you equivalent functionality to a segmented buffer with a single trigger condition where the segment sizes are runtime reconfigurable.
state ST1: if ( condition1 && (c1 <= m) )// each "segment" triggers on condition // 1 begin // m = number of total "segments" start_store; increment c1; goto ST2: end else (c1 > m ) // This else condition handles the last // segment. begin start_store trigger (n-1) end state ST2: if ( c2 >= n) //n = number of samples to capture in each //segment. begin reset c2; stop_store; goto ST1; end else (c2 < n) begin increment c2; goto ST2; end
The next figure shows the segmented buffer that the trigger flow example describes.
During runtime, you can modify the values m and n. Changing the m and n values in the trigger flow description adjust the segment boundaries without recompiling.
You can add states into the trigger flow description and selectively mask out specific states and enable other ones at runtime with status flags.
This example is like the previous example with an additional state inserted. You use this extra state to specify a different trigger condition that does not use the storage qualifier feature. You insert status flags into the conditional statements to control the execution of the trigger flow.
state ST1 : if (condition2 && f1) // additional state for non-segmented // acquisition set f1 to enable state begin start_store; trigger end else if (! f1) goto ST2; state ST2: if ( (condition1 && (c1 <= m) && f2) // f2 status flag used to mask state. Set f2 // to enable begin start_store; increment c1; goto ST3: end else (c1 > m ) start_store; trigger (n-1) end state ST3: if ( c2 >= n) begin reset c2; stop_store; goto ST1; end else (c2 < n) begin increment c2; goto ST2; end
Did you find the information on this page useful?