signal assignment update time in an always block

Howdy all,

We've wrritten the following code which implements a finite state machine:


We ran a simulation on that module and it looks like vc_state_ps doesn't sample vc_state_ns on clk rising on certain situations.
We've attached the waveform showing the problem. Using the $display command we see in the log that the values used are the values after the clk risen and not before..
Do you have any idea where is the problem?



Thanks,

ProjectX.

projectx100 said:

Howdy all,

We've wrritten the following code which implements a finite state machine:

Code:

always_comb // vc global state transition implementation
begin
	case (vc_state_ps)
		IDLE :	vc_state_ns = idle_2_cred ? CRED : (idle_2_active ? ACTIVE : (idle_2_route ? ROUTE : vc_state_ps));
		ROUTE :	vc_state_ns = route_2_va ? VA : vc_state_ps;
		VA :	vc_state_ns = va_2_cred ? CRED : (va_2_active ? ACTIVE : vc_state_ps);
		ACTIVE :	vc_state_ns = active_2_cred ? CRED : (active_2_idle ? IDLE : vc_state_ps);
		CRED :	vc_state_ns = cred_2_active ? ACTIVE : vc_state_ps;
		default: vc_state_ns = IDLE;
	endcase
end

logic [2:0] vc_state_prev;
always_ff @(posedge clk or posedge reset)
begin
	if (reset)
	begin
		vc_state_ps <= IDLE;
		vc_state_prev <= IDLE;
	end
	else
	begin
		$display("Updated VC state %t for %d: %b, %b", $time, MY_VC, vc_state_ns, vc_state_ps);
		vc_state_ps <= vc_state_ns;
		vc_state_prev <= vc_state_ps;
	end
end

We ran a simulation on that module and it looks like vc_state_ps doesn't sample vc_state_ns on clk rising on certain situations.
We've attached the waveform showing the problem. Using the $display command we see in the log that the values used are the values after the clk risen and not before..
Do you have any idea where is the problem?

View attachment 95987

Thanks,

ProjectX.

Click to expand...

i'm more of a VHDL guy, but i think in combinatoric (async) process you need
to have all signals in sensitivity list.
and i pray that sometime in the future vendors will support the process (all) feature ....

How do you expect anyone to help when you don't post ALL the code especially the definitions of those states. Is IDLE 3'h0 or is it 3'h1 etc.

Given the lack of signal definitions, and going by my gut feeling. It's a testbench problem. the transition you have for idle_2_route seems to have worked. You applied idle_2_route on the falling edge of the clock and placed the va_2_active on the rising edge of the clock.

Now given the coding "style" (I use that term very loosely) I would deduce you probably wrote an in line testbench that just wiggles the inputs to your FSM with assigns or force statements separated by # delay statements. Well unless the rising edge of va_2_active is generated from a register using the signal clk in your code you'll end up with errors just like this. Try shifting the va_2_active by 1/2 cycle and it will probably work.

BTW, I would read up on coding FSMs and use a "style" that is readable (a.k.a. maintainable).

Regards

ads-ee said:

Well unless the rising edge of va_2_active is generated from a register using the signal clk in your code you'll end up with errors just like this. Try shifting the va_2_active by 1/2 cycle and it will probably work.

Click to expand...

Thats was it, Thanks man
projectx