Simulation issue - verilog

On Mon, 23 Jul 2007 23:40:59 -0000, "trescot@gmail.com"
<trescot@gmail.com> wrote:

>I am writing a test-bench in verilog. Its as follows.
>
>
>`timescale 1ns/100ps
>
>....
>....
>
>initial
> begin
> tb_tclk = 1'b0 ;
> Reset_tb = 1'b0 ;
> # 10000 $finish ;
> end
>
>
>always
> #10 tb_tclk = !tb_tclk ;
>
>
>initial
> begin
> $vcdpluson ;
> end
>
>
>
>Basically I want the clock to run for 10000 ns. When I open the vpd
>file, I am surprised to see the clock toggling just for 1 cycle
>instead of multiple cycles since the clock is 20 ns.
>
>I will appreciate for any feedback.
>
>
>Thanks
>Trescot

Your clock doesn't toggle because you haven't provided any reason for
it to toggle ie there is no reason for always statement to be
scheduled again. You have to type something like "always @(tb_clk)
...." to make it work.

On Mon, 23 Jul 2007 19:28:34 -0700, mk <kal*@dspia.*comdelete> wrote:

>On Mon, 23 Jul 2007 23:40:59 -0000, "trescot@gmail.com"
><trescot@gmail.com> wrote:
[...]
>>always
>> #10 tb_tclk = !tb_tclk ;

>Your clock doesn't toggle because you haven't provided any reason for
>it to toggle ie there is no reason for always statement to be
>scheduled again. You have to type something like "always @(tb_clk)
>..." to make it work.

eh????? can you then explain (a) where you think tb_clk is going
to come from, (b) what you think "always #10 a = !a;" should do?

I think the more plausible reason is that the OP has used the
wrong "run" command to their simulator, and has run the simulation
only for one (short) preset time interval. Try

run -all (ModelSim)
. (VCS)
run (NC)

at the simulator's command prompt. The code looks OK to me.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

On Jul 23, 9:38 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Mon, 23 Jul 2007 19:28:34 -0700, mk <kal*@dspia.*comdelete> wrote:
> >On Mon, 23 Jul 2007 23:40:59 -0000, "tres...@gmail.com"
> ><tres...@gmail.com> wrote:
> [...]
> >>always
> >> #10 tb_tclk = !tb_tclk ;
> >Your clock doesn't toggle because you haven't provided any reason for
> >it to toggle ie there is no reason for always statement to be
> >scheduled again. You have to type something like "always @(tb_clk)
> >..." to make it work.
>
> eh????? can you then explain (a) where you think tb_clk is going
> to come from, (b) what you think "always #10 a = !a;" should do?
>
> I think the more plausible reason is that the OP has used the
> wrong "run" command to their simulator, and has run the simulation
> only for one (short) preset time interval. Try
>
> run -all (ModelSim)
> . (VCS)
> run (NC)
>
> at the simulator's command prompt. The code looks OK to me.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

Thanks Jonathan. I guess you are right. I am getting waves for just 1
time unit.
But the command that I am using is

vcs test_bench.test -R -PP +prof +vpdfile+vpd_out2.vpd

On Jul 23, 10:49 pm, "tres...@gmail.com" <tres...@gmail.com> wrote:
> On Jul 23, 9:38 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
> wrote:
>
>
>
> > On Mon, 23 Jul 2007 19:28:34 -0700, mk <kal*@dspia.*comdelete> wrote:
> > >On Mon, 23 Jul 2007 23:40:59 -0000, "tres...@gmail.com"
> > ><tres...@gmail.com> wrote:
> > [...]
> > >>always
> > >> #10 tb_tclk = !tb_tclk ;
> > >Your clock doesn't toggle because you haven't provided any reason for
> > >it to toggle ie there is no reason for always statement to be
> > >scheduled again. You have to type something like "always @(tb_clk)
> > >..." to make it work.
>
> > eh????? can you then explain (a) where you think tb_clk is going
> > to come from, (b) what you think "always #10 a = !a;" should do?
>
> > I think the more plausible reason is that the OP has used the
> > wrong "run" command to their simulator, and has run the simulation
> > only for one (short) preset time interval. Try
>
> > run -all (ModelSim)
> > . (VCS)
> > run (NC)
>
> > at the simulator's command prompt. The code looks OK to me.
> > --
> > Jonathan Bromley, Consultant
>
> > DOULOS - Developing Design Know-how
> > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> > The contents of this message may contain personal views which
> > are not the views of Doulos Ltd., unless specifically stated.
>
> Thanks Jonathan. I guess you are right. I am getting waves for just 1
> time unit.
> But the command that I am using is
>
> vcs test_bench.test -R -PP +prof +vpdfile+vpd_out2.vpd

By 1 time unit I meant just 1 clock cycle.

On Tue, 24 Jul 2007 03:38:37 +0100, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

>On Mon, 23 Jul 2007 19:28:34 -0700, mk <kal*@dspia.*comdelete> wrote:
>
>>On Mon, 23 Jul 2007 23:40:59 -0000, "trescot@gmail.com"
>><trescot@gmail.com> wrote:
>[...]
>>>always
>>> #10 tb_tclk = !tb_tclk ;
>
>>Your clock doesn't toggle because you haven't provided any reason for
>>it to toggle ie there is no reason for always statement to be
>>scheduled again. You have to type something like "always @(tb_clk)
>>..." to make it work.
>
>eh????? can you then explain (a) where you think tb_clk is going
>to come from, (b) what you think "always #10 a = !a;" should do?

a) reg tb_clk starts as x and gets assigned 0 which is the first
change.
b) but of course ...

trescot@gmail.com wrote:
> I am writing a test-bench in verilog. Its as follows.
>
>
> `timescale 1ns/100ps
>
> ....
> ....
>
> initial
> begin
> tb_tclk = 1'b0 ;
> Reset_tb = 1'b0 ;
> # 10000 $finish ;
> end
>
>
> always
> #10 tb_tclk = !tb_tclk ;
>
>
> initial
> begin
> $vcdpluson ;
> end
>
>
>
> Basically I want the clock to run for 10000 ns. When I open the vpd
> file, I am surprised to see the clock toggling just for 1 cycle
> instead of multiple cycles since the clock is 20 ns.
>
> I will appreciate for any feedback.
>
>
> Thanks
> Trescot

