feature: Adding support for explict pin placement

[KelvinChung2000]

Self checks

• I have searched existing issues, including closed issues.
• I have read the documentation and development guide.
• This is a feature request, not a bug report or usage question.
• I have described the workflow need before proposing a solution.

Affected area

Flow/runtime

Problem or workflow need

I am working on an hieratical design and for that to work we will need to be able to place IO pin explictly.

Proposed solution

It will nice to have something that similar to macro placement text file and this should do the job

Alternatives considered

No response

Examples, command sketches, or references

No response

Are you willing to contribute this feature?

Yes, but I need design or implementation guidance.

Additional context

No response

[Emin017]

Hi, could you explain your requirements in more detail? ECC already has the automatic IO pin placement feature.

ecc/chipcompiler/tools/ecc/runner.py

Line 761 in efcd90f

sub_flow.update_step(step_name=EccSubFlowEnum.place_io_pins.value, state=StateEnum.Success)

Do you want to specify the positions yourself for placing the IOs, or do you have other requirements?

[ZhishengZeng]

@KelvinChung2000 Currently, IO pins are placed automatically, and we plan to further optimize their placement based on the floorplan in future iterations.

Could you share the main motivation for requiring explicit IO pin placement? If there is a concrete need, we can consider adding a script-based interface to place IO pins individually.

[KelvinChung2000]

Placing an IO in an explicit but suboptimal location is sometimes desired. For example, you might want all the clock ports starting from the left so you can clock multiple macros individually, or you might want the data-in pin along one edge and the data-out pin along the other.

For our main use case is as follows:

To do the stitching as above, I will need to explicitly define the locations of all the pins for this to work.

[KelvinChung2000]

For the above implementation, I think the tool flow still has a few things missing, such as the PDN strip. Also, can the tool correctly tell when two macro pins are touching and are considered connected by the tooling? Since this is something we need to upstream when we did this in OpenRoad.

[ZhishengZeng]

I don't understand what PDN means. PDN does not extend beyond the core area and does not reach the I/O pins on the die edge.

[ZhishengZeng]

The PDN can now correctly connect to the power pins of the macro.

[KelvinChung2000]

The above example is just a 2x2. We might want to do it to 10x10. Then the middle tile will not have an accessible power pin unless we route it into the macro. The idea is that we assemble all the small tile macros and build a larger macro.

[ZhishengZeng]

That sounds quite interesting. So does that mean PDN also needs to be precisely controlled to ensure smooth stitching?

[KelvinChung2000]

Yes. We need full control over the physical interface that connects to and from the macro to ensure smooth stitching.

This also raises issues about how the sign-off LVS and DRC will handle things like this. Because when stitching, the compiled tile itself might not have any DRC/antenna errors, but when stitched together, those errors might reappear. This reminds me of one thing: we also want a preventive diode/buffer at the ports to prevent issues like this. Ideally, automatically inserted.

[ZhishengZeng]

This is indeed an interesting issue, but it would introduce a large number of modifications. Currently, our development is primarily based on a single‑chip architecture. As for the compact stitching approach you mentioned, we are unable to support it at this time; however, we may consider it in the future.

[KelvinChung2000]

At what layer/EDA/tool is this not supported right now? Since it depends on what is limited, we can adjust the implementation method. Explicit pin placement is a highly desirable feature in general.

[ZhishengZeng]

If it is only a matter of I/O placement, there is no issue – we will introduce this feature in the near future. However, supporting stitching with respect to PDN and even antenna effect analysis will likely be difficult, as this differs considerably from the traditional single‑chip design methodology.

[KelvinChung2000]

We will see what the minimal workaround would be

[KelvinChung2000]

What about something similar to ODB that lets the user edit the geometry directly?