I am integrating a component environment into an integration level environment, and never having done it before, it feels very clunky. Is this discussed in detail in a paper or book somewhere? It’s certainly not as simple as “dropping it in”. There are interfaces to plug into the DUT, place virtual Ifs into the DB, configure the component environment configuration object, set up test parameter knobs to configure the config object, set these up in the script, make sure you include all the component SV files in the compilation, etc…
Perhaps some of you have tips to make the process a little easier.
For example, do you compile the test package for the component? I don’t, but I essentially wanted to repeat a test I performed at a component level at the integration level. So, I had to copy the test… change a few sequencer paths, and I was good to go.
This may just be something that needs to be done to fully understand, which I intend to to, just wanted any feedback or tips.
Besides the component environment…
Do you include the test package for the component?
Do you include the sequence package for the component?
My approach is that I have a test sequence library that I use for the component which I can re-use for the system level environment. The component level tests will only start one test sequence. Since the component level tests will create the environment, I can’t re-use them at the system level.
However, well written component level test sequences which contain sequencer handles can be re-used at the system level. To re-use these test sequences, the system level test will create the component level test sequence, assign the appropriate sequencer handles, then start the sequence.
When integrating multiple component-level environments, multiple component-level test sequences can be started in parallel.
At the integration level, what are your thoughts on the coverage collectors and checkers for the component environment(s)? Do you disable those blocks, and focus on the integration level coverage/checking? Or, do you just leave all coverage and checking activated? I suppose if you turned off all the component coverage/checking, it’s like the environment isn’t doing anything for you at that point…
I leave all of the component-level coverage and checkers active as I consider them an important part of the system-level testing. There will be additional coverage collectors, checkers and scoreboards created that are required for the system-level testing.
There are two areas to work on: one is the testbench and another one ist the reuse of tests and sequences.
Migrating blocklevel environments into a toplevel environment is quite easy and straight forward.
One question you have to decide is whether you want to integrate really the environments or only the agents. Both approaches are possible. In my projects I reuse the agents. In my eyes it is more easy. This requires only a new toplevel env with all the agents you need inside. This is one file to create. Then you have to adopt the toplevel module to pass all interfaces to the virtual interfaces, connect the DUT and implement all clock gens you need.
I’m not following; what about the component level coverage collectors & checkers? Also, this approach makes you simply copy and paste the agents into the integration level environment.
The question is how you are dealing with coverage collectors and checkers on block-level. The UVM User Guide does not say where to place the coverage blocks for instance. In my personal practice I have the coverage collectors related to a certain interface in the agent, i.e. an agent consists of a sequencer/driver pair and a monitor/coverage collector pair. I do this this way because I want to know what was stimulated by the local sequences. Checkers are mostly assertion checkers and scorboards. Assertion checkers are instantiated in the top level module of the block level testbench. They have to be moved to the toplevel module of the toplevel testbench.
Scoreboars are a little bit more tricky. They are application dependent. But you might have in the toplevel env main-scoreboard consisting of scorboards checking blocklevel behavior.