Predictors

UVM
1

I have a block-level environment for a “comp-A”. It has a scoreboard, which contains a predictor and a comparator.
The comp-A predictor is a model of the comp-A DUT.
The environment connects to the DUT via interfaces/agents.
Pretty standard so far…

I would like to now create a chip environment. The chip contains a state-machine, and 4 comp-A. The chip has a control interface (CIF) which is used to send commands to the state-machine, and the state-machine responds via a data interface (DIF).

Naturally, I pull in 4 copies of the comp-A environment into my chip environment, and connect all their agents to the appropriate interfaces. Super!

*** Here comes the confusing part!!! ***
I need to create a scoreboard for the chip. The predictor (aka transfer function, aka model) in the scoreboard should essentially be a functional model of the chip.
Here is an example: the chip predictor receives a “STATUS” request over the CIF. It must then gather up 4 statuses, one from each comp-A, and return this data over the DIF. How does it gather these status words? The comp-A predictors are driven entirely by interfaces/pin-wiggles!

If that was too confusing to make sense of, perhaps answer this; is a chip level predictor/scoreboard supposed to interact with block-level predictor/scoreboards?

2

In reply to bmorris:

I believe the weakness of your approach is you are using a pinlevel predictor/reference model.
Using a transaction-level model gives you a lot more freedom and functionality to handle your problem.

3

In reply to chr_sue:

I was a little unclear in my wording. All of my predictors are transaction-based models written in SV. My point was that bus activity (picked up by monitors) is the sole driver for the predictors; the predictors do not receive information from other IP, such as a different predictor via analysis port, etc.

If my predictors cannot talk to each other, to whom should by chip level predictor communicate with as it attempts to gather status information block level components?

4

In reply to bmorris:

I’m not sure what kind of information you want to exchange. If you are looking only for activity you could use one of the synchronisation mechanisms UVM is providing (barriers, events etc.)
If you want to exchange data you have to implemen TLM connections.

5

In reply to chr_sue:

Perhaps this example can help illustrate. The chip contains:

  1. state machine
  2. comp-A

When the chip predictor (aka the state machine) receives a “status” command, it needs to read a comp-A status register.

Available options:

  1. Chip-predictor access the comp-A predictor using a handle; read status directly.
  2. Chip-predictor access the comp-A predictor using TLM; send a “read” transaction to the predictor.
  3. Ignore the comp-A predictor; use RAL to grab the DUT register information directly from comp-A.

Option 2 doesn’t make sense, personally; the comp-A predictor already has TLM connections from the block-level agents.

6

In reply to bmorris:

You are adding step-by-step additional information to the story.
I understood the status will be stored in a register. Then in my eyes a RAL in the chip env makes really sense and would be the most easy way.