• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Logic Design
  3. TIP OF THE MONTH: How to pack up a Conformal testcase for...

Stats

  • Locked Locked
  • Replies 0
  • Subscribers 61
  • Views 13118
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

TIP OF THE MONTH: How to pack up a Conformal testcase for your Cadence AE

archive
archive over 18 years ago

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.


Originally posted in cdnusers.org by buda
  • Cancel

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information