[SOLVED] When does a flip-flop capture its input

[keyboardcowboy]

Consider the following piece of Verilog

 always @(posedge clk_i or negedge rst_n_i) begin
    if(!rst_n_i) begin
      flipflop        <=  1'b0;
    end else begin
      if(pulse) begin
        flipflop      <=  1'b1;
      end else begin
        flipflop      <=  1'b0;
      end
    end
  end

The pulse occurs during the negative period of clk_i but the simulator (Questasim) still shoes that it was captured by the flipflop. Why is that and does this also work after synthesis/in hardware?.
My understanding was that at the positive edge and before the next positive edge there was no pulse so flipflop should be 0 too, but that does not seem to be the case.

 

[FvM]

It's not possible to see exact timing in shown simulation waveform. flip-flop output is expectable if pulse input is still high at rising clock edge. Presume this is a functional simulation that doesn't care about setup and hold timing constraints. In a timing simulation, output may be flagged as 'X' if setup or hold requirements are not met.

 

[dick_freebird]

The front latch starts off transparent and on active clock
edge, goes latched while the back end goes transparent
(pushing the latched data through to Q). On "inactive"
edge, front latch goes transparent again but back latch
still holds last clocked data. This is how tristate-inverter
type DFFs work, and NAND-latch types are similar once
you zoom out a little (just fatter, slower and hungrier).

But I see nothing wrong in the plot, though seeing the data
line-on-line with the clock has "mysterious behavior potential"
depending on setup and hold times (in this ideal FF, maybe
none?). The D at time of CLK LH is being caught and put out
at Q in all cases.

 

[ThisIsNotSam]

Consider the following piece of Verilog

 always @(posedge clk_i or negedge rst_n_i) begin
    if(!rst_n_i) begin
      flipflop        <=  1'b0;
    end else begin
      if(pulse) begin
        flipflop      <=  1'b1;
      end else begin
        flipflop      <=  1'b0;
      end
    end
  end

The pulse occurs during the negative period of clk_i but the simulator (Questasim) still shoes that it was captured by the flipflop. Why is that and does this also work after synthesis/in hardware?.
My understanding was that at the positive edge and before the next positive edge there was no pulse so flipflop should be 0 too, but that does not seem to be the case.
View attachment 191942

this is a race condition of sorts, a violation of setup timing. pulse should not switch at the same time as clk.

 

[kaz1]

Consider the following piece of Verilog

 always @(posedge clk_i or negedge rst_n_i) begin
    if(!rst_n_i) begin
      flipflop        <=  1'b0;
    end else begin
      if(pulse) begin
        flipflop      <=  1'b1;
      end else begin
        flipflop      <=  1'b0;
      end
    end
  end

The pulse occurs during the negative period of clk_i but the simulator (Questasim) still shoes that it was captured by the flipflop. Why is that and does this also work after synthesis/in hardware?.
My understanding was that at the positive edge and before the next positive edge there was no pulse so flipflop should be 0 too, but that does not seem to be the case.
View attachment 191942

I don't have anything to add but I see FvM reply makes sense. What puzzles me is why your pulse is so short to get this observation and how did you generate it. It is just a wrong pulse if your design is meant to be synchronised to clock.

 

[keyboardcowboy]

Here are more details with real signal names.
A block operates at 24MHz. This block as an input called enable_block
When this input goes high I generate a pulse.

 reg [3:0] enable_block_delayed;
 wire enable_block_pulse = enable_block & ~enable_block_delayed[0];
 always @(posedge clk_i or negedge rst_n_i) begin
  if(!rst_n_i) begin
    enable_block_delayed[0]        <=  1'b0;
  end else begin
    if(enable_block) begin
      enable_block_delayed[0]      <=  1'b1;
    end else begin
      enable_block_delayed[0]      <=  1'b0;
    end
  end
end

The generated pulse is delayed as follows

 always @(posedge clk_i or negedge rst_n_i) begin
  if(!rst_n_i) begin
    enable_block_delayed[1]        <=  1'b0;
  end else begin
    if(enable_block_pulse) begin
      enable_block_delayed[1]      <=  1'b1;
    end else begin
      enable_block_delayed[1]      <=  1'b0;
    end
  end
end

The input enable_block is from a slower clock domain (4MHz). This slower clock is generated from the 24MHz clock but it could be phase shifted
The simulator does not show that enable_block_pulse is high @ posedgde of clk_i under normal mode but when I use "Expanded Time Events mode" then it does show that it was high

What would be a proper way to generate a pulse in a faster clock domain from a signal coming from a slower clock domain and avoid this kind of ambiguity?. My understanding is since the slower clock is generated from the fast clock (divided) I don't have to worry about synchronization

 

[barry]

The input enable_block is from a slower clock domain (4MHz). This slower clock is generated from the 24MHz clock but it could be phase shifted

What do you mean "it COULD be phase shifted"? Either it's synchronous or its not.

 

[keyboardcowboy]

What do you mean "it COULD be phase shifted"? Either it's synchronous or its not.

My bad. This is what seems to be the issue with my understanding. I thought a clock can be synchronous to another and can be delayed and I set up my testbench this way.

 

[barry]

My bad. This is what seems to be the issue with my understanding. I thought a clock can be synchronous to another and can be delayed and I set up my testbench this way.

yes, it can be phase-shifted AND synchronous. But when you said it COULD be phase-shifted, that implies an ambiguity that is not present in synchronous systems. Words matter.

 

[FvM]

My understanding is since the slower clock is generated from the fast clock (divided) I don't have to worry about synchronization

Both clocks have fixed relation, but clock edge of slower clock is delayed, domain crossing signals from fast to slow clock need additional sync measures.

What would be a proper way to generate a pulse in a faster clock domain from a signal coming from a slower clock domain and avoid this kind of ambiguity?

I don't see ambiguity in the shown waveform, as stated the behaviour is expectable. I don't however understand how "pulse" is generated. Is the signal combining posedge and negedge triggered registers? Can't recognize if it's a "proper way" (meeting timing constraints).

You can transfer one-bit signals even between asynchronous clock domains quite easily. Disadvantage is a propagation delay of several clock cycles caused by sync chains.

 

[keyboardcowboy]

I don't however understand how "pulse" is generated. Is the signal combining posedge and negedge triggered registers? Can't recognize if it's a "proper way" (meeting timing constraints).

"pulse" is "enable_block_pulse" in the RTL I provided in post#6. I was generating it based on a testbench signal "enable_block" as shown in the RTL above. In my testbench

#10000
@(posedge clk_4)
@(posedge clk_4)
enable_block = 1'b1
@(posedge clk_4)
enable_block = 1'b0

 

[FvM]

clk_4 is apparently double clk_i rate. Doesn't fit the description in post #6.

 

[keyboardcowboy]

clk_4 is 4MHz and clk_i is 24MHz.

#10000
@(posedge clk_4)
@(posedge clk_4)
enable_block = 1'b1
@(posedge clk_4)
enable_block = 1'b0

In my testbench I am just setting "enable_block" to 1 after 2 clk_4 posedges and setting it to 0 after 1 clk_4 posedge. Why do you say "clk_4 is apparently double clk_i rate"?

 

[barry]

This is another thread I just need to walk away from…

 

[keyboardcowboy]

This is another thread I just need to walk away from…

apologies if what I did or what I asked was stupid. I understood a few things much better and got to clear a few misconceptions from reading everyone's responses. Thank you