In reply to dave_59:
Thanks for the reply.
Seems like there are at least 3 ways to try to make a generic/re-usable driver or monitor.
And I have seen and attempted to understand your (Dave’s) papers discussing abstract classes inside interfaces (…Outshine Virtual Interfaces), and factory pattern (the third being abstract class and extension). The paper which discusses factory pattern (…Yin and Yang…) indicates it is preferred over abstract class and extension.
Maybe there is some experienced based judgment for the choice of how to architect these classes.
Any guidance about which method would be better under what circumstances for a re-usable driver or monitor class?
- Factory Pattern (would be nice to see a complete example of a factory pattern for a driver
class which uses virtual interfaces w.o, UVM or OVM). - Abstract interface (classes inside the interface)
I understand that this has been hashed out in the UVM and OVM prior to that. Unfortunately my organization (and several others I know of have not adopted UVM). So that leaves some of us trying to figure out the best practices using what we have with SV 2012.
It seems like there is a potential paper somewhere “Making the best of SystemVerilog in 2018”