In software development, as in any rigorous scientific discipline, the ability to detect and correct problems is only as good as the data available to the developer. When you do run into issues that need to be reproduced at the factory, what's the easiest way to pack up a testcase for Cadence R&D?

1. Narrow the scope: For a hierarchical design, first try to narrow the issue down to the smallest relevant level of hierarchy. Set your new root module using:
   'set root module -both '
   
   
2. Generate golden.v and revised.v netlists. After you have read in the libraries and designs, write out the golden and revised designs at the current module level using:
   'write design -rtl -golden golden.v'
   'write design -revised revised.v'
   
   The above example assumes an RTL to Gate testcase. If this was a gate to gate testcase, you would omit the "-rtl" option for generating the golden.v
   
   Note: The major advantage of using Conformal to generate your testcase is that the 'write design' command will automatically grab `included code, as well as push through any compiler defines. This is similar to the decompile process in Incisive Unified Simulator (IUS) using ncdc, or the "tokens build" process with Synopsys' VCS. This does imply that your `includes and compiler defines must be set properly, as there's no way to recover files that weren't included in the first place, or source code that was `ifdef'd away.
   
   
   Where the 'write design' process differs from IUS/ncdc or VCS/tokens is that it generates an elaborated Verilog netlist, which instantiates "Verplex primitives," while the IUS/ncdc or VCS/tokens flows only flatten the source file(s) and compiler directives into a single file, but do not write out elaborated design structures.
   
   Using 'write design' in Conformal will also handle any type of mixed language design, generating a functionally equivalent Verilog (only) netlist.
   
   
3. Generate golden and revised libraries. Write out the golden and revised libraries using:
   'write library -golden golden.lib'
   'write library -revised revised.lib'
   
   
   
4. (optional) Encrypt the data: Note that the Conformal generated golden.v and revised.v are effectively Verplex netlists, and though they are ASCII files, they are hardly readable.
   Nevertheless, if you feel the need to encrypt data, you can use the vpxProtect utility (located in ${VPXHOME}/tools.{PLATFORM}/cfm/bin/{32|64}bit/) as follows:
   • Add "`protect" and "`endprotect" around those sections of the golden.v and revised.v files that you want encrypted. You can encrypt everything, including module port definitions.
   • Run vpxProtect as follows:
     > vpxProtect golden.v revised.v
     This will generate two files: golden.vpx.v and revised.vpx.v
     
     
5. Verify that the issue can be reproduced with the new files! Modify your original dofile so that you are now reading in the golden.v (or golden.vpx.v) and revised.v (or revised.vpx.v) files, and rerun Conformal.
   
   Your testcase is now encapsulated in the following files:
   • golden.v (or golden.vpx.v)
   • revised.v (or revised.vpx.v)
   • golden.lib
   • revised.lib
   • new dofile that references the above files.
     
     
6. Tar up the above files to create your testcase.
   Using the above procedure, you can easily pack up a testcase for shipment to Cadence.