Introduction of Test Bench Development

1. Testbench
Development
Abhishek Tiwari
100942010
1

2. If we hear, we forget;
if we see, we remember;
if we do, we understand.
-Anonyms
2

3. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Unified Testbench.
• Testbench Components.
• Top-Down Vs Bottom-Up Approach.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 3

4. How we deal here?
WHAT ?
• What is Testbench ?
WHY ?
• Why we need Testbench ?
WHEN ?
• When we need Testbench ?
WHICH ?
• Which Factors to be considered ?
HOW ?
• How we can create Testbench ?
WHO ?
• Who develop Testbench ?
4

5. What is Testbench?
• A testbench is a virtual environment used to
verify the correctness of a design or model.
• A testbench provides several basic functions,
including creating and applying stimulus and
verifying the correct interfacing and responses.
• Developing a testbench environment is often
the single most important and time-consuming
task for an advanced verification team.
5

6. 6

7. 7

8. 8
Fig 1. Algorithmic Workbench

9. WHY we need Testbench?
• Simulation is by far the most prevalent technique used
in functional verification today.
• The ability to verify the ideas as well as the
implementation before a device is manufactured saves
a development team time and effort.
• To Simulate the MUT under a variety of test
conditions including correct and faulty test inputs.
9

10. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Top-Down Vs Bottom-Up Approach.
• Unified Testbench.
• Testbench Components.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 10

11. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Top-Down Vs Bottom-Up Approach.
• Unified Testbench.
• Testbench Components.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 11

12. Trade-Offs
• Testbench developers have been striving to meet the
goals of efficiency, reuse, and flexibility for many
years.
• Unfortunately, attaining these goals often makes
testbenches more complex to create and more difficult
to use.
• Every testbench developer must make a trade-off
between the time and effort to create and use the
testbench versus the potential gain from making the
testbench efficient, reusable, and flexible.
12

13. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Top-Down Vs Bottom-Up Approach.
• Unified Testbench.
• Testbench Components.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 13

14. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Top-Down Vs Bottom-Up Approach.
• Unified Testbench.
• Testbench Components.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 14

15. WHICH Factor to be considered?
• Teams should focus on three basic goals when
developing a testbench:
» Reusability.
» Efficiency.
» Flexibility.
15

16. Reusability
• To improve the reusability of a testbench, a developer should
focus on isolating the design-specific information in the
testbench and separating the functionality of the testbench.
• Knowing about the number of cycles after stimulus the
response appears, or observing internal design signals to help
predict the expected result, can simplify testbench creation.
• Most advanced verification teams find that small internal
blocks with nonstandard interfaces are the worst candidates for
reuse.
• Testbench reuse is most advantageous at the subsystem level,
where interfaces are more standard and the testbench
components more complex.
16

17. Efficiency
• To improve the efficiency of a testbench, a developer
should abstract design information to a higher level.
• The testbench should represent data and actions in a
format most easily understood by those using the
testbench.
• Low-level implementation details that are irrelevant to
the test should not be specified.
• Throughout the testbench, data should be captured
and compared at a higher level of abstraction to make
debug easier.
17

18. Flexibility
• The developers should focus on utilizing standard
interfaces to facilitate multiple different uses.
• Developers should not be trapped into using only
a limited set of options for tools and processes
associated with the testbench.
• Advanced verification teams develop their
testbenches independent of the tools or languages
used.
• The environment of the language used should not
dictate the architecture of the testbench.
• These teams make sure their testbench is adaptable
so that they can easily switch tools or technologies
without changing the testbench architecture. 18

19. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Top-Down Vs Bottom-Up Approach.
• Unified Testbench.
• Testbench Components.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 19

20. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Top-Down Vs Bottom-Up Approach.
• Unified Testbench.
• Testbench Components.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 20

21. Balancing practical Concerns
• Knowing the scope of the verification task
helps determine the size of the testbench and
the requirements for reuse and integration.
• The number of resources and the skill level of
the developers should be factored into how the
testbench will be implemented and how
complex it will be.
• The testbench developer also needs to know
how thoroughly the design needs to be tested
within the testbench environment.
• In general, a testbench should be a reflection of
the environment that the device will operate in.
21

22. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Top-Down Vs Bottom-Up Approach.
• Unified Testbench.
• Testbench Components.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 22

23. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Top-Down Vs Bottom-Up Approach.
• Unified Testbench.
• Testbench Components.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 23

24. Unified Testbench
• The development of a unified testbench is vital
to attaining the UVM goals of increased speed
and efficiency.
• Here, we describe a high-speed, reusable
testbench that meets the requirements of the
UVM.
• This Topic will Guide us to “HOW we develop
testbench?”.
24

25. Unified Verification Methodology
(UVM)
• UVM provides one of the most powerful set of
tools for a Verification Engineer
• UVM helps to remove dependency among
individual processes
• UVM promotes reuse of previous stages of the
process
25

26. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Unified Testbench.
• Testbench Components.
• Top-Down Vs Bottom-Up Approach.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 26

27. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Unified Testbench.
• Testbench Components.
• Top-Down Vs Bottom-Up Approach.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 27

28. Testbench Component
Unified Testbench
Structure
28

29. Stimulus Generators
• Stimulus generators create the data that
testbench uses to stimulate the design.
• Stimulus generators can create the data in a
preprocessing mode with custom scripts or
capture programs, or they can create the data
on-the-fly as the simulation occurs.
• Stimulus generators are usually classified by
the control the test writer exerts on the
generation of the stimulus.
29

30. Transactors
• Transactors change the levels of abstraction in a
testbench.
• The most common use is to translate from
implementation-level signaling to a higher level
transaction representation or the reverse.
• Transactors are placed in a testbench at the
interfaces of the design, providing a transaction-
level interface to the stimulus generators and the
response checkers.
• Transactors can behave as masters initiating
activity with the design, as slaves responding to
requests generated by the design, or as both a
master and a slave. 30

31. Continued…..
• The design of a transactor should be
application-independent to facilitate maximum
reuse.
• Also, when developing a transactor, the
designer should consider its use in a hardware
accelerator.
31

32. Interface Monitors
• Interface monitors check the correct signaling
and protocol of data transfers across design
interfaces.
• In some testbenches, interface monitors are
combined either with the transactors or with
the response checkers. Keeping interface
monitors separate from these components
allows for maximum reuse of the monitors.
• The interface monitors should be application-
independent and written in a manner that
allows their easy reuse in hardware
acceleration. 32

33. Response Checkers
• Response checkers verify that the data
responses received from the design are correct.
• Response checkers contain the most
application-specific information in the
testbench and usually can only be reused when
the block they are monitoring is being reused.
33

34. Continued………
• There are three basic types of response
checkers:
• Reference model response checkers apply the same
stimulus the design receives to a model of the design and
verify that the response is identical to the design.
• Scoreboard response checkers save the data as it is
received by the design and monitor the translations made
to the data as it passes through the design.
• Performance response checkers monitor the data flowing
into and out of the design and verify that the correct
functional responses are being maintained. These
checkers verify characteristic of the response rather than
the details of the response.
34

35. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Unified Testbench.
• Testbench Components.
• Top-Down Vs Bottom-Up Approach.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 35

36. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Unified Testbench.
• Testbench Components.
• Top-Down Vs Bottom-Up Approach.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 36

37. Top-Down Testbench
Development
• Teams believe it is best to develop a testbench from the
highest level of the hierarchy and derive the testbenches
for each lower level from the higher levels.
• The top-down approach is usually most applicable to
teams that are using a system model in their verification
environment.
• The top-down approach is beneficial when the design
requires integrating software or analog/RF domains at
the system level.
• The top-down approach offers greater benefits if the
development team has a separate verification team to
write tests and develop the testbench in parallel with the
implementation of the design.
• The subsystem team develops the tests, which are
verified in the testbench by substituting the FVP TLM
for the implementation until it is available. 37

38. Continued…….
• The top-down approach fully utilizes reusable
testbench components.
• Often designers want to verify at the lowest
unit level as they develop individual modules.
• This creates the fastest and most efficient
debugging and integration flow.
• A testbench developed from a top-down
system model requires more maintenance to
keep the model and testbench up-to-date with
the design.
38

39. Top-Down Reuse of Testbench Components
39

