Multiple Simulink runs only changing signal vector

I'm much more practiced at MATLAB than Simulink, but this problem has stumped me on a few models. I do signal processing and am using Simulink->HDL Coder so doing more in Simulink. I want to sometimes run "Monte Carlo" runs of a model with randomized signal streams to for instance calculate Probability of Detection. However, I've tried From Workspace blocks and Signal From Workspace and any time you simply rebuild the signal vector it triggers a model recompile. I want to be able to have a simple iteratative loop (and ability to parfor would be nice) that builds the signal, calls sim() (preferably in 'rapid' mode) and then parses the output, without recompiling every time. Is Binary File Reader the only viable option? The parsim() documentation talks about establishing Configuration Sets but that seems very confusing and I'm not sure it avoids the problem. Examples that have solved this would be most helpful.

Answer 1

[Murali Yeddanapudi]

Hi Martin:

Bharath brought your quesiton to my attention.

Firstly you are correct that changing the From Workspace variable causes the rapid-accelerator target rebuilt. We plan to fix this in a future release so that it does not rebuild and works as you expect with RapidAcceleratorUpToDateCheck off.

In the latest release, R2023b, using the root-level input port to feed the input sequence can avoid rebuild. I have attached a modified version of the example (that Bharath linked above) to demo this approach.

Best Regarfs

Murali

[Martin Ryba]

I haven't tried it in R2023b yet, but in order for my flow control to work, the signal must be presented as essentially a vector buffer constant. I finally got the Root Level Inport approach to work in R2022b (the structure didn't work, but making it a timetable with t=0 did), but I noticed that at least in Accelerator mode the simulation took much longer. When I instead changed that port feed to a Constant block with the vector as payload, the run time was back to where it was when that vector was a parameter to an enabled Signal From Workspace block. However, changing the vector input to a Constant block apparently still triggers a rebuild in Rapid mode.

[Murali Yeddanapudi]

Changing a Constant block's value from run-to-run should not trigger a rebuild. If you can send us reproduction steps (with the necessary files), I can look into it.

The wall clock execution time in accelerator (or rapid accelerator) mode can be longer in some cases, if the computational content of the model is dominated by precompiled/optimized blocks implemented a C-Mex S-Functions. Not sure if this applies in your case, if you can send an example, we can dig into it and see if we can speed up the accelerator modes.

[Martin Ryba]

Thanks Murali, when I built a simpler model using that same sample writer and constant block you're correct it didn't force a recompile. I'm getting a fairly generic "Generated code was out of date." reason. Running through the checksum process, I finally located the culprit: my test sample generator was inadvertently generating a buffer that changed length each interation (a variable delay at the front to test Time of Arrival computation). When I forced it to fixed length, that cleared it up. Thanks!

Answer 2

[Bharath Venkataraman]

This example shows how to accelerate BER measurements for HDL LTE Turbo Decoder model with data from MATLAB feeding a Simulink model. Does this help?

[Martin Ryba]

It helps, once I figured out some of the logic. However, each time the stimulus changes, I still see a recompile because the variable was changed.

The example uses the same Signal From Workspace block, so I don't know what's different. If I set RapidAcceleratorUpToDateCheck to 'off' then the signal doesn't update. Is this a difference between sim() and parsim()?

Update: running with parsim() and watching the behavior of the CPU, I think it's just doing the recompile "under the hood." The recompile takes ~5 minutes while the execution takes about 1 minute. I think your example model is just too small to see it happening.

[Bharath Venkataraman]

I will check with some of the Simulink folks to see what the best approach is. One thing you could try is to put most of the model into another model and use model reference. That may reduce the time for the model compilation since the top level model will be pretty simple (assuming the model reference will need no compilation).

[Martin Ryba]

Yes, we already do that. The "test bench" model is pretty much just stimulus and data recording; the core is incorporated by reference and is what is set up to be converted by HDL Coder. I tried to see if Root Level Input ports provide a good mechanism, but that doesn't seem to be well configured for simulation input vectors/buffers. The incorporation of flow control is, I understand, an extra wrinkle (what makes defining them as timeseries/timetables a problem) but one that needs to be thought through as a normal use case.