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?
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.
Have you checked that SE got connected to the clock gaters cells correctly?
Is there actually a controllable path from the port scan_shift_enable to the clock gater enable cells? If not, that is the reason for the failure. You can check the controllablity of this path by using the dft_trace_back command:
Usage: dft_trace_back [-mode <integer>] [-polarity] [-continue] [-print] <pin|port> [-mode <integer>]: trace back one level under the specified mode (0-3). 0: no constant propagation, 1: tied-constant propagation, 2: tied-constant and test-mode propagation, 3: tied-constant, test-mode and shift-enable propagation [default: 3] [-polarity]: also return whether the polarity changes through the trace [-continue]: continue the trace back until PI, sequential gate, complex instance or constant is reached [-print]: print the status and pin at every trace back <pin|port>: pin or port to start the back-trace from
Use -mode 3 to propagate shift_enable.
You could also try temporarily using a primary input for SE (rather than using -hookup_pin) just to prove to yourself that controlling the clock gaters with SE is ok. But, I believe this to be a better solution than using scan_mode.