Home > Community > Blogs > Logic Design > Do you also need to be a DFT, STA, verification, low power, and library expert? Not anymore!
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Logic Design blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Do You Also Need to be a DFT, STA, Verification, Low-Power, and Library Expert? Not Anymore!

Comments(0)Filed under: Low power , Logic Design, DFT, conformal, SDC constraints, RTL compiler, cadence, Jack Marshall

By Jack Marshall
Sr. Tech Leader, Solutions

Our R&D team has just released a major new feature in RTL Compiler 9.1.100.  It is called "Quality Analyzer".  I call it "RC QA" for short - since that's how you invoke the feature (rc -qa).  It's our first attempt at producing an integrated, multi-checking, front end design, signoff, analysis, and debug tool.  It works at the RTL block level, the RTL Chip Level and at the Gate level.

RC QA utilizes, organizes and analyzes information from different checking operations from several successful Cadence tools: Conformal Constraint Designer, Conformal Clock Domain Crossing, Conformal Low Power, RTL Compiler and HAL.  It brings all this information to one centrally organized graphical user interface and enables the RTL designer to selectively check different aspects of their design prior to signing off their design at different levels of development.

Oh, and did I mention that it's a free feature?  You must have the licenses to operate the different aforementioned Cadence tools - but if you do - then RC QA can access them for you automatically.  RC QA can also help you invoke the different checking tools individually (assuming that you are familiar with the tools), by creating a dofile for each tool with all of your design information loaded into the dofile. 

By centralizing all the information in one tool, RC QA can become an integral and important step in every design team's implementation flow.   RC QA's rulesets can be customized, the severity of each violation can be chosen, and the users only have to learn one interface to check their design against several different critical design areas (Clock domain crossing, constraints, libraries, Design for Test, low power intent, synthesizeability etc).

Today I'm just going to talk about how to invoke the tool, how to create a configuration file - since it's different than how you usually invoke and use RTL Compiler and how to run some checks.  I'll let you check out the user manual "clds_user.pdf" (in the doc directory under the 9.1.100 RTL Compiler executable path) to learn more about the different aspects of the tool (reports, analysis, debug, messages, filtering, customizing etc).    

You can also read about all the different checks RC QA performs in "clds_rules.pdf" (also in the doc directory).  Then for my next blog article I'll write about a design debug flow I use that utilizes RC QA.

To invoke RC QA:

Type "rc -qa" from the linux or unix prompt.  This will automatically invoke the GUI - so make sure you have your "DISPLAY" environmental variable defined (setenv DISPLAY <machine_name:0>).  Note: you typically run the checks in "batch mode" (i.e. no gui) then use the GUI to analyze & debug & fix the violators.

To configure RC QA:

This is different.  RC QA does not currently use the same attributes and variables that RTL Compiler uses.  RC QA was developed separately and uses a very simply formatted Tcl configuration file to load up the libraries, HDL files, and constraints to be checked by RC QA. 

A sample configuration file looks like this:

set LIB_SEARCH_PATH "./library"
set STD_LIBRARY_LIST "slow.lib"
set CHECKS_ON_NETLIST false
set VHDL_FILE_LIST ""
set VERIFICATION_SETUP_FILE ""
set HDL_SEARCH_PATH "./rtl"
set VERILOG_FILE_LIST "channelarb.v clock_divider.v dma.v dma_mac_pwr.vdmacontrol.v dmaextdevbridge.v dmaslave.v"
set TOP_MODULE "dma_mac"
set LEF_FILE_LIST ""
set SDC_FILE_LIST "./MODS/rc.dma_mac_m.sdc"
set CPF_FILE_LIST "./dma_mac.cpf"
set CAP_TABLE_FILE_LIST ""
set INC_DIR "./rtl"
set HDL_LINT_CHECK_OPTIONS ""
set CONSTRAINTS_RULE_FILE ""
set CLOCK_RULE_FILE_SETUP ""
set CLOCK_RULE_FILE_VERIFY ""
set DFT_SETUP_FILE "./dft_setup.tcl"

You also have the option to create a configuration file interactively using a menu choice from the GUI.  To create a configuration file interactively in the GUI select the menu item:

   File -> Configuration File -> Create

That will open a multi-tabbed window with blank slots for where you can enter your design data information.  After you create the configuration file you will need to read it in - saving it off to a file is not enough.

   File -> Configuration File -> Read

Or you can use the command:

   read_config_file <config.file>

Check the monitor window to insure that your config file and all of your design data was read in succesfully  - if not - go back and edit the file and re-read it.  Once the configuration file has been properly loaded - you are ready to run some checks:

Running RC QA Checks:

You have a choice of 7 different types of checks to run on your design data, I purposely used the phrase "design data" since these checks can analyze more than just your HDL files - they check your HDL files, library files, CPF file, SDC file or dft setup files.

The 7 checks are:

  • Library Checks
  • HDL Lint Checks
  • Clock Domain Crossing Checks
  • Constraint Checks
  • Low Power Checks
  • DFT Checks
  • Physical Checks

You can activate the checks via GUI menu:

   Tools -> Signoff Checks

Or you can execute them via command:

   signoff_checks

Either way, once a check has been run - it can not be repeated unless the configuration file is re-read (which is easy to do - just re-read the configuration file).

I'll leave the rest of the operation of the tool up to you to explore.  I'll write about a practical flow using RC QA in my next blog where I'll explain how to use the filters to cut down on information overload and how to systematically go through the violators in a straightforward manner.

Until then,

Good luck designing.

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
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.