[dv,usbdev] Failing USBDEV block-level DV tests

[alees24]

Description

This issue exists to collect and track failing USBDEV block-level DV tests:

• [ ] usbdev_csr_bit_bash - "(usb20_driver.sv:282) [uvm_test_top.env.m_usb20_agent.driver] timeout waiting for usb_pullup" (Agent should surely not be active during this test; CSR traffic was still ongoing)
• [ ] usbdev_pkt_received - fails, suspect seed-dependent. "UVM_ERROR @ 8382223854 ps: (usbdev_pkt_received_vseq.sv:66) [uvm_test_top.env.virtual_sequencer.usbdev_pkt_received_vseq] Check failed pkt_received == 1 (0 [0x0] vs 1 [0x1])" Example seed 1 ('--fixed-seed 1' to dvsim, '+ntb_random_seed=1' to vcs-generated executable
• [ ] usbdev_enable - "UVM_ERROR @ 8352057670 ps: (usbdev_enable_vseq.sv:49) [uvm_test_top.env.virtual_sequencer.usbdev_enable_vseq] Check failed pkt_received == 1 (0 [0x0] vs 1 [0x1])" Example seed 1 ('--fixed-seed 1' to dvsim, '+ntb_random_seed=1' to vcs-generated executable
• [ ] usbdev_smoke - seed-dependent failure; "Too many events in simulation cycle"; simulation time not advancing, and test killed due to timeout
• [ ] usbdev_intr_test - failing because of interrupt type change to Status; cip_base_vseq requires modifications, affecting multiple IP blocks
• [ ] usbdev_csr_mem_rw_with_rand_reset - "UVM_ERROR @ 407997277 ps: (cip_base_vseq.sv:756) [uvm_test_top.env.virtual_sequencer.usbdev_common_vseq] Check failed (!has_outstanding_access()) Outstanding access never cleared to allow us to reset."

A number of other tests are failing because '...it is not registered with the factor' and are expected to be resolved following review and merge.

@jdonjdon, @rswarbrick, @Saad22386, @MubashirSaleem775

[MubashirSaleem775]

We have proactively addressed the issues encountered in our developed tests by implementing necessary changes. We have submitted multiple pull requests to address the DV environment modifications in the first PR and the sequence adjustments mentioned earlier in the second PR. I have attached the details for your review. Kindly merge them to resolve these failures. Thank you."

1. 2.

[MubashirSaleem775]

@alees24 @rswarbrick Can you please look into this. So that we can add more PRs after this get merged.

[rswarbrick]

Hi @MubashirSaleem775,

Yes, I think we're planning to look at this in the coming week. It's a bit concerning that we're still writing new vseqs when some tests fail. At a quick glance, one problem seems to be that the driver is reactive and depends on the USB device being enabled. This isn't true for some sequences, which lock up.

If someone on the Imparé side could try running these sequences and figuring out what's going wrong, that would be fantastic. Otherwise, I guess that either @alees24 or I are going to have to get things sorted out.

[alees24]

All extant tests passing.