VERIFICATION ASYNCHRONOUS FIFO CUMMINGS

In reply to GiuseppeT:
You’re in the right direction. Some comments:

  1. Clocks and interface
    It is much more common to have the clock passes as an argument to the interface. It is very uncommon to have an interface just for the clock. Thus, do this instead:
interface write_if(input logic wclk);
logic winc;
logic [7:0] wdata;
endinterface
interface read_if(input logic rclk);
logic rinc;
logic [7:0] rdata;
endinterface
  1. class full_transaction;
    Looks ok. On situation, you may need to add an IDLE condition
    // typedef enum {RD, WR, RD_WR} situation;
  2. class full_generator; write_driver
    Looks OK. You have 2 mailboxes,and in main you put transactions. That is OK.
    However, in write_driver you declare another mailbox mailbox wgen2wdriv;, but I don’t see the connection between the mailbox in full_generator and the write_driver. Also, where is the call to the full_generator.main()?

I understand that it is partial code. You still need to add the scoreboard/monitor and verifier.
In my SVA book I wrote a model of a traffic light controller with East/West nd North/South lights for use in formal. My first attempt at the design was to have 2 separate control logic, one for each direction with the 2 controls talking to each other. I struggled making it work because I had issues wtht he synchronization between the two controls. I ended up with one master control directing the traffic between the 2 logic units (i.e., EW NS).
My point here is that I see the possibility of some difficulties in having 2 separate, non-coordinated transactions and monitor without good coordination. After all, if you want to do a write on full or read on empty, there’s got to be coordination in creating the full or empty conditions before exercising the test.
I would prefore ONE interface, ONE triver with separate tasks (1 for rd, 1 for wr), constrained randomization to create the end conditions.