Altium slow and funny behaviour with polygons

[dmg]

Hi,

I'm not new to Altium, I've already done several relatively complex layouts with it and I'm fairly happy, it's a pretty efficient package. However, there's always this time when I'm about to finish routing and start reviewing the job so I pour all polygons and do a DRC and such things and almost always Altium screws things up with polygons.

It either:
-Gets slow as hell to generate and pour  them (about 2-3 minutes on a core i7)
-Doesn't abide by the pouring order and pours whatever polygon it wants first, normally screwing things up
-A combination of both

Normally this happens when I have local polygons surrounded by a large ground polygon or similar things.
I'm on Altium 14. Does anyone experience the same issues? It's an efficiency killer in the last stages of design... I usually have to pour polygons manually...

[dmg]

I always pour polygons manually, I don't even know how to automate this in a particular order, so I never experienced this.

Some times polygon pour can be slow, but I mean 1~3 secs, not minutes, on an E3 1271 v3, which is the workstation equivalent of i7 4790.

It depends on your PCB complexity, so for a ground layer, poly pour is super fast. On a dense signal layer it takes considerably longer.

My reference 1~3 sec refers to ~50*50mm PCB size with 0.15/0.15mm tracks laid out very densely.

I'm talking about 6-8 layer designs with relatively complex geometry. The problem is that all this slowness starts at some point, and I can make it much much faster by just cutting and repasting all polygons. Then, they'll pour fine 3-5 times and after that slowness and random pouring again. It's damn frustrating sometimes... thankfully it only affects me during the very final stages and in very specific points, so not so much time lost there...

[dmg]

If it worked in the exact same condition but is not working now, than it should be considered a bug.

I suggest you to email Altium for their support. Of course, this may only benefit the others, not you, since their patch are only for subscribers.

However, they might tell you how to avoid this known bug if they can find it.

I've searched and seems like I'm the only one out there with this problem (or I can't express my problem well enough for google to understand), so I'm thinking this might be my fault, maybe I'm doing something I shouldn't...

Apart from that, I've found quite some bugs in Altium, I know of about 6 ways to crash it if I want, and I've experienced funny random behaviours but they are sporadic enough not to cause any trouble, about 90% of the time things are fluent and I can work pretty well. I love many things in altium. But well, for some reason I'm a bug magnet and prone to breaking software... last time some friends launched an Android app to the wild after quite extensive testing and I learned how to crash it on demand in about 5 minutes and in less than 10 I found a convoluted bug that allowed you to spam other app uses with notifications and even crash their phones, and that without even trying...

I should get my altium updated soon and should stay up to date from there, so I'll be able to report bugs.

[DerekG]

I'm talking about 6-8 layer designs with relatively complex geometry. The problem is that all this slowness starts at some point, and I can make it much much faster by just cutting and repasting all polygons. Then, they'll pour fine 3-5 times and after that slowness and random pouring again.

You are running low on RAM. Altium allows for multiple undo/redo & it stores all of these changes in RAM.

Adjust the number of undo/redo held in memory or do a save & close Altium to flush the memory.

[dmg]

I'm talking about 6-8 layer designs with relatively complex geometry. The problem is that all this slowness starts at some point, and I can make it much much faster by just cutting and repasting all polygons. Then, they'll pour fine 3-5 times and after that slowness and random pouring again.

You are running low on RAM. Altium allows for multiple undo/redo & it stores all of these changes in RAM.

Adjust the number of undo/redo held in memory or do a save & close Altium to flush the memory.

When you think 16 GB of RAM would be enough... darn it, thank you very much.

Hopefully that also explains why at some point it stops following the pouring order and pours in whatever order it feels like, usually the worst possible one.

[free_electron]

15 and 16 have massive speed improvements on polygon pours.
Polygon order is set in the polygon manager.
If your machine is slow you have either memory or graphics problems.
shelve the polygons while working. Then unshelve. Do a flash repour using T-G-V ( make sure your design rules are set up right. way too many people write very bad design rules grinding the software to a halt.

[free_electron]

When you think 16 GB of RAM would be enough... darn it, thank you very much.

it runs fine even on a 4 Gb ram machine. It is a 32 bit application and cannot allocate more then 3Gig ( if you have the registry hack ) or 2 Gig. No matter how much ram you throw in. It is also not a multithreaded program. You are better of using a faster clocked dual core than a slower quad core. Raw GHZ is what you want. And lots of cache memory.
Graphics card performance is important. Reflooding a polygon is a graphics operation. if you sit there waiting for the pixelcruncher ....

[T3sl4co1l]

Pour order:
T, G, M (Polygon Manager).

Polygons are poured in the order you place them, first most recently.  So if the last thing you did was place a huge ground poly, say goodbye to everything else when you repour, until you sort things out there!

Polygons do take quite some time to crank on complex boards, but I don't spend even 10 seconds repouring all on a complex (600 components, 4 layer board, ~40 polys?) design.

Tim

[Psi]

15 and 16 have massive speed improvements on polygon pours.

Yeah, i noticed that.
I'm using Altium 10 at home and it takes maybe 2 seconds for one plane.
Compare that to Altium 16 at work where it takes under a second to repour all polygons at once on a small 4 layer board.

[dmg]

Pour order:
T, G, M (Polygon Manager).

Polygons are poured in the order you place them, first most recently.  So if the last thing you did was place a huge ground poly, say goodbye to everything else when you repour, until you sort things out there!

Polygons do take quite some time to crank on complex boards, but I don't spend even 10 seconds repouring all on a complex (600 components, 4 layer board, ~40 polys?) design.

Tim

My current board is 1500 components, 8 layers and about 40 polys too. When things are fresh polys get poured in less than 10 seconds. My problem is that peroformance starts degrading until it gets unusable. Then I cut all polygons, paste them with "keep net name", repour and everything is fine again.

I do use the polygon manager and set the order I want. It pours the polygons and everything's fine, they pour as they should... but when things start getting slow it also starts pouring them the way it wants. If I set some poly to pour the last it sometimes pours it first, or in whatever order it wants, messing it all. Again, cut, paste, repour, all fine.

15 and 16 have massive speed improvements on polygon pours.
Polygon order is set in the polygon manager.
If your machine is slow you have either memory or graphics problems.
shelve the polygons while working. Then unshelve. Do a flash repour using T-G-V ( make sure your design rules are set up right. way too many people write very bad design rules grinding the software to a halt.

That's how I work, all polys shelved till last stages, that's why it affects me during those stages and not during normal routing which is fine and fast, even with online DRC on and such. Do you have any tutorial on how to setup proper rules? I normally work with netclasses and diff pair classes in a superclass-subclass way (i.e. a class for 100 ohm pairs and and within that class PCIE pairs, LVDS and such) and then setup rules from general to specific.

The PC has a fairly recent dedicated nVidia graphics card (a GT 800 something) and a 4th generation core i5 (not i7 sorry). Will check specs.

[T3sl4co1l]

Yeah, sounds like a bug then.  Call 'em and see if they have anything to say about it.

Tim