Is it permissible to use a condition generated by one clock with another, fully-synchronized clock (generated by a PLL with 0 phase shift) of different frequency?

This works as expected in simulation:

`default_nettype none

`timescale 1ns/1ps
module top;

   reg base_clk = 0;
   reg fst_clk = 0;

   reg cond = 1'b0;
   reg [2:0] ctr = 3'd0;
   reg some_reg = 1'b0;

   always #15 base_clk = !base_clk;
   always #5 fst_clk = !fst_clk;

   initial begin
      $dumpvars(0, top);
      #10000 $finish;

   always @(posedge base_clk) begin
      ctr  <= ctr + 1'b1;
      if (ctr == 3'd5)
        cond <= 1'b1;
        cond <= 1'b0;

   always @(posedge fst_clk) begin
      if (cond)
        some_reg <= 1'b1;


enter image description here

Can I assume this will also work when synthesized (in synthesis fst_clk would be generated by a PLL)? In my mind there shouldn't be any issues here since the clocks are synchronized and so I'm not crossing clock domains. Am I correct in thinking this? Or, have I overlooked something and I should only use a condition generated by the same clock.

  • \$\begingroup\$ if you are transferring data from fast clock to slow, then data should be stable for at least T of slow clock. \$\endgroup\$ – Mitu Raj Sep 23 '19 at 19:11
  • \$\begingroup\$ I'm transferring from slow to fast so that shouldn't be a concern. However, why is that? Is the setup time somehow longer for slow clocks? \$\endgroup\$ – MattHusz Sep 23 '19 at 19:16
  • \$\begingroup\$ To avoid possible data loss. \$\endgroup\$ – Mitu Raj Sep 23 '19 at 19:28
  • \$\begingroup\$ Right, but if the output of the fast clock reg meets the setup timing requirements of the slow clock reg, shouldn't that be enough? \$\endgroup\$ – MattHusz Sep 23 '19 at 19:31
  • \$\begingroup\$ You are thinking only about the data launched at first edge. Think about the data launched by second edge? Can the next edge of slow clock capture it? By the time next edge of slow clock comes, fast clock would have launched many data depending on frequency ratio. And all that are lost \$\endgroup\$ – Mitu Raj Sep 23 '19 at 19:36

Since both your clocks are generated by the same PLL, they are synchronous with well known phase relationship. Hence, there is no asynchronous clock domain crossing between the signals driven by base-clk and fast-clk.

When sending data from slow clock to fast clock, as long as the fast clock has sufficiently smaller time period, there should be no risk of data loss. However, these inter-clock paths have to be properly multi-path constrained and ensure that timing is met.

Sending data from fast clock to slow clock is different story. You will get some good insight here


Maybe. You can get away without performing a clock domain crossing in this case as long as you can guarantee that the signal you are passing will maintain a state for at least three edges on the receiving clock. That being said, I would still recommend the use of a two flip-flop synchronizer.

Take a look at this article from Sunburst design for more information.

Note that the duration of the cond pulse may also vary in the receiving clock domain. If this is a problem, a synchronizer can easily be combined with a synchronous edge detector.


simulate this circuit – Schematic created using CircuitLab


If base_clk and fast_clk have constant phase relationship, you will be operating in the same clock domain. In that case, your assumption is right and I would assume your design to work correctly when synthesized.

  • \$\begingroup\$ What does OP do if it isn't? \$\endgroup\$ – TonyM Sep 24 '19 at 17:07
  • \$\begingroup\$ In that case, this becomes a problem of passing a slow changing 1-bit signal to a fast clock domain. This is generally not a problem if the fast clock is at least 1.5x the frequency of slow clock. And OP could use a 2 flip-flop synchronizer along with proper constraints. \$\endgroup\$ – rvkrysh Sep 25 '19 at 3:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.