I would have thought the help you received would be more... helpful.

While it seems clocks are often problematic, it's pretty easy to get
them running.

First, I'd provide an event - always @(tb_clk) - and second, I'd move
the delay. Please feel free to read up on the different styles of
delay, but by changing the delay location in the statement - tb_clk =
#10 !tb_clk; - you should end up with a workable equation. I believe
this flavor is "transport delay." The differences in delays are helpful
for simulation.

In some of my annoying clock in my early simulations, I may have even
needed to add an additional transition 0->1 in the initial block for the
clock.

Happy toggles!
- John_H

"trescot@gmail.com" <trescot@gmail.com> writes:

> But the command that I am using is
>
> vcs test_bench.test -R -PP +prof +vpdfile+vpd_out2.vpd

That seems right. Is there something else (i.e. the ......) in your
file which you are not showing us?


Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On Tue, 24 Jul 2007 05:25:22 GMT, John_H <newsgroup@johnhandwork.com>
wrote:

>I would have thought the help you received would be more... helpful.

Jonathan's right; the code should work, and is also the obvious way to
generate a clock. It looks like it was just finger trouble.

>While it seems clocks are often problematic, it's pretty easy to get
>them running.
>
>First, I'd provide an event - always @(tb_clk) - and second, I'd move
>the delay. Please feel free to read up on the different styles of
>delay, but by changing the delay location in the statement - tb_clk =
>#10 !tb_clk; - you should end up with a workable equation. I believe
>this flavor is "transport delay." The differences in delays are helpful
>for simulation.

you don't need an event and a delay; the delay will advance simulation
time by itself. Also, I wouldn't use an intra-assignment delay (tb_clk
= #10 !tb_clk), for at least 2 reasons:

1 - if you make this change, you get a time-zero race. If you're
lucky, the clock will toggle; if you're not, it will stay low for
10ns, and then go to X indefinitely:

always
tb_clk = #10 !tb_clk; // bad: sample at time 0, race

2 - If you're also tempted to change the blocking assignment to an
NBA, you'll get an infinite loop:

always
tb_clk <= #10 !tb_clk; // bad, bad, bad

In general, putting a delay on the right of a blocking assignment is
probably an error of some sort. Putting a delay on the right of an NBA
is generally Ok (except in the case above, since it has no sensitivity
list) and will model transport delay, if that's what you want.

Evan

On Jul 23, 10:28 pm, mk <kal*@dspia.*comdelete> wrote:
>
> Your clock doesn't toggle because you haven't provided any reason for
> it to toggle ie there is no reason for always statement to be
> scheduled again. You have to type something like "always @(tb_clk)
> ..." to make it work.

It sounds like you are too used to synthesis tools, how they
synthesize the language, and the restrictions they impose. Those are
not the rules of the Verilog language itself.

In Verilog, "always" is equivalent to "initial forever". It just
starts an infinite loop containing the body of the always block. If
that body starts by waiting for an event, then that will have the
effect of the always block responding to the event. Then it will loop
around and wait for the event again. The event control isn't the
reason the block starts running the first time; it naturally runs at
the start of simulation, and the event control makes it stop until the
event occurs. And triggering the event doesn't cause it to start
executing from the top again; it naturally loops back to the top when
it reaches the end, and then stops again at the event control.

I have seen this same "triggering" misconception lead to other
misunderstandings. For example, it can lead to the belief that the
same always block can be triggered again by an event while it is
waiting at a delay, starting a second thread of execution in the
block. This is untrue. There is a single thread of execution for an
always block, which is created before simulation starts, not by any
event. And if that thread is waiting at a delay, then it is not
waiting at the event control, and will not respond to an event.

If the body starts by waiting for a delay, then after the delay, the
always block will resume running. Then it will loop around and reach
the delay again. There is no need for an event to schedule it. It
started out scheduled at the start of simulation, and each delay
schedules it to resume again after the delay has passed. This makes a
perfectly good clock generator. I don't know the cause of the problem
the original poster is seeing, but it is not due to the clock
generator code that he posted.