baesae
Electrical
- Dec 6, 2011
- 1
Hello
I'm using Simulink and HDL-Coder to generate code for some hardware algorithm for OCT (doesn't really matter for the problem underneath
)
Recently I discovered a strange behavior when debugging in simulink: the input data did not change on every clock, even though the input vector changes its value for every sample-time.
I checked the sample time (fixed step size) for the simulation as well as the sample time vector in the matlab code. But they fit to each other.
Therefore I made a small example to see, whether I could reproduce this 'error'. As you can see in the picture I have the simplest possible simulink model containing an 'from workspace' and a 'to workspace' block. using the settings from underneath I keep receiving a strange behavior for the output. the first half of the ramp is constantly increasing whereas the second half looks has some "edges" (a few samples are not loaded on time)
Settings/configs:
--> sample rate of the 'from workspace' block equals 0.1 (equals simulations fixed step size)
--> 'to workspace' block has sample time "inherited" (--> 0.1 as well)
--> matlab code (as in the screenshot) is:
dt = 0.1;
N = 200;
time = -0.01:dt
N-1)*dt;
sample = linspace(0,N-1,N);
%samples = [time', sample'];
samples.time = time';
samples.signals.values = sample';
sim('test_data_read_in.mdl', N*dt);
You may know this problem from timing problems in hardware when not respecting the set-up-times for components and so on. But Simulink should NOT behave like hardware, I guess.. Despite that I tried to make the input-signals valid shortly before they will be read in (likely respecting set up time in hardware). And it worked! The ramp of the output data was neat!
Code:
dt = 0.1;
N = 200;
time = -0.01:dt
N-1)*dt;
sample = linspace(0,N-1,N);
%samples = [time', sample'];
samples.time = time';
samples.signals.values = sample';
sim('test_data_read_in.mdl', N*dt);
I experienced the same problems with Lookup-tables.
Anybody encountered this problem before or has an idea how to avoid it?
Thanks a lot for your help!
baesae
I'm using Simulink and HDL-Coder to generate code for some hardware algorithm for OCT (doesn't really matter for the problem underneath
Recently I discovered a strange behavior when debugging in simulink: the input data did not change on every clock, even though the input vector changes its value for every sample-time.
I checked the sample time (fixed step size) for the simulation as well as the sample time vector in the matlab code. But they fit to each other.
Therefore I made a small example to see, whether I could reproduce this 'error'. As you can see in the picture I have the simplest possible simulink model containing an 'from workspace' and a 'to workspace' block. using the settings from underneath I keep receiving a strange behavior for the output. the first half of the ramp is constantly increasing whereas the second half looks has some "edges" (a few samples are not loaded on time)
Settings/configs:
--> sample rate of the 'from workspace' block equals 0.1 (equals simulations fixed step size)
--> 'to workspace' block has sample time "inherited" (--> 0.1 as well)
--> matlab code (as in the screenshot) is:
dt = 0.1;
N = 200;
time = -0.01:dt
sample = linspace(0,N-1,N);
%samples = [time', sample'];
samples.time = time';
samples.signals.values = sample';
sim('test_data_read_in.mdl', N*dt);
You may know this problem from timing problems in hardware when not respecting the set-up-times for components and so on. But Simulink should NOT behave like hardware, I guess.. Despite that I tried to make the input-signals valid shortly before they will be read in (likely respecting set up time in hardware). And it worked! The ramp of the output data was neat!
Code:
dt = 0.1;
N = 200;
time = -0.01:dt
sample = linspace(0,N-1,N);
%samples = [time', sample'];
samples.time = time';
samples.signals.values = sample';
sim('test_data_read_in.mdl', N*dt);
I experienced the same problems with Lookup-tables.
Anybody encountered this problem before or has an idea how to avoid it?
Thanks a lot for your help!
baesae