AHB Slave VVC Implementation

Hello,

I’m in the process of implementing an AHB VVC with both master and slave support. When implementing the slave receive BFM procedure I mostly took inspiration from axistream_receive(). But this implementation starts from one transfer’s start request and this would not support pipelining over multiple transfers; having the AHB slave sample the next address while sampling the current request’s data, as the slave procedure is only executed when it’s called from the sequence.

Running multiple slave receive procedures for the same VVC does not seem to be the correct way to allow for pipelining, seeing as they would be blocking in the command queue.

It seems the correct functionality of a slave VVC would be to have the BFM always ready to receive data from the DUT, i.e. having a procedure that is running during the whole duration of the simulation. But I have not seen this kind of BFM procedure implementation in any of the already existing VVCs.

So my question is essentially what is the standard way to use slave VVCs, should they be able to constantly handle incoming requests over the duration of a simulation, or only when issued from the sequence? I feel like the first option reflects the protocol more realistically, but I also haven’t seen many examples of it being implemented this way.

Best regards,

Veronica

Hi Veronica,

Thanks for taking the initiative on this VVC. We truly appreciate all contributions from users who want to help expand and evolve the capabilities of UVVM.

To answer your question directly: the Slave VVCs we’ve built so far work by having the sequencer issue requests, not by continuously monitoring for incoming transactions. Email me at ks@emlogic.no and I’ll send you our upcoming Avalon MM Agent VVC so you can see how we handled it there.

That said, if you’ve got a proposal for a version that can handle incoming requests continuously, we’d definitely like to hear more. What use cases do you have in mind for this VVC?

Best regards,
Kim Spildrejorde
EmLogic