@User Was hoping to pick your brain about some layout issues with my design. There's quite a few macros which I am manually placing. I am placing them towards the edges, but leaving enough space for the met4/met5 straps to provide power to the chunks of met1 between the edge and the macro. I did this because I can't see anything to prevent placement from putting a cell in these regions (eg buffering an I/O) and as such they'd be unpowered. I was wondering what best practices are here. I can move them closer to the edges, but I presume I still need some space to route the user_project_wrapper external I/Os. My macro pin placement avoids these narrow areas, so that isn't a problem. How do I avoid the original placement issue in that case? Does Openlane need an easy way to specify placement blockages?

Sorry Anton, I don't have any experience in this area yet, but there have been some discussions about incorrect power routing through macros.

Thanks Mitch. I did see some of those discussions, and it does look like vias are in the correct place to power the macros. Can I use CVC to verify power connections to the complete user_project_wrapper design, including the macros?

You should be able to do that. Right now the cvcrc file is generically setup to be used in the openlane flow.tcl, but you should be able to copy and modify it locally. You can then run interactively to examine the connections. Something like this

cvc -i mycvcrc
> continue
> expandnet *(*)/VPWR
> expandnet *(*)/VGND

That should show you what all your standard cell power connections are. Of course you can use macro names too.

> expandnet *(macroname)/VPWR

If you have the netlist extracted from GDS, you can use that too (after changing the device lines). If you wanted me to walk you through it via zoom sometime, let me know.

Thank you Mitch. I'm not quite there yet, but will try that and report back when I do

Excellent! Nice work reporting the short. Correct by design is a nice concept when it works, but I think it's important to have independent double checks.

Thanks! I'm still impressed by LVS and how well it works.

@Anton Blanchard I'm curious about your need to manually place the macros and what happens with automatic placement. We are working on a new macro placer in OR and perhaps we should test on your design.

@Matt Liberty I was doing manual placement way back on the MPW1 shuttle, so it's mostly a hold over from then. I can give the new macro placer a try sometime soon

@Anton Blanchard What is the size of your SRAM? I did not use any halo and it looked fine (4KB SRAM)

@mehdi I'm still using DFFRAM based RAM (4kB). The halos helped the register file and multiplier macros mostly. Let me push what I have.

Thanks @User - Then I need to check back but I remember that after removing the macro wrapper in ORFS, the SRAM did not have any issues. Re: the ECO flow, are you using openlane? we did not port the flow to orfs yet. But here is the doc: https://docs.google.com/document/d/1RYWNeVjQpBkMhN1LGLOyMwwtLzFAENI-veqsfWg-5v8/edit

Thanks. I am using openlane, let me give it a try now

Let me check. It seems the design path is not set correctly.

Ok let me try that

hmmm It works from my side.

@Haolin Dong Ok. I was referring to the fact that the branch on that PR has conflicts with upstream

@Anton Blanchard Thanks. The conflicts are just some formatting things. Let me know if there are any issues regarding the eco flow.

Lots of whitespace changes, in general it's better for them to be in a separate patch. I also noticed this and wanted to confirm that it is correct:

# pin
-                    if (pin_name == ''):
+                    if (pin_name == '' and skip_pin == 0 ):
                         pin_name=start_point
                         pin_type="BTerm"
                         # continue
-                    vio_dict[pin_name + " " + pin_type].append(float(minus_time_str.group(1)))                     
+                        vio_dict[pin_name + " " + pin_type].append(float(minus_time_str.group(1)))

Thanks @Anton Blanchard For LVS are you picking up the netlist /final files out of eco? this should be done automatically but just checking

@mehdi If I enable the ECO flow, I see fill issues. For some reason it's only using decap_3 cells, and there are lots of gaps.

@Anton Blanchard Thanks. I will check the code and fix these things.

@Haolin Dong Makes sense, but my question was around avoiding a final extra pass to add fill, then do routing. The buffer fixup stage could remove all fill, then add buffers

I think in our current version, if we disable the eco, then ECO_FINISH will be 1. So the original fill process won’t be skipped.

I presume the fill will potentially have DRC issues with routed signals. I'm not sure though

I see. I’ll check that in a while. I was working on other stuff this morning.

Thanks. One other interesting thing I found:

