[SOLVED] Rising edge detector, phase aligned clocks

[ned_zeppelin]

I need a pulse of 1 clk_fast cyle duration, whenver clk_slow has a rising edge, in order to make a time stamp (of sorts) in the clk_fast domain.
Clk_slow and clk_fast are phase-aligned and generated from the same source. Clk_fast may be anything from 2 to 32 times faster than clk_slow.

I have implemented a "rising edge detector" circuit to generate the pulse as follows:

---

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
module rising_edge_detect
  (
   input wire      clk,
   input wire      signal,
   output reg      pulse
   );
   
   reg            signal_prev;     
   
   always @ (posedge clk)   
     begin
     signal_prev <= signal;  
     pulse <= signal & ~signal_prev;
     end
 
endmodule

---

It detects the clk_slow posedge with one clk_fast cycle delay (i.e. it generates the pulse at the clk_fast posedge after the one coinciding with the clk_slow posedge). This seems to work, but if anyone has a better solution or any comments, please let me know.

However, my main concern is that I am using clk_slow directly as "signal" (clk_char is used as "clk" btw).

I fear using clk_slow directly in the logic like this is a bad idea?
So what is the general solution to this, if it is in fact a problem?

Any help is appreciated.

 

[poluekt]

See this note

 

[ned_zeppelin]

I have actually read that note before. However, phase aligning the clocks is one way of eliminating the need for synchronizers, as far as I have understood.

The risk of metastability is not the issue here, but rather the use of clk_slow in combinational logic (not acting as a clock signal as such). I am not sure if this really is a problem though, I just seem to remember reading somewhere that it might not be a good idea. That's really what I want to get cleared up. If signals from phase-aligned clock domains (generated form the same PLL, derived from the same source clock signal) do in fact need to be synchronized, that would also be interesting to hear about though.

 

[mrflibble]

There's several ways to do this, bit depending on what the consumer of that edge will be.

Since the clocks are synchronous you could do a simple counter.

Suppose clk_fast is 16 times clk_slow then you can do:

---

Code Verilog - [expand]
1
2
3
4
5
6
7
reg <3:0> counter   = 0; // not really < > but the square brackets are getting messed up by the forum "syntax" tag
reg       edge_fast = 0;
 
always @(posedge clk_fast) begin
    counter   <= counter + 1'd1;
    edge_fast <= (& counter);
end

---

I've used that for a few things where I needed the fast counter value for other things as well. Then at the cost of 1 extra FF you get the edge detect. Or at the cost of zero FFs and just combinatorial if you can absorb the delay into something else.

If you have no use for the clk_fast cycle count then the counter is a waste of perfectly good FFs. In that case you can do something like:

---

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
reg toggle_slow = 0;
reg toggle_prev = 0;
reg edge_fast   = 0;
 
always @(posedge clk_slow) begin
    toggle_slow <=  ~toggle_slow;
end
 
always @(posedge clk_fast) begin
    toggle_prev <= toggle_slow; // since clk_fast and clk_slow are phase synchronous no synchronizer is needed
    edge_fast   <= toggle_slow ^ toggle_prev;
end

---

 

[K-J]

I have actually read that note before. However, phase aligning the clocks is one way of eliminating the need for synchronizers, as far as I have understood.

The risk of metastability is not the issue here, but rather the use of clk_slow in combinational logic (not acting as a clock signal as such). I am not sure if this really is a problem though, I just seem to remember reading somewhere that it might not be a good idea. That's really what I want to get cleared up. If signals from phase-aligned clock domains (generated form the same PLL, derived from the same source clock signal) do in fact need to be synchronized, that would also be interesting to hear about though.

The possible problem with the code you posted is that the changes on clk_slow, since they are phase aligned with clk_fast, will be that clk_slow will likely not be guaranteed to meet either a setup or hold time requirement relative to clk_fast. Here are some workarounds:
- Since the clocks are aligned, you can make the edge detector work off of the falling edge of clk_fast. The downside here is that the users that get the output of the phase detector will have only half of a clock cycle of setup time (maybe that's a problem, maybe not...timing analyzer will tell you)
- A work around to the above problem when using the falling edge is to then realign it with the rising edge of clk_fast before sending it out to everyone, but...
- If you do that, you might as well put that additional flip flop right up front rather than at the back end. This will give all of the circuits in the design the full clock cycle to work with.
- Depending on the actual clock frequency of clk_fast, maybe you don't have to do anything. When clk_slow violates the setup/hold time and it causes metastability if clk_fast is slow enough then the metastability will resolve itself in plenty of time before the next clock. Whether or not this will work for you depends on the part you're using and the clk_fast frequency.
- Get rid of clk_slow and only use clk_fast. I'm assuming that you may have good reasons for having two clocks, but maybe those reasons aren't really all that valid. Worth a thought to explain why you have these two phase aligned clocks in the first place.

The thing to keep in mind here is that this situation is somewhat worse than if clk_slow was truly asynchronous to clk_fast. The reason is that clk_slow is practically designed to cause a metastable situation since it will likely fail to meet timing requirements unless the synthesis tool adds some extra delays for you to avoid this situation. Even if it does, it's worth asking if you really want your design to be hanging by that thread and whether you can really count on that down the road, different versions of the tools, etc.

The short answer is that if you do truly need to have two clocks, then the best course of action is to treat clk_slow as being asynchronous to clk_fast and design accordingly to mitigate against metastability. Any other course that appears to work will ultimately depend on the performance of the synthesis tool and the performance of particular lots of actual parts both of which, in the end, are something that is outside of your control.

Kevin Jennings