Real Intent tries to shift left on DFT
Real Intent has launched a design-for-test (DFT) tool intended to relax the bottlenecks that occur as an SoC project moves into its final phase ahead of tapeout.
The approach taken by Real Intent with Verix DFT is to push the analysis needed to check that a design is ready for test-program generation earlier in the flow with a greater focus on continuous regression where the tool is run repeatedly to catch problems before they feed forward. However, Prakash Narain, president and CEO of the company, notes that there are common DFT errors that typically arise not within cores but in the interfaces between them as the SoC is assembled.
“Testability issues occur both in the cores and in the interfaces between different RTL blocks. It is an important part of ‘shifting left’ that designers run DFT sign-off on the individual cores to identify and address DFT errors before integration, and then again at the full-chip level after integration,” Narain said.
The Verix DFT tool employs static analysis rather than simulation. “Part of Verix DFT’s value is that it is high performance with a low memory footprint,” Narain claimed.
Multimode analysis
Designed to run during design, after netlist generation and after place-and-route, the tool handles different automatic test pattern generation (ATPG) mode. It will simultaneously analyze multiple ATPG partitions and constraint sets for different types of test pattern, such as those that use compression, to avoid the need to create separate runs for each test mode the SoC will be run during manufacturing. Constraint sets can be created to help analyze the logic for different test aims, such as patterns that aim for low power consumption or for reduced time on the tester.
“To reduce peak power dissipation during scan test today, the design is usually partitioned, and each partition is tested with a dedicated set of scan load and unload patterns while other partitions are ‘quiet’, that is, not under test. Each such partition requires a dedicated constraint set,” Narain explained.
A single DFT error can have implications for many different test modes and constraint sets although the tests will operate the scan-inserted logic in different ways. Taking the difference between compressed and uncompressed test as an example, Narain said: “The scan-chain checks that involve tracing scan chains forward and backward must be repeated since the scan chains themselves are defined differently between these two test modes.”
Reporting tools
To try to make it easier to deal with the results from analysis, Real Intent has built flexibility into the reporting. The tool will categorise violations hierarchically in different ways with the user able to drill down into the data to identify the root causes. The tool labels schematics with rule-specific debug information, such as glitch sources and convergence instances for reset glitch rules. For path-based rule violations, the tool can show complete debug paths.
A typical reporting hierarchy might be one where the violations are grouped by status, whether they are new or waived errors, for example. Drilling down would allow analysis by mode and within each mode, the errors could be grouped by severity.
Rule sets can be tuned by the users to focus them on different test modes. Narain said: “A designer can choose to enable a specific rule for one test mode or for multiple test modes. This configurability also lets the designer focus attention to one specific type of rule violations. For example, the user may use a separate test mode for connectivity checks only, and exclude these rules from all other test modes.”
Verix DFT has an additional tool option for fault coverage estimation. When the option is enabled, it will provide fault coverage for each test-mode, along with a rollup of overall scan test fault coverage estimation. The idea behind the estimation to to give users a tool for prioritizing violation debug order and assess readiness for SoC sign-off.
