Friday, 2020-05-29

*** tpb has joined #symbiflow00:00
*** gsmecher has quit IRC00:30
*** citypw has joined #symbiflow02:22
*** Degi has quit IRC02:56
*** Degi has joined #symbiflow02:57
*** andrewb1999 has joined #symbiflow03:28
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.03:46
*** Bertl is now known as Bertl_zZ03:48
*** citypw has quit IRC04:12
*** az0re has joined #symbiflow04:21
*** _whitelogger has quit IRC04:48
*** _whitelogger has joined #symbiflow04:50
*** _whitelogger has quit IRC05:18
*** _whitelogger has joined #symbiflow05:20
*** citypw has joined #symbiflow05:50
*** kgugala__ has joined #symbiflow06:08
*** kgugala_ has quit IRC06:10
*** andrewb1999 has quit IRC06:29
*** Bill86 has joined #symbiflow06:55
*** OmniMancer1 has joined #symbiflow06:56
*** OmniMancer has quit IRC06:58
*** OmniMancer1 has quit IRC07:17
*** OmniMancer has joined #symbiflow07:19
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:28
*** yeti has quit IRC07:34
*** yeti has joined #symbiflow07:37
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:39
sf-slack<mkurc> https://github.com/SymbiFlow/symbiflow-arch-defs/issues/1442#issuecomment-61905567507:43
tpbTitle: OpenTitan support · Issue #1442 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)07:43
*** lopsided98 has quit IRC07:43
*** lopsided98 has joined #symbiflow07:45
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:02
*** kgugala__ has quit IRC08:02
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:03
*** kgugala has joined #symbiflow08:03
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:04
sf-slack<timo.callahan> And yes, the misleading error message caused me to look in the wrong direction for quite a while...08:15
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:19
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:20
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:41
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.08:43
*** Bill86 has quit IRC10:15
*** madushan1000[m] has quit IRC10:29
*** hzeller[m] has quit IRC10:30
*** Bertl_zZ is now known as Bertl11:09
*** andrewb1999 has joined #symbiflow13:45
sf-slack<timo.callahan> My top.net is only 208M.15:09
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?15:17
*** gsmecher has joined #symbiflow16:01
*** shadtorrie has joined #symbiflow16:26
*** citypw has quit IRC16:32
*** shadtorrie has quit IRC16:33
*** OmniMancer has quit IRC17:58
*** OmniMancer has joined #symbiflow17:59
*** andrewb1999 has quit IRC18:31
*** kgugala_ has joined #symbiflow19:02
*** kgugala has quit IRC19:04
*** kgugala_ has quit IRC19:10
*** kgugala has joined #symbiflow19:11
*** kgugala_ has joined #symbiflow19:12
*** kgugala has quit IRC19:16
*** lopsided98 has quit IRC19:58
*** lopsided98 has joined #symbiflow20:00
*** kgugala has joined #symbiflow20:01
*** kgugala_ has quit IRC20:05
*** kgugala_ has joined #symbiflow20:06
*** kgugala has quit IRC20:08
*** kgugala has joined #symbiflow20:19
*** kgugala_ has quit IRC20:22
*** QDX45 has quit IRC20:29
*** kgugala_ has joined #symbiflow20:41
*** kgugala_ has quit IRC20:43
*** kgugala_ has joined #symbiflow20:44
*** kgugala has quit IRC20:44
*** miek has quit IRC20:52
*** andrewb1999 has joined #symbiflow21:02
mithro@timo.callahan / andrewb1999: I pushed the non-SDF changes to prjxray-db22:41
*** andrewb1999 has quit IRC22:41
mithro@timo.callahan / andrewb1999: https://github.com/SymbiFlow/prjxray-db/compare/master...mithro:master22:42
tpbTitle: Comparing SymbiFlow:master...mithro:master · SymbiFlow/prjxray-db · GitHub (at github.com)22:42
mithroI'm mostly concerned with the changes in the slicel.sdf file -> https://github.com/SymbiFlow/prjxray-db/compare/master...mithro:master#diff-2a8202e62b71dfabf852dbb3d26a80d522:43
tpbTitle: Comparing SymbiFlow:master...mithro:master · SymbiFlow/prjxray-db · GitHub (at github.com)22:43
*** somlo has quit IRC23:39
*** somlo has joined #symbiflow23:43

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!