Visible to Intel only — GUID: bhc1411020523630
Ixiasoft
Visible to Intel only — GUID: bhc1411020523630
Ixiasoft
A.2.6. Constrained Random Test
Randomized video, control, and user packets are generated using the SystemVerilog’s built-in constrained random features. The DUT processes the video packets and the scoreboard determines a test pass or fail result.
test.sv comprises the following code sections:
Declaration | Description |
---|---|
1 Object Declarations | |
|
Declare some objects to be used later in the test. Notice that the number of pixels in parallel is not needed in these definitions as that is abstracted away from the user and handled via the classes in av_st_video_source_bfm_class.sv and av_st_video_sink_bfm_class.sv. Note that the video item class is the base class, so could hold objects of any of the more specialized classes, such as control or video data. |
2 Mailbox Declarations | Description |
|
The bfm_drivers.sv file contains mailbox declarations required for transmission and receipt of video packets, but the test harness requires a mailbox for the scoreboard. It is declared in line 27 and constructed at time zero in line 35. |
3 Start the Source and Sink BFMs | Description |
|
The source and sink BFMs must be started. Once started, the source will wait for objects for sending to be pushed into its mailbox whilst the sink will push objects into its mailbox when one is received from the DUT. |
4 Stimulus—Start Producing Control and Video Packets | Description |
|
In the main loop calls are made to the tasks in class_library/tasks.sv to produce randomly sized control packets with matching video packets. |
4 Packet Checker—Checking Produced Control and Video Packets Against the Scoreboard | Description |
|
The corresponding loop to the stimulus loop is the checker code. This polls the sink’s mailbox for video items, categorizes according to type and to which packet type is expected, compares video packets to those previously input and then marks the packet as pass or fail accordingly. Line 161 shows that the checker loop runs until twice the input frame count has been seen (control plus video packet per input frame) and uses the try_get() call on the sink mailbox in line 166 to check for DUT packets. |
|
Once the packet type is determined (lines 174-179) it is cast to an object of the corresponding type (see line 181). As earlier described, in testbench/nios2_control_model.sv, the Mixer II is set up to offset the output video from the frame buffer by zero pixels for constrained random testing, so line 184 below shows that we expect to see one frame of test pattern (while the frame buffer receives and buffers the first input frame) followed by the video packets. The code from lines 195-205 iterates through every item in the scoreboard, casting to a video packet type as required, before comparing to the DUT video packet in line 200 (using the built-in silent_compare method from class_library/av_st_video_classes, which does not generate output if the packets do not match). A flag is set if a match is found and the scoreboard packet is pushed onto a temporary mailbox store. After the search, all scoreboard packets are popped off the temporary store ready for comparing with subsequent video frames. Control packets are compared against a golden one in a similar way. |