Simulink Variable Time Delay - is this a bug?

Hi all. I have attached two similar Simulink models for testing Simulink's Variable Time Delay module. The only difference between the two models is that I have placed the Variable Time Delay module ahead of a divide-by-four module (for one model). The other model has the same Variable Time Delay module placed before a divide-by-four module. For both Simulink models, an identical amount of delay is applied.

I was expecting that the Simulink Scope output of both Simulink models to be the same. However, one of the models appears to apply the wrong amount of delay.

In my two attached Simulink model files, one model provides the correct delay of 1E-5 seconds. While the other model provides the wrong delay of 0.5E-5 seconds (which turns out to be always one clock period less than what I wanted to apply, which means I would need to manually add an extra 0.5E-5 seconds to whatever I wanted to apply in order to achieve the correct observed delay on the Simulink Scope).

Does anyone know if there are bugs associated with Variable Time Delay? And could this behaviour shown in these attached simulink models be a bug?

I'm not excluding rookie error though! I'm just trying to figure out why one model always has a delay that is always 1 clock period short (ie. 0.5E-5 second short) of what I wanted to apply.

Also, an interesting thing about the model that I named 'incorrect_delay.slx' is that applying a time delay of 0.0 will truly provide zero delay as seen in the Scope. But applying a delay such as 0.000001 is seen to introduce of time advancement (a lead, not a lag!!) of 0.5E-5 seconds, which appears quite suspicious.

Thanks all.

Answer 1

[Kenny]

With the help of Mathworks, it turns out that the "Initial Condition" value (setting) within the Variable Time Delay module (accessed by double-clicking on it) can effect on the delay!

Originally, I had the initial condition (ie. default initial output value) set to the default value of '0' (ie. zero), which resulted in wrong delay. But when I set the initial condition output value to '1' (ie. one), everything worked properly.

The reason for the skip in time step due to setting initial value of '0' is due to the edge trigger setting of the flip-flop. Whether the flip flop triggers (or not) depends on initial value setting of the Variable Time Delay. This condition is not necessarily obvious unless it is pointed out.