verilog simulation question

[floatgrass]

delta-cycle change verilog

if i use posedge clock triger always statement ,but A sigal is posedge change,simulator think it as low level,but that is for synthesis ok?

if Pix_Mux_s1[7] change from 0 to 1,at the same time memtemp_v1 change frome one value to another value ,then how to assign? it is after or before the change?
thanks!
always @ (Mem_Pointer_s1 or pixel_s1 or Pix_Mux_s1)
begin
if (Pix_Mux_s1[7])
begin
case (Mem_Pointer_s1)
3'b001: begin
pixelcol_v1[23:16] = pixel_s1;
pixelcol_v1[15:8] = memtemp_v1[15:8];
pixelcol_v1[7:0] = memtemp_v1[7:0];
end

3'b010: begin
pixelcol_v1[23:16] = memtemp_v1[23:16];
pixelcol_v1[15:8] = pixel_s1;
pixelcol_v1[7:0] = memtemp_v1[7:0];
end

3'b100: begin
pixelcol_v1[23:16] = memtemp_v1[23:16];
pixelcol_v1[15:8] = memtemp_v1[15:8];
pixelcol_v1[7:0] = pixel_s1;
end

default: pixelcol_v1 = memtemp_v1; // nothing new is written
endcase
end
end

 

[z81203]

Hi,

I think the reason is you "always" condition.

"always @ (Mem_Pointer_s1 or pixel_s1 or Pix_Mux_s1)"
you have three bundle, you must describe them detail here.

synthesis tool desn't care them, but simulation tool care them.

just try it.

B.R.
z81203

 

[stevepre]

z81203, what are you talking about? This is verilog, not VHDL. floatgrass 's example doesn't need any more explanation.

Now here are the problems of floatgrass's example:
1. It's gonna infer a latch because the if statement is not complete. (You have if (Pix_Mux_s1[7]), but no "else".

2. sensitivity of memtemp_v1 is missing.

OK, now your question is if Pix_Mux_s1[7] changes at the same time as memtemp_v1, what will happen.

You must remember one thing, there's no such thing as "at the same time" in a simulator. There's always an order. Even though the simulator "schedules" it at the same time, there's always an order. The order USUALLY is the order of your code, but not necessarily, it depends on the simulator.

Let's consider 2 cases, and assume your simulator schedule event according to the order of your code.
And assume "B" changes exactly the same time as Pix_Mux_s1.

case 1:
always @(B)
memtemp_v1 = B;
always @ (Mem_Pointer_s1 or pixel_s1 or Pix_Mux_s1)
....this is your big always block

case 2:
always @ (Mem_Pointer_s1 or pixel_s1 or Pix_Mux_s1)
....this is your big always block
always @(B)
memtemp_v1 = B;


Let's take a look at your question:
in case 1: pixelcol_v1 will get "NEW" memtemp_v1 value since memtemp_v1 was calculate earlier than your always block.

in case 2: pixelcol_v1 will get "OLD" memtemp_v1 value.


*** The main problem is that you missed the memtemp_v1 in the sensitivity list.

Suppose you add memtemp_v1 to your sensitivity list, in both case 1 & 2
pixelcol_v1 will get "NEW" memtemp_v1 value

WHY?
Take a look at case 2:
at time T, the simulator schedule:
1. evaluate pixelcol_v1 because Pix_Mux_s1 changes
2. evaluate memtemp_v1 because B changes
3. evaluate pixelcol_v1 AGAIN because memtemp_v1 changes due to B changes

If you don't have memtemp_v1 in your sensitivity list, basically the simulator will skip "3", that's why it will screw up.

Enjoy.

 

[floatgrass]

thanks for your careful answer.
i add it to sensitylist,find out outcome is intant value ,but before outcome is before change value

 

[andromeda]

About your first question:
you can try to solve delta-cycle dependency problem (which exist only for functional simulation and do not exist in post-synthesis netlist with delays) in followig way:
put small part of clock cycle (lets say 10%) as a delay in sequential processes (in next_state -> current_state and, if reset is synchronous, in reset_state->current_state), do not put any delay in combinational processes
this delays will be ignored by synthesis tools (will produce some Warning messeges, but it is unimportant), but it will solve delta-cycle dependencies problem
other (but more complicated possibillity) is to balance number of processes in each clock path - it is hard to achive and you must experiment with that to be sure about results