03:46 <sf-slack> <timo.callahan> I seem to have a workaround to the above issue. But it's still puzzling. The expression is fine; I confirm it's being used in other designs and works correctly. Somehow in the context of my new design, lxml.etree.xpath doesn't like it. But I have an alternate way of finding the XML nodes that seems to work.

07:28 <sf-slack> <timo.callahan> My theory is that there are too many matches to the xpath query. My workaround is to break up the search by subtree.

07:39 <sf-slack> <mkurc> @timo.callahan Me and @rwinkler encountered that problem some time ago. It looks like a bug / shortcoming in the libxml XPath module. When an XML file is big enough it runs out of memory (somehow). It that the Python wrapper interprets this error incorrectly and throws the exception that you see.

07:43 <sf-slack> <mkurc> https://github.com/SymbiFlow/symbiflow-arch-defs/issues/1442#issuecomment-619055675

07:43 <tpb> Title: OpenTitan support · Issue #1442 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

08:02 <sf-slack> <timo.callahan> Thanks @mkurc, that is what it was looking like to me. I solved it by changing code like this: ```for block in net_root.xpath( "//block[@instance='inpad[0]'] | //block[@instance='outpad[0]']" ):```

08:03 <sf-slack> <timo.callahan> to code like this: ``` for tblock in net_root.xpath("./block"): for ublock in tblock.xpath("./block"): for block in ublock.xpath(".//block[@instance='outpad[0]'] | .//block[@instance='inpad[0]']"):```

08:04 <sf-slack> <timo.callahan> so that the big "//block" queries are limited to a subtree. Just one level of break-up wasn't sufficient, so I had to break it up going down a couple of levels.

08:15 <sf-slack> <timo.callahan> And yes, the misleading error message caused me to look in the wrong direction for quite a while...

08:19 <sf-slack> <timo.callahan> Ah, I see you have a different workaround suggested in the comment above. Perhaps that approach is more direct and easier to understand.

08:20 <sf-slack> <timo.callahan> I encountered an analogous issue in vpr_place_constraints.py at the line: ```for attr in net_root.xpath("//attribute[@name='LOC']"):```

08:41 <sf-slack> <mkurc> Mhm, that makes sense. BTW how big is the .net file? The one for OpenTitan, when I've encountered the error, was roughly above 350MB.

08:43 <sf-slack> <mkurc> Another approach would be to completely get rid of XPath and just loop over "block" tags in Python selecting ones with the correct instance name pattern.

15:09 <sf-slack> <timo.callahan> My top.net is only 208M.

15:17 <sf-slack> <timo.callahan> Yeah, getting rid of xPath is probably the safest. With my workaround anyway using xpath on subtrees, I can't guarantee we won't encounter the same issue at some point down the road if one of the subtrees is very large. Do we already have code for traversing XML?

22:41 <mithro> @timo.callahan / andrewb1999: I pushed the non-SDF changes to prjxray-db

22:42 <mithro> @timo.callahan / andrewb1999: https://github.com/SymbiFlow/prjxray-db/compare/master...mithro:master

22:42 <tpb> Title: Comparing SymbiFlow:master...mithro:master · SymbiFlow/prjxray-db · GitHub (at github.com)

22:43 <mithro> I'm mostly concerned with the changes in the slicel.sdf file -> https://github.com/SymbiFlow/prjxray-db/compare/master...mithro:master#diff-2a8202e62b71dfabf852dbb3d26a80d5

22:43 <tpb> Title: Comparing SymbiFlow:master...mithro:master · SymbiFlow/prjxray-db · GitHub (at github.com)