MitjaNemec / ReplicateLayout

GNU General Public License v2.0
90 stars 12 forks source link

Replicated GND zones & vias getting assigned incorrectly #38

Closed myamigo closed 11 months ago

myamigo commented 1 year ago

My 8-layer design includes GND stitching via's within an area that includes multiple zones attached to various sources: GND (large zone on inner layer and smaller zones on F.Cu and an overlapping zone on the GND plane with tighter clearances under an FPGA) and 3 different local voltages (/data_path0/FPGA/1V2L, /data_path0/0V9L & /data_path0/1V8L for example). Local voltages are switched from global sources. There are 2 copies of the seed circuit at 120deg offsets around the PCB center so 3 in total.

I am finding that local F.Cu and under-FPGA GND zones are getting assigned to one of the local voltages for one of the copies, but not both. The 1st example I show here has the small GND zone on F.Cu selected so it's properties are shown in the status bar... image

This example shows the area around the FPGA's... image

The GND zones in the data_path1 are getting incorrectly reassigned.

I have also noticed that isolated GND stitching vias also get arbitrarily assigned to the local 1V8L source as well and I won't discover this unless the assignment causes a DRC error.

I propose the following solution:

Check the net assignment for the seed zone or via being replicated. If it is assigned to a global GND net, then assign the copy to the same global GND net as well. Otherwise process as per usual.

I have been able to manage the reassigned via issue by ensuring that each stitching via is connected to a GND pad via thin traces that are embedded in the GND layer plane. The global GND net is highlighted in the following image. This shows tracks from the isolated GND vias to a pad assigned to GND. Zone fill is turned off in this image. image

The same area with zones filled... image

This is a work-around to the issue but this would be unnecessary if the isolated vias were reassigned correctly.

Great plug-in!!!

myamigo commented 1 year ago

Well, I've gone a bit of a different route as I don't want to add another checkbox. I've changed how the connectivity is tested for issues and I've changed the default behavior so that even the detected cases get replicated and I leave it to the user to check the design. When you'll have so time, I'd like you to test 2.1.1

I just got around to your request. Using 2.1.3 I can confirm that replication works with my design. I get 4 warnings to check connectivity around the 4 ID pins that I mention in https://github.com/MitjaNemec/ReplicateLayout/issues/38#issuecomment-1407065032... image ... but the connections are fine and it doesn't complain about anything else. These are connections to global nets (either 1V8 or GND depending on ID value) and I believe you now handle global nets in a strict manner. In my case the connections are correct and the popup is not a concern so well done!

I tried out the new "Group layouts" feature and noted something perhaps unexpected. I added some of the silk graphics in the seed region to a named group so I could apply a custom DRC rule allowing overlap. In the replicated regions those named groups were removed so the custom rule could not identify the objects and I got multiple DRC errors. I got round this by excluding drawing elements from the grouping process. I assume that an object cannot exist in more than one group so doing what I did is probably the right way to handle this. Agree?

I'm really happy with migration to KC 7.0 and your plugin got me there.

Thanks for the support!

MitjaNemec commented 11 months ago

In my case the connections are correct and the popup is not a concern so well done!

Thanks for persisting. Can we close this issue now?

I tried out the new "Group layouts" feature and noted something perhaps unexpected. I added some of the silk graphics in the seed region to a named group so I could apply a custom DRC rule allowing overlap. In the replicated regions those named groups were removed so the custom rule could not identify the objects and I got multiple DRC errors. I got round this by excluding drawing elements from the grouping process. I assume that an object cannot exist in more than one group so doing what I did is probably the right way to handle this. Agree?

Yeah the grouping feature has just been introduced and there are still some issues to fix/features to add. Firstly as item can be only members of one group, the plugin should/will check if this is the case.

In any case please open a new issue for different/new issues as it helps me track issues better

myamigo commented 11 months ago

All good with this one to close and understood re new issues. Thanks!