SystemVerilog builds a test platform --- Chapter 1: Introduction to Verification (Continued)

I wanted to finish the introduction together in the first chapter, but I always felt that I still wanted to highlight some important concepts in a small form, so the following article is a continuation of the previous article.

1.6 Randomizing objects

For someone who is new to the field of verification, the so-called randomization is the data field , and this kind of incentive is the easiest to create - just call the $random() function. But the rewards of this random data in finding bugs are small. Vulnerabilities found using this random data are generally in the data path, and likely are also bit-level errors. In fact, we need to find some loopholes in the control logic. For example the following types:

• Device and Environment Configuration
  Many tests use designs that have only been reset or applied a fixed initial vector set to bring the design to a known state. In a real application environment, as the design time under test increases, its configuration will become more and more random. You should randomize the configuration of the entire environment, including the duration of the simulation, the number of devices, and how they are configured.
• Input Data
  When you see random stimulus, you might think of picking a bus write transaction or ATM cell and stuffing random values ​​into the data field.
• Protocol Exceptions, Errors, and Violations
  The most likely cause of a device crash is that a part of the logic inside the product cannot be recovered once it encounters an error, so the device cannot work properly. We just wanted to try to emulate the errors that might occur in real hardware as much as possible, try each of these situations, and then make sure that the device continues to function properly.
  Be careful to catch problems while trying to use inappropriate commands to activate the hardware.
• Latency and Synchronization
  A block of code may work fine for all possible stimuli from the same interface, but with multiple inputs at the same time, hidden vulnerabilities may arise.

• Parallel Random Testing
  Random testing consists of testbench code and random seeds. If you wanted to run the same test 50 times, each time with a different seed, you would get 50 different stimulus sets. Running the same test with multiple seeds increases coverage while reducing your workload.

  1.7 Functional Coverage

  Earlier we described how to create stimuli and use those stimuli to traverse the entire space of possible inputs. With this approach, your testbench will visit parts of the area frequently, but it will take a long time to reach all possible states. Even with no limit to simulation time, unreachable states are never accessed. At this time, we need to know which parts have been verified, so that we can check the projects in the verification plan.
  The measurement and use of functional coverage includes the following steps:
  (1) Add code to the test platform to monitor the stimulus entering the device and the response of the device to the stimulus, and determine which functions have been verified accordingly. .
  (2) Run the simulation several times, each time using a different seed.
  (3) Combine the results of these simulations into a report.
  (4) Analyze the results, and finally decide how to use new incentives to achieve those conditions and logic that have not been tested.

  1.7.1 Feedback from functional coverage to incentives

  Use random bus transactions and termination decisions.
• The longer the run, the higher the coverage.

• The flexibility to create incentives is high enough to deal with design changes.
  The idea behind this approach is to include a feedback loop in the test code that monitors the generated stimuli and adjusts the weights of constraints as appropriate. This approach greatly reduces the time to full coverage and requires very little manual intervention.

  1.8 Components of the test platform

  Here I give a block diagram, I hope I can have an in-depth understanding of this block diagram after this topic is updated.
  
  Let's take a basic transaction processor as an example, and the corresponding code mapped to SystemVerilog is as follows:

   task run();
      done=0;
      while(!done)
         begin
               //获取下一事务；
               //进行变换；
               //发送事务；
           end
    endtask

Summary: The first chapter introduces the framework of using SystemVerilog to build a test platform from a general outline. In order to have a deep understanding of it, further in-depth study is required.