Visible to Intel only — GUID: hdv1697795497854
Ixiasoft
Visible to Intel only — GUID: hdv1697795497854
Ixiasoft
12.2.1. Dependent Latency Expressions
The expression is a MATLAB string. You can write the dependent latency expression directly into the GUI field or construct and evaluate it from a MATLAB expression.
The default value is an empty string '', which signifies no dependency.
The figure shows the dependent latency expression field in the SynthesisInfo block GUI:
The dependent latency expression field is a subexpression that is part of a larger Constrain Latency expression including the preceding fields. Typically, set these fields as shown e.g. ‘= 0 +’.
The dependent latency expression allows you to define the latency of your model (or of a dependent delay block) as a function of the latencies of one or more other DSP Builder models.
DSP Builder can then balance parallel datapaths that take routes through different subsystems in your design.
You may depend on the latency of primitive scheduled subsystems (those with a SynthesisInfo block) and Model IPs (such as a FIR filter, for example). DSP Builder then schedules and builds these subsystems. Except where you constrain the schedule to have a fixed latency value, those subsystems have latencies that are unknown before DSP Builder builds them and the latencies may change in various circumstances.
Dependent Latency Requirements in Large Designs
Dependent latency requirements arise when you create large designs comprising multiple subsystems and you need to impose a latency relationship between them. DSP Builder balances datapaths within a primitive scheduled subsystem such that, for example, all paths between a ChannelIn and ChannelOut block have the same latency. DSP Builder balances paths within subsystems. However DSP Builder does not automatically balance datapaths between different subsystems.
Dependent latency expressions allow you to solve this problem in larger designs with multiple subsystems.
Scheduled vs Algorithmic Latency
A dependent latency expression allows you to obtain and use the scheduled latency of other subsystems in an expression for the latency of the current subsystem.
DSP Builder dynamically determines this scheduled latency when it builds the subsystem. Using dependent latency expressions allows you to include this otherwise unknown or changeable value.
However, algorithmic latency may also contribute to the overall input-to-output delay in a subsystem you depend on. Where the subsystem has algorithmic latency, you must add it to the scheduled latency to obtain the overall latency expression.
The algorithmic latency of a subsystem occurs where the algorithm you implement calls for explicit delays in the datapath.
Latency of Other Subsystems
You need to decide if you can depend on the latency of another scheduled subsystem. If no simple singular temporal relationship exists between the inputs and outputs of a subsystem, it does not have a latency that you can depend on.
Not all FIR filter configurations have a definite latency as they may be rate changing or not have an input and output every clock-cycle.
A BitReverse block lacks a definite latency because it exhibits batch-burst behavior and accepts many inputs into an internal buffer with no output. Then when it receives a final input, DSP Builder streams out all outputs without needing any further inputs.
How you use the subsystem may effect its latency. For example, if you provide an input on every clock cycle, a singular input or output relationship may exist, even though such a relationship does not exist if you allow arbitrary gaps in input data.
FIR Filter Latency
A subsystem may have algorithmic latency. For the DSP Builder FIR filter, DSP Builder automatically determines and includes its algorithmic latency in the latency it obtains from referencing it.
If a FIR filter does not have latency you can depend on, DSP Builder generates an error.
Example
For the Crest Factor Reduction reference design (demo_cfr_deplat), the design needs to balance the delay on four data paths. Three paths pass through different FIR filters and the fourth path bypasses all the filters.
The design must balance all paths so that the delay is that of the longest path.
For the path that bypasses all FIR filters, the dependent latency expression should mean that ‘this path is required to be delayed by the maximum of all FIR paths’.
For each path appended to a FIR filter, the dependent latency expression should mean that ‘an additional delay is required, equal to the maximum of all FIR latencies, minus the latency of this FIR’. The 'mml' function allows you to implement these expressions.
The Simulink Assert block confirms that the valid signals on all four paths are aligned and so always have the same value.
The mml Function
Several functions are available for you to use in subexpressions. Most have common meanings, but mml is a shorthand for a commonly needed subexpression ‘max minus last’.
For a series of parameters the mml function finds the maximum of all parameters and then subtracts the value of the last parameter. It is an equivalent but shorter way of expressing (for example) ‘max(x,y,z) – z’. It eliminates both the minus and the repeated subexpression 'z'.
Syntax Definition
You build dependent latency expressions as MATLAB strings.
Within the MATLAB string, you write a dependent latency expression as an expr in the following grammar:
expr ::= ( neexpr ) neexpr ::= [ val | neexpr infix neexpr | func ] infix ::= [ '+' | '-' ] func ::= fname '(' neexpr ( ',' neexpr )* ')' fname ::= [ 'max' | 'sum' | 'mml' ] val ::= [ num | path ] num ::= ('0'..'9')+ path ::= [ simplepath | '\'' richpath '\'' | '"' richpath '"' ] simplepath ::= < simulink path expression without exotic characters such as spaces or minus sign; must include at least one path separator '/' > richpath ::= < simulink path expression with exotic characters such as spaces or minus sign allowed; must include at least one path separator '/' >
Comments:
- An expression is optionally a non-empty expression, so it can be empty.
- A non-empty expression is a value, a pair of subexpressions combined by an infix operator ('+' or '-'), or a function.
- Functions have one or more parameters, each a subexpression.
- A function can be the 'max' of the contained subexpressions, or the 'sum' of them, or 'mml'.
- A value is either a non-negative number or a Simulink path. Simulink paths appear for example in the title bar above the sheet you are viewing and express a hierarchy of subsystems in your design, with ('bdroot') at the root and '/' to separate levels.
- As the syntax has no macro capability or aliasing of paths or subexpressions, you must write each use in full. However, you can construct your expression in MATLAB.
- You cannot use brackets to change evaluation precedence. Brackets always only indicate function application.
- Only enter non-negative numbers. Simulink paths always have non-negative latency, but negative values can legitimately arise during evaluation. It is only an error if the whole dependent latency expression evaluates as negative.
- Numeric values allow you to add algorithmic latencies to your expressions.
- Intel suggest you construct the expression programmatically either in the setup.m file or the mask of the subsystem encapsulating the dependent latency use.
For quotes:
- When you place a Simulink path in an expression, you may surround it with either single or double quotes, which you must do if the path contains more exotic characters such as spaces.
- When you need to place a single quote within a MATLAB string, which is also delimited in single quotes, a literal single quote is expressed by a pair of single quotes.
- Use quotes if in doubt about your Simulink path content.