DFT DRC's D8 D10

[rishabh_1999]

Hi all...I am working as DFT Inter...Yesterday I used Design Compiler tool
It's showing D8 & D10 DRC's
I tried autofixing with following commands

Fix the Clock DRC using Autofix

dc_shell > set_dft_configuration -fix_clock enable
dc_shell > set_dft_signal -view spec -type TestData -port clk
dc_shell > set_dft_signal -view spec -type TestMode -port TestMode
-active_state 1
dc_shell > set_autofix_configuration -type clock -control TestMode

Fix the Clock RESET using Autofix

dc_shell > set_dft_configuration -fix_reset enable
dc_shell > set_dft_signal -view spec -type TestData -port reset
dc_shell > set_autofix_configuration -type reset -control TestMode -test_data reset

But could not solve DRC...I also search online but could't get commands to solve DRC's...please share some insights

 

[glennramalho]

I usually do not allow the tool to fix the DFT violations, I read the reports and do the fixes myself. And the tool cannot fix them all, it only fixes the trivial ones.

The general idea of the DFT is all flops need to be observable and controllable. This means all flops need to be clocked from your dft clock and all resets from your dft reset pin. It is ok to have logic gates in the path as long as they all can be controlled from other flops also in the scan chain. And the tool is very good, so when it complains it is usually because it really caught something and perhaps it is just in some odd logic combination that it does not work, and if you look carefully at the path of the violation reported you will usually find the issue.

How to fix the DRCs it really depends on what it is. Here are some examples:

• if you have clock gates, you usually have a test enable input, which switches it always on. It needs to be connected to the scan enable. This can be in the RTL or via a dc tcl command
• if you have a ripple clock, then you will need to put a mux to bring in the clock yourself
• if you have a reset that is comming from a flop, you will have to force that reset high when scan_enable is high. This is needed or the reset path will get triggered during scan shift. This also can be done in the RTL or via DC tcl command.
• if you have a clock mux, you might have to select one path to use in DFT, or perhaps have some scan chains with one path selected and some scan chains with the other selected. Depends on how complex it is. The best is to make sure every path is tested.
• if you have a mux-based clock divider, you probably have to just bypass the whole thing. It is just to wierd for DFT to handle.
• if you have an analog block in the middle of the design then depends:
  • if it is just data signals you can have DC put a wrapper around it
  • if there is a clock or reset comming out of it you can use a mux to bypass the clock and resets to bring them from the clock pin
  • if it is an analog clock source like a PLL you might need something more sophisticated like a at-speed clock source (in Cadence it is called OPCG)

It all depends on your dft strategy.

Now, should it be done via script or via RTL, that depends on your company philosophy. Some people like to do it all in the RTL and some like to do it all in scripts. Both are possible. In Cadence you use add_test_point. I can't remember the command for design_compiler, I have not used the tool in a while.

 

[rishabh_1999]

I usually do not allow the tool to fix the DFT violations, I read the reports and do the fixes myself. And the tool cannot fix them all, it only fixes the trivial ones.

The general idea of the DFT is all flops need to be observable and controllable. This means all flops need to be clocked from your dft clock and all resets from your dft reset pin. It is ok to have logic gates in the path as long as they all can be controlled from other flops also in the scan chain. And the tool is very good, so when it complains it is usually because it really caught something and perhaps it is just in some odd logic combination that it does not work, and if you look carefully at the path of the violation reported you will usually find the issue.

How to fix the DRCs it really depends on what it is. Here are some examples:

• if you have clock gates, you usually have a test enable input, which switches it always on. It needs to be connected to the scan enable. This can be in the RTL or via a dc tcl command
• if you have a ripple clock, then you will need to put a mux to bring in the clock yourself
• if you have a reset that is comming from a flop, you will have to force that reset high when scan_enable is high. This is needed or the reset path will get triggered during scan shift. This also can be done in the RTL or via DC tcl command.
• if you have a clock mux, you might have to select one path to use in DFT, or perhaps have some scan chains with one path selected and some scan chains with the other selected. Depends on how complex it is. The best is to make sure every path is tested.
• if you have a mux-based clock divider, you probably have to just bypass the whole thing. It is just to wierd for DFT to handle.
• if you have an analog block in the middle of the design then depends:
  • if it is just data signals you can have DC put a wrapper around it
  • if there is a clock or reset comming out of it you can use a mux to bypass the clock and resets to bring them from the clock pin
  • if it is an analog clock source like a PLL you might need something more sophisticated like a at-speed clock source (in Cadence it is called OPCG)

It all depends on your dft strategy.

Now, should it be done via script or via RTL, that depends on your company philosophy. Some people like to do it all in the RTL and some like to do it all in scripts. Both are possible. In Cadence you use add_test_point. I can't remember the command for design_compiler, I have not used the tool in a while.

Thank You...I will kept these points in my mind now onwards