Is it VCS bug OR problem in my model ??? 
Author Message
 Is it VCS bug OR problem in my model ???

I have a simple verilog model clk_gen (clock generator).
It's appended below.

----------- CLOCK GENERATOR -----------------------

module clk_gen;
reg clk1;

initial
begin
        clk1 = 1'b0;
end

initial
begin
        $monitor("CLK1=%b\n", clk1);
end


// always
begin
        clk1 <= #10 ~clk1;
end
endmodule

---------------------- END MODEL ---------------------

This module generates clock when done with Verilog-XL.
I checked this some-time back. It should oscillate by the
fact that change in the value clk1 is scheduled after
10 time units and always block is re-entered after 10 units
as there is a change in clk1. Hence it oscillates.

But in VCS, this piece of code does not oscillate. In fact
simulator hangs. Dont know why ?



Mon, 03 Mar 2003 03:00:00 GMT  
 Is it VCS bug OR problem in my model ???

Quote:

> I have a simple verilog model clk_gen (clock generator).
> It's appended below.

> ----------- CLOCK GENERATOR -----------------------

> module clk_gen;
> reg clk1;

> initial
> begin
>         clk1 = 1'b0;
> end

> initial
> begin
>         $monitor("CLK1=%b\n", clk1);
> end


> // always
> begin
>         clk1 <= #10 ~clk1;
> end
> endmodule

You have a timing hole at time 0 - does the always statement
arm itself before or after clk1 is set to 0? since the ordering
of these two is arbitrary it's going to work in some environments
and not other

(one way to think about this is simply to replace 'always' with
'initial forever' in the above verilog then think about what happens
if the first initial is executed before the second one)

Also making clocks with <= is fraught with subtle danger and
probably should be avoided (it has to do with running the
non-blocking queue more than once per time period - something
that IMHO should be avoided unless you really really understand
what's going on in detail - this ties back in to the annual
blocking vs. nonblocking debate above :-).

My favorite idiom for RTL clocks is:

        initial begin
                clk = 0;
                forever #(period/2) clk=~clk;
        end

If you have a clock that's only sampled on one edge
(say posedge for example) you also want to avoid
any edges in that direction during time 0 - so
initialize a posedge clock to 0 and a
negedge clock to 1 - this way you can avoid triggering
any of those edges when only some of the always
statements that will wait on them have been
armed (similar to the problem above) - alternately a
good reset methodology will do wonders :-).

I have seen some people argue that for this reason
you should keep your clock at Xs untill after time 0
ie:

        initial begin
                #1
                clk = 0;
                forever #(period/2) clk=~clk;
        end

but I haven't had any experience with this so I
can't directly recommend it.

        Paul Campbell



Mon, 03 Mar 2003 03:00:00 GMT  
 Is it VCS bug OR problem in my model ???

by including #0 before clk1=1'b0 in the initial block solves the
problem.
Quote:


> > I have a simple verilog model clk_gen (clock generator).
> > It's appended below.

> > ----------- CLOCK GENERATOR -----------------------

> > module clk_gen;
> > reg clk1;

> > initial
> > begin
> >        (Modified) --->> #0 clk1 = 1'b0;
> > end

> > initial
> > begin
> >         $monitor("CLK1=%b\n", clk1);
> > end


> > // always
> > begin
> >         clk1 <= #10 ~clk1;
> > end
> > endmodule

> You have a timing hole at time 0 - does the always statement
> arm itself before or after clk1 is set to 0? since the ordering
> of these two is arbitrary it's going to work in some environments
> and not other

> (one way to think about this is simply to replace 'always' with
> 'initial forever' in the above verilog then think about what happens
> if the first initial is executed before the second one)

> Also making clocks with <= is fraught with subtle danger and
> probably should be avoided (it has to do with running the
> non-blocking queue more than once per time period - something
> that IMHO should be avoided unless you really really understand
> what's going on in detail - this ties back in to the annual
> blocking vs. nonblocking debate above :-).

