• 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. RTL Compiler: DFT Checks and non controllable/observable...

Stats

  • Locked Locked
  • Replies 6
  • Subscribers 63
  • Views 4018
  • 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

RTL Compiler: DFT Checks and non controllable/observable I/O

moogyd
moogyd over 13 years ago

Hi,

I am synthesizing a top level digital block that has interfaces to external pads and to a top level analog block.

When I run DFT checks, it assumes that all ports are controllable, which is not the case for the signals from the top level analog block.

Is the an attribute I can apply to these ports to indicate that they are not controllable?

Thanks,

Steven

 

  • Cancel
  • grasshopper
    grasshopper over 13 years ago
    Hi Steven, I believe you are looking for attribute dft_controllable as described below rc:/> get_attr -h *controllable* * attribute category: dft attribute name: controllable category: dft (controls design for test) object type: test_clock access type: read-write data type: boolean default value: false help: Whether the test clock is controllable in test mode. attribute name: dft_controllable category: dft (controls design for test) object type: pin access type: read-write data type: string default value: help: In test mode the output pin can take either the non_inverting or inverting value of the input pin. attribute name: dft_include_controllable_pins_in_abstract_model category: dft (controls design for test) object type: root access type: read-write data type: DftIncludeControllablePinsEnum default value: allmodes help: Enable writing out controllable pins in abstract model. hope this helps, gh-
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • moogyd
    moogyd over 13 years ago

    Hi,

    Excellent - this is just what I'm looking for.

    Thanks for the quick feedback, Steven

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • moogyd
    moogyd over 13 years ago

    Hi Again,

    Having checked further, this is not what I want.  This attribute only applies to pins, and is intended for internal black boxes.

    I need something to apply to design ports, and to indicate that a pin is not controllable (even though it is a primary input)

    Any additonal suggestions?

    Thanks, Steven

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • bmiller
    bmiller over 13 years ago

     Steven,

     I think the only thing you can do is prevent RC from automatically identifying test clocks and test mode signals.  

     To turn off auto identifcation of test signals:

      set_attr dft_identify_test_signals false /

      set_attr dft_identify_top_level_test_clocks false /

     

    The defaults are "true".

     You will have to manually define test clocks and test mode signals (define_dft test_clock, define_dft test_mode, etc) on the ports that CAN be controlled on the tester.  Any internal clocks that cannot be controlled can have the test clock muxed on them using fix_dft_violations.

    Regards,

    Brad

     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Douglas Foster
    Douglas Foster over 13 years ago

    Hi Steven,

    Did you get any solution for your trouble?

    I have a trouble that it seems very close to your.

    I need to include DFT accessibility in design but I will not have access for both input and output ports of digital circuit because they are connected to analog peripherals blocks.

    Is there any command in Encouter Test or RTL Compiler which won't take in account the use of the I/O ports for the test pattern generation? I think it isn't a recommend approach for test, but in my case I need to try it.

    BR,

    Douglas Foster

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • moogyd
    moogyd over 13 years ago

    Hi Douglas,

    I did not find a solution other than to disable auto-identification as described by Brad.

     Steven

    • Cancel
    • Vote Up 0 Vote Down
    • 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