https://open-source-silicon.dev logo
#openlane
Title
# openlane
a

AndrewSftD

08/11/2020, 10:56 PM
is there a reason why all those cells are on that list ? (I know one previous reason mentioned was to keep runtime decent because of there being so many cells)
a

Ahmed Ghazy

08/12/2020, 3:55 PM
Actually running time is not one of the reasons. First, there are some cell types that you don't want to use in synthesis like, for example, delay cells and clock buffers (since CTS is a separate step that would insert the clock buffers). Second, some of the cells, back when this list was created, had hard-to-access pin shapes, so the detailed router didn't manage to do routing cleanly. However, this list is likely over-constraining, and if you have done experiments allowing smaller sizes incrementally and still got clean routed layouts, please let us know your findings, or better yet, submit a pull request at open_pdks with a suggested no_synth list. The above should and will be documented under https://github.com/efabless/openlane/blob/master/doc/PDK_STRUCTURE.md soon.
a

AndrewSftD

08/12/2020, 4:13 PM
@Ahmed Ghazy ok thank you for that, along the line of what I was expecting
unfortunately this is a very long discussion
currently I have been running a slightly larger and more complex design
and there as actually a couple of things here: 1. I would caution that the parameters PL_TARGET_DENSITY & FP_CORE_UTIL are a lot more important than the current doc leads on...
and not just for one step but they actually influence a lot of steps in the flow as well as how the outputs of those steps interact
2. I am not at all happy with the solution of solving antenna by inserting diodes (I already had a bad feeling during the presentation), to make a longer story short for most users if we document DIODE_INSERTION_STRATEGY properly that should be enough
for any advanced use cases though (which means targeting high to very high utilization) this is just not a good idea
it leads to problems....
and personally it also seems like a very massive workaround
I am still collecting findings, once I have some stuff documented properly with test cases I will bring it forward (unfortunately larger designs are not that fast to test, and I am not 100% on this currently)
and 3. also related to my cells questions above: SYNTH_MAX_FANOUT also has quite a large impact on the flow (did not really see a lot of doc on this already), in particular depending on the cell set it is coupled with it can make it such that triton cts (or other steps like the placer become really unhappy or just give up on you)
a

Amr Gouhar

08/12/2020, 6:03 PM
@AndrewSftD refer to this and that since you're running experiments. They should be a great help. Also the version of this on the develop branch is more powerful.
a

AndrewSftD

08/12/2020, 7:06 PM
yeah, the wiki is what i was refering to above. second sugestion makes a lot of sense and does look like it will help, i will give a try later and i will pull dev as well
@Amr Gouhar & @Ahmed Ghazy is there any plan for a software freeze yet for the shuttle ?
or are we just going to wing it, and keep adding changes right up until the tapeout ?
a

Ahmed Ghazy

08/18/2020, 1:20 PM
@AndrewSftD: There's another release by Mohamed Kassem's dial-up talk; there are always going to be issues that we discover and fix or report in one of the tools, but we hope by then that things will be stable enough for the shuttle.