How to contribute?

[niv280]

Hi, There is any way to contribute to the openRoad project?

[QuantamHD]

They accepted code changes through PRs.

Is there something you are interested in working on?

[maliberty]

We are glad to have contributors. Do you want some suggestions or do you have something in mind?

[niv280]

I don't got specific idea, I was hoping you got some open item which I can work on.

[maliberty]

To help narrow it a bit are you more interested in development, testing, documentation, outreach? If you are willing to share a bit about yourself it would help to find a task of appropriate complexity.

On the development side one idea that comes to mind is to improve write_abstract_lef written by @QuantamHD to give more precise obstructions. I can describe that further if it is of interest.

[niv280]

I am more interested in the development, I'm physical design engineer and in the past year I am working mainly in STA area.
To be honest I don't got a lot of professional coding skill, but I am love to code in my free time and I willing to learn and improve.

The write_abstract_left sound like very good start, can you explain more about it?

[maliberty]

The LEF abstract is a physical model of a block that is intended to be used at a higher level in the hierarchy to model the interface and obstructions in the block. The current code starts from

OpenROAD/src/odb/src/lefout/lefout.cpp

Line 1213 in c4a8479

bool lefout::writeAbstractLef(dbBlock* db_block, const char* lef_file)

The current code is rather simplistic in its modeling of obstructions. If you look at lefout::getTechLayerObstructions it just gathers a set of layers that have any shapes on them and then blocks the entire layer.

I think it would be better to use Boost polygon to OR together the shapes on each layer; do a bloat then shrink cycle to merge them into simpler shapes and then write out the result as the layer obstruction. The amount of bloating could be a user control with a reasonable default (say 2*pitch).

The goal is to balance model size with precision. Does this make sense? I can go into more detail where needed.

[niv280]

Ok, I started to review the code and I get the general Idea.
There is any place I can see example of lef that the created by the current code?

Also can you elaborate on the bloat and shrink cycle?

[stefanottili]

Please keep in mind that there are two types of abstracts used by $$$ tools. The “cutout” where obstructions are cut out around pins and the “cover everything” where the pins are at the edges and the block is completely covered with obstruction. For the latter to work, the router has to be smart enough to route to covered pins and drc has to know that covered pins on the edge are ok too. It’s good practice to have pins on the edge of blocks anyways.

[maliberty]

Cutting out the pins is unnecessary unless they are not on the edge of the block.

[maliberty]

You can see gcd_abstract* in https://github.com/The-OpenROAD-Project/OpenROAD/tree/master/src/odb/test for two examples.

The idea of the bloat/shrink cycle is to merge nearby shapes. I've tried to quickly illustrate it with:

You can learn about Boost polygon at https://www.boost.org/doc/libs/1_79_0/libs/polygon/doc/index.htm (the docs aren't great).

[maliberty]

The red boxes in the middle image merge together into a single polygon

[niv280]

Hi, I will love to get some help in 2 issues.
First I will need to import to boost::polygon library, in which file can I do it? Do other part of the code already import it?

Second, I having trouble to understand how can I test my change, I gather all the shapes into kind of list and I now write it into the lef file instead the whole block boundary bbox, but I probably got some mistake so I want to run some test to debug it.
There is any tutorial how can I do it?

[maliberty]

Boost is widely used so I don't think there will be an issue to import it where needed (lefout.cpp)

You can look at the existing unit tests for an example of how to test your change. You can build a small unit test for testing

[niv280]

Hi, So I make some progress with the abstract lef.
But I encounter on some problem that I would like to get some help.

So I modify the abstract lef that in order to write the merge between all the rect that intersect ( after bloat ).
To demonstrate it I edit the picture from above:

The green rect is currently my OBS which isn't very efficient, but i didn't found any easy way to do it with the utils in the rect class.

So I am guessing that I need to go back to your first suggestion which is use boost polygon to OR all the rect, my problem is that is after that I will need to convert it back into different rects, there is any easy way to do that?

[stefanottili]

https://www.boost.org/doc/libs/1_79_0/libs/polygon/doc/gtl_polygon_90_set_concept.htm Have a look at get_rectangles and get_max_rectangles On Aug 25, 2022, at 02:20, niv280 ***@***.***> wrote:  Hi, So I make some progress with the abstract lef. But I encounter on some problem that I would like to get some help. So I modify the abstract lef that contained the merge between all the rect that intersect. To demonstrate I edit the picture above: The green rect is currently my OBS which isn't very efficient, but i didn't found any easy way to do it with the utils in the rect class. So I am guessing that I need to go back to your first suggestion which is use boost polygon to OR all the rect, my problem is that is after that I will need to convert is back into different rects, there is any easy way to do that? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[maliberty]

get_rectangles would be the better choice as get_max_rectangles may produce overlapping rectangles. You an experiment with the slicing direction to see what produces a more minimal result. My guess is the non-preferred routing direction will work best.