Additionally, the insertion of dummy VIBE EcoBee Masks geometries is based on a density analysis of the layer. This analysis is made on a window basis and requires to have a flat view of the top level of the layout. When using a regular oasis ® file, flattening a full chip requires a huge amount of memory, although only one small part of the drawing (the window) is processed at a time. The oasis.Mask format, which is topological by design, is definitively more convenient for such an operation. The physical representation of the chip has already been flattened and split in small areas.

By doing that, bit 0 of the  adder named add_3 used in the arithmetic and logic unit named alu, may become alu.Add_3.B[0]. This will guarantee the unicity of each label and will greatly help the lvs to find the correspondence between layout and schematic. Nowadays, sequential access is not an interesting property anymore and one of the new features offered by oasis ® was to give direct access to parts of the file. To allow this, oasis ® offers the possibility to store indexes in reference tables either at the beginning or the end of file (see ii-b1 for further details). In addition to faster random access, oasis ® goals were to reduce file size and remove some critical limitations such as numerical precision.  To meet this second requirement, the original restriction of 32 bits for all integer values has been removed.

No change to the format is required as a different layer number may be specified for each trapezoid. Datatypes are also specified in the specification but flagged as “ignored”. Supporting several layers and datatypes should come at almost no implementation cost. Of course, limiting layers and datatypes to a finite number is necessary. But restricting layer and datatype number to 256, as in the current version of the oasis.Mask specification, is an acceptable limitation.

We have seen that oasis.Mask is pretty well suited for all the steps of a design flow. However, in order to be more efficient for validation, some simple modifications are required. This chapter points out some suggestions to improve oasis.Mask usability. In the latter case, the reader now has to seek to the end of the file to know the table offsets.

For example, the localization area width and height can vary based on the cell density of the mask. All these parameters need to be taken into account in the oasis.Mask writer to strike a good balance between file size and random-access speed. The oasis.Mask file will be used for post layout data processing and it will be the result of a conversion from the designer database.

In the same way, the original limitation of gdsii to 256 layers and 256 datatypes has been cancelled. If we also take into account the possibility to apply an horizontal or vertical mirror on the cells, we again multiply by 4 the number of common cells to be described. If we consider that applying a rotation to a trapezoid will change its type, it is true that allowing rotations will increase the file’s complexity. Oasis.Mask fixes some of these issues while at the same time offering a topological view of the database, which is required by some tools in the layout flow. And its compatibility with oasis ® allows for a smooth transition between the design world and the process world. As such, oasis.Mask is an important step towards standardizing the various file formats used in microelectronics.

This hierarchy should follow the schematic hierarchy and the layout vs. Schematic verification is performed hierarchically. Each cell in the schematic should match a cell in the layout, and the interconnections between them should match the connections drawn at a higher level of the hierarchy. Working on the hierarchy speeds up the process, and makes it easier to identify and localize errors. Oasis.Mask has restricted the types of repetition to only standard orthogonal arrays.