In reply to withankitgarg:
While it's true that you can do the job without using a register abstraction layer, this doesn't mean you won't benefit from using one. What it provides is a nice way of centralizing all register verification aspects, such as applying stimulus, checking and collecting coverage.
Let's go through your questions one by one.
1. Using hierarchical paths isn't directly possible from packages, so you won't be able to use sequences or the such to do it.
2. I don't really get what you mean by this one. How long a transaction takes isn't a function of the way you insert it, but a function of the DUT you verify. Of course they're going to take the same amount of time.
3. If you don't write this code, you're going to have to write your sequences in such a way as to avoid magic numbers (address 0x1234 or whatever where some important register is mapped).
4. You can do this only with sequences, but you won't benefit from automated checks by having a register model.
5. Why should there changes need to be made in the register model? It's completely agnostic of the bus you access your registers.
6. Because the same register could be mapped at different addresses when accessing it through different interfaces. No one is stopping you from using the same address map for multiple interfaces if that's not the case.
7. Checks for registers are already provided by the register model. I don't see why there would be two scoreboards. You would have different coverage classes, but that's not a big deal, since you're just moving aspects from one to the other.
8. I'm pretty sure that row/column address come from one "big" address, because from a programmer's point of view, RAM is mapped as contiguous locations each with its own address (and not as a matrix).
