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

Status
Not open for further replies.
K

keyboardcowboy

Member level 3
Joined
Mar 4, 2010
Messages
55
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
1,715
Consider the following piece of Verilog

Code: 
 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.
 

Sort by date Sort by votes
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.
 

Upvote 0 Downvote
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.
 

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

Upvote 0 Downvote
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.
 

Upvote 0 Downvote
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.

Code: 
 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

Code: 
 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
 

Upvote 0 Downvote
keyboardcowboy said:
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
Click to expand...
What do you mean "it COULD be phase shifted"? Either it's synchronous or its not.
 
Upvote 0 Downvote
barry said:
What do you mean "it COULD be phase shifted"? Either it's synchronous or its not.
Click to expand...
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.
 

Upvote 0 Downvote
keyboardcowboy said:
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.
Click to expand...
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.
 

Upvote 0 Downvote
keyboardcowboy said:
My understanding is since the slower clock is generated from the fast clock (divided) I don't have to worry about synchronization
Click to expand...
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.

keyboardcowboy said:
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?
Click to expand...
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.
 
Upvote 0 Downvote
FvM said:
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).
Click to expand...
"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

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

Upvote 0 Downvote
clk_4 is 4MHz and clk_i is 24MHz.

Code: 
#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"?


 

Upvote 0 Downvote
barry said:
This is another thread I just need to walk away from…
Click to expand...
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
 

Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…