# Multiple VVCs question (1 testbench, 1 test harness, 1 test sequencer process?)

**URL:** <https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212>\
**Category:** VVC Framework\
**Created:** [June 4, 2021, 2:35pm UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212 "2021-06-04T14:35:14Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![KevNug](https://avatars.discourse-cdn.com/v4/letter/k/cdc98d/32.png) [@KevNug](https://forum.uvvm.org/u/KevNug)\
**Post date:** [June 4, 2021, 2:35pm UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/1 "2021-06-04T14:35:15Z")

</div>

Hi Marius,

The FPGA has different modules which require to be verified in Simulation.

Currently using UVVM & building the BFMs / VVCs to verify different individual FPGA modules. Using at the moment 1 testbench (TB instantiates 1 test harness, a clock generator and a Test Sequencer process) & 1 test harness (Test harness instantiates uvvm\_engine, 1 DUT and 1 VVC related to the DUT)

Is it better to instantiate the clock generator within the testbench or test harness? I currently have it instantiated within the testbench. If in the testbench, can use potentially the same clock generator clocking to different harnesses (if more than 1 harness is the preferable choice). But each time clocking the clock generator it will delay the other DUT module unit and it will be tested eg one clock cycle later (via the one Test Sequencer process that resides in the single TB). Any comments here will be appreciated.

So far I used 1 VVC instantiated within the test harness and 1 DUT. VVC was developed to verify the specific DUT.

Within the test harness can we instantiate all the VVCs + different DUTs or do we need a different test harness per related VVCs/DUT ?  
What about the testbench? Different one per related test harness/VVCs/DUT too?

Reason for asking is because I currently have 2 small VHDL modules (ie 2 different DUTs within the FPGA) which I developed BFMs & VVCs for them. Verified in simulation one of them using UVVM VVC platform scripts. Currently developing the platform for the other one.

Can I use 1 common testbench for both of them and 1 separate test harness (ie 2 instances within the testbench) for each related DUT/VVCs and use the same ie 1 test sequencer process of the TB to execute the various commands?

Your prompt reply to this matter will be appreciated.

Kind regards,  
Kevin

---

<div class="post-metadata">

**Author:** ![KevNug](https://avatars.discourse-cdn.com/v4/letter/k/cdc98d/32.png) [@KevNug](https://forum.uvvm.org/u/KevNug)\
**Post date:** [June 6, 2021, 10:05pm UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/2 "2021-06-06T22:05:39Z")

</div>

Hi Marius,

I did not receive a reply to the above yet. It could be due to the weekend involved.

Can we use a common testbench (ie 1 testbench) for both DUTs? Do we require to use 2 different test harnesses (ie 2 different test harness instantiations within the testbench) for verifying the 2 different DUTs together with 1 testbench? Is this the right flow?

or do we just need to create 1 testbench / 1 test harness / 1 Test Sequencer per DUT or place all the DUTs, VVCs instances in 1 test harness (that uses 1 testbench)?

→ So far seen that can simulate standalone both DUTs with 1 testbench and 1 test harness each independently.

What is the flow/method of simulating 2 different FPGA internal modules together in UVVM VVC?

Can you please explain / clarify this?

* * *

I tried to use 1 common testbench, 2 test harnesses wrt 2 different related DUTs/VVCs. Don’t know if this method is the right one to follow…

The 2 different DUTs are eg ‘clockcyclecounter’ & ‘checkstable’.

The python script generated the same .vhd names for the following:  
vvc\_cmd\_pkg.vhd  
vvc\_context.vhd  
vvc\_methods\_pkg.vhd

The other 2 names were unique: (xx represents either ‘clockcyclecounter’ or ‘checkstable’ names)  
xx\_bfm\_pkg.vhd  
xx\_vvc.vhd

I updated then the template files for both DUTs. Simulated standalone the 1st one the Counter one (clockcyclecounter) and works ok. Simulated the 2nd one (checkstable) with just checkstable\_reset procedure added. That was ok standalone. So standalone I had 1 testbench and 1 testharness for each DUT/VVCs.

Main aim with this combined 1 testbench method is to see if 1 testbench can call individually the VVC commands for each DUT.

However, experienced complilation issues and decided to the compile then for each DUT all relevant following files in a different -work xxx library:

xx\_bfm\_pkg.vhd  
xx\_vvc\_cmd\_pkg.vhd  
td\_target\_support\_pkg.vhd  
vvc\_methods\_pkg.vhd  
td\_queue\_pkg.vhd  
td\_vvc\_framework\_common\_methods\_pkg.vhd  
td\_vvc\_entity\_support\_pkg.vhd  
xx\_vvc.vhd  
vvc\_context.vhd  
xx\_vvc\_th.vhd (test harness)

For the combined 1 testbench tried to compile this to the work library (ie -work work)  
combined\_tb.vhd (combined testbench)

I still get lots of compilation errors at the moment:

eg \*\* Error: ../../tb/Combined\_tb.vhd(104): (vcom-1078) Identifier “C\_CLK\_PERIOD” is not directly visible.

# Potentially visible declarations are:

# user\_checkstable.checkstable\_bfm\_pkg.C\_CLK\_PERIOD at ../../checkStable/src/checkstable\_bfm\_pkg.vhd(23) (constant)

# user\_clockcyclecounter.clockcyclecounter\_bfm\_pkg.C\_CLK\_PERIOD at ../../ClockCycleCounter/src/clockcyclecounter\_bfm\_pkg.vhd(29) (constant)

Line 104:  
i\_clock\_generator\_vvc : entity bitvis\_vip\_clock\_generator.clock\_generator\_vvc  
generic map(  
GC\_INSTANCE\_IDX =\> C\_CLOCK\_GEN,  
GC\_CLOCK\_NAME =\> “Clock”,  
GC\_CLOCK\_PERIOD =\> C\_CLK\_PERIOD, ← line 103  
GC\_CLOCK\_HIGH\_TIME =\> C\_CLK\_PERIOD / 2 ← line 104  
)  
port map(  
clk =\> in\_clock  
);

Line 103 reported same error.

:::

\*\* Error: ../../tb/Combined\_tb.vhd(138): (vcom-1600) No feasible entries for subprogram “set\_clock\_high\_time”

line 138:  
set\_clock\_high\_time(CLOCK\_GENERATOR\_VVCT, 1, C\_CLK\_PERIOD/2, “Changing the duty cycle to 50%”, C\_SCOPE);

# Visible subprograms are:

# (explicit) vvc\_methods\_pkg.set\_clock\_high\_time[bitvis\_vip\_clock\_generator.td\_target\_support\_pkg.t\_vvc\_target\_record, INTEGER, std.STANDARD.TIME, std.STANDARD.STRING, std.STANDARD.STRING] at ../../bitvis\_vip\_clock\_generator/

Awaiting for your reply to this matter.

Kind regards,  
Kevin

---

<div class="post-metadata">

**Author:** ![Marius](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.uvvm.org/marius/32/43_2.png) [@Marius](https://forum.uvvm.org/u/Marius)\
**Post date:** [June 7, 2021, 7:47am UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/3 "2021-06-07T07:47:12Z")

</div>

Hi Kevin,

I would use the Clock Generator VVC to run the clock and put this in the test harness, while controlling it from the test sequencer. You should have all you test components inside the test harness, so for different test cases you only switch which testbench, i.e. test sequencer, to run. So, for 10 test cases you will typically have 10 testbenches/sequencers, and only 1 test harness that will have all the VVCs and the DUT.  
When you have more than one DUT you can:

1. Have a single test harness with both DUTs, but with different Clock Generator VVC instences to run their clocks or individual resets to prevent both DUTs from running at the same time, or
2. Have multiple test harnesses, one for each DUT.

It depends on the complexity of your design, how related the two DUTs are etc, but I would probably have gone for number 1.

For the error you are receiving for the C\_CLOCK\_PERIOD is because there are two constants with the C\_CLOCK\_PERIOD name that are visible from combined\_tb.vhd. One is in there checkstable\_bfm\_pkg and one is in the clockcyclecounter\_bfm\_pkg. You should only have one, and it should be defined in the testbench or test harness. You can set the BFM config record with the clock period using the  
`shared_<VVC_NAME>_vvc_config(<VVC_INSTANCE_NUMBER).bfm_config.<BFM_CONFIG_PARAMETER> := <CONFIG_PARAMETER_VALUE>;`  
in the beginning of your test sequencer, after

```auto
await_uvvm_initialization(VOID);

```

Passing the C\_CLOCK\_PERIOD constant value from the testbench to test harness can be done by port mapping in the test harness entity.

Br,  
Marius

---

<div class="post-metadata">

**Author:** ![KevNug](https://avatars.discourse-cdn.com/v4/letter/k/cdc98d/32.png) [@KevNug](https://forum.uvvm.org/u/KevNug)\
**Post date:** [June 7, 2021, 9:06am UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/4 "2021-06-07T09:06:35Z")

</div>

Hi Marius,

Thanks for your reply.

So planning to move then the clock generator in the test harness and control it from the test sequencer process of the specific testbench. Each DUT will have its own VVC (eg clockcyclecounter\_vvc) generating the reset to that specific DUT (ie clockcyclecounter).

So you recommend to have different Testbenches / process Sequencers. For each test case have it’s own testbench that instantiates the same test harness (that contains all VVC’s and all DUT’s instances + 1 UVVM engine instance). Please re-confirm.

So if this is the case then the test harness will get updated each time by adding new DUT & VVC instances within it & the new DUT’s / VVC’s get verified by a separate testbench (that instantiates the same updated version of the test harness for all DUT’s/VVC’s within it). Is this the case?

You mention that it depends on the complexity of the design, how related the 2 DUTs are etc. But your suggestion was to go for the 1st option (ie 1 test harness instantiating all DUTs & VVCs). The issue I see here if 1 test harness is used it’s portmap list will increase with time propagating signals to the corresponding top-level testbench. If specific test harness signals of a specific DUT are not related then could have an issue with the separate testbenches having to initialize within them any unwanted top level test harness input signals. Isn’t this the case? I don’t mind doing this if it be easier to do.

Before I attempt to try this option1, like your further comments please on this matter.

Kind regards,  
Kevin

---

<div class="post-metadata">

**Author:** ![Marius](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.uvvm.org/marius/32/43_2.png) [@Marius](https://forum.uvvm.org/u/Marius)\
**Post date:** [June 7, 2021, 10:00am UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/5 "2021-06-07T10:00:06Z")

</div>

Hi,  
Yes, I think I would go for option 1, but option 2 is also a fair choice.  
Which signals do you want to access from the sequencer? Normally the signals from the DUT are connected to the BFMs, and then also to the VVCs, and any timing checkers etc would be in the test harness. Should you need access to test harness signals from the sequencer you could always do

```auto
alias signal_name is <<signal path_name : signal_type>>;

```

Br,  
Marius

---

<div class="post-metadata">

**Author:** ![KevNug](https://avatars.discourse-cdn.com/v4/letter/k/cdc98d/32.png) [@KevNug](https://forum.uvvm.org/u/KevNug)\
**Post date:** [June 9, 2021, 4:12pm UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/6 "2021-06-09T16:12:13Z")

</div>

Hi Marius,

After talking to one of my team members yesterday he suggested using 1 main testbench with 1 test sequencer process (within it) executing all commands for the entire FPGA UVVM VVC verification platform so no multiple testbenches/sequencers.

Each main sub-block of the FPGA will have its own Test harness and within each test harness we will have all the related main sub-block DUT / VVC instances, clock & reset generation, ti\_uvvm\_engine.

Is this flow ok? What is your opinion on this matter?

Kind regards,

Kevin

---

<div class="post-metadata">

**Author:** ![KevNug](https://avatars.discourse-cdn.com/v4/letter/k/cdc98d/32.png) [@KevNug](https://forum.uvvm.org/u/KevNug)\
**Post date:** [June 9, 2021, 4:34pm UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/7 "2021-06-09T16:34:14Z")

</div>

Hi Marius,

Another important query I have wrt UVVM architecture with multiple FPGA VCC’s / DUT’s.

When I created from Python the vvc templates for one DUT created the following files:  
• \<dut\_name\>\_bfm\_pkg.vhd  
• \<dut\_name\>\_vvc.vhd

• transaction\_pkg.vhd (extra file generated when extended UVVM features is enabled)  
• vvc\_cmd\_pkg.vhd  
• vvc\_context.vhd  
• vvc\_methods\_pkg.vhd

First 2 look unique FPGA submodule DUT ones.

If multiple DUTs are used related to the same FPGA sub\_module, the last 4 files listed above will they be regarded as common ones for all FPGA sub-modules because they don’t start with \<dut\_name\>\_ extension?

If yes, do you advise placing these in a top-level common\_src directory to be updated accordingly by all FPGA submodules or each FPGA submodule should have these last 4 files included?

I believe that the last 4 files listed above should be in a top-level common\_src directory for access to all FPGA submodules and updated with the relevant info for all the DUT VCCs. Isn’t this the case?

Your prompt reply to this matter will be appreciated.

Kind regards,  
Kevin

---

<div class="post-metadata">

**Author:** ![Marius](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.uvvm.org/marius/32/43_2.png) [@Marius](https://forum.uvvm.org/u/Marius)\
**Post date:** [June 10, 2021, 7:31am UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/8 "2021-06-10T07:31:24Z")

</div>

Hi,  
All files generated by the vvc\_generator script are for that VVC only. If you have more than one DUT, but with the same interface, you will use that VVC to interface with the DUTs from the tests.  
The following files belong to one single VVC and should be compiled to a unique library for that VVC:

- \<interface\_name\>\_bfm\_pkg.vhd
- \<interface\_name\>\_vvc.vhd
- vvc\_cmd\_pkg.vhd
- vvc\_context.vhd
- vvc\_methods\_pkg.vhd

When you use a VVC in a testbench/environment you will import that library (e.g. \<interface\_name\>\_vvc\_lib) and the required files:

- library \<interface\_name\>\_vvc\_lib;
- use \<interface\_name\>\_vvc\_lib.vvc\_methods\_pkg.all;
- use \<interface\_name\>\_vvc\_lib.td\_vvc\_framework\_common\_methods\_pkg.all;

or use the context file:

- library \<interface\_name\>\_vvc\_lib;
- context \<interface\_name\>\_vvc\_lib.vvc\_context;

Br,  
Marius

---

<div class="post-metadata">

**Author:** ![KevNug](https://avatars.discourse-cdn.com/v4/letter/k/cdc98d/32.png) [@KevNug](https://forum.uvvm.org/u/KevNug)\
**Post date:** [June 10, 2021, 1:15pm UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/9 "2021-06-10T13:15:28Z")

</div>

Hi Marius,

When I generated the VVC templates for the eg clockcyclecounter the vvc\_content.vhd listed eg

library bitvis\_vip\_clockcyclecounter;  
use bitvis\_vip\_clockcyclecounter.transaction\_pkg.all;  
use bitvis\_vip\_clockcyclecounter.vvc\_methods\_pkg.all;  
::

So the library I must use will be bitvis\_vip\_clockcyclecounter and not clockcyclecounter\_vvc\_lib

& in the testbench if I use the VCC I could then declare at the top as:

library bitvis\_vip\_clockcyclecounter;  
context bitvis\_vip\_clockcyclecounter.vvc\_context;

My script here works fine when I do this change …

Please comment here.

Regards,  
Kevin

---

<div class="post-metadata">

**Author:** ![KevNug](https://avatars.discourse-cdn.com/v4/letter/k/cdc98d/32.png) [@KevNug](https://forum.uvvm.org/u/KevNug)\
**Post date:** [June 10, 2021, 1:58pm UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/10 "2021-06-10T13:58:06Z")

</div>

Hi Marius,

Another matter. the clockcountercycle VVC related file showed ‘work’ library within it eg vvc\_cmd\_pkg.vhd included within it:

– Removed  
–use work.transaction\_pkg.all;

– Replaced  
library bitvis\_vip\_clockcyclecounter;  
context bitvis\_vip\_clockcyclecounter.vvc\_context;

& within the package:

– Removed  
–alias t\_operation is work.transaction\_pkg.t\_operation;

– Replaced  
alias t\_operation is bitvis\_vip\_clockcyclecounter.transaction\_pkg.t\_operation;

Is this correct to what I removed & replaced ?  
Thought I do not have to touch these template files wrt declaration of libraries

Can I leave all those with ‘work’ as they were before?

–

When I tried above changes, observed compilation issues so put them back to ‘work.xx’ as it was before:

vvc\_cmd\_pkg.vhd was left as:

```
use work.transaction_pkg.all;

```

& within the package:

```
alias t_operation is work.transaction_pkg.t_operation;
:::

```

Script with ‘work.xx’ declared as shown in the above example works ok…

Regards,  
Kevin

---

<div class="post-metadata">

**Author:** ![Marius](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.uvvm.org/marius/32/43_2.png) [@Marius](https://forum.uvvm.org/u/Marius)\
**Post date:** [June 10, 2021, 5:25pm UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/11 "2021-06-10T17:25:34Z")

</div>

Hi,  
That is correct - your VVCs will expect to be compiled to a library in the form "bitvis\_vip\_\<interface\_name\>, and in your design it will be “bitvis\_vip\_clockcyclecounter”. And in your TB you will use this library name.

For your 2nd question - no, do not make any changes to the use statements nor the use clauses in the VVC files. Library work will be a reference to working library in the VVC files, and in your case this will be bitvis\_vip\_clockcyclecounter. Your changes will work, but the VVCs works as is when generated from the vvc\_generator script, and making other changes than required will increase the chances of creating a bug/error.

Br,  
Marius

---

<div class="post-metadata">

**Author:** ![KevNug](https://avatars.discourse-cdn.com/v4/letter/k/cdc98d/32.png) [@KevNug](https://forum.uvvm.org/u/KevNug)\
**Post date:** [June 11, 2021, 4:10pm UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/12 "2021-06-11T16:10:26Z")

</div>

Hi Marius,

So if we have different VVCs for different interfaces you listed above the 5 unique files per VVC that should be compiled to their unique library. That includes the transaction\_pkg.vhd (if Extended UVVM Features’ option is enabled).

So the following 4 files are not common to all FPGA VVCs if they come with different DUT interfaces:

- vvc\_cmd\_pkg.vhd
- vvc\_context.vhd
- vvc\_methods\_pkg.vhd
- transaction\_pkg.vhd

And if the VVCs come with the same interface all the above 4 files including the 2 following VVCs

- \<interface\_name\>\_bfm\_pkg.vhd
- \<interface\_name\>\_vvc.vhd

should be placed in a separate related VVC directory.

Please re-confirm all above. It is important because my colleagues were informing me that these (ie above first 4 .vhd files listed) should be common files for the entire FPGA.

They will be only common files for related VVCs if they belong to the same interface of the DUTs (as you state in your above msg) & thus we can use these 4 common extra files for the related DUTs. Please re-confirm.

The names of the 4 files are common ie same names to all VVCs. The thing that makes them unique wrt the DUTs with same interface is where that VVC gets compiled into and they are placed in different directories (if this is right wrt one of my above queries). Is this the case? Please confirm

Kind regards,  
Kevin

---

<div class="post-metadata">

**Author:** ![KevNug](https://avatars.discourse-cdn.com/v4/letter/k/cdc98d/32.png) [@KevNug](https://forum.uvvm.org/u/KevNug)\
**Post date:** [June 11, 2021, 4:20pm UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/13 "2021-06-11T16:20:01Z")

</div>

Thank you for confirming my previous msg 🙂

Will appreciate a reply to my last today’s message too. Thanks…

---

<div class="post-metadata">

**Author:** ![KevNug](https://avatars.discourse-cdn.com/v4/letter/k/cdc98d/32.png) [@KevNug](https://forum.uvvm.org/u/KevNug)\
**Post date:** [June 11, 2021, 4:43pm UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/14 "2021-06-11T16:43:36Z")

</div>

> [@KevNug](#):
>
> Hi Marius,
> 
> After talking to one of my team members yesterday he suggested using 1 main testbench with 1 test sequencer process (within it) executing all commands for the entire FPGA UVVM VVC verification platform so no multiple testbenches/sequencers.
> 
> Each main sub-block of the FPGA will have its own Test harness and within each test harness we will have all the related main sub-block DUT / VVC instances, clock & reset generation, ti\_uvvm\_engine.
> 
> Is this flow ok? What is your opinion on this matter?
> 
> Kind regards,
> 
> Kevin

Hi Marius,

Can you please comment here too wrt the above email posted 2 days ago?  
Thanks.

Regards,  
Kevin

---

<div class="post-metadata">

**Author:** ![KevNug](https://avatars.discourse-cdn.com/v4/letter/k/cdc98d/32.png) [@KevNug](https://forum.uvvm.org/u/KevNug)\
**Post date:** [June 11, 2021, 4:45pm UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/15 "2021-06-11T16:45:37Z")

</div>

> [@KevNug](#):
>
> Will appreciate a reply to my last today’s message too. Thanks…

Will appreciate a reply to my latest today’s message too. Thanks…

---

<div class="post-metadata">

**Author:** ![KevNug](https://avatars.discourse-cdn.com/v4/letter/k/cdc98d/32.png) [@KevNug](https://forum.uvvm.org/u/KevNug)\
**Post date:** [June 13, 2021, 10:10am UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/16 "2021-06-13T10:10:30Z")

</div>

Hi Marius,

Just edited in **bold** my previous message for clarity to the queries raised.  
Will appreciate your response to this matter because will have to inform my team about it, if it is as I describe below.

Thanks.  
Kevin

> [@KevNug](#):
>
> So if we have different VVCs for different interfaces you listed above the 5 unique files per VVC that should be compiled to their unique library. That includes the transaction\_pkg.vhd (if Extended UVVM Features’ option is enabled).
> 
> So the following 4 files are not common to all FPGA VVCs if they come with different DUT interfaces:
> 
> **vvc\_cmd\_pkg.vhd**  
> **vvc\_context.vhd**  
> **vvc\_methods\_pkg.vhd**  
> **transaction\_pkg.vhd**
> 
> **If on the other hand** the VVCs come with the same interface all the above 4 files including the 2 following VVCs
> 
> \<interface\_name\>\_bfm\_pkg.vhd  
> \<interface\_name\>\_vvc.vhd
> 
> should **be all placed in one** related VVC directory **with a unique VVC directory name.**
> 
> Please re-confirm all above. It is important because my colleagues were informing me that these **(ie above first 4 bolted .vhd files listed)** should be common files for the entire FPGA. **I don’t think this is correct.**
> 
> They will be only common files for related VVCs if they belong to the same interface of the DUTs (as you stated in your above msg) & thus we can use these **4 above bolted** common extra files for **each** related DUTs **together with the \_bfm\_pkg.vhd & \_vvc.vhd**. Please re-confirm.
> 
> The names **of the 4 above bolted files** are common ie same names to all VVCs. The thing that makes them unique wrt the DUTs with same interface is where that VVC gets compiled into and they are all ( **ie all 6 of them above** ) placed in a separate VVC directory (if this is **correct** wrt one of my above queries). Is this the case? Please confirm

---

<div class="post-metadata">

**Author:** ![Marius](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.uvvm.org/marius/32/43_2.png) [@Marius](https://forum.uvvm.org/u/Marius)\
**Post date:** [June 13, 2021, 5:34pm UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/17 "2021-06-13T17:34:23Z")

</div>

Hi Kevin,  
The files generated from vvc\_generator.py belongs to 1 VVC and its instances only. If you for some reason create several VVCs, and after editing the generated files the vvc\_cmd\_pkg/vvc\_context/vvc\_methods\_pkg/transaction\_pkg contains the same information, it is a big chance you only needed 1 VVC in the first place. So, generate the VVCs (interfaces) you will need to verify your DUT(s) and keep all the files generated for each VVC separate from other VVCs - and compile them to their own libraries. Have a look at the VVCs that we have shipped with UVVM - the files are kept separate.

For your other question - I would have used multiple testbenches/sequencers, but I guess you have a good reason for putting all in one. Tests that can and/or need be tested separately should be tested in individual testcases. How you structure your testcases can be a matter of taste, but I like to have one test sequencer for each testcase. The test sequencer will issue VVC commands towards the DUT, but if you have changed the test harness to have a DUT with a different interface and VVC in another testcase, this will result in VVC commands that have no VVC and no DUT - i.e. creating an error.  
The only solution I can think of is if you structuring your tests like this inside a single test sequencer is by using a generic on the TB entity that selects which test to run, and putting each testcase inside procedures which will be selected by an if-statement inside the test sequencer, based on the TB entity generic value.  
E.g.  
GC\_TESTCASE : integer := 0;

… p\_sequencer: process()

procedure testcase1(…testcase 1 code…)  
prosedure testcase2(…testcase 2 code…) and so on

begin  
if GC\_TESTCASE = ‘1’ then  
testcase1();  
elsif GC\_TESTCASE = ‘2’ then  
testcase2();  
… and so on

Br,  
Marius

---

<div class="post-metadata">

**Author:** ![KevNug](https://avatars.discourse-cdn.com/v4/letter/k/cdc98d/32.png) [@KevNug](https://forum.uvvm.org/u/KevNug)\
**Post date:** [June 15, 2021, 1:13pm UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/18 "2021-06-15T13:13:19Z")

</div>

Hi Marius,

Thanks for your replies so far. I have another query.

I am looking now into incorporating 2 VVCs into the my UVVM VVC testbench environment and using 1 Testbench (1 Test Sequencer). Each VVC in this instance has its own test harness because they are 2 separate DUTs and their interfaces are different.

I created a separate directory to where I include all 6 below related VVC .vhd files:

vvc\_cmd\_pkg.vhd  
vvc\_context.vhd  
vvc\_methods\_pkg.vhd  
transaction\_pkg.vhd  
\<interface\_name\>\_bfm\_pkg.vhd  
\<interface\_name\>\_vvc.vhd

In my current flow, I noticed that there were also 4 other following uvvm\_vvc\_framework .vhd target dependent package files that had to be compliled too:

**td\_target\_support\_pkg.vhd**  
**td\_vvc\_framework\_common\_methods\_pkg.vhd**  
**td\_queue\_pkg.vhd**  
**td\_vvc\_entity\_support\_pkg.vhd**

Currently the above 4 **bolted** files I was compiling them into work library. I will need to change the work library here to the specific VVC one to where the other 1st 6 above .vhd files were compiled.

So, the 4 above **bolted** td\_\* files are intended also to be compiled into each VVC, providing supporting datatypes and methods for the UVVM VVC Framework. Please confirm.

Seen also the following statement within the VC\_Framework\_Manual.pdf (pg.20):

"3. ‘VVC FRAMEWORK target dependent packages’  
Functionality that is common for all (or most) VVCs, but is dependent on VVC dedicated definitions/declarations.

- Such packages are located under the UVVM\_VVC\_Framework directory as their contents are common, but they are compiled into VVC libraries as they depend on other compiled packages in their respective VVC library.
- Shown in Figure 9 as orange – to indicate that the packages are located under UVVM\_VVC\_Framework, but compiled into a dedicated VV "

Kind regards,  
Kevin

---

<div class="post-metadata">

**Author:** ![KevNug](https://avatars.discourse-cdn.com/v4/letter/k/cdc98d/32.png) [@KevNug](https://forum.uvvm.org/u/KevNug)\
**Post date:** [June 15, 2021, 1:34pm UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/19 "2021-06-15T13:34:38Z")

</div>

Hi Marius,

My UVVM Framework environment will have multiple test harnesses and 1 testbench as stated in one of my previous emails. My choice was to use multiple testbenches but the team asked me to stick to 1 testbench / multiple test harnesses which I am currently doing.

My other query now is related to the different test harnesses and the single Testbench.

Where do you suggest compiling each test harness .vhd file? To a new library eg adc\_work, i2c\_work etc? And the test harness name for the related VVCs should have a unique name that relates to those VVCs eg adc\_vvc\_th.vhd, i2c\_vvc\_th.vhd etc. Is this the case?

Also, the testbench that instantiates all test harnesses and includes 1 test sequencer. What library will be best to use to compile the testbench to? work library?

Your reply to this matter too will be appreciated.

Kind regards,  
Kevin

---

<div class="post-metadata">

**Author:** ![Marius](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.uvvm.org/marius/32/43_2.png) [@Marius](https://forum.uvvm.org/u/Marius)\
**Post date:** [June 15, 2021, 5:51pm UTC](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212/20 "2021-06-15T17:51:04Z")

</div>

Hi Kevin,  
The 4 **td\_** files will have to be compiled into the same libraries as the VVCs. You can see the compile order in e.g. bitvis\_vip\_sbi/doc/sbi\_vvc\_qr.pdf - final page.

Br,  
Marius

[Next page](https://forum.uvvm.org/t/multiple-vvcs-question-1-testbench-1-test-harness-1-test-sequencer-process/212.md?page=2)