Metastability synchronizer or positive and negative clock edges?

[zapta]

I have a synchronous FPGA design that operates on the positive edge of the system clock. The design needs to sense an asynchronous external signal so I am thinking having a two stage synchronizer, where the first FF use the negative clock edge and the second on the positive. The goal is to have a delay of one clock instead of two. 

Is it reasonable?

Here is the verilog code

Code: [Select]

`default_nettype none

module meta_stability #(
    parameter integer INITIAL_VALUE = 0
) (
    input sys_clk,    // System clock.
    input sys_reset,  // Synchronous reset.
    input in,         // Asyncnhronous external input
    output out        // Input delayed by one clock
);

  reg reg1;
  reg reg2;

  assign out = reg2;

  always @(negedge sys_clk) begin
    if (sys_reset) begin
      reg1 <= INITIAL_VALUE;
    end else begin
      reg1 <= in;
    end
  end

  always @(posedge sys_clk) begin
    if (sys_reset) begin
      reg2 <= INITIAL_VALUE;
    end else begin
      reg2 <= reg1;
    end
  end

endmodule


[hamster_nz]

Nope, Bad idea.

The settling time for a metastable FF is an exponential of time, as it needs time for the noise and gain in the system to allow it to resolve.

The metastability settling time for a synchronization chain is the sum of the output timing slacks for each register in the chain. More registers and routing delays leaves less time for settling.

[zapta]

Nope, Bad idea.

The settling time for a metastable FF is an exponential of time, as it needs time for the noise and gain in the system to allow it to resolve.

The metastability settling time for a synchronization chain is the sum of the output timing slacks for each register in the chain. More registers and routing delays leaves less time for settling.

What would make it better than?  No metastability stages? A single stage? Two stages but on the positive clock? Something else?  What if I run both on the positive edge and double the FPGA clock rate? Will this be better?

The FPGA clock is 12Mhz and two clock cycles delay will slows the operation. The FPGA writes bytes to an FT2232 in asynchronous FIFO mode and the TE# (Transmit Enable) signal is used to enable to next byte write. Spending two cycles just for the propogation will result in 12Mhz/(1+2) byte writing rate.

[hamster_nz]

Nope, Bad idea.

The settling time for a metastable FF is an exponential of time, as it needs time for the noise and gain in the system to allow it to resolve.

The metastability settling time for a synchronization chain is the sum of the output timing slacks for each register in the chain. More registers and routing delays leaves less time for settling.

What would make it better than?  No metastability stages? A single stage? Two stages but on the positive clock? Something else?  What if I run both on the positive edge and double the FPGA clock rate? Will this be better?

The FPGA clock is 12Mhz and two clock cycles delay will slows the operation. The FPGA writes bytes to an FT2232 in asynchronous FIFO mode and the TE# (Transmit Enable) signal is used to enable to next byte write. Spending two cycles just for the propogation will result in 12Mhz/(1+2) byte writing rate.

Here's Altera take on it..  You can plug in your suggestions to find the answers (assuming all other things remain constant).

The factor you can control that makes the biggest is change in MTBF is t_MET

[zapta]

Thanks. I will plug my numbers. If I got it correctly the goal is to have sufficient reslution time between the stages, regardless if using pos or neg edge?   (e.g. doubling the FPGA clock and having both stages running on pos clock will keep the analysis the same).

[SiliconWizard]

"Dual-edge" designs are often a risky game when dealing with FPGAs, as most of them don't actually have dual-edge FFs. So they have to insert some logic, and then you're (often) not on a clock tree anymore.
(I remember having seen at least one series that did, but can't remember which.)
TIming analysis (post-PAR) should give you the info you need. But I'd still avoid doing this. One question to ask in your case is, why would an extra clock cycle delay be a problem?

[zapta]

"Dual-edge" designs are often a risky game when dealing with FPGAs, as most of them don't actually have dual-edge FFs. So they have to insert some logic, and then you're (often) not on a clock tree anymore.
(I remember having seen at least one series that did, but can't remember which.)
TIming analysis (post-PAR) should give you the info you need. But I'd still avoid doing this. One question to ask in your case is, why would an extra clock cycle delay be a problem?

Ok, I gave up ;-)  Will double the clock and use pos/pos synchronizer.  There is a reason why I couldn't find examples for a neg/pos syncrhonizer.

My design output one byte a time to an FT2232 in FIFO mode. The #WR signal I generate is high one cycle and low one cycle and with sampling on the falling edge of the #WR outupt. If I will pass the #TE (tx enable) output of the FT2232 through two stage syncrhonizer, the output reate will drop because it will three cycles per byte.

[SiliconWizard]

In async mode, there's nothing much better you can do about it. The obvious advice would be to increase your clock frequency for this process.

Note that in async FIFO mode, the FT2232 maxes out at about 8MB/s best case anyway, so you'd get pretty much the max throughput you can get out of it with a process clock of 24MHz (which doesn't sound very high, but I don't know the details of your design.)

If you need higher throughput, you can consider using the synchronous FIFO mode. Note that with the sync mode of the FT2232, it's the FT2232 that provides the clock (60MHz), so you need to use a dual-port FIFO in your design (easiest path) to cross clock domains. I've used this, you can get up to 30-35MB/s sustained (as long as the host-side code is written appropriately).

[BrianHG]

Make sure your core clock is 4x faster than your input data clock.
Latch all inputs in parallel and do the rest as I do:

wire ena_dual_edge_clk_toggle_detect = latched_input_clk != latched_input_clk_dly;
always @ (posedge core_clock) begin
 all_latched_inputs <= all_inputs;
 latched_input_clk_dly <= latched_input_clk;
  if (ena_dual_edge_clk_toggle_detect) begin
      'process your process'
  end
end

This keeps all your core at a synchronous posedge...
Though, you might have trouble with this if your external data clock is above 100mhz.

Also, many FPGAs have DDR input buffers on most pins which will operate way into the >400mhz domain (800mtps data rates), with buffers and data re-sync buffers designed for re-syncing your inputs to a single posedge clocking system.  Usually we would use a true dual clock FIFO between the DDR buffers and the core system clock to avoid metastability issues and leave the dirty work to the FPGA's megafunction core.