IP with scan, insane or not?

[beeflobill]

I'm working at mystery company X right now, and I'm helping develop models for non-volatile memory IP. We have a requirement to put a scan chain for DFT into the control logic for IP were developing right now. As a team, we're not deep into digital methodologies, and so we're learning quite a bit to do this.

Anyway, I'm trying to figure out what views to give our users to enable them to actually use the scan chain of our IP inline with their design scan chains. I'm not finding evidence that our tool vendors had this kind of thing in mind.

If anyone has any particularly sage advice about this, then that would be welcome. But, what I'm really looking for is:

1) Do other people put scan chains into their IP?
2) Are there any really good arguments for why people *should not* do it?

Also, I suppose if any one wants to simply complain, I'm in the mood to enjoy reading other people's rants about how freaken stupid this sort of thing is .


Thanks!

 

[ads-ee]

You might be interested in reading this from Synopsys, which describes suggested methodologies for scan insertion.



Maybe that will give you some ideas whether or not doing what you're doing makes any sense.

As I recall (when I worked on ASICs) we inserted the scan chain on the synthesized netlist which meant the IP was already part of the design. So the scan registers were inserted in the IP blocks along with everything else.

I imaging the scan insertion tool will replace all the registers with the library scan registers and leave all your IP scan logic in the design along with the scan registers from the vendor library. That might be an interesting situation. The inserted scan chain that checks the IP scan chain along with the rest of the logic, bet the coverage goes down.

regards

 

[rca]

1- do you provide your IP with RTL based format, and the customer will do the synthesis..., in this case, no scan insertion is needed, but you need to check that your design is scan freindly, I means, the scan could be inserted and no coverage lost due to your design.
2- if you provide only the gds2 of our IP, you should insert the scan. The customer does not need to connect his scan chains to yours scan chains, he could define as separate test mode, specific to your IPs or as he should know how the scan was inserted by you, to concatenate to his scan chains.

 

[kornukhin]

The only practical usage for specifying scan chains at RTL I see is ability not to use scan insertion tools (DFT Compiler, DFT Advisor, DFT Architect...), which can save you some money. If part of the design doesn't have scan chains inserted you will still need to use scan insertion tool.
If all of your IP's have inserted scan chains you can just stitch them without additional DFT license. But you will still need to write test protocols for ATPG.

 

[beeflobill]

To clarify, the IP is a mixed signal design. We don't give out RTL. We give out GDSII, behavioral models, liberty, and the like. We have used DFT tools to add scan into the digital part of our design. But, what we will be giving the customers is going to be fixed and unchanging, or in other words, a hard macro.

rca said, "do you provide your IP with RTL based format .... in this case, no scan insertion is needed". I would definitely prefer to give out an RTL controller for our IP that the users could synthesize and implement scan in as they wish. But, since we are pretty late in the project and management is stubborn, I don't think it's going to happen.

kornukhin said, "The only practical usage for specifying scan chains at RTL I see is ability not to use scan insertion tools". We're not trying to manually put the scan in with RTL, and we are not trying to avoid using the scan tools. I'm just trying to make sure we are supplying our customers/users with everything they need to effectively implement a scan test with our IP. In fact, we used the scan tools to put scan into our IP. Now, I think there is strong argument for not putting scan into hard IP in general, if I'm not just a strong emotional reaction to the idea.

rca said, "The customer does not need to connect his scan chains to yours scan chains, he could define as separate test mode". I had not considered that possibility. With this approach we would not need to deliver any special views to the customer, they would just have to hook up the scan pins and make sure they are accessible. This suggests that if things came to an extreme situation, that our uses could get by without special views, except maybe scan patterns provided by us.

rca said, "he should know how the scan was inserted by you, to concatenate to his scan chains". This was the approach I assumed the customers would be taking. It seems the only way to give this information to the user would be to supply a netlist of the IP digital controller. Maybe it would be best to let the users figure out how to do scan insertion by themselves. Then with the netlist, I could provide a view to help them simulate and validate their scan patterns, and that would be enough.

@ads_ee I took a look at the document you sent me. What I understand from what I read was that DFT Compiler allowed the users to create CTL models for each pre-scan-synthesized netlist that would help the tool stich (or concatenate) the various netlists together. That provides me with some hope! There are tools that can do it.

 

[rca]

The information needed, could be only the pins scan in out, scan enable, scan clock if different of system clock, scan reset is also different, and the length of the scan chain.