Skip to content
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

Open
mwachs5 opened this issue May 7, 2020 · 3 comments
Open

How to classify signals to clamp/ignore during scan? #22

mwachs5 opened this issue May 7, 2020 · 3 comments

Comments

@mwachs5
Copy link

mwachs5 commented May 7, 2020

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

@fferhani
Copy link

fferhani commented May 7, 2020

@mwachs5 why do you want to ignore some outputs during scan mode. @drom and I are working on a DUH scan insertion bus interface https://observablehq.com/@drom/scan-bus-definition. It specifies which inputs to clamp to put the circuit in test mode, and what clocks and resets to use for scan. Is that what you had in mind?

@mwachs5
Copy link
Author

mwachs5 commented May 7, 2020

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.

@fferhani
Copy link

fferhani commented May 8, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants