Consider the scenario where you have all the test signals as shared signals except for a dedicated test_mode signal
If you define the scan enable signal as a shared signal then you must and that signal with an active high test_mode signal to produce the scan enable signal internally
Now the output of this AND gate in your design would become your scan enable hookup-pin
hookup-pin is considered by the tool as the source of scan enable and will assume that this pin is directly controllable from a primary input
Note: The term hookup-pin could be particular to Mentor tools
7 thoughts on “What does hookup-pin mean?”
thanks for the explanation.
I can confirm that the term hook-up is also used in Cadence RTL Compiler.
Question: in the case you described, why did the scan enable have to be shared in order to define with a hook-up pin? what if it wasn’t shared? would a hook-up pin be useful then?
I see your post is from 2008. I hope you’re still around 🙂
I am still around 🙂
A hook up is defined since the scan enable is shared, it is not the other way around. When the scan enable is shared it cannot be directly controlled from the primary inputs. A hook up is a pin which would virtually act as the scan enable in scan mode. When the scan enable is not share you do not need a hook up pin.
I hope I answered your question.
That was a fast reply.
can you please be more detailed?
I understand that when the scan enable is shared, it can be used for other purposes during functional mode, but in test mode, it has to be held at 1 during shift and 0 during capture. so it is really used for one purpose in test mode. so what difference does the hookup make?
To put it simply, it is not straight forward in how you can put the chip in scan mode. So instead of specifying to the tool how to put the chip in scan mode (sometimes the tool cannot do that directly from the PIs (Primary Inputs); for example when there is a TAP controller that sets the modes of the chip, we just simply ask the tool to consider an internal pin as scan enable as if it is a PI.
Thank you Nagendra.
I have already seen scripts that define DFT signals (like test clocks for example) on internal pins, but without the use of a hookup.
Obviously the tool allows it, but I do not understand what is the motivation to that, since at the end, the physical tester that tests the chip interfaces only with PIs.
Can you please comment on that?
I think what you might be overlooking is the functional mode of the chip.
If you don’t add this gate between scan enable and test_mode, your scan tests will still work ok. But in functional mode, the scan enable input will be toggling between 1 and 0, depending on the functional purpose of this pin, meanwhile putting all your flipflops into and out of scanmode and breaking the functionality of your chip. A horror scenario :-).
hookup pin concepts also there in synopsys DETCompiler