Due to a problem in the DSP Builder Advanced Blockset version 17.1 and earlier, you may see the following errors if Simulink® executes other bus blocks before the BusStimulus block.
- The write enable on the deprecated BusSlave block will never assert
- Other outputs on all bus blocks will occur one clock cycle later
In DSP Builder, the bus blocks (e.g. the RegField block) are dependent on the BusStimulus block: there is an implicit wire between them. Therefore, Simulink should execute the BusStimulus blocks before any other bus blocks. However, Simulink does not know about this dependency, so Simulink is free to execute these blocks in an arbitrary order.
The execution order of the bus blocks might change due to unrelated changes to the design. For example, a design that relied on the bus latency for auto-verification might start failing because you added an additional Scope block. The additional block might change the execution order by putting a RegField block before the BusStimulus block, thus altering the latency between them.
To work around this problem, set the Priority of the BusStimulus block to a value lower than the subsystem block containing the DSP Builder design. For example, set the BusStimulus block Priority to 0 and the DSPBA subsystem block to 1. Simulink should execute the BusStimulus block before anything in the subsystem, which guarantees consistent bus operation.
To view the execution order: from the main menu bar, select Display -> Blocks -> Sorted Execution Order
To set a block’s Priority: right-click the block, select Properties: the Priority field is in the General tab
Note: Priority values are similar to execution order in that a lower value means execute first. However, priority values differ from execution order in that they do not span subsystems, this is the reason for the requirement to set the priority on the DSP Builder subsystem rather than the bus blocks contained within it.