#L28

Q: Can AutoFind locate tristated outputs?




AutoFind in DC PMU

AutoFind is a search/build tool. It simply locates vectors at which certain device pins are at a given state (i.e., comparing for an "H", or driving a logic Lo, etc). It then lists the vector addresses and coverage at these addresses. The F1 help window has instructions for it's use. Just open "DC PMU" from the LaunchPad and click "AutoFind". Pressing the function key F1 brings up the online help for AutoFind.

This feature was suggested to us by a customer, let's call him Steve. We thank him very much for helping in the development of this and other ETSNT tools. He makes an important point about assuming too much when using AutoFind, particularly in searching for tristate conditions. We'll let him tell it in his own words.

"Per your query on how I feel HILEVEL should approach the use of AutoFind for tristate, I can think of several approaches. First of all, let me say that based on the standard set of vectors that I generally receive (using the 0,1,Z,H,L,X format), I don't believe a function like AutoFind could determine that the output is actually tristated or not, UNLESS, the translator that comes from the simulator monitors the output enable signal(s). The translator would then fill the output condition with an 'X' ONLY if the output was disabled, and AutoFind would only have to search for an 'X'. The user must verify that the translator handles this situation properly. Keep in mind, that if the test frequency is increased (i.e. from 1MHz to 10 MHz), the simulator must verify that the outputs remain in the same state as the original simulation test frequency. It is very possible that an output may be tristated at the end of a 1000ns-test cycle, but not at the end of a 100ns cycle. Again, simulation should confirm this. In fact, I would run the simulation at the various test speeds, and do a file compare of just the tabular vector set. If there is no difference between the vectors, then I would not anticipate a problem with the increased test speed."

So it would seem most prudent to check the state of the enables when looking for tristated outputs, bearing in mind the possible delay needed for disable time.

Steve continues:
"If the simulator does not monitor the enable signal(s), then we are left with the following options:

    1) Create a test program for just that purpose,
    or,
    2) Go back to the simulation and/or the person who wrote the vectors and manually search for the test vectors that satisfy the tristate condition."

Steve goes on to suggest, "you may want to write a translator that monitors the output enables of the simulator output file, assuming that you are starting from the simulator output."

Thank you very much, Steve for your feedback. It cleared our minds. The suggested enhancements have made the system better for you and for the rest of us. Perhaps one day such a translator feature can become a reality; until then, it's great to know that users are sharing their ideas and solutions to the benefit of all.

We should mention an important point in AutoFind; that of interpreting the results. Here it is in a nutshell; the online Help has more information.


AutoFind Results

AutoFind can be a great aid in finding complete coverage of your desired states, as long as they exist in the vectors.

Also See:

Q'nApp #L9: Iddq Testing
Q'nApp #L17: Stimulus Formats
Q'nApp #L23: Inhibit Delay

QL28.zip is a zipped Word file of this Q'nApp.


Click your browser's Back button to return to the Q'nApps index.

© 1999 HILEVEL Technology Inc.