Modelsim - same component names with different functionallity

[shaiko]

Hello,

I'm trying to run a Modelsim simulation of a project that consists of 2 separate FPGAs.

The top entity of FPGA A is called : a_top.
The top entity of FPGA B is called : b_top.

I've opened a Modelsim project and called it combined_tb.
My current problem:

Entity a_top has an inner component that's called: "uart"
Entity b_top also has an inner component that's called: "uart" - however, it's not the same file and not the same design as the "uart" of a_top.

How can I add both files to my Modelsim project without having a_top accidently use the "uart" design intended for "b_top" ?
Or b_top accidently use the "uart" design intended for "a_top" ?

The only solution I can think of is changing the name of both "uart" components to have a unique name - for example: "uart_of_a" / "uart_of_b". Any other suggestions?

 

[mrflibble]

Maybe put them in different libraries? Or maybe with the `uselib directive if you are using verilog.

Now that I think about it, probably using both. Compile the whole bunch into 2 different libs, and then at top level you only have to have 2 `uselib statements, one for each of your a_top and b_top. I never had to use it like you do, but I think the above has all the required parts to make it work...

 

[shaiko]

Maybe put them in different libraries?

Like: instead of simply "work" - compile them into: "work1" & "work2" for example?

 

[mrflibble]

Personally I would not name them work1 and work2. Something like "i" and "j" would be more appropriate according to some guidelines I came across the other day. XD

But yes, compile them into two libraries work_meaningful_name_for_design_a and work_meaningful_name_for_design_b. You can control that with the compile commands that already have been discussed in your other thread.

And then with `uselib you can select which one you want to give priority when resolving module instantiations.

 

[shaiko]

Thanks,
Can you post an example of how you meant I should use the uselib command ?

 

[mrflibble]

I'll get right on that after I finish this tea. As I said I have never needed this before, but I vaguely recalled uselib. And after checking the docs I think the above plan should work. But as said, tea first and then I'll make a toy example to test it. Because I'm curious as well.

 

[sharath666]

Why don't you rename the uart files as uart_a and uart_b? Wouldn't that would simplify matters?

 

[TrickyDicky]

Why don't you rename the uart files as uart_a and uart_b? Wouldn't that would simplify matters?

No use, as its the component name that's important, not the file name.

If possible, have them is separate libraries. But that might affect them if they both reference the work library, then this idea wont work. To get around this, you can use configurations, so you can map a component to a specified entity, but this will require you to use component declarations.

 

[sharath666]

I was suggesting to change the entity/module itself and not the file name. Sorry if my words misled you.
Looks like I am missing something. Otherwise this discussion would not have progressed so much...

 

[shaiko]

Why don't you rename the uart files as uart_a and uart_b? Wouldn't that would simplify matters?

The simplification has been done when I started this post to make things clearer...the real designs at question have around 25 components with different functionality but similar names - not just one.

 

[sharath666]

Sorry. Did not observe your last sentence in the first post.

 

[mrflibble]

Why don't you rename the uart files as uart_a and uart_b? Wouldn't that would simplify matters?

Nah. I get what he's doing, and renaming is a poor man's solution that you do not want. The renaming knee jerk reaction should really be removed from the human genome. ;-) Failing a world wide genome edit, best to keep that restricted to an office environment where pointey clickey busy work is more or less acceptable behavior. Lets not foul the engineering waters with it. ;-)

Anyways, finished my tea and got a working solution. It indeed is a collection of "stuff it in the right lib" and then do a `uselib.

Your compilation should look something like this:

# this goes into work lib as per the defaults
vlog -sv "../src/top_test.sv"

vlib design_a
# these two will end up in the design_a lib
vlog -sv  -work design_a  "../src/design_a/design_same_name.sv"
vlog -sv  -work design_a  "../src/design_a/uart.sv"

vlib design_b
# these two will end up in the design_b lib
vlog -sv  -work design_b  "../src/design_b/design_same_name.sv"
vlog -sv  -work design_b  "../src/design_b/uart.sv"

# Specify all libs you intend to use for this simulation
vsim -voptargs="+acc" -t 1ns -lib design_a -lib design_b -lib work work.top_test

And then top level module looks something like this:

