Testbench with clock issue

[Kyle H.]

I am trying to generate a clock signal and other stimuli in this
testbench. What am I doing wrong about the clk generation? I get and
error duing run time simulation, because of that line. I've used the
clock generation code before without a process for other stimuli, and
it worked great, but now, what gives?

# ** Error: (vsim-3601) Iteration limit reached at time 0 ns.


--=================================================================
LIBRARY IEEE;
USE IEEE.std_logic_1164.all;

ENTITY fsm1_tb IS
END fsm1_tb;

ARCHITECTURE fsm1_tb_arch OF fsm1_tb IS

COMPONENT fsm1
PORT(w, clock, reset: in std_logic;
z: out std_logic);
END COMPONENT;

CONSTANT clkperiod: TIME := 1 ns;
SIGNAL test_w: std_logic;
SIGNAL test_clock: std_logic := '0';
SIGNAL test_reset: std_logic;
SIGNAL test_z: std_logic;
SIGNAL value: std_logic_vector (0 TO 17) := "010111100110011111";

BEGIN
UUT:fsm1
PORT MAP(w => test_w, clock => test_clock, reset => test_reset, z
=> test_z);

test: PROCESS
BEGIN
test_reset <= '0';
FOR i IN 0 TO 17 LOOP
test_w <= value(i);
WAIT FOR 1 ns;
END LOOP;

test_reset <= '1';
WAIT FOR 1 ns;
test_reset <= '0';
END PROCESS test;


test_clock <= NOT test_clock AFTER clkperiod/2; --CLK Generation

END fsm1_tb_arch;
--=================================================================

P.S. Yes I am a noob.

 

[KJ]

Kyle H. wrote:
I gather that the question is simply about the signal 'test_clock'
where you have

test_clock <= NOT test_clock AFTER clkperiod/2; --CLK Generation

This statement needs to be inside a process like this...

process
begin
test_clock <= NOT test_clock AFTER clkperiod/2; --CLK Generation
wait for clkperiod;
end process;

The signal test_clock also needs to be initialized in the signal
declaration (you might have this...but I deleted it and now wish I
hadn't)...

signal test_clock: std_logic := '0';

The way I generally write this is...

signal test_clock: std_logic; -- NO initial value required
....
process
begin
test_clock <= '0', '1' AFTER clkperiod/2; --CLK Generation
wait for clkperiod;
end process;

 

[Ajeetha]

Hi,
2 calculated guesses:

1. Your time resolution is default - i.e. 1ns, hence clkperiod/2 -->
1ns/2 becomes 0.
Set this in modelsim.ini:

Resolution 100ps

(Refer to doc for exact syntax)

2. Your second process may need a "wait" to hang up after toggling
reset.

BTW - this way of "isolated toggling" of signals in various processes
doesn't scale up well. If you have a complex design, there are better
testbench techniques, start looking at WTB book from Janick perhaps.

Regards
Ajeetha, CVC
www.noveldv.com

 

[Kyle H.]

Thanks for the replies, I was looking at it wrong, and like Ajeetha
mentioned. Changing my clockperiod to 10ns fixed my problem.

 

[Paul Uiterlinden]

KJ wrote:

Kyle H. wrote:
I gather that the question is simply about the signal 'test_clock'
where you have

test_clock <= NOT test_clock AFTER clkperiod/2; --CLK Generation

This statement needs to be inside a process like this...

No, it does not. The way the OP has written his code is perfectly OK.
The concurrent signal assignment triggers itself, generating the
clock that is wanted.

process
begin
test_clock <= NOT test_clock AFTER clkperiod/2; --CLK Generation
wait for clkperiod;
end process;

Too many lines. ;-)

signal test_clock: std_logic; -- NO initial value required
...
process
begin
test_clock <= '0', '1' AFTER clkperiod/2; --CLK Generation
wait for clkperiod;
end process;

OK, that is a real advantage: no initial value needed.

What I still miss is stopping the clock at the end of simulation. I
write my clock generators always like this:

clk <= NOT clk AFTER clk_hp WHEN simulate ELSE '0';

clk_hp is a constant (half clock period) and simulate is a signal of
type boolean. This signal is assigned FALSE at the end of the
simulation. Provided that every self-generating process uses this
signal to stop, the whole simulation will end because there are no
events anymore.

--
Paul.

 

[KJ]

"Paul Uiterlinden" <paulu@sx4all.nl> wrote in message
news:4523fbea$0$5890$e4fe514c@dreader29.news.xs4all.nl...

No, it does not. The way the OP has written his code is perfectly OK.
The concurrent signal assignment triggers itself, generating the
clock that is wanted.
Yep, I was just having a brain fart at the time, should've read a bit

closer....in fact had I 'looked again' to see if the OP had an
initialization for test_clock I would've seen that it did and not gone off
on my path thinking that test_clock was unknown....which wasn't the case at
all....it was simply too small of a time step for the default sim time unit
resolution. Note to newsgroup: 'Late in the day' KJ advice occasionally
leaves something to be desired...as does the 'early in the day' at times.

What I still miss is stopping the clock at the end of simulation. I
write my clock generators always like this:

clk <= NOT clk AFTER clk_hp WHEN simulate ELSE '0';
I have basically the same type of boolean but call it 'Simulation_Complete'

and find 'Clock_Period / 2' for my delay to be more descriptive. I
basically do the same thing as you but inside a process....but I like the
one liner approach better...well as long as I remember to initialize the
clock signal which, since signal inits are not something you 'normally' have
in the RTL, I'm sure I'll forget to do once or twice.

KJ

 

[Paul Uiterlinden]

KJ wrote:

Note to newsgroup: 'Late in the day' KJ advice
occasionally leaves something to be desired...as does the 'early in
the day' at times.

Still that leaves one question: what timezone are you in? ;-)

What I still miss is stopping the clock at the end of simulation. I
write my clock generators always like this:

clk <= NOT clk AFTER clk_hp WHEN simulate ELSE '0';
I have basically the same type of boolean but call it
'Simulation_Complete'
and find 'Clock_Period / 2' for my delay to be more descriptive.

Perhaps, but it does have the risk that it may not be dividable by two
(as the OP knows by now).

Btw: your process solution has the nice property that the clock runs
on clockperiod, even if clock_period cannot be divided by two without
loss of precission. With the one liner that is not the case.

I
basically do the same thing as you but inside a process....but I
like the one liner approach better...well as long as I remember to
initialize the clock signal which, since signal inits are not
something you 'normally' have in the RTL, I'm sure I'll forget to do
once or twice.

Been there, done that! It sometime happens in the beginning of
creating a new testbench. But it is easy to locate, especially once
you have seen it before.

--
Paul.