3

I am working on a design which should detect the first match of two rising edges of two asynchronous clocks of different frequencies.

code something like this may work for simulation.

fork 
@posedge clkA 
begin 
    a=$time 
end 
@posedge clkB 
begin 
    b=$time 
end 
join 

if (a=b) then some code.

this code may work for simulation but if I want some synthesizable hardware logic what else can I use?

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
Reddy
  • 98
  • 1
  • 7
  • 2
    This smells like a poor design to me, can you say why you need to do such a thing? There is likely a better and more robust way to get to wherever you're trying to go. – Tim Jun 14 '13 at 23:16

3 Answers3

2

This one is kind of tricky but if you can get a third clock that is twice as fast as the fastest clock between the two that you need to detect and can accept a one cycle delay of detection (the one cycle is in reference to the third clock domain) then it is possible.

what you will need to do is set up to registers for each clk domain like this:

input clk1, clk2'

...

reg clk1_in, clk1_out;
reg clk2_in, clk2_out;

wire clk1_posedge, clk2_posedge;

//take in the clock value, you should register this so that way jitter on the line does not mess with it 
always@(posedge clk3)begin 
    clk1_in <= clk1;
    clk2_in <= clk2;
end 

always@(posedge clk3)begin
    clk1_out <= clk1_in;
    clk2_out <= clk2_in;
end 

//now you need to detect the posedge for each signal independently, you can use and and gate for this 
assign clk1_posedge = (~clk1_out && clk1_in);
assign clk2_posedge = (~clk2_out && clk2_in);

// now just and the two together 
assign pulse_detected = clk1_posedge && clk2_posedge

you need clk 3 to be twice as fast, otherwise you get aliasing (look up nyquist freq)

so what happens is the first register for the clock domain will be be high and if it is the just getting high then the second register will still be low for that cycle.

Eric
  • 95,302
  • 53
  • 242
  • 374
alex_milhouse
  • 891
  • 1
  • 13
  • 31
2

It is not possible to reproduce in HW the behavior you described. The reason for this is that you compare the times exactly.

First of all, you need to explain what do you mean by "detect the first match of two rising edges". Given that two async clocks have variable (and unpredictable) phase relationship, the task of detecting simultaneous edges will (usually) be stated in terms of how much time is "simultaneous".

For example: detect when rising edges are spaced at most 5ns in time.

BTW, I assume here that both frequencies in question are known.

Please describe your problem in more details.

EDIT: This question became hardware question, which is not related to Verilog. It is not clear whether any of the solutions proposed here may work (and it is my personal belief that they won't). I submitted the same question at EE Stack Exchange - it is a place for HW questions, and there is higher chance that it will be answered there.

Community
  • 1
  • 1
Vasiliy
  • 16,221
  • 11
  • 71
  • 127
  • he (or she) wants to know when both go high at the same time, within some tolerance of course. and you do not need to know the frequency as long as you can say that you can have an independent frequency that is at least twice as fast as the fastest – alex_milhouse Jun 14 '13 at 18:48
  • also these kinds of things are better asked in the comments section seeing as you provided no answer. – alex_milhouse Jun 14 '13 at 18:49
  • 1
    I don't see any mention of tolerance in the original question. I see that he (or she) compares the times exactly. I suggested to add more details to the question and provided a guidelines, but, meanwhile, the answer is "it is impossible". Why isn't this an answer? – Vasiliy Jun 15 '13 at 11:50
  • @VasiliyZukanov is correct. As it was asked, it is impossible to do what the original poster wanted to do. To say that the edges must go high at the same time "with some tolerance of course" is not true, it is not at all obvious that there is any tolerance, much less a reasonable tolerance, involved. When someone asks a question like this, the best advice is that such a thing is not possible. –  Jun 16 '13 at 23:39
  • Thanks for all for ur response. – Reddy Jun 21 '13 at 05:47
  • @Alex Rellim I cant use another clock as u said in my design. sorry if the question is not detailed properly. I know that it is impossible to compare exactly. considering some tolerance of any small value can we achieve this?? And as Greg mentioned about Dual clock d flipflop may work good. But cant it be achieved with normal flipflops? – Reddy Jun 21 '13 at 05:59
  • yeah i though it was possible too but I think we may be missing something. checking clock domains like this is always a challenging thing to do – alex_milhouse Jun 21 '13 at 17:16
1

Too pull this off, first make dual-edge,dual-clock flip-flop. Start off with a dual clock D flip-flop Patent US6320442 B1. Now substitute the sub flip-flops with dual edge D flip-flops Patent US5793236 A or Patent US5327019 A. Each patent has diagrams of the circuit design.

With the custom flop, create a small pipeline sampling the history of the clocks. Look for a zero to one transition.

Example:

wire [1:0] historyA, historyB;
// dualedge_dualclock_dff     ( output Q, input D, clkA, clkB, rst_n)
dualedge_dualclock_dff dedc_histA1( .Q(historyA[1]), .D(historyA[0]), .* );
dualedge_dualclock_dff dedc_histA0( .Q(historyA[0]), .D(clkA), .* );
dualedge_dualclock_dff dedc_histB1( .Q(historyB[1]), .D(historyB[0]), .* );
dualedge_dualclock_dff dedc_histB0( .Q(historyB[0]), .D(clkB), .* );

wire dual_posedge_match = ({historyA,historyB} == 4'b0101);

Dual-edge flops and dual-clock flops are not common design practices. Excessive timing analysis will be needed and tools might complain about the cell. Plus, steps need to be taken for patent uses compliance with the law.

Greg
  • 18,111
  • 5
  • 46
  • 68
  • Very interesting techniques, thanks. One can't analyze these schemes without excessive (analog) simulation, however, there is one point that seems suspicious: the output of Patent US6320442 B1 circuit needs to be synchronized, which is obvious, but the synchronized value is fed back to both inner flops (through combo logic). No matter which clock your synchronizer uses, there will be async feedback path to one of the inner flops, which might go metastable. This metastability will not propagate past the output synchronizer, but it can cause the circuit to miss edges. Am I missing something? – Vasiliy Jun 21 '13 at 07:28
  • hmm, I guess am not really following this, do you mind explaining it a bit further. Thanks! – alex_milhouse Jun 21 '13 at 17:01
  • In all honesty, I didn't look to deeply into possible metastable. I saw the anti-metastable circuit and the reference to [Patent US6531905](http://www.google.com/patents/US6531905) titled "Flip-flop with metastability reduction". The 4th to last paragraph talks about how additional precautions be taken for metastability. There are risks in the design that need to be addressed. I'd even suggest reviewing the reason why detecting the matching positive edge on asynchronous clocks is a design requirement. – Greg Jun 21 '13 at 17:14
  • @user2484982, I think that we may agree that this is HW question, not related to Verilog strictly. I asked the same question at EE Stack Exchange. You may follow the link in my answer if you're interested in further discussion. – Vasiliy Jun 21 '13 at 19:28