Electronic – D flip flop data extraction

The only change that is required to convert your falling-edge triggered flip-flop to a rising-edge triggered flip-flop is to swap the true (non-inverted) clock and the inverted clock at the pins of your tri-state buffers and the transmission gate. For example, the center transmission gate in a rising-edge triggered flip-flop would have the true clock connected to the NMOS transistor and the inverted clock connected to the PMOS transistor.

By the way, near the middle left of your diagram you have a circled inverter that shows Q at its output and !Q at its input. That's correct...the output of the inverter just to the right of the circled inverter is !Q (Q-bar) rather than Q. If you follow the path from the D input through an inverting tristate buffer and the NOR gate you will see that the signal at the right end of the (non-inverting) transmission gate must have the same polarity as D, so that point in your circuit represents the true (non-inverted) Q value.

First one is generally how it is supposed to look as the output level AFTER the active clock edge should reflect the input level BEFORE the active clock edge. However, when the input transition falls ON the active clock edge, it's ambiguous as it is technically a violation of the setup and hold time. In this case, the difference between using <= and = in your testbench will determine if you get #1 or #2. This is because of the way delta cycles work. If you use = in the testbench, then the new value will be reflected at the input of the flip-flop immediately at the beginning of the cycle and you will get #2. However, if you use <=, then the new value will be reflected at the end of the update cycle and you will get #1.

I went through several different testbench iterations to find the most effective one. At first, I used = in the testbench for the clock generator and for the testbench logic and the testbench logic ran on the falling edge instead of the rising edge. This made the traces in the simulator a bit more obvious (halfway between your #1 and #2), however I ran into some timing issues when trying to get some deeper interaction between the testbench and the DUT. I ended up moving on to using = in the clock generator and <= in the testbench and switching the testbench over to using the rising edge of the clock. This ended up looking like your #1, and it solved the interaction issues I was having. Now, I use the Python-based MyHDL for the functional part of the testbench with a verilog wrapper for the DUT, but that's a completely different story.