An Appropriate Folder Structure for Combined Design and Verification Version Control

Hi
I have divided my RTL source files into two categories: IPs and Platforms. IPs are generalized modules that can be reused in different projects, for example, a parametrized sync_fifo_array. On the other hand, Platforms are single-purpose modules that use IPs as building blocks. For example, a Platform can consist of FIFO arrays, memories, a special encoder, or other IPs to have a specified functionality. This division is very similar to what we see in the UVMF folder structure: project_benches and verification_ip, where verification_ip are reusable source files and project_benches are test-specific files.
Now I have a question: I have generated some tests for my IPs and Platforms with UVMF or UVM. Some of my tests cover only one IP and other tests cover the whole Platform. Now if I want to add UVM or UVMF tests to my file repository, how can I combine the UVMF folder structure with my existing repository to guarantee reusability and compatibility?

In reply to mr.rahmani:

Greetings!

While the division of reusable UVMF blocks into the verification_ip folder and non-reusable source into project_benches is intentional and useful, the actual location of those directories is variable at the point in time when the source is generated. There are global generation options that allow you to change the default output directory from just “project_benches” to anything you want, likewise for “verification_ip” as well as the subdirectories beneath which currently default to “interface_packages” and “environment_packages”. If you modify these global variables then the location of the output as well as references to that output in both Makefiles and the BCR compile files will reflect the updates.

It is possible that you can use these options to have UVMF output generate in such a way as to be structured in an identical way to your existing repository.

Look into the UVMF Code Generator Manual for details, specifically the chapter titled “Global Data YAML Structure”.

If you prefer not to use the approach above, you can still simply move the UVMF source around in any way you desire (again, to match your existing non-UVMF structures) but you’ll have to manually update the Makefile references to these files and/or the associated BCR compile file references. Making changes by hand to the Makefile structure is sometimes not straightforward and may be problematic (I’ve found). Updating the BCR compile files is generally far more straightforward.