In the meantime I pushed a patched docker image to

htms/openlane:mpw-3a

. This is not using the modified decap_12 cell that @User is working on but a combination of standard decap and fill cells. With the right settings it made my previously failing tapeout jobs pass. To use it, update

OPENLANE_IMAGE_NAME

in openlane/Makefile, add

set ::env(DECAP_PERCENT) 75

to your project's config.tcl and if you made changes to DECAP_CELL or FILL_CELL, comment them out. It will fill the empty space in your design with 75% decap cells and 25% fill cells. You might have to tweak this 75 if you still have density issues.

@User I’m giving it a try, right now. Thank you.

@User As far as I understand slew violations are not critical. Try to get your design through precheck and tapeout and see if it works. After that you can try to iron out the slew issues.

@User OK, I’ll give it a try. Thank you.

Congrats. Digital circuits are pretty complex so it would be hard to simulate their timing on the full circuit level. Instead they simulate the behaviour of the individual standard cells under certain conditions and then use this data to calculate the timing for the full chip. A slew violation occurs when some cell doesn't satisfy these conditions, so there is no pre-calculated timing info for the cell. In this case the static timing analyzer extrapolates the existing data, which can result in inaccuracies. Most of the time it's harmless, but it might mean that a setup or hold violation goes undetected. Slew violations typically occur when more current is drawn from a cell than it was designed to drive (i.e. the cell's output is used as an input in several other cells). They can usually be dealt with by setting a lower fanout limit for synthesis or resizing cells (using variants with bigger drive strength) or buffering (adding buffer cells whose output is the same as their input but only use some power from the input cell and the rest from the power rails).

@User Wow! Thanks a lot. A very complete description of the issue and its solutions. So how can I make sure if in my case it is harmless or I’m missing something (like undetected hold violation in worst case)?

You can't make it absolutely sure unless you fix the violations, so it makes sense to give it a try. But even if you don't succeed, you can still get into the shuttle and will most likely get a chip that works (or at least fails for some unrelated reason 🙂).

@User Currently it has only violations on ss corner. MAX_FANOUT = 4 CLOCK_BUFFER_FANOUT = 8

That should be fine. I've read it in one of the channels that they would keep the fabrication as close to the typical corner as possible.

@User Hi, thanks for the patch. Now we have passed the tapeout checking. However, in the wrapper we obtain this:

===========================================================================

report_check_types -max_slew -max_cap -max_fanout -violators

============================================================================

max slew

Pin                                    Limit    Slew   Slack

------------------------------------------------------------

la_data_in[120]                         1.50    8.63   -7.13 (VIOLATED)

la_data_in[117]                         1.50    8.16   -6.66 (VIOLATED)

la_data_in[108]                         1.50    8.10   -6.60 (VIOLATED)

la_data_in[122]                         1.50    7.94   -6.44 (VIOLATED)

la_data_in[115]                         1.50    7.85   -6.35 (VIOLATED)

la_data_in[124]                         1.50    7.80   -6.30 (VIOLATED)

la_data_in[125]                         1.50    7.75   -6.25 (VIOLATED)

la_oenb[115]                            1.50    7.74   -6.24 (VIOLATED)

Is it critical? Seems to be huge

@User These numbers are indeed larger than the ones I usually see. I still don't know whether it's critical, this sort of stuff will be easier to know once we have more experience with how chips produced in earlier MPW runs behave in practice. I suggest that you try fixing it. As you see above, reducing SYNTH_MAX_FANOUT and CLOCK_BUFFER_FANOUT helped for @User, so you can try experimenting with those values.

@User @User I managed to solve the slew violations of the “Macro” for TT and FF corners by changing the parameters. But it still exists for the wrapper and there’s nothing I can do for the wrapper (we can not put buffers in the wrapper, I guess). One possible issue which cause such problem could be the missing of .lib files for the FILL1 and FILL2 (the tool warns us multiple times against it).

@User it would be possible to use your openlane for the macros and then the other openlane for the wrapper? might this solve the slew violations in the wrapper?

@User That’s a great idea. Do you mind give it a try? Because I think it’s completely possible (note that currently our OpenLane version and efabless’s are completely different and we passed the precheck and tapeout successfully). But you should switch BW different PDKs and OpenLanes.

well, its a docker, so maybe is changing the OPENLANE_IMAGE_NAME from efabless to the one of @User and viceversa

As well as the PDK version I guess.

but i don't know if its legal or what, maybe the @User image is equal to the original one for the things of the wrapper and the slew violations comes from the macro side when it is integrated into the wrapper

So you should see them again if anything breaks.

@User Sure, it's perfectly possible to use two different docker images for building the macro and the wrapper. Just indicate it somewhere in your final documentation so that others can rebuild your project if they wish to build upon it.

@User you are correct. @User can you provide some guidance?

@User As long as you have no hold/setup violations, you should not worry about slew rate violations. For sure, it is good to reduce the transition time (slew) to reduce the delay and the short circuit current.

@User @User We have tried my idea of using different docker images for macros and the wrapper. it worked and passed the prechecks. We have the same slew violations in the macros as always but we don't have the new slew violations in the wrapper. To sum up, htmas images for macros, default image for wrapper

If my image has extra slew violations in the wrapper, it's probably because I didn't use the exact same commits for the packages as in the official image. I just used the newest version of everything at the time. The patch itself shouldn't change anything for the wrapper as it is designed to do nothing unless

DECAP_PERCENT

is defined in

config.tcl

. I could rebuild the image with a specific set of commit hashes, but for the time being using the official image for the wrapper is a clever workaround.