[SOLVED] always block in test bench

[Selvakumaran_007]

1)
initial
clock=1'b0;
always
clock=~clock;
2)
initial
clock=1'b0;
always@(clock)
clock=~clock;

Can someone explain me about the difference between the two programs? The first program doesn't produce any output because both initial and always are parallel and clock is initialized to '0' in initial and inverted in always block. So the compiler tool cannot decide on a value at the instant.
In the second case I noticed in model sim that it produces a signal '1'. I'm confused about that. What difference does the second question make? Aren't we making inversion of clock at the same instant as in initial? Can someone please explain how this works?

 

[TrickyDicky]

the @(some_signal) means the code inside the always block wont be executed until some_signal changes. So in your case, 1) has a problem because the always wants to run and the initial wants to run at the same time, causing a problem. 2) works because the always doesnt run until clock changes, which is does so when the initial block sets clk to 0. Then the always block detects a change in clock and flips it to a '1'. You'll probably find with 2) modelsim gets stuck in an inifinite loop, because as soon as clk changes, it wants to change it again in zero time.

 

[FvM]

Neither of these works as they are missing a timing statement. You better start with an example from a text book or tutorial.

 

[Selvakumaran_007]

This was asked to me in a test, I am doing a course in vlsi/Verilog and had this in a test. I knew that the first one wouldn't run because both blocks will try to run parallel at time 0 but second one runs perfectly, and I am not able to figure out why and what difference clock makes in the sensitivity list. I compiled in model sim and clock becomes '1' at time 0 and remains at '1' forever. When clock is assigned '0' at time 0 always block should be executed and the value should be changed to '1' at the same instant so won't it create a problem like in the first case where you have multiple values at the same instant?

 

[TrickyDicky]

simulation works on "delta" cycles - infinitly small increments in time. Initial blocks run at delta 0. THen the always detects the change in clock so it executes in delta 1, changing it to '1'. I am confused as to why it wouldnt then change back to '0' in delta 3 because it detects a change in delta 2.

 

[dave_59]

1) is an hanging infinite loop
Any time you have

always begin
          // statements that do not wait for time of some other event
     end

or

initial begin
        // statements
       forever begin
          // statements that do not wait for time of some other event
          end
      end

your simulation will hang at time 0 (or whatever time the infinite looping statement begins) because there is no opportunity for time to advance. There is always one more statement to execute at the current time.

2) is a race condition and process hang. The way to read your code is

always            // start a concurrent process at time 0
         begin
          @(clock)         // first statement: start waiting for a change on clock
          clock = ~ clock  // change clock
         end               // since this is an always block, go back to the first statement.

initial begin    // start a concurrent process at time 0
      clock = 0; // first statement: change clock
      end        // since this is an initial block, end the process.

There is a race between the first statements of the initial and always blocks.
If the @(clock) statement in the always block executes first, it will wait until the clock = 0 statement executes, and then change the clock to 1. But then when it goes back to the first statement, clock has already changed, it it will wait for a change on clock that never happens. clock will remain at 1.
If the clock = 0 statement in the initial block executes first, the always block will hang waiting for a change on clock because the change already happened. clock will remain at 0.