help:dual-edge flip-flop possible using Verilog?

yyqonline schrieb:

It is not difficult to driscrobe dual-edge flip-flop in an HDL. The real question is: Can you build them in your target technology? Most FPGAs do not have them and most standard cell libraries do not have them either.

Kolja Sulimma

Do you really mean KHz and not MHz? If this is not a typo I would suggest using a much faster clock to run an FSM that samples the

If you're really talking MHz, modern FPGA's have ways to deal with this at the I/O buffer (double-data-rate flip-flops).

Generally multi-edge flip-flops are not synthesizable, but if the part has them, they can be instantiated. i.e. you can't just write:

always @ (posedge clk or negedge clk) ...

and expect the synthesis tool to generate useful RTL.

I think the only device that supports this are the Xilinx CoolRunner II.

This Should work:

always @(posedge Clk or negedge Clk) begin if(Rst == 1) Cnt datarate of which are both 640KHz. It is not complicated when the

I suggest we wait for the original poster to clarify. I think there is no real need for a dual-edge triggered flip-flop. Definitely not at the low frequenciesmentioned. There is also a simple circuit that XOR differentiates the clock, thus generating a clock pulse at both the rising and the falling edge. (See, among others, at "Six Easy Pieces" in TechXclusives) Peter Alfke

\quote Do you really mean KHz and not MHz? If this is not a typo I would suggest using a much faster clock to run an FSM that samples the

at the I/O buffer (double-data-rate flip-flops). Generally multi-edge flip-flops are not synthesizable, but if the part has them, they can be instantiated. i.e. you can't just write: always @ (posedge clk or negedge clk) ... and expect the synthesis tool to generate useful RTL. \quote

Now we are using FPGA for verification while at the end this circuit will be implemented by asic tech, so the system clock is fixed at

Thanks a lot for replying. \quote There is also a simple circuit that XOR differentiates the clock, thus generating a clock pulse at both the rising and the falling edge. (See,

among others, at "Six Easy Pieces" in TechXclusives) \quote I have found the circuit and thanks for information. I am checking the stability of this circuit. If this circuit is reliable, I think this may be a good idea.

The circuit is reliable, although the generated pulse width is determined by gate delays. But it is self-compensating, since the clock pulse will not end until the flip-flop has toggled. It's kind of clever, if I am allowed to say so... Peter Alfke

The circuit is reliable, although the generated pulse width is determined by gate delays. But it is self-compensating, since the clock pulse will not end until the flip-flop has toggled. It's kind of clever, if I am allowed to say so... Peter Alfke

It probably needs some care, to ensure CLK_min times are ok ?

eg if you drive a large clock tree, it would be better to not use a local FF clk, and then buffer, but to buffer, and then FF.CLK from the CLK tree output, with optional additional delays, if you want even more margin.

Yes, I recall a similar [XOR-Q] clock scheme many, many years ago, on a circuit ( from HP?) for Biphase decode.

-jg

Slurp

Thanks I have done some work using this circuit and it seems to function well. Since the clk is 640Khz, the requirement of clk_min should be satisfied. I have another two aspects:

As a learner with little experience, every reply give me great help and will be highly appreciated.

Thanks for putting forward so good a circuit, which is one of the most wonderful design I have ever learned!

Hi Peter, Clever the circuit may be, but I'm concerned that it may not be a good idea to suggest this circuit to a guy who appears to be just starting out using FPGAs. I agree it's a quick and easy answer to get him going, but he should be made aware of the pitfalls of this circuit. For one, how will the timing analyser cope with this? Also, how does he control the skew between input and output? In your article you rightly say "This asynchronous circuit ... should only be used as a tool of last resort.", so it should be in CAF threads as well! I'd strongly suggest the OP use a DCM or PLL or whatever his FPGA vendor supplies to double his clock. He should wait until he's really desperate before resorting to asynchronous tricks, no matter how clever they are! Just IMHO! Cheers, Syms. p.s. If the goal is to achieve a frequency doubled clocking signal, would the "six easy pieces" asynchronous circuit be improved by inserting a GBUF at the output of the XNOR gate?

This circuit really shouldn't be advocated for FPGA use. It is an asynchronous hack. It would not get through a serious design review except in extenuating circumstances. Generally speaking, depending on gate delays for circuit operation is bad practice. This particular circuit has potential problems with pulse width and is dependent on the clock duty cycle for proper operation. (Yes, I can remember using it a long long time ago with some TTL designs, but then those designs also had one-shots in them). Another problem with it, is the static timing analyzer and timing driven place and route do not consider the asynchronous behavior of this circuit.

\quote Ray Andraka wrote This circuit really shouldn't be advocated for FPGA use. \quote Thanks for help. I am not sure how to realize the same function (double the frequence of the clk)? Maybe some of the FPGA's architecture support this. Then I would like to know how this circuit perform as far as asic is concerned?

Peter,

Newbie question - I remember seeing an edge detector made up from a single XOR gate and a few inverters to add a propagation delay, but no registers.

Would such a circuit be equivalent to yours? Any pros/cons either way?

Regards, Paul

Hi -

I kind of like a DDR FF emulation circuit that Gabor described in a post last May; see the drawing below (please view with fixed-width fonts). You use two D FFs and three XORs to create the function of a FF that clocks on both edges. The extra gates at the inputs and outputs mean that the setup time and CP-to-Q delays suffer somewhat, but the Q output is glitch-free.

-----------------------. | | | __ | '-\\ \ .--o--. | || |------|D S Q'-o-)--. .--//_/ | | | | | | .----|> | | | | | | | R Q| | | | | | '--o--' | | | __ DIN ------o | | | '--\\ \ | | | | || |- Q CLK ------)--------o | | ---//_/ | __ | | | | '--\\ \ | .--o--. | | | || |-)----|D S Q'-)-o--' -//_/ | | | | | '---o|> | | | | R Q| | | '--o--' | | | '--------------------'

Me, if my circuit were operating at low speed, I'd probably just use a

Bob Perlman Cambrian Design Works

That's exactly where I'd expect to run into problems. It's not too difficult to characterize it in a particular FPGA, but the performance in the FPGA tells you almost nothing about what to expect in an ASIC.

Using asynchronous logic in an FPGA leads to trouble, and doing it then expecting it to work the same in an ASIC could lead to a disaster.

As others have suggested, unless your transition rate is extremely fast, you're much better off using a clock at a higher rate, a synchronizer (two chained FFs), another FF, and an XOR between the D and Q of that last FF. That will get you a pulse with a width of one clock cycle every time the input transistions.

The idea of the register, is you get some register-dependance time into the system, as the CLK will eventually be used to CLK registers - but otherwise the ideas are similar.

The risk I see, is on large CLK trees, and very nimble registers - you really need to get the CLK tree delay 'into the loop'

If the OP has a 640KHz SqW signal, and wants to keep it low risk, simple to analyze, and avoid the complexity of faster clocks, he could use 1 x 74HC1G97/1G98 Single Gate logic device externally, Wired as a XOR or XNOR, with a RC delay on one IP of 100~200ns. ( ie as above ) These devices have Schmitt inbuilt.

Use the leading edge as CLK, as the trailing edge will be RC determined, and it will move slightly on each 'phase' with HL and LH thresholds. Choose XNOR or XOR gate, depending on which edge you require.

-jg