caravel_openframe_project physical implementation

[mo-hosni]

Physical implementation of caravel_openframe_project is done in this PR.

3 major things yet to be done:

1. Standalone physical verification
2. SDC files Review (can be found at openlane/*/*.sdc)
3. Standalone STA

[RTimothyEdwards]

@mo-hosni : What is in this pull request? It appears as "infinite" files changed, and I cannot view the diffs.
The only thing I want to be merged into the main branch is changes to the underlying source code and configuration files for openlane. Anything generated by openlane and final results should remain in a branch.

[RTimothyEdwards]

@mo-hosni : What you are making a pull request for is not an example project. It is a fully completed project ready for submission for manufacture. What I want for a pull request is the minimum number of files needed to generate the entire finished layout, and instructions on how to run openlane to obtain the finished layout.

[RTimothyEdwards]

Otherwise, the finished layout in your fork appears to be good. But there are a lot of unneeded files lying around, many in places they should not be.

Can you tell me what is the minimum set of source files I need to reproduce the final layout?

[RTimothyEdwards]

@mo-hosni : You have removed power pins from the openframe wrapper definition. You can't do that. How to preserve them?

[mo-hosni]

or a pull request is the minimum number of files needed to generate the entire finished layout, and instructions on how to run openlane to obtain the finished layout.

Okay, I agree. We can use this PR to review the implementation and I will make another one with the openlane files to be merged.

@mo-hosni : What you are making a pull request for is not an example project. It is a fully completed project ready for submission for manufacture. What I want for a pull request is the minimum number of files needed to generate the entire finished layout, and instructions on how to run openlane to obtain the finished layout.

Yes, this is will be ready for submission after review. Aren't we going to tapeout the example?

Otherwise, the finished layout in your fork appears to be good. But there are a lot of unneeded files lying around, many in places they should not be.

Can you tell me what is the minimum set of source files I need to reproduce the final layout?

The minimum source files for reproduction are the openlane folder files and the 2 manual macros views which are vssd1_connection and vccd1_connection. I used openlane version 01e67230f35aa4cd08ef33a9f8df8a83f578b710 for all the macros. You will need to rerun digital_locked_loop, then picosoc, then openframe_project_wrapper.

clock_routing is not used in this implementation as a macro (it is flattened) so its openlane folder can be deleted.

@mo-hosni : You have removed power pins from the openframe wrapper definition. You can't do that. How to preserve them?

The thing is, if we have all 6 power domains in the RTL we will have to place pins for each one and hence there will be lots of manual connections, unused pins, and unused power rings/grids. This is no only an large overhead on the users but also a disadvantage of the layout as it takes from the routing resources, complicates the PDN, and might introduce LVS issues.
So, our idea is that the users will only add in the RTL the power domains that they are actually using, then they update user_defines binary variables which determines what power domains they are using and what they are not. Then, we add an ifdef in caravel_openframe.v RTL which connects only the used domains by the users. This is an initial PR: https://github.com/efabless/caravel/pull/486/files.

[RTimothyEdwards]

@mo-hosni : You should not create power rings/grids for any power domain that is not used, but you still need to keep the pins so that we can run an XOR at the boundary of the openframe wrapper to ensure that all connections have been made. I was originally advocating for an "interposer" layout which would connect between the routed design with the minimum number of rings/grids needed, and the power pins, with different interposers for common configurations. For example, a very common configuration would be to tie all three 1.8V domains (VCCD, VCCD1, VCCD2) to a single ring/grid in the project, which maximizes the amount of current that can be delivered to the project.

[RTimothyEdwards]

(By "ensure that all connections have been made", I mean "ensure that all mandatory connections have been made"; and of course the XOR is to ensure that the wrapper layout does not extend beyond the wrapper boundary so that it does not collide with the padframe.)

[mo-hosni]

@RTimothyEdwards: I agree that the ideal layout should have all power pins. And grids only to the utilized power domains. That's for sure. The issue is in the tools limits.

The power pins are not read from the template def. So, in order to have any power pins using OpenLane we have 2 approaches as far as I know.

1. Using PDNgen, by default it will add rings/grids to each power domain. To prevent that, a tcl script should be written and the flow will be a bit different than usual.

2. Put the pins manually on the layout after hardening.

In approach 1, the pins/labels will be on the rings and that's why I made a manual macro that connects the ring to the padframe. Approach 2 is easier and can produce the layout we want but I don't think we can ask the users to do that.

So, if this is necessary

You should not create power rings/grids for any power domain that is not used, but you still need to keep the pins

We need to think of a new approach and it will probably be a hacky one.

[mo-hosni]

@RTimothyEdwards: I guess the hacky solution would be similar to what we have in caravel:
Rings to all power domains and the connections can be made on the caravel_openframe level. The grids could be done only for the utilized power domains but the rings will be there for XOR and to prevent manual layout edits.
However, if we assume the power ring would be 20um wide with 2.4um spacing. We would waste more than 25% of the user_project area.

[RTimothyEdwards]

@mo-hosni : That would be similar to what I suggested as an "interposer"---For a fixed set of power rings of a fixed size, you can create a subcell that connects them to the power supply or supplies. I do not see how that wastes 25% of the user area, however. How do you come to that result? And if you create a DEF file out of the power connections, can't you apply that to the place & route and have the place & route take up all available space except for the power connections?

[mo-hosni]

How do you come to that result?

The current user_project area is 3.1666mm * 4.7666mm which is ~15.09mm^2
If the ring width is 20um with spacing 2.4um, and we have 12 rings for the 6 power domains, we waste 22.4um * 12 * 2 in each dimension which is 0.5376mm.
So, the new area is 2.629mm * 4.229mm which is ~11.11mm^2 and that's 73% of the original area.

And if you create a DEF file out of the power connections, can't you apply that to the place & route and have the place & route take up all available space except for the power connections?

The power pins are not applied by the template def in PnR. The template def is only used to determine the location of the signal pins, the power ones are inserted by PDNgen which only inserts rings and stripes.

[RTimothyEdwards]

@passant5 : I noticed you made a commit where you changed the name of the wrapper. Please don't do this. Is there not a way to use the SDF with a cell of a different name? If not, then how can the analog user project wrapper for caravan work?

[mo-hosni]

@RTimothyEdwards :

I deleted the physical views from this PR so it can be merged directly, I see you already copied from my fork the source files I wrote and pushed them in the commit 87eac64
Anyway, you can find here updated openlane source files to fix a bug in openroad using OpenLane version: 01e67230f35aa4cd08ef33a9f8df8a83f578b710 that was triggered after the RTL updates
So, you still need to merge this PR to get the flow to run

Cc: @shalan

[RTimothyEdwards]

@mo-hosni : How do you obtain the .lib files for digital_locked_loop and picosoc?

[mo-hosni]

@RTimothyEdwards : Change this to 1 and rerun.

caravel_openframe_project/openlane/digital_locked_loop/config.tcl

Line 70 in 87eac64

set ::env(STA_WRITE_LIB) 0

btw, the digital_looked_loop was developed months ago so it was developed using OpenLane version 6bb1e0dd91227c6bc5ff64309d6a5fb897d4809a

[mo-hosni]

For picosoc it should be generated by default.

[RTimothyEdwards]

@mo-hosni : You're right; I didn't bother to look but yes, there was a .lib file generated for the picosoc macro. Thanks!