Strict mode oasis

Masaki

Hi Matthias,

1) I'm trying to make a strict mode oasis.

I found something wrong with table-offsets structure
textstring-offset,
propstring-offset,
layername-offset
indicates same value.
I believe offsets should be different values.

2) Also, I could not find the way to set "per-cell bounding boxes" enable flag from python script. I found corresponding dropdown list in Layout writer option dialog.

for strict mode,
opt= pya.SaveLayoutOptions()
opt.oasis_strict_mode=Trule
works well. I believe there is a similar way.

Thank you for your efforts to develop this wonderful software.
Masaki

Matthias

Hi Masaki,

thank you :-)

Regarding the OASIS topics:

1.) This can happen if the tables are empty. In that case, the start position of the table and the start position of the next table are identical since the table does not contain any records.

It's true, such a table can be written as "not present" (position 0), but from the spec I don't see that this is mandatory.

My reasoning was the following: since there is no "end of table" flag, any reader is required to check the record types to detect the end of the table. So if the reader just stops immediately when there is no matching record, everything is fine. That's the special case of an empty table.

2.) The Ruby equivalent to the Python code is simply

opt = RBA::SaveLayoutOptions::new
opt.oasis_strict_mode = true

The attribute getter is

opt.oasis_strict_mode?

which is common Ruby naming style.

Regards,

Matthias

Masaki

Hi, Matthias,

Thank you for your response.

1) Thank you for your suggestion. Your reading strategy might work.

2) My questions was to crate per-cell bounding box.

opt.oasis_write_std_properties=2

seems a proper syntax but it seems bool(True/False) type of python.

Thank you.
Masaki.

Matthias

Hi Masaki,

yes, "oasis_write_std_properties" is a boolean property, so

opt = pya.SaveLayoutOptions()
opt.oasis_write_std_properties = True

should work.

Doesn't it?

Matthias

Masaki

Hi, Matthias,

opt.oasis._write_std_properties =True
makes oasis include global standard properties.
but the oasis does not include per-cell bounding boxes.

I found a comment on dbOASISWriter.h
"if 2, bounding box standard properties are written for evey cell too."

Thank you.
Masaki.

Matthias

Oh yes, I see.

That's inconsistent. The property should be integer, not bool. I'll fix that in the next minor release.

Thanks for mentioning this,

Matthias

Masaki

Hi, Matthias,

Thank you for your note on the bug list about the flag.

I have another issue. I made a strict mode oasis with per-cell bounding box.
(oasis_write_std_properties were set by GUI)

But created oasis seems that the box properties are placed after CELL record.
I think the properties should be placed after CELLNAME records.

I do not have enough skill to read source code, so my observation might be wrong.
I would like you to confirm the order of the records.

Thank you.
Masaki.

Matthias

Hi Masaki,

you're right. The spec says the S_BOUNDING_BOX records need to appear in the cell table, not in the cell itself.

I'll fix that in the next minor release.

Thanks for bringing this up.

Best regards,

Matthias

Masaki

Hi, Matthias,

Thank you for your effort to make a release of 24.3.
I checked the created file which has S_BOUNDIG_BOX.

Order of the records seems fine, but I found another issue.

According to the specification of the S_CELL_OFFSET, it must be an unsigned integer (TYPE 8), but created oasis has b-string (TYPE11) for the value.

Best Regards,
Masaki

Matthias

Hi Masaki,

I am sorry, but can't confirm that.

Here is a sample for a table written by KLayout:

000000013   01                       START
000000014   03 31 2e 30              version ("1.0")
000000018   00 e8 07                 resolution (1000)
000000021   01                       table flag (at end)
# S_CELL_OFFSET is property ID #0:
000000022   07 0d 53 5f 43 45 4c 4c  PROPNAME ("S_CELL_OFFSET")
000000030 + 5f 4f 46 46 53 45 54  
....
000000334   03 01 41                 CELLNAME ("A")
000000337   1c 17 00                 PROPERTY (id=0)         # S_CELL_OFFSET
000000340   08 b9 01                 value[0]=185 (type 8)
000000343   03 03 54 4f 50           CELLNAME ("TOP")
000000348   1c 11                    PROPERTY (same id)      # S_CELL_OFFSET
000000350   08 c6 01                 value[0]=198 (type 8)
000000353   02                       END

This says that the value of the S_CELL_OFFSET property is of type 8.

Matthias

Masaki

Hi, Matthias,

Thank you for the confirmation.
I tested CELLNAME "TOP" as same as you.

I found that my Linux binary creates type 8 of the value for S_CELL_OFFSET.

03 03 54 4f 50 1c 17 00 08

But, my windows7(64) binary creates type 11 as the value.
I was afraid my compilation makes a mess of the program, so I also checked by zip archived binary provided by http://www.klayout.de/build.html, it made type 11.

03 03 54 4f 50 1c 17 00 0b

Best Regards,
Masaki

Matthias

Hi Masaki,

you're right ... that happens on Windows 64 bit only. On Linux, 32 and 64bit behave correctly.

I assume it's something with the way the VC++ handles the different data types. I'll try to fix that for 0.24.4.

Thanks and best regards,

Matthias

Masaki

Hi Matthias,

Thank you for your confirmation.

I found another issue about file level property.
File level property should be placed immediately after start record (spec 31.8).
But, for the file generating by klayout, file level property seems placed after propertyname records. Propertyname record is one of <name> record, so the property is not associated to entire file but be associated to propertyname record which just previously placed.