---

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
module top_test;
    logic       clk;
    logic       rst;
    logic [7:0] in_a;
    logic [7:0] out_a;
    logic [7:0] in_b;
    logic [7:0] out_b;
 
    initial begin
        clk  = 0;
        rst  = 0;
        in_a = 0;
        in_b = 0;
    end
    
    `uselib lib=design_a
    design_same_name  from_design_a_inst (
            .clk (clk),
            .rst (rst),
            .in  (in_a),
            .out (out_a));
 
    
    `uselib lib=design_b
    design_same_name  from_design_b_inst (
            .clk (clk),
            .rst (rst),
            .in  (in_b),
            .out (out_b));
    
    always begin
        #50 clk <= ~clk; // 10 MHz clock
    end
 
endmodule // top_test

---

That works as intended. One word of caution regarding `fun_directive style directives. They tend to be global. I have not checked it yet, but my default assumption is that after this file has been parsed, every compilation unit that comes after it will essentially behave as if `uselib lib=design_b was used. This assumption may or may not be true (more docs required), but it is a good idea to keep this in mind. If you want to be on the safe side you can put `uselib lib=work near the end to reset things back to default. That way you make things less dependent on compile order (for simulation I mean).

Hope that helps...

 

[shaiko]

Thanks for your effort mrflibble - I really appreciate it!
The thing is - my Verilog is a bit rusty and your solution seems to be somewhat tricky...

For now, I'll just try to rename all modules and see how it goes.
Thanks again for the effort.

 

[mrflibble]

Thanks for your effort mrflibble - I really appreciate it!
The thing is - my Verilog is a bit rusty and your solution seems to be somewhat tricky...

For now, I'll just try to rename all modules and see how it goes.
Thanks again for the effort.

ROFL!! Love it! Get working solution and then use renaming anyways.

But it's all good, since your question was totally legit (just never needed it before) and now I have a solution for future cases.

Anyways, I suspect the VHDL equivalent of my proposed method also exist. You'll just have to wait for the vhdl posse to translate it. The compilation side I do know how to do a 1:1 translation. The `uselib I don't know. Just out of curiosity I'll google it, but after that you're on your own. ;-)

- - - Updated - - -

Yeah, something like this:

http://www.sigasi.com/content/use-and-library-vhdl

So you'd use the library and use directives. Just make sure you have a clearly defined scope where you dump the actual instantiation and job done.

- - - Updated - - -

No use, as its the component name that's important, not the file name.

If possible, have them is separate libraries. But that might affect them if they both reference the work library, then this idea wont work. To get around this, you can use configurations, so you can map a component to a specified entity, but this will require you to use component declarations.

I was just re-reading this to get a better idea how people using VHDL do this. And in verilog you also have the mapping / aliasing of entities (instantiations). But wouldn't that then require you to map every single module? That and with the library approach you get an easy to follow hierarchy basically for free.

 

[shaiko]

ROFL!! Love it! Get working solution and then use renaming anyways.

It took me forever to convince management that this type of simulation is absolutely necessary. I got an OK - under the term that it'll take < 2 days...so now, I can't afford any ventures.

I don't like it myself - but sometimes the "brute force" approach is the only viable option.

 

[mrflibble]

I would venture that doing it the right way the first time is not more expensive (in terms of time) than doing it the haphazard way. I mean, it took me 4 hours total elapsed time from start of problem definition to solution, and < 2 hours + some tea in terms of real work (mostly reading the docs). To be fair, I'd spend some more time before I would call this production ready, but the exact same thing would go for a renaming based solution...

Besides, management that you literally have to fight to get the right thing done ... that type of management deserves some feedback in the form of letting them have their way. Right after you document what would be the correct way + point out the risks of not doing it the correct way. I mean, you might learn something, or they might learn something. If management thinks you are being overly cautious, then maybe theirs is a good call. If however you turn out to be correct and the projects burns down to the ground 3 months later due to insufficient/incorrect testing, then you can point to your documented recommendations + risk assessment. Sometimes the only way people learn is through pain, so best make sure it's not your pain. ;-)

 

[shaiko]

I agree in spirit...but the fact is that sh*t ALWAYS rolls down hill - never up, it physics...

No matter how you play it - if it doesn't go smoothly as management planned it would (or better say: hallucinated) despire the warning, then there's always someone downhill.

I do my best so my educated opinion is heard upstairs - but it never helps saying: "I told you so".