Help in writing Verilog code for t flipflop with asynchronous Load.

Hi, I am designing a jitter bounded DPLL in verilog for which I need a T flip-flop (for a down counter) which can toggle output on positive edge and load data asynchronously on negative edge. I wrote the code but it is not working as needed. Code is :-

The problem in this program is that even though the always@ block is activated at negative edge but since it checks if load=0 so say in case load is still at 0 and positive edge of clk arrives and the logic then checks to find that load=0 and again loads the data to q.
I am unable to figure out how to make this loading of data as edge triggered.
Please help!

What you are trying to describe is not a flip-flop that exists. There aren't any rising edge clocked, falling edge load registers in an FPGA.

You could do something hideous like this:


I'm sure there are other ways of using asynchronous preset and reset to generate a load pulse, but I'm not going to figure it out. I don't recommend using the above circuit it's likely to result in timing problems for the tools and would be very difficult to get the timing constraints right to ensure it works across temp/process.

Use at your own risk.

Unfortunately things don't work that way. Regular fabric flip-flops can only toggle on one edge of your choice. Not on both as you are trying to do now.
The only elements that do double datarate are things like ODDR (an OLOGIC resource), if on Xilinx.

Anyways, it's probably a good idea to clock your design on the posedge only.

ads-ee said:

What you are trying to describe is not a flip-flop that exists. There aren't any rising edge clocked, falling edge load registers in an FPGA.

You could do something hideous like this:

---

Code Verilog - [expand]
1
2
3
4
5
6
7
8
always @ (negedge clk)
  load_dly <= load;
 
assign load_pulse = ~load & load_dly;
 
always @ (posedge clk or load_pulse)
  if (load_pulse) q <= data;
  else q <= !q;

---

I'm sure there are other ways of using asynchronous preset and reset to generate a load pulse, but I'm not going to figure it out. I don't recommend using the above circuit it's likely to result in timing problems for the tools and would be very difficult to get the timing constraints right to ensure it works across temp/process.

Use at your own risk.

Click to expand...

Thankyou sir for your timely reply!
I was also thinking to generate a small pulse using the load as you did but wont the logic assign load_pulse = ~load & load_dly; give a zero output while simulating in modelsim/Xilinx? Also the frequency of the PLL is not fixed so I dont think it is possible to give a predefined delay to load_dly <= load; as maybe at later stage we change the frequency and system becomes inoperable. Also I m okay with the loading of flipflop at positive edge, but in that case too the same problem will persist(i.e. the logic will keep on checking if Load=1 and as long as load is high it will not do the task of toggling)

- - - Updated - - -

Thank You mrflibble sir, But here I am not much concerned with which edge of the clock but rather on if we can start toggling the flipflop as soon as it is loaded on positive/negative edge of the clock(which then is used to generate down counter of N bit) but here due to level dependency on Load, a number of clock signals are wasted and I am not able to achieve frequency locking in PLL.

Why do you think you need to do the load on the negedge? Just make everything it synchronous to the posedge.

Something like:

maxxtorr723 said:

Thank You mrflibble sir, But here I am not much concerned with which edge of the clock but rather on if we can start toggling the flipflop as soon as it is loaded on positive/negative edge of the clock(which then is used to generate down counter of N bit) but here due to level dependency on Load, a number of clock signals are wasted and I am not able to achieve frequency locking in PLL.

Click to expand...

I sort of follow what you say there, but don't see how that would become a problem. To avoid confusion, do you have a schematic of what you're trying to implement? The solution to this will depend on what the consumers of the T-flipflop output look like.