-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to classify signals to clamp/ignore during scan? #22
Comments
@mwachs5 why do you want to ignore some outputs during scan mode. @drom and I are working on a DUH scan insertion bus interface |
No, thisis not about how to get into test mode. Consider a Bandgap or OTP which is controlling power to your chip, with a memory-mapped register control interface. During scan you a) don't want to turn the thing off/corrupt its contents and b) probably don't want to look at the data output. So you'd want to clamp the controls into the OTP and mux the data output going into your scanned registers. I think this is slightly different from what you are saying above. This doesn't necessarily put the circuit into test mode, it just says what to do if the overall circuit is in scan mode. But maybe those are the same thing in your mind? It's not about how to test this IP, it's about how to not mess up this IP or have it mess up the rest of your circuit when you're trying to test the REST of it. |
Yes @mwachs5 it's different from what I was saying. I see what you mean by clamping OTP controls. I've seen it called a "safe value", because you clamp a signal at a value that won't damage the Silicon. But when you say "mux the data output going into your scanned registers" I think you mean clamping the OTP outputs because their values are unknown and propagating Xs can reduce coverage. Right? Perhaps we should have a DUH test safe value interface that has the ports and the safe value data. |
A common case I've run into when onboarding IP (especially analog IP) is that you may want to clamp some inputs to known values during test/scan mode, and ignnore some outputs during scan mode.
It might be nice to be able to annotate signals in that way in the DUH file so that as you generate code around the IP you can properly insert that logic.
FYI @fferhani
The text was updated successfully, but these errors were encountered: