Stats

  • Locked Locked
  • Replies 3
  • Subscribers 62
  • Views 16179
  • 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

Disable Scan Shift Enable in Functional Mode

Terry2000

Hello,

I'm trying to disable shift enable in function mode.  

This is the VHDL code:
 i_scan_shift_enable <= '0' when scan_mode_in = '0' else scan_shift_enable;
   

So "scan_shift_enable" is driven from a pad and  "i_scan_shift_enable" drives the flops.

However I can't seem to keep net i_scan_shift_enable preserved and even if I did would it be a valid pin for the DFT tools to hookup to.

How is this generally done? Is it necessary to instantiate tech cell, preserve and hookup to the output pin?  

Parents

  •  Hi,

     I have seen tech cells instantiated for this purpuse, but it isn't absolutely necessary.

    Using a hierarchical pin for this purpose is quite useful.  If you can make i_scan_shift_enable a hierarchical pin, then you can define your shift_enable as follows:

        define_dft shift_enable -name SE -hookup_pin [find / -pin <hier_path>/i_scan_shift_enable] -hookup_polarity non_inverted [find / -port scan_shift_enable]

     When connecting scan chains, RC will know to connect to the <hier_path>/i_scan_shift_enable pin.  But, when writing out interface files for Encounter Test, RC will know that the shift_enable port is scan_shift_enable.

     You are correct that you cannot rely on net names to be preserved throughout the flow.  But, you can generally rely on hierarchical pins to remain throughout the flow (at least through synthesis), as long as you prevent them from being ungrouped.

    Good luck!

     

Reply

  •  Hi,

     I have seen tech cells instantiated for this purpuse, but it isn't absolutely necessary.

    Using a hierarchical pin for this purpose is quite useful.  If you can make i_scan_shift_enable a hierarchical pin, then you can define your shift_enable as follows:

        define_dft shift_enable -name SE -hookup_pin [find / -pin <hier_path>/i_scan_shift_enable] -hookup_polarity non_inverted [find / -port scan_shift_enable]

     When connecting scan chains, RC will know to connect to the <hier_path>/i_scan_shift_enable pin.  But, when writing out interface files for Encounter Test, RC will know that the shift_enable port is scan_shift_enable.

     You are correct that you cannot rely on net names to be preserved throughout the flow.  But, you can generally rely on hierarchical pins to remain throughout the flow (at least through synthesis), as long as you prevent them from being ungrouped.

    Good luck!

     

Children
No Data

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.