contact us
     
 
RSI Websites 

Genesis 2000, Enterprise 3000, Trilogy 5000, ODB++

Overview

CAMCAD loads an ODB++ Directory that includes all boards and panels defined.

Versions Supported

CAMCAD supports all systems which will produce ODB++ Directory output.

Specific Import Procedures

  1. Launch CAMCAD and select " ODB++ Read" from the FILE> IMPORT menu. A dialog box will appear asking you to specify a file.
  2. ODB++ files come with Main directory and Sub directory. The file to import into CAMCAD is the folder that contains all information files. The information files inside the main folder are fonts, matrix, misc, steps, and so on.

    Select the main file and then select OK. Another dialog box will appear as shown below.

  3. Select OK to start importing ODB++ file to CAMCAD. During the process of importing files, "odb.log - notepad" might appear. Simply close the appearing notepad, and then select Place at ORIGIN and FIT PAGE to Image to place ODB++ file in CAMCAD display window.

    Note -
    When selecting Manufacturing Read, the ODB++ data will be read into CAMCAD and CAMCAD will create intelligence such as padstacks and hierarchical component definition. This is critical if users want to translate the ODB data into any format that requires padstacks and hierarchical components (nearly every translation requires this).
    When selecting the Artwork Read, the ODB++ data will be read in as graphics only. It would only be a graphical representation of the design.

Tips and Importing Notes

  • ODB++ files are typically compressed using the unix compression algorithm TAR. CAMCAD offers an option to automatically inflate TAR files to import the data, but the inflation of the data may take some time. Users are free to inflate TAR files outside of CAMCAD, before the import, using a utility like WinZip. This will accomplish the same inflation of the TAR file into it's directory structure, but WinZip will do it faster than the untarring routine built with CAMCAD.
  • Polylines that have netnames attached to them are classified as ETCH during import. Other polylines, regardless of the layer they exist on, are not classified as ETCH if they do not have a net assignment.
  • ODB++ files can be very large. If users want to recreate the ECAD intelligence (padstacks) that are not present in the ODB++ file, the option is available with the "Manufacturing Read" option during import. However, computer system resources must be available to make this reconstruction possible. Users should moniter memory usage using their Windows Task Manager and add memory if hard drive disk swapping occurs. Memory requirements for padstack reconstruction are typically about 3-4 times the total size of the unzipped ODB++ files.
  • Component pin padstacks can only have one feature graphic per layer per padstack. This means, for example, if two or more features are present on the same layer within the boundary of a component pin, the feature with the centroid matching the center of the pin will be selected.
  • When specific inserts of components differ from reconstructed full geometry definitions, insert-specific geometries will be created.
  • Fiducials must have pad usage of 2 or 3 in order for CAMCAD to classify the pad as a fiducial. The pad usage must be defined within the Feature file.
    For example:


#Feature attribute names
#
@0 .nomenclature
@1 .pad_usage


#Layer features
#
P 0.6 0.2 2 P 0 0;1=2

Format and Translation Notes

Valor ODB++ files are extremely complicated and very large, spanning tens or hundreds of individual ASCII files in a large directory structure. For all intents and purposes, the complexity of the format prohibits most 3rd party vendors from even making tools to read ODB++. In all cases, we would rather perform data preparation and translations from original ECAD layout data versus ODB++ files. The reason is simple: ODB++ data is natively flattened. This means, the original Design hierarchy is destroyed. During import CAMCAD needs to recreate padstacks and hierarchy. Subsequent translations, to manufacturing, test, or other ECAD formats, may be impacted negatively because they typically all utilize a hierarchical approach to data storage. Any hierarchical reconstruciton that CAMCAD does to the ODB data is not as good as the native hierarchical data, i.e. the ECAD layout data.

  • For ECAD or GenCAD exports, the superior method of translations is
    Native ECAD Layout-> CAMCAD -> ECAD / GenCAD    .
    The inferior method of translation is
    ECAD -> ODB -> CAMCAD -> GenCAD
    The quality of the results from these two processes is*not* the same!
  • For Test and Manufacturing exports, the superior method of translation is
    Native ECAD Layout-> CAMCAD -> Test / MFG     file.
    The inferior method of translation is
    ECAD -> ODB -> CAMCAD -> Test/MFG file
    The quality of the results from these two processes is *not* the same!

ODB++ files may be intelligent or unintelligent, or may have various degrees of intelligence. This means, a Valor user can save ODB++ data with only Gerber files originally loaded; the resulting ODB++ file will probably not have the component or netlist intelligence to be the basis for subsequent translations. The difficulty in spotting unintelligent data not suitable for test or manufacturing translations versus intelligent data is another reason why the format should be avoided whenever ECAD layout data is also available. CAMCAD will not recreate the intelligence from gerber-only ODB data.

The ODB++ data structure is such that there is a directory and sub-directories filled with many ASCII files, all of which together comprise one design. It is virutally impossible for an end user to use Notepad to actually point to a specific component or via padstack, as the format stores data layer by layer without storing actual padstack information, netlist information, component information, or attribute information. This is very unappealing to any user who is used to ECAD and ECAD-Like formats that have actual padstacks, components, netlists, and attributes.

Valor is very good at bareboard DFM analysis and for that reason the program is popular in board fabrication environments. However, the ODB++ data is a poor choice for Contract Manufacturing environments interested in a robust data file for driving assembly and test processes. For a much more suitable file format investigate the CAMCAD .CC file.

Known Translation Limitations

ODB++ data is not suitable for translations in some cases.

  1. Gerber generated ODB data - If ODB data is created strictly from Gerber information, the resulting data set will probably lack the intelligence required for many outputs.
  2. ODB data to GenCAD format - ODB data normally contains many line segments and polylines. ECAD data is flattened when brought into the Valor tool, and this flatteneing has negative ramifactions for translations to Gencad. If pour areas are flattened to individual line segments, or if polylines have more verticies than what is allowed in Gencad files, any Gencad file created from that ODB data will be "bad". It is highly recommended that users start with the native ECAD Layout data rather than ODB data when performing translations with RSI tools
  3. Mentor generated ODB data - Some Mentor created ODB data does not have proper netlist connectivity information. This has been demonstrated in several files sent to RSI. In these cases, it is always better to work with the native Mentor data, either the Boardstation files or the Neutral file, to achieve optimal translation results. .