In reply to GiuseppeT:
Comments, blunt as they may be…
- Async vs Sync FIFO
my supervisor told me that an asynchronous FIFO might be more complicated than expected so he decided to a first cut of the TB by imagining that is SYNCHRONOUS. So basically the two clocks are equal right now or at least that’s how I am proceeding.
I disagree, the clocks don’t make that much difference. - Multiple interfaces
I have like 5 interfaces: Write_if, Read_if, Clock_if, OutputFlag_if and Internal_if (this last one should provide the WR_pointer and the RD_pointer to the DUT monitor)
Too complex. Adding interfaces does not make it easier. An interface is a container. The code can use what it needs from one container. - The verification approach
It seems that you want a uvm-like approach without the UVM. I believe your “supervisor” is your teacher or thesis advisor. He is misdirecting you into the correct approach.
If the gaol is UVM, you’re not doing that. This particular model can be verified with one simple module and some tasks. By that I mean the randomization or directed selection of the transaction to dermine the ‘kind’ of transaction to execute, and calls to wr task and rd task to drive the fifo that is instanced directly into the test module.
This chart is a high-level uvm concept. - This is a good vase for assertions in the interface and/or as a bind to the RTL.
You need to draw your approach before you build it. The model shows the interactions between the classes. I took an attempt at the mode to give you an idea as to what I meant.
best wishes to your success.
Ben