In reply to Tudor Timi:
Bear in mind a scoreboard is just a comparator - what you compare is up to you. A predictor may suit or perhaps interface equivalence checking is all you need.
Over the years i have found that scoreboard architectures have adapted to the dut. E.g. i was once looking at a abstracted memory controller with 100's of ports. I could have created a huge scoreboard, but in this case lots of little ones server the purpose with greater reuse. I have also had scoreboards with lots of analysis ports (mostly analysis fifos to decouple data from the monitors) juggling lots of comparisons
I have always found that a significant amount of scoreboard time is spent decomposing and reforming sequence_items into a common format. Some times this has been an independent easily comparable format, other times i have used the do_compare() from one of the sequence_items.
Register models are a curious case because of the UVM format used to update the register model - in this scenario my predictor and adaptors are always housed with the rest of my UVC components, well away from the scoreboard.
My answer follows your initial train of thought. Either create a configurable predictor for all DUT modes or create multiple predictors dependent on the mode of the DUT you wish to replicate. Where you put the analysis port is up to you. If you want to reuse the predictor then perhaps multiple predictors is best and allow the scoreboard to route the incoming data?
I assume your "configuration" interface is trivial enough that your could create a uvm_monitor or route the sequence_items direct from the driver. This then leads onto if you are verifying how the DUT responds to silly things on the "configuration" interface.
