are this two equivalent?

Hello,

first of all I am newbie to vhdl

I am playing with ghdl, learning syntax and
basic features of vhdl

since it creates a runnable executable for
simulation I was looking for a way to
let my simulation run 20 clock cycles
and then stop it (otherwise it would stay in
forever loop)

here are 2 tries, which are identical from my point of view
but the first doesn't stop simulation

architecture testbench of tb is
-- some code ..
signal run: bit := '1';
signal clk: std_logic := '0';
begin
-- first try
process
begin
wait for 20 ns; -- 1
run <= '0'; -- 2
end process;

-- second try
--run <= '0' after 20 ns; -- 3

process(clk)
begin
if run = '1' then
clk <= not clk after 1 ns;
end if;
end process;
end;

doesn't 1 block the process for 20 ns?
(and then assign '0' to run)

Regards, Daniel

=?ISO-8859-1?Q?Sch=FCle_Daniel?=

I just tried this and it worked also

process(clk)
variable cnt: integer := 0;
begin
if clk'event and clk = '1' then
cnt := cnt + 1;
if cnt = 20 then
run <= '0';
end if;
end if;
end process;

maybe I am misunderstanding what

wait for 20 ns;

means. I assume that it blocks for 20 ns
and then executes

run <= '0';

=?ISO-8859-1?Q?Sch=FCle_Daniel?=

Schüle Daniel <> writes:
> -- first try
> process
> begin
> wait for 20 ns; -- 1
> run <= '0'; -- 2
> end process;

The process doesn't stop. It just doesn't do anything visible (it
keeps assigning '0' to "run" every 20 ns). Try adding a single
wait-statement just before the end of the process.

-- Marcus

Marcus Harnisch

Schüle Daniel wrote:
> Hello,
>
> first of all I am newbie to vhdl
>
> I am playing with ghdl, learning syntax and
> basic features of vhdl
>
> since it creates a runnable executable for
> simulation I was looking for a way to
> let my simulation run 20 clock cycles
> and then stop it (otherwise it would stay in
> forever loop)
>
> here are 2 tries, which are identical from my point of view
> but the first doesn't stop simulation
>
> architecture testbench of tb is
> -- some code ..
> signal run: bit := '1';
> signal clk: std_logic := '0';
> begin
> -- first try
> process
> begin
> wait for 20 ns; -- 1
> run <= '0'; -- 2
> end process;
>
> -- second try
> --run <= '0' after 20 ns; -- 3
>
> process(clk)
> begin
> if run = '1' then
> clk <= not clk after 1 ns;
> end if;
> end process;
> end;
>
> doesn't 1 block the process for 20 ns?
> (and then assign '0' to run)
Yes it should....almost 'first try' should
- Initialize run to '1' because of the initial value given to it in the
signal declaration.
- Wait for 20 ns
- Set run to '0'. This should then cause your other process to stop
toggling 'clk'.
- Restart the process (i.e. wait for another 20 ns and then again
assign run to '0'). This 'restarting' will happen over and over even
though the value of run is not changing since it will keep getting set
to '0'.

This is 'almost' equivalent to your 'second try' (i.e. run <= '0' after
20 ns. Once again, the initial value comes from the signal
declaration and once again run will be set to '0' after 20 ns. In this
case though there is no 'restarting' of the process going on so once
the 'run <= '0' after 20 ns' statement completes it will do nothing
further.

The equivalent process is shown below. The only thing added is the
'wait forever' at the end. VHDL processes, once they complete,
'automagically restart'.
process
begin
wait for 20 ns; -- 1
run <= '0'; -- 2
wait; -- This will wait forever and prevent the
process from ever completing
end process;

I'm not quite sure when you say that it doesn't 'stop simulation'.
Your signal 'run' should switch from '1' to '0' at t=20 ns and that
should cause signal 'clk' to stop toggling. Are you not seeing that?
Or do you mean something else by 'stop simulation'?

By the way, yet another way to skin the cat is the assignment
run <= '1', '0' after 20 ns;

Now you don't need the initial assignment value where 'run' is declared
(i.e. you can just say signal run: bit Either way is OK though, just
yet another way to skin the cat and sometimes it clearer to keep all of
the things that assign values all in one place and keep signal
declarations as just that, things that simply declare signals.

KJ

KJ

Hi,

[...]

>> doesn't 1 block the process for 20 ns?
>> (and then assign '0' to run)
> Yes it should....almost 'first try' should
> - Initialize run to '1' because of the initial value given to it in the
> signal declaration.
> - Wait for 20 ns
> - Set run to '0'. This should then cause your other process to stop
> toggling 'clk'.
> - Restart the process (i.e. wait for another 20 ns and then again
> assign run to '0'). This 'restarting' will happen over and over even
> though the value of run is not changing since it will keep getting set
> to '0'.

ok I understand
process having no sensitivity list and no "wait on" is a kind of
while(1){} to put it in software mindset

> This is 'almost' equivalent to your 'second try' (i.e. run <= '0' after
> 20 ns. Once again, the initial value comes from the signal
> declaration and once again run will be set to '0' after 20 ns. In this
> case though there is no 'restarting' of the process going on so once
> the 'run <= '0' after 20 ns' statement completes it will do nothing
> further.

I know that everything between
architecture ... is
begin
-- runs in parallel
a <= '1';
a <= '0';
end;

eg one can't say wheather a is '0' or '1', right?

are there "triggers" (like sensitivity list in usuall process)
that force this "top level process" to rerun?


>
> The equivalent process is shown below. The only thing added is the
> 'wait forever' at the end. VHDL processes, once they complete,
> 'automagically restart'.
> process
> begin
> wait for 20 ns; -- 1
> run <= '0'; -- 2
> wait; -- This will wait forever and prevent the
> process from ever completing
> end process;

jepp, it's working fine now

> I'm not quite sure when you say that it doesn't 'stop simulation'.
> Your signal 'run' should switch from '1' to '0' at t=20 ns and that
> should cause signal 'clk' to stop toggling. Are you not seeing that?
> Or do you mean something else by 'stop simulation'?

ghdl generates a runnable program and this program
didn't exit
now I know more way to limit the running time
one need to provide --stop-time=20ns and it terminates
after 20 ns simulation time
I also use --vcd=out option so I can see the signals plot
over time (gtkwave out)

>
> By the way, yet another way to skin the cat is the assignment
> run <= '1', '0' after 20 ns;

indeed more information at one glance
it's programmers habit to always initialize variables
I try to apply it to vhdl

> Now you don't need the initial assignment value where 'run' is declared
> (i.e. you can just say signal run: bit Either way is OK though, just
> yet another way to skin the cat and sometimes it clearer to keep all of
> the things that assign values all in one place and keep signal
> declarations as just that, things that simply declare signals.
>
> KJ
>

thanks

Regards, Daniel

=?ISO-8859-1?Q?Sch=FCle_Daniel?=

Schüle Daniel wrote:
>
> I know that everything between
> architecture ... is
> begin
> -- runs in parallel
> a <= '1';
> a <= '0';
> end;
>
> eg one can't say wheather a is '0' or '1', right?
>
> are there "triggers" (like sensitivity list in usuall process)
> that force this "top level process" to rerun?
>
>
I think this wont work anyway, because signal (or port) 'a' has
multiple drivers. Your compiler of synthese-tool would give you an
error.

horst