> My favorite idiom for RTL clocks is:

>         initial begin
>                 clk = 0;
>                 forever #(period/2) clk=~clk;
>         end

> If you have a clock that's only sampled on one edge
> (say posedge for example) you also want to avoid
> any edges in that direction during time 0 - so
> initialize a posedge clock to 0 and a
> negedge clock to 1 - this way you can avoid triggering
> any of those edges when only some of the always
> statements that will wait on them have been
> armed (similar to the problem above) - alternately a
> good reset methodology will do wonders :-).

> I have seen some people argue that for this reason
> you should keep your clock at Xs untill after time 0
> ie:

>         initial begin
>                 #1
>                 clk = 0;
>                 forever #(period/2) clk=~clk;
>         end

> but I haven't had any experience with this so I
> can't directly recommend it.

>         Paul Campbell




Mon, 03 Mar 2003 03:00:00 GMT  
 Is it VCS bug OR problem in my model ???

I usually use:

initial clk = 0;

assign #(period/2) clk = ~clk;

bkk



Quote:
> I have a simple verilog model clk_gen (clock generator).
> It's appended below.

> ----------- CLOCK GENERATOR -----------------------

> module clk_gen;
> reg clk1;

> initial
> begin
>         clk1 = 1'b0;
> end

> initial
> begin
>         $monitor("CLK1=%b\n", clk1);
> end


> // always
> begin
>         clk1 <= #10 ~clk1;
> end
> endmodule

> ---------------------- END MODEL ---------------------

> This module generates clock when done with Verilog-XL.
> I checked this some-time back. It should oscillate by the
> fact that change in the value clk1 is scheduled after
> 10 time units and always block is re-entered after 10 units
> as there is a change in clk1. Hence it oscillates.

> But in VCS, this piece of code does not oscillate. In fact
> simulator hangs. Dont know why ?

Sent via Deja.com http://www.deja.com/
Before you buy.


Thu, 06 Mar 2003 03:00:00 GMT  
 Is it VCS bug OR problem in my model ???

Quote:

> Actually, it is the usage of Intra assignment

if you use non_intra assignment then I think it
shouldn't be a problem and it runs in VCS.
the code is
always
begin
  #10 CLK = ~CLK;
end

Quote:

> I usually use:

> initial clk = 0;

> assign #(period/2) clk = ~clk;

> bkk


>   Venkat Muralidhar

> > I have a simple verilog model clk_gen (clock
generator).
> > It's appended below.

> > ----------- CLOCK GENERATOR ------------------
-----

> > module clk_gen;
> > reg clk1;

> > initial
> > begin
> >         clk1 = 1'b0;
> > end

> > initial
> > begin
> >         $monitor("CLK1=%b\n", clk1);
> > end


> > // always
> > begin
> >         clk1 <= #10 ~clk1;
> > end
> > endmodule

> > ---------------------- END MODEL -------------
--------

> > This module generates clock when done with
Verilog-XL.
> > I checked this some-time back. It should
oscillate by the
> > fact that change in the value clk1 is
scheduled after
> > 10 time units and always block is re-entered
after 10 units
> > as there is a change in clk1. Hence it
oscillates.

> > But in VCS, this piece of code does not
oscillate. In fact
> > simulator hangs. Dont know why ?

> Sent via Deja.com http://www.deja.com/
> Before you buy.

Sent via Deja.com http://www.deja.com/
Before you buy.


Sat, 08 Mar 2003 14:24:45 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Help on VCS + VirSim (GUI for VCS)

2. Simulator differences -- apparent VCS bug

3. VCS v5.2 bug?

4. VCS problem

5. VCS problem

6. vcs include problem

7. VCS with C++ problem under SunOS 5.7

8. VCS/Specman, possible problem with Linux resource limit

9. vcs include problems

10. Object models, Domain models, Application models, and MVC?

11. Object models, Domain models, Application models, and MVC?

12. System Bug, Or Am I Really Dense?

 

 
Powered by phpBB® Forum Software