Built-in self-test (BIST) circuitry, along with scan circuitry, greatly enhances a design’s testability. BIST leaves the job of testing up to the device itself, eliminating or minimizing the need for external test equipment. A discussion of BIST and the BIST process is provided in the Built-in Self-Test Process Guide. Scan circuitry facilitates test generation and can reduce external tester usage. There are two main types of scan circuitry:
Internal Scan and boundary scan
Internal scan (also referred to as scan design) is the internal modification of your design’s circuitry to increase its testability.
Boundary Scan While scan design modifies circuitry within the original design, boundary scan adds scan circuitry around the periphery of the design to make internal circuitry on a chip accessible via a standard board interface. The added circuitry enhances board testability of the chip, the chip I/O pads, and the interconnections of the chip to other board circuitry.
Wednesday, January 23, 2008
Monday, January 21, 2008
What is DFT and why do we need it?
A simple answer is DFT is a technique, which facilitates a design to become testable after production. Its the extra logic which we put in the normal design, during the design process, which helps its post-production testing. Post-production testing is necessary because, the process of manufacturing is not 100% error free. There are defects in silicon which ontribute towards the errors introduced in the physical device. Of course a chip will not work as per the specifications if there are any errors introduced in the production process. But the question is how to detect that. Since, to run all the unctional tests on each of say a million physical devices produced or manufactured, is very time consuming, there was a need to device some method, which can make us believe without running full exhaustive tests on the physical device, that the device has been manufactured correctly. DFT is the answer for that. It is a technique which only detects that a physical is faulty or is not faulty. After the post-production test is done on a device, if it is found faulty, trash it, don’t ship to customers, if it is found to be good, ship it to customers. Since it is a production fault, there is assumed to be no cure. So it is just a detection, not even a localization of the fault. That is our intended purpose of DFT. For the end customer, the DFT logic present on the device is a redundant logic.To further justify the need of DFT logic, consider an example where a company needs to provide 1 Million chips to its customer. If there isn’t any DFT logic in the chip, and it takes for example, 10 seconds (Its very kind and liberal to take 10 seconds as an example, in fact it can be much larger than that) to test a physical device, then it will take approx. three and a half months just to test the devices before shipping.So the DFT is all about reducing three and a half months to may be three and a half days. Of course practically many testers will be employed to test the chips in parallel to help reduce thetest time.
Sunday, January 20, 2008
What is Design-for-Test?
Testability is a design attribute that measures how easy it is to create a program to
comprehensively test a manufactured design’s quality. Traditionally, design and
test processes were kept separate, with test considered only at the end of the
design cycle. But in contemporary design flows, test merges with design much
earlier in the process, creating what is called a design-for-test (DFT) process flow.
Testable circuitry is both controllable and observable. In a testable design; setting
specific values on the primary inputs results in values on the primary outputs
which indicate whether or not the internal circuitry works properly. To ensure
maximum design testability, designers must employ special DFT techniques at
specific stages in the development process.
DFT Strategies
At the highest level, there are two main approaches to DFT: ad hoc and
structured. The following subsections discuss these DFT strategies.
Ad Hoc DFT
Ad hoc DFT implies using good design practices to enhance a design's testability,
without making major changes to the design style. Some ad hoc techniques
include:
Structured DFT
Structured DFT provides a more systematic and automatic approach to enhancing
design testability. Structured DFT’s goal is to increase the controllability and
observability of a circuit. Various methods exist for accomplishing this. The most
common is the scan design technique, which modifies the internal sequential
circuitry of the design. You can also use the Built-in Self-Test (BIST) method,
which inserts a device’s testing function within the device itself. Another method
is boundary scan, which increases board testability by adding circuitry to a chip.
comprehensively test a manufactured design’s quality. Traditionally, design and
test processes were kept separate, with test considered only at the end of the
design cycle. But in contemporary design flows, test merges with design much
earlier in the process, creating what is called a design-for-test (DFT) process flow.
Testable circuitry is both controllable and observable. In a testable design; setting
specific values on the primary inputs results in values on the primary outputs
which indicate whether or not the internal circuitry works properly. To ensure
maximum design testability, designers must employ special DFT techniques at
specific stages in the development process.
DFT Strategies
At the highest level, there are two main approaches to DFT: ad hoc and
structured. The following subsections discuss these DFT strategies.
Ad Hoc DFT
Ad hoc DFT implies using good design practices to enhance a design's testability,
without making major changes to the design style. Some ad hoc techniques
include:
- Minimizing redundant logic
- asynchronous logic
- clocks from the logic
- Adding internal control and observation points
Structured DFT
Structured DFT provides a more systematic and automatic approach to enhancing
design testability. Structured DFT’s goal is to increase the controllability and
observability of a circuit. Various methods exist for accomplishing this. The most
common is the scan design technique, which modifies the internal sequential
circuitry of the design. You can also use the Built-in Self-Test (BIST) method,
which inserts a device’s testing function within the device itself. Another method
is boundary scan, which increases board testability by adding circuitry to a chip.
Friday, January 18, 2008
Designing For Synthesis
Below is a list of coding styles that might cause synthesis problems and/or inefficient design
implementation. This is not an exhaustive list, but it contains the most common problems
1. Incomplete Sensitivity List
When using an always statement to implement combinational logic, the sensitivity list
has to include all signals that appear on the right hand side of the assignments inside the
always block.
Incorrect:
always @ (a or b or c)
begin
x <= a + b; y <= b + c + d; // might cause latch inferred warning in FPGA // Express end Solutions: - Put signal d in the sensitivity list in the always statement - Use assign statement to implement combinational logic. Correct: always @ (a or b or c or d) begin x <= a + b; y <= b + c + d; end 2. The Use of ‘case’ vs. ‘if – else’ Statements
In general, case statements would translate to parallel muxes in hardware. Meanwhile, the
use of if – else statements results in priority-based hardware, which can slow down the
overall implementation of the design. Thus, only use if – else statement when priority-
based hardware is required. Otherwise, use case statements to avoid possible inefficient
implementation of the design.
While unlikely to produce incorrect outputs, the slowdown caused by large priority-based
implementations can cause problems for projects with strict clock frequency targets.
3. Incomplete ‘case’ Statement
To avoid problems with inferred latches, always specify all the possible cases in a case
statement.
Incorrect:
input [1:0] select
always @ (a or b or c or d or select)
begin
case (select)
0: x <= a; 1: x <= b; 2: x <= c; end // causes latch inferred warning in FPGA Express Solutions: - Completely specify the cases in the case statement - Always use default statement. Correct: input [1:0] select always @ (a or b or c or d or select) begin case (select) 0: x <= a; 1: x <= b; 2: x <= c; 3: x <= d; // complete cases based on the select signal default: x <= 1’bx; // add default statement to prevent unwanted // latches and/or aid debugging end 4. Unspecified Assignments in ‘case’ or ‘if – else’ Statements
Incorrect:
if (….)
begin
a <= 1; b <= 0; end // latch inferred for the signal c else if (….) begin a <= 0; end // latch inferred for the signal b else begin c <= 1; end // latch inferred for the signals a and b Solutions: - Always assign known values to all the signals in a case or if-else statements. Correct: if (….) begin a <= 1; b <= 0; c <= 0; end else if (….) begin a <= 0; b <= 0; c <= 0; end else begin a <= 0; b <= 0; c <= 1; end Note: the piece of code above is typically found in control modules, thus the designer knows what values each signal has to be in each case/if/else blocks. This problem will not usually occur if the only item in the sensitivity list for the always block is a clock signal. 5. Signal Assignment in Multiple ‘always’ Blocks
Multiple always blocks may not assign values to the same signal in the same time step.
This would result in the signal having an indeterminate value. FPGA express would
produce an “assignment in multiple always blocks” warning.
Incorrect:
always @ (posedge clk)
begin
a <= 1; b <= 0; end always @ (posedge clk or reset) begin a <= 0; // multiple assignment to signal a c <= 1; end Solutions: - Only one behavioral block can have an assignment to a signal. - The use of assign statements for combinational logic. Correct: always @ (posedge clk) begin a <= 1; b <= 0; end always @ (posedge clk or reset) begin c <= 1; end 6. Dangling Wires
Due to misspelling (very common!) or unused signals, there might be dangling wires in
the design. The synthesis tool might optimize these wires away. Further, due to the
recursive algorithm used to optimize the design synthesis, the logic inside the design
itself might get optimized away. When trying to do post-synthesis simulation, your
design will not generate correct results since part of the logic or even all the logic in the
design gets optimized away, in which case you are left with just input and output ports
with no logic in between.
Incorrect:
Module Incomplete (a, b, out);
input a;
input b;
output
out;
assign Out = a ? b : 1’b0; // output port out is not being driven here
endmodule
Solutions:
- Check for misspelling
- Check for dangling or unconnected wires
- Check for incorrect assignments (i.e. assigning to incorrect output
signal).
Correct:
Module Incomplete (a, b, out);
input a;
input b;
output out;
assign out = a ? b : 1’b0;
endmodule
References: (all reference material is linked from the class website at: http://www.cae.wisc.edu/~ece554/)
HDL Synthesis References (hardcopies available in the lab)
Verilog – FPGA Express Synthesis Reference:
http://www.cae.wisc.edu/~ece554/website/ToolDoc/FPGA_Express_3.6.1_docs/hdlref.pdf
VHDL – FPGA Express Synthesis Reference:
http://www.cae.wisc.edu/~ece554/website/ToolDoc/FPGA_Express_3.6.1_docs/vhdlref.pdf
Papers on Design Synthesis
SNUG 2000 (San Jose): Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!
SNUG 1999 (San Jose): RTL Coding Styles That Yield Simulation and Synthesis Mismatches
SNUG 1998 (San Jose): State Machine Coding Styles for Synthesis
The papers listed above can be found at: http://www.sunburst-design.com/papers/
implementation. This is not an exhaustive list, but it contains the most common problems
1. Incomplete Sensitivity List
When using an always statement to implement combinational logic, the sensitivity list
has to include all signals that appear on the right hand side of the assignments inside the
always block.
Incorrect:
always @ (a or b or c)
begin
x <= a + b; y <= b + c + d; // might cause latch inferred warning in FPGA // Express end Solutions: - Put signal d in the sensitivity list in the always statement - Use assign statement to implement combinational logic. Correct: always @ (a or b or c or d) begin x <= a + b; y <= b + c + d; end 2. The Use of ‘case’ vs. ‘if – else’ Statements
In general, case statements would translate to parallel muxes in hardware. Meanwhile, the
use of if – else statements results in priority-based hardware, which can slow down the
overall implementation of the design. Thus, only use if – else statement when priority-
based hardware is required. Otherwise, use case statements to avoid possible inefficient
implementation of the design.
While unlikely to produce incorrect outputs, the slowdown caused by large priority-based
implementations can cause problems for projects with strict clock frequency targets.
3. Incomplete ‘case’ Statement
To avoid problems with inferred latches, always specify all the possible cases in a case
statement.
Incorrect:
input [1:0] select
always @ (a or b or c or d or select)
begin
case (select)
0: x <= a; 1: x <= b; 2: x <= c; end // causes latch inferred warning in FPGA Express Solutions: - Completely specify the cases in the case statement - Always use default statement. Correct: input [1:0] select always @ (a or b or c or d or select) begin case (select) 0: x <= a; 1: x <= b; 2: x <= c; 3: x <= d; // complete cases based on the select signal default: x <= 1’bx; // add default statement to prevent unwanted // latches and/or aid debugging end 4. Unspecified Assignments in ‘case’ or ‘if – else’ Statements
Incorrect:
if (….)
begin
a <= 1; b <= 0; end // latch inferred for the signal c else if (….) begin a <= 0; end // latch inferred for the signal b else begin c <= 1; end // latch inferred for the signals a and b Solutions: - Always assign known values to all the signals in a case or if-else statements. Correct: if (….) begin a <= 1; b <= 0; c <= 0; end else if (….) begin a <= 0; b <= 0; c <= 0; end else begin a <= 0; b <= 0; c <= 1; end Note: the piece of code above is typically found in control modules, thus the designer knows what values each signal has to be in each case/if/else blocks. This problem will not usually occur if the only item in the sensitivity list for the always block is a clock signal. 5. Signal Assignment in Multiple ‘always’ Blocks
Multiple always blocks may not assign values to the same signal in the same time step.
This would result in the signal having an indeterminate value. FPGA express would
produce an “assignment in multiple always blocks” warning.
Incorrect:
always @ (posedge clk)
begin
a <= 1; b <= 0; end always @ (posedge clk or reset) begin a <= 0; // multiple assignment to signal a c <= 1; end Solutions: - Only one behavioral block can have an assignment to a signal. - The use of assign statements for combinational logic. Correct: always @ (posedge clk) begin a <= 1; b <= 0; end always @ (posedge clk or reset) begin c <= 1; end 6. Dangling Wires
Due to misspelling (very common!) or unused signals, there might be dangling wires in
the design. The synthesis tool might optimize these wires away. Further, due to the
recursive algorithm used to optimize the design synthesis, the logic inside the design
itself might get optimized away. When trying to do post-synthesis simulation, your
design will not generate correct results since part of the logic or even all the logic in the
design gets optimized away, in which case you are left with just input and output ports
with no logic in between.
Incorrect:
Module Incomplete (a, b, out);
input a;
input b;
output
out;
assign Out = a ? b : 1’b0; // output port out is not being driven here
endmodule
Solutions:
- Check for misspelling
- Check for dangling or unconnected wires
- Check for incorrect assignments (i.e. assigning to incorrect output
signal).
Correct:
Module Incomplete (a, b, out);
input a;
input b;
output out;
assign out = a ? b : 1’b0;
endmodule
References: (all reference material is linked from the class website at: http://www.cae.wisc.edu/~ece554/)
HDL Synthesis References (hardcopies available in the lab)
Verilog – FPGA Express Synthesis Reference:
http://www.cae.wisc.edu/~ece554/website/ToolDoc/FPGA_Express_3.6.1_docs/hdlref.pdf
VHDL – FPGA Express Synthesis Reference:
http://www.cae.wisc.edu/~ece554/website/ToolDoc/FPGA_Express_3.6.1_docs/vhdlref.pdf
Papers on Design Synthesis
SNUG 2000 (San Jose): Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!
SNUG 1999 (San Jose): RTL Coding Styles That Yield Simulation and Synthesis Mismatches
SNUG 1998 (San Jose): State Machine Coding Styles for Synthesis
The papers listed above can be found at: http://www.sunburst-design.com/papers/
Thursday, January 17, 2008
Purpose Of This Blog
Hi,
This is a blog about Design For Testability. It will contain information about DFT from various sources. Please feel free to leave any comments or send any new comments to the author for putting here.
Happy Designing!!!
This is a blog about Design For Testability. It will contain information about DFT from various sources. Please feel free to leave any comments or send any new comments to the author for putting here.
Happy Designing!!!
Subscribe to:
Posts (Atom)