module multiplier(
input clk,
input [15:0] a,
input [15:0] b,
output reg [31:0] p
);
reg [31:0] in;
always@(posedge clk) begin
p <= a*b*in;
in <= in+1;
end
multi_test mu(
.clk(clk),
.in(in[15:0])
);
endmodule
hi above is a demo for my problem,,,,"in" output of multi_test , i must used in two places like above (its demo).. but when i synthesize it , its throwing an error "in" must be a wire. but if i declare it as a wire i cant use it inside always block.
how to solve this?
did anybody came across this issue before ,any help is really appreciated
how to assign the value of wire to a reg?
UPDATE ..............................................
now i am doing like below
Code:
reg [31:0] in2;
always@(posedge clk) begin
in2 =in;
end
I think a and b default to wire types since they are not explicitly defined as reg. However your output p is of type reg.
In the operation shown above you are mixing the types.
[Synth 8-685] variable 'in' should not be used in output port connection ["/home/dipin/development/multi_test/multi_test/multi_test.srcs/sources_1/new/multiplier.v":41]
so above code will work fine right,,little changes from FvM's code
is there any way to assign in to in2 immediately like blocking assignments or "assign" statement " (i need to synthesize it )
You aren't thinking about what your description (HDL) represents when it's supposed to be synthesized to hardware (HDL).
Here is what you are describing in your code...
That shorted in1 and in2 can't be implemented in hardware either using Verilog or Systemverilog. You need to understand if you want to synthesize logic you cannot just use V/SV like a "programming" language you have to restrict your usage to only synthesizable constructs that can be realized in a piece of hardware.
Shorting two outputs together does not work well in hardware as driver contention will burn out one or both drivers if they are at different logic levels. This is why there are tristate drivers, open-drain/collector drivers, etc to allow such shorted connections. In an FPGA there are no such drivers. So you can't write code like this (with multiple drivers) and expect it to compile.
- - - Updated - - -
I think it would help if you took a lot of simple HDL circuit descriptions for various basic code snippets like muxes, decoders, etc and synthesized each of them and look at the logic that is synthesized (schematic view) to understand how code is interpreted as logic. You've proven over many previous posts (including this one) that you need to work on understanding how synthesis interprets your HDL code and what logic it produces.
If you choose to disregard this advice, then you will forever be force to continually return here and ask questions on fundamentally flawed code.