Consider a design with two IP cores ip1.v
and ip2.v
that each declare a (different) module with the same name.
For example, the contents of ip1.v
:
module ip1 (input A, B, C, output X);
wire T;
mygate gate_0 (.I0(A), .I1(B), .O(T));
mygate gate_1 (.I0(T), .I1(C), .O(X));
endmodule
module mygate (input I0, I1, output O);
assign O = I0 & I1;
endmodule
And the contents of ip2.v
:
module ip2 (input A, B, C, output X);
wire T;
mygate gate_0 (.I0(A), .I1(B), .O(T));
mygate gate_1 (.I0(T), .I1(C), .O(X));
endmodule
module mygate (input I0, I1, output O);
assign O = I0 | I1;
endmodule
And then a top module that uses both IP cores (top.v
):
module top (input A, B, C, output X, Y);
ip1 ip1_inst (.A(A), .B(B), .C(C), .X(X));
ip2 ip2_inst (.A(A), .B(B), .C(C), .X(Y));
endmodule
How can I process a design like that so that each IP cores sees it's own version of mygate
?
For situations like this it is necessary to read and elaborate the two IP cores as separate designs and then link it all together by "importing" the two designs for the individual IP cores into the top-level design:
# Read IP core 1
read_verilog ip1.v
hierarchy -top ip1
design -stash ip1
# Read IP core 2
read_verilog ip2.v
hierarchy -top ip2
design -stash ip2
# Read top level and link design
read_verilog top.v
design -import ip1
design -import ip2
synth -top top
The command design -import ip1
will import the modules ip1
and mygate
from the ip1
design, but it will rename mygate
into ip1.mygate
. Similarly design -import ip1
will rename mygate
from ip2
to ip2.mygate
.