Test Bench Development

4,707 views

Published on

Introduction of Test Bench Development

2 Comments
11 Likes
Statistics
Notes
No Downloads
Views
Total views
4,707
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
0
Comments
2
Likes
11
Embeds 0
No embeds

No notes for slide

Test Bench Development

  1. 1. TestbenchDevelopmentAbhishek Tiwari 100942010 1
  2. 2. If we hear, we forget;if we see, we remember;if we do, we understand. -Anonyms 2
  3. 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. 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. 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. 6
  7. 7. 7
  8. 8. 8Fig 1. Algorithmic Workbench
  9. 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. 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. 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. 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. 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. 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. 15. WHICH Factor to be considered?• Teams should focus on three basic goals when developing a testbench: » Reusability. » Efficiency. » Flexibility. 15
  16. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 28. Testbench Component Unified Testbench Structure 28
  29. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 39. Top-Down Reuse of Testbench Components 39
  40. 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. 41. Bottom-Up Reuse of Testbench Component 41
  42. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 56. Abbreviations• FVM :- Functional Virtual Prototype.• UVM:- Unified Verification Methodology.• TLM:- Transaction-level model.• SoC:- System on Chip. 56
  57. 57. 57
  58. 58. 58

×