Dear Openlane team, am I right that x(n)ors are not used in the flow ? If so, is there a chance to add them again ? I need them to generate a spike "free" clock generator circuit (and larger netlists without x(n)ors are kinda weird). Thanks for your answer in advance.

It seems wrong. Can you build a minimal test case where you expect an xor to be used and file an issue

Thank you for your answer. x(n)or_1 show up in the open_pdks/sky130/openlane/sky130_fd_sc_hd/*no_synth.cells* list. So I guess yosis isn't using them. Follow up tools either use the same excluding list or might not be smart enough to do a proper technology-mapping\optimization. Or I'm wrong. Any medium size netlist has x(n)ors. So you can check it with a grep _x netlist....v if an x(n)or exists on your largest available netlist. It has been mentioned, that the exclusion is due to router issues. But it supports ao.... cells with equal complexity. Right now I don't have time for submitting an issue. Thanks, Tobias

All the

*_1

cells are excluded (not just xnor) during synthesis (

no_synth.cells

). It was never clear to me why, but I'm guessing it's so we use the larger cells in an attempt to help placement and routing. The cells will eventually get shrunk by the resizer if they are too large. We already have cell padding for this, so I wonder how much this is helping in reality. @User do you have any more insight into this? I see

xnor2_2

cells in the Microwatt design after synthesis, so we are definitely not excluding all xnors from synthesis:

sky130_fd_sc_hd__xnor2_2 _055833_ (
    .A(\microwatt_0.soc0.uart0_16550.uart0.regs.transmitter.fifo_tx.bottom[3] ),
    .B(_009495_),
    .Y(_009496_)
  );

Later on in the flow, we exclude a smaller set of cells (

no_synth.cells

). These probably had pin access issues ages ago but should be re-evaluated with a recent version of OpenROAD. I attempted that in https://github.com/RTimothyEdwards/open_pdks/pull/211 but it caused routing issues at the time, and I haven't been able to go back to root cause it.

Thanks for your answer. So my assumption was wrong and I will try xor_1 in my design. Thanks. Out of curiosity, where do you "exlclude a smaller set of cells" in the flow ? might be good to now for handcrafted designs. Cheers.

The small cells are excluded as the router had not difficulty with pin access

@User Thank you for your reply. There are a lot of small (and large) cells in the final ...lvs.powered.v netlist. So why excluding them for synthesis in the first place ?

@User Refer this https://github.com/The-OpenROAD-Project/OpenLane/blob/7891c2c8859e8c800226920c181fa039ad298e79/configuration/README.md and search for

NO_SYNTH_CELL_LIST

will provide default cell list excluded. You can manually customize as per your need

@User Thank you for your reply. This cell list file you are refering to has already been mentioned in this thread. And I'm not sure if your reply answers the open questions I directed to Matt and Anton. The list contains all _1 cells available but some _1 cells are used in the final netlist list. So my questions are a) why excluding them in the first place when they show up in the final netlist anyway and b) where to exclude them, so that they don't show up in the final netlist.

Possible can you provide test case and which cells excluded and shown again in final netlist?

When I make a "_1" grep on a lvs.powered.v netlist I see all kind of comb cells and dffs. You can give it a try on one of your netlists.

@User Here is default exclude cell list:

sky130_fd_sc_hd__a2111oi_0
sky130_fd_sc_hd__a21boi_0
sky130_fd_sc_hd__and2_0
sky130_fd_sc_hd__buf_16
sky130_fd_sc_hd__clkdlybuf4s15_1
sky130_fd_sc_hd__clkdlybuf4s18_1
sky130_fd_sc_hd__fa_4
sky130_fd_sc_hd__lpflow_bleeder_1
sky130_fd_sc_hd__lpflow_clkbufkapwr_1
sky130_fd_sc_hd__lpflow_clkbufkapwr_16
sky130_fd_sc_hd__lpflow_clkbufkapwr_2
sky130_fd_sc_hd__lpflow_clkbufkapwr_4
sky130_fd_sc_hd__lpflow_clkbufkapwr_8
sky130_fd_sc_hd__lpflow_clkinvkapwr_1
sky130_fd_sc_hd__lpflow_clkinvkapwr_16
sky130_fd_sc_hd__lpflow_clkinvkapwr_2
sky130_fd_sc_hd__lpflow_clkinvkapwr_4
sky130_fd_sc_hd__lpflow_clkinvkapwr_8
sky130_fd_sc_hd__lpflow_decapkapwr_12
sky130_fd_sc_hd__lpflow_decapkapwr_3
sky130_fd_sc_hd__lpflow_decapkapwr_4
sky130_fd_sc_hd__lpflow_decapkapwr_6
sky130_fd_sc_hd__lpflow_decapkapwr_8
sky130_fd_sc_hd__lpflow_inputiso0n_1
sky130_fd_sc_hd__lpflow_inputiso0p_1
sky130_fd_sc_hd__lpflow_inputiso1n_1
sky130_fd_sc_hd__lpflow_inputiso1p_1
sky130_fd_sc_hd__lpflow_inputisolatch_1
sky130_fd_sc_hd__lpflow_isobufsrc_1
sky130_fd_sc_hd__lpflow_isobufsrc_16
sky130_fd_sc_hd__lpflow_isobufsrc_2
sky130_fd_sc_hd__lpflow_isobufsrc_4
sky130_fd_sc_hd__lpflow_isobufsrc_8
sky130_fd_sc_hd__lpflow_isobufsrckapwr_16
sky130_fd_sc_hd__lpflow_lsbuf_lh_hl_isowell_tap_1
sky130_fd_sc_hd__lpflow_lsbuf_lh_hl_isowell_tap_2
sky130_fd_sc_hd__lpflow_lsbuf_lh_hl_isowell_tap_4
sky130_fd_sc_hd__lpflow_lsbuf_lh_isowell_4
sky130_fd_sc_hd__lpflow_lsbuf_lh_isowell_tap_1
sky130_fd_sc_hd__lpflow_lsbuf_lh_isowell_tap_2
sky130_fd_sc_hd__lpflow_lsbuf_lh_isowell_tap_4
sky130_fd_sc_hd__mux4_4
sky130_fd_sc_hd__o21ai_0
sky130_fd_sc_hd__o311ai_0
sky130_fd_sc_hd__or2_0
sky130_fd_sc_hd__probe_p_8
sky130_fd_sc_hd__probec_p_8
sky130_fd_sc_hd__xor3_1
sky130_fd_sc_hd__xor3_2
sky130_fd_sc_hd__xor3_4
sky130_fd_sc_hd__xnor3_1
sky130_fd_sc_hd__xnor3_2
sky130_fd_sc_hd__xnor3_4

I dont find these cells in my netlist.

The list contains all _1 cells available but some _1 cells are used in the final netlist list. So my questions are a) why excluding them in the first place when they show up in the final netlist anyway and b) where to exclude them, so that they don't show up in the final netlist.

I explained this above. I think we exclude all the _1 cells at synthesis stage to help with routing. We don't exclude them from the resizer, so that's why you see them in the final netlist

I assume that the list used for synthesis is [1] and these cells show up in the final netlist. So why exclusing them from synthesis. If someonw can show me the link to the list for the resizer, that would be great. @User where is your list from ? Cheers. [1] https://github.com/RTimothyEdwards/open_pdks/blob/master/sky130/openlane/sky130_fd_sc_hd/no_synth.cells

The exclude list used later on in the flow is https://github.com/RTimothyEdwards/open_pdks/blob/master/sky130/openlane/sky130_fd_sc_hd/drc_exclude.cells

Thanks Anton for showing the link. I was not sure due to its confusing name that it covers also the resizer. Thanks again. For some weird reasons I don't want a buffer-chain to be replaced with a delay cell, so I will add all delay cells to the drc_exclude file. Thanks again.

The lists aren't particularly well named. You also might be able to disable the resizer completely if you are sure you aren't creating violations (hold, max slew, max capacitance). DFFRAM does that for example.