40. Bottom-Up Testbench Development
• Some teams believe that it makes most sense to start at the
lowest level of hierarchy and develop the testbench to first
verify the units or blocks that make up the design.
• The bottom-up approach is usually used by teams that only
have a written specification.
• Often designers want to verify at the lowest unit level as they
develop individual modules.
• The verification of these units uses simple methods applying
stimulus vectors and waveform inspection or application-
specific environments.
• A bottom-up approach requires less knowledge of complex
verification, such as system model development and reuse.
• The flow reuses testbench components from the lower levels
as the design is integrated and tested.
40

41. Bottom-Up Reuse of Testbench Component
41

42. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Unified Testbench.
• Testbench Components.
• Top-Down Vs Bottom-Up Approach.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 42

43. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Unified Testbench.
• Testbench Components.
• Top-Down Vs Bottom-Up Approach.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 43

44. VERIFICATION TESTS
• Many verification teams separate the creation
of the testbench from the creation of the test
stimulus, because the two tasks are very
different and require different skills.
• The two basic types of tests written today are
• Directed Test
• Random Test
44

45. Directed Tests
• Directed tests specify the exact type and
sequence of stimulus to provide to the design.
• A directed test tests a specific function in a
consistent, thorough, and predictable way.
• Using directed tests, you can incrementally test
function after function and build up a thorough
regression suite that can be used to reverify
that function if the design changes.
• The disadvantages of directed tests are that
they require detailed knowledge of the design
being tested and are often very difficult to set
up.
45

46. Continued……
• The time required to write these tests might not
be feasible for the development schedule.
• There are several types of directed tests :-
• Interface test.
• Stress test.
• Feature test.
• Error test.
Recoverable error test.
Non-recoverable error test.
• Performance test.
46

47. Random Test
• Random tests allow for the automatic creation of many
cycles of stimulus with limited knowledge of the design
required.
• Random tests automatically select part or all of the
information for the test, including type, sequence, and
timing of the stimulus.
• One random test can verify many functions, so fewer
random tests are required than directed tests.
• The disadvantage of random tests is that it is difficult to
know what the random test has verified.
• Even if you can determine which functions have been
verified, it is often difficult to consistently repeat the test
for regression purposes.
• Very difficult to debug.
• Most advanced verification teams use a combination of
random and directed tests. 47

48. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Unified Testbench.
• Testbench Components.
• Top-Down Vs Bottom-Up Approach.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 48

49. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Unified Testbench.
• Testbench Components.
• Top-Down Vs Bottom-Up Approach.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 49

50. Testbench Requirement
• The testbench must be self-checking.
• The testbench needs to be able to check the
responses as they occur so that the test can be
stopped when an error occurs.
• The stimulus generator must provide an
efficient interface for the random tests
• In the most simple form, a test might only need
to specify how long to run, and the stimulus
generator generates data based on the default
constraints.
• The complexity in a constrained random test is
not in the test but in the testbench.
50

51. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Unified Testbench.
• Testbench Components.
• Top-Down Vs Bottom-Up Approach.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 51

52. Areas to be covered
• What is Testbench and its Need?
• Different Trade-Offs.
• Reusability, Efficiency, Flexibility.
• Balancing Practical Concerns.
• Unified Testbench.
• Testbench Components.
• Top-Down Vs Bottom-Up Approach.
• Testbench Development.
• Verification Tests.
• Test bench Requirements. 52

53. WHO writes Testbench?
• Usually a testbench is developed by a few
engineers who are highly skilled at developing
complex code and systems.
53

54. Conclusion
• Simulation is by far the most prevalent technique
used in functional verification today.(Answer To
WHEN we need Testbench).
• The ability to verify the ideas as well as the
implementation before a device is manufactured
saves a development team time and effort.
• There are various approaches to develop a
reusable, flexible and efficient testbench.
• Simulate the MUT under a variety of test
conditions including correct and faulty test inputs.
• Tests should be developed to verify the
functionality of the system completely.
54

55. Reference
• Professional verification by PAUL WILCOX
Cadence Design Systems, Inc.
• Writing Testbenches—Functional Verification
of HDL Models, :By Bergeron, Janick. 2nd ed.
Boston.
Internet sources
• www.testbenchpro.com
• Wikipedia .
• YouTube.
55

56. Abbreviations
• FVM :- Functional Virtual Prototype.
• UVM:- Unified Verification Methodology.
• TLM:- Transaction-level model.
• SoC:- System on Chip.
56

57. 57

58. 58