Skip to content

Latest commit

 

History

History

verification_area

Arithmetic Encoder - Verification

Introduction

  • The verification process is comprised by several .sv (SystemVerilog) files.
  • Each file has a specific purpose and targets the verification of a specific block of the architecture.
  • For blocks related directly to the AV1 codec functionality (i.e., stages 1--4), input datasets must be generated from the AV1 Reference Codebase using the entenc.c modified file.
  • Blocks that aren't related to the AV1 codec (i.e., (LZC.v) have their data randomly generated by the SystemVerilog testbench.

Files

The verification_area comprises several SystemVerilog files that allow different kinds of simulation.

Input Files

  • All testbenches rely on input data. Sometimes, the input data is randomly generated by the SystemVerilog code itself. However, offenly an input data is required so the testbench and validate the architecture under real world scenarios.

  • For all testbenches used to validate the architecture's modules (tb_1-bool.sv, tb_arith_encoder.sv or the individual pipeline stages) the input data can be easily generate using the AV1 Reference Codebase and the modified entenc.c. This execution will generate a .csv file that can be used to simulate the architecture using the testbenches. As one may notice, it'll indeed be necessary for the user to switch the filepaths inside the .sv files.

  • For testbenches used to validate components that aren't directly related to the AV1 codec (i.e., LZC or Vedic multiplier), the .sv testbenches will randomly generate input values so it can cover a greater area of the architecture and more accurately validate it.

How to generate the input file?

  1. Download the modified file of the AV1's entropy encoder, entenc.c;
  2. Download/clone the AV1's reference code;
  3. Copy and overwrite the file entenc.c modified into the folder aom/aom_dsp;
  4. Run any encoding process according to the procedure as specified in the AV1's website;
  5. After the encoding process is completed, access the folder arith_analysis created;
  6. The normal data sequence for the testbench is a file called main_data.

Observation

  • The herein cited testbenches were simulated until Altera ModelSim. Therefore, the use of other softwares might required some changes upon the .sv files, or even on the rtl files.

Modelsim Flow

  • Problem? Running simulation using the Altera Modelsim tool doesn't allow the use of different datasets. Hence, it was created the modelsim_flow.tcl script to solve this problem.
  • Easy to configure:
    1. Set the arc_version variable to define the waveforms to be added into the proper Modelsim window;
    2. If the testbench is set to generate VCD files for each simulation, set dump_vcd to 1. Otherwise, leave it 0;
    3. Take the corresponding testbench from testbenches and set the constant MODELSIM_FLOW to one. Change the DUMPFILE variable in the testbench according to step 2;
    4. Make sure TARGET_PATH in the testbench matches with target_path in modelsim_flow.tcl;
    5. Use the variable set_dataset in modelsim_flow.tcl or modify the if statement around line 40 to reflect your sequence directory. The script will read the directories according to the following path: cqs/configs/videos.
    6. As a follow-up for 5., set the final_bitstream and final_main in modelsim_flow.tcl to reflect the suffix used for the bitstream and main_data files for each video sequence.
    • The file with all inputs will be set to: ${videos}-${final_main}
    • The file with all outputs for verification will be set to: ${videos}-${final_bitstream}
    1. Make sure TARGET_MAIN and TARGET_BITSTREAM in the testbench match with ${target_name}-${final_main} and ${target_name}-${final_bitstream}, respectively, in the modelsim_flow.tcl.
  • Most of the above presented steps are just part of a check-list to ensure the correct execution of the flow.
  • The modelsim_flow.tcl relies on the idea of moving the datasets to an specific directory to be read by the testbench.
  • The execution loop is defined by:
    1. The flow moves each dataset (main_data and bitstream),
    2. Runs the simulation,
    3. Deletes the dataset, and
    4. Restarts with another video sequence.