I have a design with two top-level modules, these two tops are used based on the memory model i choose (whether it is a single or dual port memory)
my question isas follows : in my top level testbench ,can I instantiate the two modules in the same file or should I create a top testbench for each of the modules ?
Same question for the system verilog interfaces , can I define two interfaces in the same file or not?
You do not provide enough information to give you a correct advice.
The number of modules in a file doe’t matter. But you can have also more than 1 DUT module in the toplevel module.
Hello thank you for your answer.
I’ll try to detail more : so basically in my design I have the two following verilog files : “memory_rw.v” for single core memory (holding memory_rw top level module ) and an other file called “memory_2rw.v” which holds the memory_2rw module.
as I said these two are two independent top level modules that I need to verify.
my question is about how to verify them in my testbench : should I instantiate both modules in a single testbench module or should I create two different top testbench modules in for each .
same question for the DUT interfaces.
Normally independent designs have independent test benches. This is so they can provide independent stimulus and end the test when needed. Even if the stimulus is the same, uou probably want to stop a test as soon as one of the designs fails so that you don’t waste CPU time in simulation.
It is not of interest which files do you have. Important is only which kind of pinlevel interfaces you have.
It might be a solution to differentiate between the single-port RAM and the dual-port solution using macros when the functional interfaces are the same.
But you could also create 2 UVM environments reusing the agents from the single-port approach in the dual-port solution.
Hello Thank you for your replies.
indeed my memory wrapper IP which holds these two top level modules ( single and dual port memories ) have almost the same pinlevel interfaces except the memory signals which are addr, wr_en; rd_en; wdata; rdata in case of single port mem while for the dual port memory design we have the same signal but twice for each port A & B (addr_a ,addr_b ,wr_en_a,wr_en_b etc…)
I have already built the uvm environment for my memory wrapper but for now it supports only the single port memory model and I really don’t want to duplicate all of the components ( agent , scoreboard etc ) I have already created.
I just want to find a way to make the actual testbench used to verify both designs, is that feasible ?
There is still not enough information available to answer this question.
Which interface protocoll is used in the DUTs? Is it all the same or do you have differnt functional (pinlevel) interfaces?
Can you share the DUT interfaces please?
yes as I said in my previous reply Only the name of the module and the memory ports are different ( mem_* I/O ). All other features are identical (APB, Power, BIST, Redundancy, etc.)
below you can see both interfaces, I hope I provided all the needed infos
interface memory_wrapper_rw_if#(
parameter MODE = “ASIC” ,
parameter MEM_NB_WORDS = 32 ,
parameter MEM_SIZE_WORDS = 8 ,
parameter APB_ADDR_WIDTH = 6 ,
parameter ENABLE_ECC = 0 ,
parameter ENABLE_APB = 1 ,
parameter ENABLE_LATCH = 0 ,
parameter ASIC_ENABLE_BIST = 1 ,
we distinguish 1R1W 2P memories ( but it is not a dual port mem as we can not perform for example 2 write Operations simultaneously in both ports) and 2RW DP memories.
Anyway thanks for your help so far , I’ll try to figure it out myself as I don’t think that we are converging as my question is not related to how many clocks or resets I have.
my question is a general one and I wanted to know what is the best practice when we have such design with many top level modules with some common pins.
The problem is never related to the number of clocks or resets, but it is related to the functional interfaces and how they are working together.
In your case it looks like you have APB bus-based interfaces for the memory access.
And you have 2 access methods:
(1) exclusive read and write
(2) concurrent read and write.
In the UVM you can do anything. The question is whether you are limiting the (re-)usability of your architecture by packing to much functionality into the resulting environment.