EmbDev.net

Forum: FPGA, VHDL & Verilog unexpected behavior of non-blocking assignment in an priority arbiter


unexpected behavior of non-blocking assignment in an priority arbiter
von Jimmy Z. (itchimp)

Attached files:
Rate this post
• ▲ useful
▼ not useful 
I am a hdl noob currently experimenting with various styles of fsm.
My module is a simple priority arbiter. The non-blocking assignment 
statement is not behaving  the way I expected. On line 17 and 18 there 
are two non-blocking assignments, but they don't occur on the same 
cycle... the first one (gnt0 <= #1 0) occurs on cycles later then the 
ensuing assign(state <= next_state)... can someone explain to me why I 
attached the simulation result and complete source code for your 
reference.

1
always @(posedge clk) 

2
 begin : OUTPUT_LOGIC

3
   if (reset) begin

4
     gnt0 <= #1 0;

5
     gnt1 <= #1 0;

6
     state <= #1 IDLE;

7
   end else begin

8
     $monitor(" time for state assignment %d is %d \n",state, $time);

9
     case (state)

10
       IDLE: begin

11
         $display("set both gnt0 and gnt1 0");

12
          state <= #1 next_state;

13
         gnt0<=  #1 0;

14
                gnt1<=  #1 0;

15
       end

16
       GNT0: begin

17
         gnt0 <= #1 1;

18
          state <= #1 next_state;

19
       end

20
       GNT1: begin

21
        $display(" time for gnt1 assertion is %d ", $time); 

22
         gnt1 <= #1 1;

23
         state <= #1 next_state;

24
        $display(" gnt1 is %d at time %d ", gnt1,$time);

25
      end    

26
      default: begin

27
         state <= #1 next_state;

28
         state <= IDLE;

29
      end

30
     endcase

31
   end

32
 end

Report post Edit Move Thread sperren Anmeldepflicht aktivieren Anpinnen Delete topic Thread mit anderem zusammenführen Quote selected text Reply Reply with quote
Re: unexpected behavior of non-blocking assignment in an priority arbiter
von Vancouver (Guest)

Rate this post
• ▲ useful
▼ not useful 
Jimmy Z. wrote:
> but they don't occur on the same
> cycle

But they do. In the same clock cycle where gnt0 becomes 1 (around 60ns), 
state becomes 00, which is the current value of next_state.

Report post Edit Delete Quote selected text Reply Reply with quote
Re: unexpected behavior of non-blocking assignment in an priority arbiter
von Jimmy Z. (itchimp)

Rate this post
• ▲ useful
▼ not useful 
No they don't there is a one cycle delay from req0 to gnt0, and from 
req1 to gnt1

Report post Edit Delete Quote selected text Reply Reply with quote
Watch this topic | Disable multi-page view
Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.