Test bench principle

When I write test bench for design simulation, I confronted some weird problems in GTL simulation. The results are similar, but I want to post here to discuss. For example, I have RAM, in testbench I input address to write or read like;

// example 1

always @(posedge clock) // posedge is active edge of the clock

begin

wren<=1;

address<=address+1;

data<=data+1;

end

// example 2

always @(posedge clock) // posedge is active edge of the clock

begin

rden<=1;

address<=address+1;

end

Sometimes, the Modelsim will give warning in each clock posedge to warn the setup and hold timing violation. And GTL simulation results are weird like the output data does not follow the sequence of address.

The Altera staff mentioned "Changing the data in a test bench at the exact same time as the active edge of the clock can produce unreliable and inconsistent results" , and he suggests don't use active edge of clock to change data or add delay like:

always @(negedge clock) // posedge is active edge of the clock

begin

wren<=1;

address<=address+1;

data<=data+1;

end

or

always @(posedge clock) // posedge is active edge of the clock

begin

wren<=1;

# 5 address<=address+1;

# 5 data<=data+1;

end

So I just have questions, when I writed testbench, I always change data using style:

always @(posedge)

begin

data<=f(data); // f(data) means a function of data

end

should I put timing delay in all these commands? And in testbench, blocking assignment and non-blocking assignment, which I should use? I think both of them work the difference are concurrent and one cycle delay.

Hope anyone can give me some advices. Thanks very much.