Our group looked at this more closely, and I now understand why the standard delay block with an enable port works the way that it does (which can be simply stated as: data is delayed until the next input enable comes in - at which time it goes out immediately). I can see this being useful, but it is not the behavior that I want usually. We decided to call the block that I want a Load Register (which acts like the Obsolete component does which is to say: data is loaded into the the register only when paired with enable = 1 and there is a 1 clock delay before the data shows up at the output). We will just have to build it with components (or M-code) given I don't want to keep using an Obsolete Block (which seems to still work in 2016b, but I'm going to substitute it out).
Delay with Show Enable Port not working as expected
3 views (last 30 days)
Show older comments
I just noticed that previous models I had built using the Unit Delay Enabled block were still simulating without error but the help page on this block now says "Obsolete" (as of 2016b). So I created a test model for the suggested replacement which is a standard delay element with "Show enable port" option checked. It does not work as expected (see sim). Can anyone explain the way it behaves? It would seem problematic to obsolete a block without an exactly equivalent one (unless you build your own replacement which is where I'm leaning now).
My sim uses 3 designs for an enabled register. 1) build-your-own: a delay element without an enable port is used with a switch at the input, 2) 'Unit Delay Enabled' (now obsolete), 3) standard delay block with enable port option.
Here is the output:
clk din en dout_1 dout_2 dout_3
0 1 0 0 0 0
1 2 0 0 0 0
2 3 1 0 0 0
3 4 0 3 3 0
4 5 1 3 3 3
5 6 0 5 5 3
6 7 1 5 5 5
7 8 0 7 7 5
8 9 1 7 7 7
9 10 1 9 9 9
10 11 1 10 10 10
Notice that designs 1 and 2 act identically but design 3 is late at the output when an enabled input causes a change in value, but only if it can be late - i.e. if there is no enable on the next clock bringing in another value. So on clk = 4, the value 3 comes out 2 clocks later because there is no enable on the clock after the input value 3, but the value 9 comes out at the expected time (clk = 9) because there is an enable on the next clock.
This seems pretty strange to me.
Note for reference, here is my command to instantiate a Unit Delay Enabled block:
add_block('simulink/Additional Math & Discrete/Additional Discrete/Unit Delay Enabled', [sys '/' er],'Position', pos);
Thanks, Dara
4 Comments
Ian Winter
on 8 Aug 2017
I have encountered essentially the same issue; namely that the "delay with show enable" block does not have the same behaviour as the now obsolete "unit delay enabled" block it is intended to replace. Is there any way to get back the old block? The new behaviour seems much less useful as it prevents the use of, for example, single clock cycle enable pulses latching a signal. The data is only outputted at the second rising edge (for a single delay) and the delay in general is based upon the enable signal and not simply the sampling rate.
Ludo Visser
on 6 Aug 2018
Just to add to this: it's not only in HDL coder that this causes issues. Also in a "regular" Simulink model the behavior is like described. Coincidentally, it can also be solved in "regular" models by putting the delay block in a Synchronous subsystem, which is probably only available if you have the HDL coder toolbox to begin with...
Answers (1)
Dara Parsavand
on 6 Aug 2018
1 Comment
Ludo Visser
on 7 Aug 2018
If you look under the mask of the Unit Delay Enabled Synchronous, you'll find a regular delay block with enable port and a state control block set to synchronous, like Kiran Kintali was suggesting. I hope it makes it way back to the regular Simulink toolbox also...!
See Also
Categories
Find more on HDL Coder in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!