Result browser gives error message

[tband]

klayout klayout_debug.gds -m klayout_debug.out
Warning: Obviously reaching end of shapes list before the specified number of shapes was read - parsing next category. (line=578)
ERROR: Expected an unsigned long integer value here: -4000 -242 .. (line=579)

This is a results database from Calibre nmDRC so could it be that the syntax has changed? I've created a small testcase that reproduces the issue. I did limit the rdb to only two results. When I delete the second one, klayout opens normally.

klayout_rdb_issue.tar.gz

[klayoutmatthias]

Thanks at lot for the test case. I'll take at look at this problem.

[tband]

Let me know if you need more examples. I have a rdb now for which I saved all check results one by one. Some checks fail to load while others just load fine. Can't seem to find what the difference is between the failing and correctly loading ones.
I now use calibredrv as a workaround, but prefer klayout :-)

[klayoutmatthias]

@tband I found some time to look into this issue.

Basically I think that there is something wrong with the DB file.

My understanding of the format is this:

XP3004 1000                           # Header + 1/DBU
4XV5.SZ1                              # Check name (Category)
112 112 4 Mar 11 12:19:02 2021        # Number of markers (112), ?, Lines of comment (4), timestamp
4XV5.SZ1 {@ stripped                  # Comment (here: 4 lines) 
    E = NOT A
    E
}
p 1 4                                 # polygon #1 with 4 points
CN XP3004 c 1 0 0 1 0 0 0             # cell name "property"
-100580 -100580                       # points in DBU units
-100180 -100580
-100180 -100180
-100580 -100180
...

But when I look at line 569++, I see this:

IND.WLX
15 15 7 Mar 11 12:19:59 2021                   # 7 lines of comment???
IND.WLX {@ stripped
    E = NOT A
    E
}
p 1 70
CN match_balun_2t1t1t3t c 0 1 -1 0 314295 42060 1
-6895 -14240
-4000 -14240
-4000 -24230
...

Which is somewhat inconsistent. There are 4 lines of comment. That's why the reader reads 7 lines and comes out at the wrong place.

What tool is generating this file? Maybe there is something wrong there?

Kind regards,

Matthias

[tband]

Hi Matthias I did edit the file to remove sensitive information like design rules. I was not aware that the lines where actually counted. The file comes from Calibre. I think the issue is that the rule contains // delimited comment: [image: image.png] This screenshot is not complete because we have an NDA with the foundry of course. If I remove the // only, then the check loads. Cheers, Theo Op ma 22 mrt. 2021 om 18:19 schreef Matthias Köfferlein < ***@***.***>:

…

@tband <https://github.com/tband> I found some time to look into this issue. Basically I think that there is something wrong with the DB file. My understanding of the format is this: XP3004 1000 # Header + 1/DBU 4XV5.SZ1 # Check name (Category) 112 112 4 Mar 11 12:19:02 2021 # Number of markers (112), ?, Lines of comment (4), timestamp 4XV5.SZ1 {@ stripped # Comment (here: 4 lines) E = NOT A E } p 1 4 # polygon #1 with 4 points CN XP3004 c 1 0 0 1 0 0 0 # cell name "property" -100580 -100580 # points in DBU units -100180 -100580 -100180 -100180 -100580 -100180 ... But when I look at line 569++, I see this: IND.WLX 15 15 7 Mar 11 12:19:59 2021 # 7 lines of comment??? IND.WLX {@ stripped E = NOT A E } p 1 70 CN match_balun_2t1t1t3t c 0 1 -1 0 314295 42060 1 -6895 -14240 -4000 -14240 -4000 -24230 ... Which is somewhat inconsistent. There are 4 lines of comment. That's why the reader reads 7 lines and comes out at the wrong place. What tool is generating this file? Maybe there is something wrong there? Kind regards, Matthias — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#747 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATF4UUEGTFP2QIGBAKWPOTTTE53ZTANCNFSM4ZAHXTVA> .

[klayoutmatthias]

I don't see the image :(

[tband]

I replied to the mail. Apparently the images gets scrubbed.

[klayoutmatthias]

Hi,

Lines starting with // should alread be skipped automatically (#522). This went into 0.26.6. So you mean you just delete the two lines starting with // and everything works?

That's basically what the reader does by itself. Are you using a version later than 0.26.6?

Thanks,

Matthias

[tband]

Hi Matthias I use version 0.26.8. It only works if I leave the lines, but remove the "//" at the beginning. So it's not considered comment anymore. Thanks, Theo Op zo 18 apr. 2021 om 12:49 schreef Matthias Köfferlein < ***@***.***>:

…

Hi, Lines starting with // should alread be skipped automatically (#522 <#522>). This went into 0.26.6. So you mean you just delete the two lines starting with // and everything works? That's basically what the reader does by itself. Are you using a version later than 0.26.6? Thanks, Matthias — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#747 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATF4UUGFKJTTY3NJMQSB5HLTJK2MDANCNFSM4ZAHXTVA> .

[klayoutmatthias]

I see, thanks for the information.

This basically means that the fix of #522 is not applicable. Originally, the problem was a Tanner specific one. So maybe Tanner has a different opinion about how to read RVE files. Or rather the dropping of comment lines should not happen inside the description text.