Synchronizer Standard Cell Synthesis

[EmrysOling]

Hello everyone,

I have two asynchronous designs and we opt to place synchronizers between them to reduce metastability probability. We have two different libraries/kits containing base standard cells and performance-optimized cells. These two kits have similar track and cell height. I want to use the flops as synchronizer cells in the performance kit instead of the base standard cell kit.

my question is,

• In my case what is the proper implementation of synchronizers?
  • Do we instantiate these synchronizer cells?
  • or do we allow the tool to select these cells during synthesis using constraints?
  • or do we force the tool to replace the base flops to synchronizer flops during/after synthesis?

If none of the above please advise.

I really don't know how and where to start, Please shed light on this.

 

[glennramalho]

There is no mistery on synchronizers. The idea is simple, there are two flops in series, the first one will go metastable and the second one gets the real value. The reason for this is not immediately obvious.

If you make a graph with the time between D and clk and the propagation delay varies according to the time between D and clk. If the difference is longer than the setup/hold, then the propagation delay of the flop will be slightly shorter than the spec. If the difference is shorter than the setup, the propagation delay of the flop will be longer than the spec. In fact it rises quite fast. See the sketch below (a very rough sketch I must add). So what happens if we have a metastability, the flop takes longer to settle than predicted. So, whatever logic that follows that flop will get an unexpected delay, potentially violating the next stage's setup.

I should add that these extra delays are usually very small. I tried simulating once in a 180nm process using spice and I saw that usually I would get a delay of just a few hundred picoseconds. To get an increase in the propagation delay for the flop of more than 1ns I had to get D and clk really close, well under 1ps. You might ask what is the big deal then. The problem is synthesis stops when the constraints have been met. So if you had a slack of 100ps on the logic that follows the flop it is not that hard to imagine a metastability that will increase the flop's propagation delay by 100ps and kill the next stage. And if you say D and clk are fully asynchronous it is just a matter of probability. Let's say you find out that D and clk have to be 0.1ps apart. What is the chance that would happen 1% chance? 0.01% chance? Remember though that the circuits are toggling millions of times per second, so a 1% chance might not be that hard to hit.

What is the synchronizer for then? Well, like I said, in my experiment to get a delay of 1ns I had to try hard. What about a delay of a full clock cycle. The second flop does just that. We will put two flops in series so that the first one has a full clock cycle to settle before the second one captures the result. Let's say we were at 100MHz, to get a delay increase of 10ns. For a 180nm process the difference down to attoseconds, so very unlikely. I mean really unlikely. Of course, the actual delay will depend on the technology being used, standard cell design, and other stuff. On modern processes too, 20, 30, 45nm flops will have some tricks to improve metastability margin. Even in them it is 2 flops is usually enough. And if you are really worried, just add a third flop (which is almost always unecessary); You can ask a analog engineer to calculate the MTBF or perhaps your stdcell library provider has done that calculation. But almost always 2 flops are good.

There are flops proper for synchronizers, these had an adjustment to the sizes of the feedback inverter of the second latch. There is all a discussion if they should be without reset or if that does not matter. Frankly, I just use regular flops and they will do just fine. And if you are really scared, put a third flop on it.

I would say, more important is to make it so one can quickly find them in synthesis. Often people just place the synchronizer in the middle of the RTL with no special identifiable name. The issue there is, when you have two clocks that are asynchronous to each other, synthesis will often guess a relationship. Then it will add buffers to make sure that relationship is matched; being there is no relationship the tool is just adding completely unecessary logic. Some will just put in a set_clock_groups -asynchronous, and that will settle it, but this also makes it easier to let a real path that should have had a synchronizer pass by unchecked. So I always make sure I use something standardized.

In most companies I worked then the rule is:

• create a synchronizer module and put it in a common folder. You should do this for clockgates and other common structures. Always use the ones in this folder.
• this synchronizer should be a simple RTL code describing the synchronizer. You can manually specify the flops if you have some special need, but I just let the tool pick something.
• there should be no logic between the two flops, so the output of one goes straight to the other
• then use a standard naming system to instantiate them, ex: always call them i_sync_whateversignalname.
• then in synthesis find them and tag them, for example: set_false_path -to [get_cells -hier i_sync_*] or set_false_path -to [get_pins -of_objects [get_cells -hier i_sync_*] -filter { @direction == in }]

Note: some tools might have some rules. Xilinx Vivado recommends you to set the "ASYNC_REG_TRUE" parameter to the flops in the synchronizer.

so here is a standard synchronizer RTL

module synccell #(parameter DEF=1'b0) (input clk, input rstn, input d, output reg Q);
reg meta;
always @(posedge clk or negedge rstn)
  if (!rstn) meta <= DEF
  else meta <= D;
always @(posedge clk or negedge rstn)
  if (!rstn) Q <= DEF;
  else Q <= meta;
endmodule

 

[ThisIsNotSam]

I am confused by what you call performance kit. It means different things for different vendors. In TSMC lingo, the performance kit has all the power shut off cells and the isolation cells and the retention cells. Make sure you are not using a retention cell for implementing the synchronizer, this is not needed. Standard flops are ok for this.