A new challenge for the startups working on AI-generated UVM testbenches

One of the startups working in the AI for Verilog area contacted me with the proposal to test their tool which generates a UVM testbench for a given RTL block. My response:

I can review your results if you use your tool to rewrite my non-UVM AXI Verification IP example to UVM:

https://github.com/verilog-meetup/non-uvm-axi-lite-verification-ip/tree/main/08_axi_master_slave_monitor/50_axi_pipelined_wr_out_of_order_rd

The description is here:

https://github.com/verilog-meetup/non-uvm-axi-lite-verification-ip/blob/main/08_axi_master_slave_monitor/50_axi_pipelined_wr_out_of_order_rd/axi_transaction.sv

Note the generated testbench should support:

1. In-order pipelining for the write transactions.

2. Cases of write address before write data, address and data in the same cycle, and data before address.

3. Out-of-order read response based on read tag.

I am not interested in APB-style sequential one-at-a-time transactions (I saw it in a demo of another AI for Verilog startup). The testbench should handle multiple transactions in flight as I described above.

I expect the solution to include at least:

1. A BFM (Bus Functional Model) driver with the functionality on par with the following, but using UVM means to process the transactions. It should handle pipelining, out-of-order, different timing of address vs data (address before data, address after data), different variants of valid/ready handshake (ready default high or low, following AMBA AXI rules from AXI4 spec):

https://github.com/verilog-meetup/non-uvm-axi-lite-verification-ip/blob/main/08_axi_master_slave_monitor/50_axi_pipelined_wr_out_of_order_rd/axi_master.sv

2. A testbench with UVM sequences covering at least the scenarios in the file below. I am not interested in an unconstrained random-only testbench which another “AI for Verilog” developer showed to me recently. See the direct test scenarios here:

https://github.com/verilog-meetup/non-uvm-axi-lite-verification-ip/blob/main/08_axi_master_slave_monitor/50_axi_pipelined_wr_out_of_order_rd/axi_testbench.sv

3. You can use the following reference slave as DUT (Design Under Test), but you need to implement from scratch the monitor agent:

https://github.com/verilog-meetup/non-uvm-axi-lite-verification-ip/blob/main/08_axi_master_slave_monitor/50_axi_pipelined_wr_out_of_order_rd/axi_slave.sv

Before I review the code, I need to see a simulation log demonstrating that the testbench covered pipelined and out-of-order scenarios. Specifically:

1. Multiple write addresses before multiple write data:

2. Write data before write address:

3. Out-of-order read data with ID tags:

Thank you,
Yuri Panchul