UVM - Layered Test bench Architecture

Layered Testbench Architecture:

  • Structured test benches are important for complex DUT Verification:
    • Better maintainability
    • Better reusability
    • Parallel development and verification
Traditional Test bench:
FIG: Traditional test bench flow.
  • DUT (Design Under Test) needs to be verified.
  • Stimulus: Contains test along with a driver that can drive all our stimulus to the design.
  • Slave: Synchs all the output from DUT.
  • Checker/Scoreboard: Taps into the driver or some of the interface signals, checks if behaviour of the design is correct.
Architecture Partition:

  • The figure above shows how a traditional test bench is partitioned or structured into layers.
  • Layer 1 - DUT: Lower layer since it specifies the interfaces.
  • Layer 2 - Driver-Monitor-Responder: Above DUT, to understand signal level information, interact with DUT.
  • Layer 3 - Stimulus generator or controller or coverage component or scoreboard or slave: Don't really communicate with the pins.

  • Bottom layer - Pin level interface.
  • Next layer abstracts to transactions, communications, classes or objects.
  • All further layers above work on transactions.
Benefits of Layered Test benches:
  • Overhead in initial architecture and development but comes with several benefits.
  • Better Maintainability:
    • Only lower layer components need to change based on design
    • Higher layer components can be coded and maintained by separate teams.
  • Better Re-use - vertically and horizontally:
    • Multiple components can be reused from unit level to chip level verification environment and maybe to emulation/silicon testing
    • Reusable across projects and organizations.
FIG: OVM Testbench Architecture layers
  • Transactors: Components that converts a stream of transaction to pin level interface and vice versa.
    • These are basically Monitors: 
      • Passive components that watch the pin toggle and convert them to a stream of transactions.
    • Drivers:
      • Converts a stream of transactions to pin level activity. Stimulus generator can pass on transactions or class objects to the driver which without worrying about the pin level info, can convert into the actual stimulus to be driven to the DUT.
    • Respondent:
      • Similar to a driver but responds to an activity rather than initiating activity. Monitor pin level information and respond to the DUT.
  • Operational Components: Transactional components that provide everything needed for DUT to operate.
    • Stimulus Generator:
      • Creates stream of transactions to stimulus the DUT. Can be random, directed or pseudo-random.
    • Master:
      • Bi-directional component taht can send requests and can receive responses.
    • Slave:
      • Bi-directional component that responds to requests by returning with responses.
  • Analysis components: Receive information about activities in the testbench and use that information for determination of correctness or completion.
    • Scoreboards:
      • They receive information about what is going into and out of the DUT and analyze those for the correctness of DUT (ensure).
    • Coverage collector:
      • Count streams of transactions and different aspects to transactions and help in determining the completeness of verification.
  • Controller components: Controller forms the main thread of the test.
    • They receive and send information from various testbench components to control the test.
    • They control the start and stop of stimulus generator, how long a test should run, etc.