OASIS® is a Registered Trademark of Thomas Grebinski
SEMI P39 OASIS READER AND WRITER
Request more Information
Yotta Data Sciences' OASIS Reader and Writer feature:
full compliance with SEMI standard P039-0308 (March 2008)
support for all OASIS concepts, including 64-bit coordinates when compiled on 64-bit platforms
support for large files (> 4 GB) even on 32-bit platforms
reader APIs for sequential file access or parallel cell-by-cell access
100% ANSI C with easy interfacing to C++
user-programmable error reporting, allowing reader code to analyze incoming
OASIS data in detail for optimality issues, warnings, dangerous usage, or fatal errors
ease of use - no need to be an OASIS expert
thorough checking of input to keep bad data out of applications
robust testing methodology for reliable code
carefully structured and well-commented code to allow developers to use more OASIS features as they become more familiar with OASIS concepts
Code Architecture Overview
Yotta Data Sciences' OASIS reader and writer are architected as a series of levels:
Level 0 is the lowest level file I/O code. This level handles random file access, checksums and CRCs, and compression.
Level 1 code handles basic OASIS file data types, such as arbitrary-length integers and all forms of real numbers.
Level 2 code reads and writes the fields of OASIS records, for example the various specialized point lists within an OASIS file.
Level 3 code handles modal variables and other record-by-record interrelationships within an OASIS file. It also includes conversion of OASIS-specific records to generic forms.
Level 4 code implements the high-level data structures of an OASIS file, in particular the name tables. This level also includes record-by-record validation functions.
Level 5 implements the Applications Program Interface. This level hides almost all of the complexity of the OASIS interface from developers who are interested in maximum functionality in the minimum amount of time.
Strict separation between levels means that low-level code never accesses high-level data structures and high-level code uses only defined APIs of the low-level code. This makes the code easier to understand as well as test. All interface files are fully documented - there are no mysterious functions or data structures to become traps for unwary developers. Functions intended only for use within a module are marked as “public for testing only.”
Every module has its own dedicated test program. Implementing a combination of white-box and black-box tests, the test programs provide coverage for all normal modes of operation, many of the exceptions, and all of the bugs found. Running the test programs after a bug fix, a refactoring, or a port to a new platform ensures that all of the code still functions as intended. The test programs follow the same high documentation standards as the main code, providing explanations of design decisions as well as sample usage for each level of code. This robust testing methodology allows Yotta Data Sciences to fix bugs quickly and make enhancements safely, knowing that new code does not break existing code.
The reader and writer are designed to be embedded in a wide range of EDA products; they work silently and yet return detailed status information so that applications developers can quickly solve problems in their own code. Error messages are stored in memory and returned to the application; a single-line function call then formats the messages according to the requirements of the application. Multiple levels of warning and error logging are supported: optimality issues (usage that slows down file readers), warnings about constructs that should be avoided, dangerous usage messages for constructs that are not yet illegal in the OASIS specification but could result in ambiguous interpretation of an OASIS file, and fatal errors that prevent all use of the data in an OASIS file.