AR# 30131: System Generator for DSP - Why is the sample rate passed to Simulink blocks from my gateway out different than the sample rate passed to my System Generator blocks?
System Generator for DSP - Why is the sample rate passed to Simulink blocks from my gateway out different than the sample rate passed to my System Generator blocks?
Keywords: FIR Compiler, FFT, sample rate probe, sample time
The sample rate of my FIR Compiler output should be four, but when I send that signal to a Simulink block, it processes as though the sample rate is one. Why is the sample rate passed to Simulink blocks from my gateway out different than the sample rate passed to my System Generator blocks?
If there is no register between a block with internal oversampling and a gateway out, the sample rate that is reported to Simulink can be incorrect. The data coming out still changes at the appropriate rate and if this signal drives additional System Generator blocks, they will inherit the appropriate rate. However, if such a block connects directly to a gateway out, the Simulink blocks can "see" a different rate. An example of this is a MAC FIR with an internal rate faster than the data rate at the output port that connects directly to a gateway out.
If you perform a model update (Ctrl-D), the correct rate is seen on all ports, and you can see what the rates will be for the actual hardware that is generated. This can be a problem if you are trying to view the results on a Simulink plot that uses relative sample rates to display the results, such as an FFT plot.
This occurs because of the way the System Generator scheduler interacts with Simulink blocks. The gateways are the perimeter of where System Generator performs its own internal simulation scheduling. When a signal is passed to Simulink, System Generator determines the sample rate of the signal. Since this interface is used to trigger or "wake up" the blocks to execute a simulation cycle, the rate that is passed to Simulink must be the highest rate required by that block for proper operation. For internally oversampled blocks, the rate must be the highest rate in the block for the block to be executed at every internal cycle, as well as the rate of the output signals.
To correct the rate seen by Simulink, add a "Zero Order Hold" block after the Gateway out and use it to resample the data at the expected rate.
Note that this does not affect the hardware behavior, and the data coming out of the System Generator blocks is absolutely correct. In the Simulink realm, they are simply being sampled at a higher rate than necessary.