wafer.space Community

@Leo Moser (mole99) Hi mole99, may I ask a further question? Can I ask why only this much metal is filled here? It seems the density requirement is still not met. Is this normal? Thank you very much!

The filler generation script was made to fill an entire chip, so it adheres to rules such as leaving a 26um spacing from the edges to meet the 10um distance to the sealring etc. I assume this is what leads to what we see here.

I see, thanks! I think this works. We do this because we will integrate this module to our analog module.

1

Oh I see, actually we don't need fill the digital module at this stage, like we can fill all during the top level?

Buck

Oh I see, actually we don't need fill the digital module at this stage, like we can fill all during the top level?

Yes, that is the usual approach. The fill for the entire chip is added at the end. If you do an analog top-level integration you can add the fill manually:

klayout -b -zz -r ${PDK_ROOT}/${PDK}/libs.tech/klayout/tech/drc/filler_generation/fill_all.rb -rd input=chip_top.gds -rd output=chip_top_filled.gds

Leo Moser (mole99)

Yes, that is the usual approach. The fill for the entire chip is added at the end. If you do an analog top-level integration you can add the fill manually:

klayout -b -zz -r ${PDK_ROOT}/${PDK}/libs.tech/klayout/tech/drc/filler_generation/fill_all.rb -rd input=chip_top.gds -rd output=chip_top_filled.gds

Hi Leo, thank you! If we want to do top-level integration, may I ask how to obtain a clean pad ring without any logic cells? My current idea is to follow the template, remove everything in the Verilog except VDD/VSS and the pad instances, and remove the metal fill step in the flow, and then rerun the synthesis and PnR flow. Is this the correct approach?

Buck

Hi Leo, thank you! If we want to do top-level integration, may I ask how to obtain a clean pad ring without any logic cells? My current idea is to follow the template, remove everything in the Verilog except VDD/VSS and the pad instances, and remove the metal fill step in the flow, and then rerun the synthesis and PnR flow. Is this the correct approach?

There is an easier approach :) You customize the flow to only generate the padring + sealring and then streamout the GDS. I already did this for the MOSbius group: https://github.com/wafer-space/gf180mcu-project-template/pull/29

Leo Moser (mole99)

There is an easier approach :) You customize the flow to only generate the padring + sealring and then streamout the GDS. I already did this for the MOSbius group: https://github.com/wafer-space/gf180mcu-project-template/pull/29

Thank you, this is very helpful! So with this, can we still configure our IO plan? Like, by changing the pad instances in Verilog and the IO placement inside the config.yaml.

Yes, it still uses the LibreLane configuration. It simply rearranges the flow slightly.

15:30

There were XOR errors between magic and KLayout (?) but I haven't had the time to look into it. Maybe you could see what the difference between the two layouts is.

Leo Moser (mole99)

Yes, it still uses the LibreLane configuration. It simply rearranges the flow slightly.

Thank you, this is helpful!

1

Leo Moser (mole99)

There were XOR errors between magic and KLayout (?) but I haven't had the time to look into it. Maybe you could see what the difference between the two layouts is.

I will try to do that. But to be honest, we are trying to catch up with the DDL now.

See what we can help. Really thank you, Leo!

Yes, just make sure to use the correct layout then if there is a difference between magic and KLayout

No worries! Looking forward to your design.

Leo Moser (mole99)

There were XOR errors between magic and KLayout (?) but I haven't had the time to look into it. Maybe you could see what the difference between the two layouts is.

I also encountered this when generating the empty pad frame today. Now I am looking into the differences between the two layouts

In my case, klayout gds is correct because I found that the only mismatch is that the magic gds has these extract tieh and tiel cells at the origin and I don't know why

Right, that's the difference! It seems that magic exports the instances even if they were not placed. There are some constants that are used in chip_top, but we stream out the padring before any of those stdcells can be placed and routed. So the KLayout version is the correct one to use.

Leo Moser (mole99)

Yes, that is the usual approach. The fill for the entire chip is added at the end. If you do an analog top-level integration you can add the fill manually:

klayout -b -zz -r ${PDK_ROOT}/${PDK}/libs.tech/klayout/tech/drc/filler_generation/fill_all.rb -rd input=chip_top.gds -rd output=chip_top_filled.gds

Hi Leo, may I ask a question? We are doing analog top-level integration now, so after we connect our design to the pad ring, is this the last step before DRC and LVS? Or any other step we should run? Thank you!

Buck

Hi Leo, may I ask a question? We are doing analog top-level integration now, so after we connect our design to the pad ring, is this the last step before DRC and LVS? Or any other step we should run? Thank you!

Hi Buck, sure thing. You should also generate the fill before doing DRC and LVS, but other than that, that should be it.

1

Leo Moser (mole99)

Hi Buck, sure thing. You should also generate the fill before doing DRC and LVS, but other than that, that should be it.

Thanks!

@Leo Moser (mole99) Hi Leo, sorry to bother you again, after we do the top level analog style integration and do the fill step, is there any script or command that we can use to tun the drc check in librelane environment? Before we used chipathon environment. Thanks!

If you run the pre-check, it will run DRC.

As Sylvain said, you can run the precheck. This can be done either through the online platform (https://platform.wafer.space/) or locally (https://github.com/wafer-space/gf180mcu-precheck). Alternatively, you can run the DRC deck directly: https://github.com/wafer-space/gf180mcu/blob/main/gf180mcuD/libs.tech/klayout/tech/drc/gf180mcu.drc

Thanks!