How can we do something like this in openlane something like this , don’t want openlane to optimise some part of my design which is asynchronous @Mitch Bailey @Anton Maurovic (efabless support)#================================= # 1ns delay subblock _elaborate #================================= elaborate $dly_1ns current_design $dly_1ns # delay gate add "SCS130MS_DLYGATE4SD3_1" adds 0.3ns delay # delay gate add "SCS130MS_DLYGATE4SD2_1" adds 0.1ns delay insert_buffer i_inp scs130ms_dlygate4sd3_1 -new_net_names w_out -new_cell_names fine_buf -no_of_cells 3 insert_buffer i_inp scs130ms_dlygate4sd2_1 -new_net_names w_out -new_cell_names fine_buf -no_of_cells 1 set_dont_touch [get_cell fine_buf*] set_dont_touch [get_net i_inp] set_dont_touch [get_net w_out*] compile -map_effort high

@samarth jain I assume that the instructions you’ve shared are for some commercial synthesis tool. I’m not familiar with commercial synthesis tools, so I probably won’ t be much help. Maybe using the

RSZ_DONT_TOUCH*

variables would work.

How can I use it? Any example or documentation 😅

@samarth jain I don’t have any actual experience with this. You might try this openlane2 document. I don’t know if the openlane1 variables are the same or not. I’m guessing that this would be the settings you want to use.

"RSZ_DONT_TOUCH_LIST": [ "fine_buf*", "w_out*", "i_inp" ],

But if you’re trying to insert a specify quantity of buffers on a given net, then you might want to ask on #C0161A4A59V.

I have tried doing it by editing the openlane/user_proj_example/config.json & openlane/user_project_wrapper/config.json file. While there were no errors in the flow, I still don't see any difference in the gds before and after adding the "RSZ_DONT_TOUCH" attribute. I have uploaded the runs folder in my drive @ https://drive.google.com/drive/folders/1_L-cRleF7j8okcwwmSPkNyPp9WIKMwmP?usp=sharing Is this the correct way to do it? Also, I noticed that some of my nets are floating here, which is not the case when I compared to the gds out on my cadence Innovus flow. Could you speculate on why that could happen? Thanks. @Mitch Bailey

With innovous are you explicitly adding buffers and then exempting them from buffering?

We simply don't want the optimization to happen to these cells, that's all. This is mainly because we noticed some critical parts getting completely ignored and optioned out during the optimization. Also, I was trying to add a few of my own pads on the gds that I could possibly use for a flip chip in the future, but after adding it manually into the def files in caravel_user_project/def/user_project_wrapper.def I found out that the file gets overwritten during the

make user_project_wrapper

. Perhaps this is the wrong way to do this. Could you please advise on how any new pins may be added to design? We had a meeting with @Anton Maurovic (efabless support) yesterday and changed the

RSZ_DONT_TOUCH_LIST

to:

"RSZ_DONT_TOUCH_RX": "cnt_fine.*|d_ff.*|dly_1ns.*|dly_dff_init.*",

which is the correct way to do it for openlane1. Get back to you with the results as soon as we can try & verify it. Thanks! @Mitch Bailey ~Anubhav

Hi @samarth jain / Anubhav, I like that you're trying to do bond pads inside your user project area and also get a hardening result with OpenLane -- a nice hybrid. I would say the easiest way to put IO cells or pads into the user project area is to just direct OpenLane to place them as macros (e.g. via

macro.cfg

) and then wire them up in

user_project_wrapper.v

. That could work, but with very small wire traces it might also not be great, depending on your actual need for those pads, so... Maybe letting OpenLane do routes to them for you is not ideal, in which case I'd say you have a few options: • Manually edit the layout after OpenLane is done, e.g. to make thick traces for power to the IO cells (and a thick analog signal trace from the pad if you need that too). • Create a macro -- a custom layout -- that contains a line of IO cells (i.e. you can place and rotate that line as many times as you need -- use it to create two lines, a square, or even a BGA -- and include the IO power rails and signal traces, with ports on the edge of that macro for signals that are suitable for OpenLane to route, and for power nets your macro could either drop back down to metal4 and let OpenLane connect to the metal5 PDN for you with vias, OR you could implement power rings in your macro edges (see power options). Again, you might need to manually route your fat analog signal traces (assuming you have any). @Kareem Farid @Marwan Abbas any thoughts, or other ideas?