2
\$\begingroup\$

I have a 1-bit signal coming from a part of my circuit that is running on a 40 MHz clock. The signal is mostly 0, except it is 1 for a single 40 MHz-cycle every ~million cycles.

Another part of my circuit is running on a 1 MHz clock. I would like to do some synchronous processing on the signal described above in this part of my circuit. What is the correct way to turn the single-cycle 40 MHz signal into a single-cycle 1 MHz signal?

In case that matters, both the 40 MHz and the 1 MHz clocks are output from the same clock manager driven by the 32 MHz clock on my dev board, so they should be phase-locked.

\$\endgroup\$
3
\$\begingroup\$

Convert that pulse to a level change (invert the output of a flip flop whenever a pulse is generated), pass that across with a couple of flip flops for synchronization, and convert the level change back to a pulse with a flip flop and XOR gate. This is called pulse synchronization with a toggle synchronizer, and it is a very common technique. See: http://www.edn.com/electronics-blogs/day-in-the-life-of-a-chip-designer/4435339/Synchronizer-techniques-for-multi-clock-domain-SoCs .

\$\endgroup\$
  • \$\begingroup\$ Good link. I was assuming he didn't have access to the 40 MHz clock; if he does, I think your method is simpler. \$\endgroup\$ – scary_jeff Jul 29 '15 at 16:33
  • \$\begingroup\$ The toggle synchronizer would not work in this case because of the 40x difference in the clock sppeds. However, the Handshake based pulse synchronizer later in the article would do the trick. \$\endgroup\$ – Argus Brown Jul 29 '15 at 16:40
  • 1
    \$\begingroup\$ Toggle sync should work even with very large differences in clock speed. The reason for this is the large gap between pulses. If the pulses were closer together, a different solution would be required. \$\endgroup\$ – alex.forencich Jul 29 '15 at 17:02
  • \$\begingroup\$ In extension to the described toggle synchronizer from Alex, this synchronizer offers a busy dignal for the 'write' clock domain. So if busy is high, any input will not be synced to the read clock domain. The synchronizer works from fast to slow and in reverse. \$\endgroup\$ – Paebbels Jul 29 '15 at 17:32
  • \$\begingroup\$ I implemented the toggle synchronizer from that blogpost as gist.github.com/gergoerdi/b926408e1a7a991f1031. It works fine; however, the output signal is a full slow clock cycle after the input signal. Is there a way to avoid this delay? \$\endgroup\$ – Cactus Aug 1 '15 at 6:21
2
\$\begingroup\$

Edit: This solution assumes you don't have access to the 40 MHz clock. If you do, then the answer by @alex.forencich is better.

Why don't you use the 40 MHz pulse as an asynchronous set for a register in the 1 MHz domain. If you then have a double-register synchroniser after this, followed by a rising edge detector, you can use the 1 MHz pulse output by the rising edge detector to trigger whatever other logic you have, and act as a synchronous clear on the first register (the one with an async set).

signal async_reg : std_logic := '0';
signal synchroniser : std_logic_vector (2 downto 0) := (others => '0');
signal rising_edge_detected : std_logic;

...

process (clk1MHz)
begin
  if (pulse40MHz = '1') then
    async_reg <= '1';
  elsif (rising_edge(clk1MHz)) then
    if (rising_edge_detected = '1') then
      async_reg <= '0';
    end if;
  end if;
end process;

process (clk1MHz)
begin
  if (rising_edge(clk1MHz)) then
    synchroniser <= synchroniser(1 downto 0) & async_reg;
  end if;
end process;

rising_edge_detected <= synchroniser(1) and not synchroniser(2);
\$\endgroup\$
  • \$\begingroup\$ Isn't there a race condition here? If pulse occurs just before the 1 MHz clock edge then it could possibly be cleared before the flip-flops setup time was met. \$\endgroup\$ – Argus Brown Jul 29 '15 at 16:43
  • 1
    \$\begingroup\$ Yeah, async reset is not a good idea unless you also stretch the pulse in the fast clock domain to at least a full cycle of the slow clock domain. \$\endgroup\$ – alex.forencich Jul 29 '15 at 17:03
  • 1
    \$\begingroup\$ @ArgusBrown There's only a race condition if the 40 MHz pulse occurs frequently. The question states that the pulse rate is of the order of 40 Hz, in which case there's no issue. \$\endgroup\$ – scary_jeff Jul 30 '15 at 11:22

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.