insert_buffer io_in[33] BTerm sky130_fd_sc_hd__dlygate4sd3_1 net_HOLD_NET_0_1 U_HOLD_FIX_BUF_0_1
insert_buffer io_in[33] BTerm sky130_fd_sc_hd__dlygate4sd3_1 net_HOLD_NET_0_2 U_HOLD_FIX_BUF_0_2
insert_buffer io_in[33] BTerm sky130_fd_sc_hd__dlygate4sd3_1 net_HOLD_NET_0_3 U_HOLD_FIX_BUF_0_3
...
insert_buffer io_in[33] BTerm sky130_fd_sc_hd__dlygate4sd3_1 net_HOLD_NET_0_97 U_HOLD_FIX_BUF_0_97
insert_buffer io_in[33] BTerm sky130_fd_sc_hd__dlygate4sd3_1 net_HOLD_NET_0_98 U_HOLD_FIX_BUF_0_98
insert_buffer io_in[33] BTerm sky130_fd_sc_hd__dlygate4sd3_1 net_HOLD_NET_0_99 U_HOLD_FIX_BUF_0_99

IO can be fixed by constraints. There is a option for disable BTerms.

But regardless, it seems like you should only place 1 buffer on a bad path per iteration right?

No, the number of buffers depends on the slack and the routing may slightly influence the slack. If the slack is small then It will insert only one buffer.

Ok that makes sense, and yes I now see the negative slack is pretty huge. 14ns of delay in the clock tree

@Anton Blanchard you can skip input to reg paths by setting a variable (see PR). Those paths needs are showing huge violations because the sdc isn't updated for multicorners timing checks. Do you have reg-to-reg violations?

@mehdi Thanks. I saw that, and did enable it because I thought I had to time my I/Os (I want to run a synchronous bus on some of my I/Os). Let me disable it for now and get clean, and then think about any issues with I/Os

Great @Anton Blanchard, regarding the fills: removing them then adding them shouldn't create a DRC problems in sky130. We have done so on our previous design. @Haolin Dong at the last iteration, are you adding back the fills/endcaps etc?

@mehdi I could reduce the DFFRAM but the macros I'm thinking about are my own multipliers and register file

your multipliers are custom? are these banks?

Custom multiplier

I need to run your design at some point this week. Let me know the paths that are failing or your timing reports and we can try to review that. But normally the ECO flow should fix them

@mehdi Ok. I need to commit the DFFRAMs, will do that today.

do you have a custom data path? and how are you generating .libs for the custom blocks? QTM?

This is where I am currently stuck. How do we handle macro timing in openroad/openlane. @Matt Liberty mentioned .lib files the other day but does openroad create them and openlane consume them?

I do not think OR is creating them. Maybe @Matt Liberty knows something about that. Also not sure if openlane is calling a tool to do so? I saw the other day a tool for .lib generation for standard cells. I will paste it if I find it.

@Haolin Dong I just retested with the latest ECO fixes and I still don't see any fill cells in my final GDS

You should look at the rows in the OR GUI to see if there are placement sites. I think the default placement halo around a macro is quite large in OL:

Hi @Matt Liberty, it's not just the macro halo. I have a bug here to track it https://github.com/The-OpenROAD-Project/OpenLane/issues/936

@Anton Blanchard: @Haolin Dong is working on it. The fix should be simple I am hoping

Yes. I've found the error and already come up with a way to solve it. Basically, we need to run routing again when the eco step is done. But I have trouble using

make pdk

to update my open_pdk verison so I am not able to test it. I got the error:

Error message output from magic script:                                                                                              /home/haolind/OpenLane/pdks/open_pdks/sky130/sky130A/libs.tech/magic/sky130A.tech: line 19: section version:                                 Error:  Magic version 8.3.260 is required by this techfile, but this version of magic is 8.3.209.                            The following sections of /home/haolind/OpenLane/pdks/open_pdks/sky130/sky130A/libs.tech/magic/sky130A.tech contained errors:            version                                                                                                                          Traceback (most recent call last):                                                                                                     File "../common/foundry_install.py", line 1696, in <module>                                                                            cwd = destlibdir,                                                                                                                  File "../common/foundry_install.py", line 274, in subprocess_run                                                                       raise SystemError("".join(emsg))                                                                                                 SystemError: Command magic failed with exit code: -11                                                                                  magic -dnull -noconsole

@Anton Blanchard Do you have any ideas on this? Thanks!

@Haolin Dong There was recently an update to allow building the pdk in docker. https://skywater-pdk.slack.com/archives/C017HPHCMEY/p1644995964291059

@Anton Blanchard Hi. I pushed a commit on OLL solving the insfill issue. I hope it can help.