In previous reply, you showed a structured dump codes, (hexadecimal table and comment). Does klayout have such function to make such code? My only weapon is od and it is very difficult to see the output....

Best Regards,
Masaki.

Matthias

Hi Masaki,

I'm starting to get suspicious .. what exactly are you doing? So far nobody looked that deeply into the OASIS writer implementation :-)

Well, never mind .. it's good you do this kind of review! I appreciate that!

I shall help you by pointing you to this tool: http://www.klayout.de/dump_oasis.html. The source code is free (GPL) and this is the tool I was using to create the dumps. It's not perfect, but will serve the debugging purpose.

Regarding your issue you are referring to this sentence:

31.8 In general, PROPERTY records directly follow the record with which they are associated. PROPERTY records occurring directly after the START record are associated globally with the entire OASIS file.

I have not understood "directly" as "immediately". This would not make much sense since in that case you can't use property name ID's. Also version, resolution and table flags have to come before the first PROPERTY record in my understanding.

I understood "directly after the START" as "before any CELL or CELLNAME record". That made more sense to me, because in general PROPERTY records a attached to the object before them. So if there is nothing (you can attach a property to) before them, a PROPERTY will be a file level property. There simply is no other choice.

But I may be wrong. Any third opinion regarding that topic?

Best regards,

Matthias

Masaki

Hi, Matthias,

I’m working for a company making lithography tool. I just want to make oasis files, which have good compatibility with other tools include my system.

Thank you for providing the pointer to the dump tool. I will try to use it. It will surely help me.

Regarding my issue, I also had a same understanding as you, but, I found other proprietary oasis viewers does not recognize file level property made by Klayout. (Yes, I doubted the proprietary viewer first! that was why I could not make a feedback for initial 0.24 release)

I was going back to the Sepc. of oasis, and found that 31.1, 31.8, 36.2 are the clue.

According to Spec 31.1, a property may be associated with (1) entire oasis file, (2) <name> record, (3)a CELL, (4)a Placement, or (5) an <element> within a cell.

On the other hand, according to the BNF syntax in spec 36.2,
<name> -> {　CELLNAME　|　TEXTSTRING　|　LEYERNAME　|　PROPNAME　|　PROPSTRINIG　|　XNAME　}

My understanding of “directly after the START record” is “before any of (2)-(5)“.
In my case, since PROPNAME is one of <name>, then the PROPERTY record after PROPNAME table is associated to the last record of PROPNAME.

Thanks a lot again.
Best Regards,
Masaki

Matthias

Hi Masaki,

thanks for your analysis.

Formally you're right. Although I think the BNF does not forbid using PROPERTY records after PROPNAME.

But if I take 31.1 seriously then PROPERTY after PROPNAME means that the PROPERTY is associated with PROPNAME .. that does not make any sense to me.

I'll check with some other readers - maybe we can come to a vote on the right solution.

Best regards,

Matthias

Matthias

Hi Masaki,

I had some short nights over this topic. But I think you're right and I have achieved some consolidated state now.

The current implementation (going into 0.24.4) will feature

• File level PROPERTY records are put before every other records, specifically records. That was a hard thing to do since this way, backward references to property names and strings are essentially impossible.
• A modified OASIS writer, so that empty tables are listed with a position 0

While doing that I found some more issues with strict mode, namely:

• In strict mode, all references needs to be through ID, not strings. This was not the case for property value strings.
• Modal variables are reset after records also, not just at the beginning of a CELL. The writer needs to take this into account.

I spend some time to implement some self-diagnosis features so I can cross check my writer implementation against my reader. I was told already that this is going to be a little self-consistent, but I had some beers between the reader and writer implementation. I hope my brain resets and won't remember one implementation when doing the other :-)

The changes are not really trivial but I'd like to release them with 0.24.4 nevertheless. I'm confident this will improve strict mode compatibility considerably. My summary is that strict mode and user properties don't go together well in OASIS. Maybe the OASIS spec responsibles read this and draw their conclusions.

Thanks for bringing these topics up.

Matthias

Masaki

Hi, Matthias,

Thank you so much for your efforts to improve file compatibility!
I'm look forward to next release.
Again, thank you for your realy sincere response.

Best Regards,
Masaki

Masaki

Hi, Matthias,

Thank you for your efforts to release 0.24.4.

I'm checking the compatibility of the files and found that there is a PROPSTRING record which is holding top cell name and the S_TOP_CELL property consists of PROPSTRING reference to the b-string (type14).

But, according to the SPEC A2-1.7, the S_TOP_CELL record should have a single n-string.
(My guess is that means type12, but I'm not sure type15 is acceptable or not.)

Your provided dump_oas made it easier for reviewing the created oasis. Thank you for introducing the tool.

Best Regards,
Masaki.

Matthias

Hi Masaki,

looks like a never-ending story ... but I hope it's converging ... :-)

It looks you're right although the tools I checked against did not complain.

I'll fix this in the next minor release. It's not a big thing. I was using a generic function to write a property value and strings are not necessarily n-strings, so this function is writing a b-string for the general case.

Do you have some more feedback? I am starting to collect topics for 0.24.5 now.

Matthias

Masaki

Hi, Matthias,

Thanks for your response, the above is the only item now I have.

Thank you.
Masaki