Skip to content

Comments

ODB: cuboid shape for dbMarker#9516

Open
osamahammad21 wants to merge 3 commits intoThe-OpenROAD-Project:masterfrom
osamahammad21:odb-marker-cuboid
Open

ODB: cuboid shape for dbMarker#9516
osamahammad21 wants to merge 3 commits intoThe-OpenROAD-Project:masterfrom
osamahammad21:odb-marker-cuboid

Conversation

@osamahammad21
Copy link
Member

Introduce Cuboid as a shape type for dbMarker to represent 3d violations needed by the 3dviewer.

Signed-off-by: Osama <osama21@aucegypt.edu>
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

The pull request successfully introduces the Cuboid shape type for dbMarker, which is essential for representing 3D violations in the 3D viewer. The implementation covers geometry definitions, database serialization, and GUI rendering. However, I identified a critical issue regarding the JSON/PTree serialization of markers, where the new Cuboid shape is not handled, which will lead to crashes during report generation or loading. I have also suggested a minor optimization in the 3Dblox checker, aligning with best practices for loop efficiency.

Comment on lines +142 to +147
case _dbMarker::ShapeType::kCuboid: {
Cuboid c;
stream >> c;
obj.shapes_.emplace_back(c);
break;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

The populatePTree and fromPTree methods in this file (lines 275 and 382 in the full file) also need to be updated to handle the Cuboid shape type. Currently, populatePTree has a default else block that assumes a Polygon, which will cause a std::bad_variant_access exception when encountering a Cuboid. Similarly, fromPTree will fail to reconstruct markers containing cuboids from JSON/TR reports.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True but 3dblox violations are not yet handled in that scope altogether. I intent to address this in a separate PR.

Copy link
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clang-tidy made some suggestions

Signed-off-by: Osama <osama21@aucegypt.edu>
@github-actions
Copy link
Contributor

clang-tidy review says "All clean, LGTM! 👍"

@maliberty
Copy link
Member

After approving I realized you need to rev the db schema to prevent an old version from loading an odb with a marker it can't understand.

@osamahammad21
Copy link
Member Author

After approving I realized you need to rev the db schema to prevent an old version from loading an odb with a marker it can't understand.

How would this change affect backward compatibility?

Signed-off-by: Osama <osama21@aucegypt.edu>
@github-actions
Copy link
Contributor

clang-tidy review says "All clean, LGTM! 👍"

@osamahammad21
Copy link
Member Author

@maliberty _dbMarker::ShapeType is serialized as a full int (same numeric values 0–3 for existing shapes). Old dbs only ever contain 0–3; the changed dbIStream still handles those and adds 4 (kCuboid). No format or size change, so no backward compatibility needed.

@maliberty
Copy link
Member

Not so much backward compatibility but as catching

  • run new version of OR and write a db with a cuboid marker
  • Use old version and load the above db. Get confused when seeing the cuboid marker.

A schema rev should give an error on the second step.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants