Below is my code for ALU which instantiates a 4:1 MUX and a 32 bit squarer modules. The port connections can be seen in module instantiations. However it is important to mention here that input of MUX's are 4 32-bit constants. The output of MUX is connected to input(op1) of squarer through an internal wire of ALU.

Test bench for ALU contains a clock with T = 20ns, and reset is high only for first 60ns.

The problem is the output of below code is slightly different than it should be which is square of 32 bit number which is there at 1st input of MUX. For example at first input of MUX the number is 32'hABCDEFAB the output I get after simulating ALU is 64'h73440a7554366fe0 whereas it should be 64'h734CC3D82A3EBC39. However squarer is working fine because when i simulate it alone and provide the operand from test bench the result is correct.

If anyone can figure out the issue, would be great.

module ALUUU (
input         clk,
input         reset,
output [63:0] ALU_final_output
);

wire   [31:0] op_1;
reg    [63:0] ALU_Out;
wire   [63:0] Sq_out;
reg     [2:0] select_ALU_operands;

MUX__EC_points M1 (
.select_ALU_operands (select_ALU_operands),
.operand_for_ALU     (op_1)
);

squarer_karatsuba FF_SQR (
.clk(clk),
.op1(op_1),
.square(Sq_out)
);

always @(posedge clk) begin
if (reset) begin
ALU_Out <= 0;
end else begin
select_ALU_operands <= 3'd0;
ALU_Out <= Sq_out;
end
end

assign  ALU_final_output = ALU_Out;
endmodule


MUX Code:

module MUX__EC_points (
input   [2:0] select_ALU_operands,
output [31:0] operand_for_ALU
);

reg    [31:0] operand;

parameter BASEPOINT_xp  = 32'habcdefab;
parameter BASEPOINT_yp  = 32'hcdabefab;

always @* begin
case (select_ALU_operands)
3'd0: operand <= BASEPOINT_xp;
3'd1: operand <= BASEPOINT_yp;
3'd2: operand <= CONSTANT_b;
endcase
end

assign operand_for_ALU = operand;
endmodule

• You should simulate your design with a testbench and a waveform viewer. Ordinarily I wouldn't have a clock input to a mux. Personally I would choose simpler mux inputs that can be quickly verified as correct, like 64'h00040002. Since you didn't post all your code this is conjecture: After reset is released, your mux doesn't see select_ALU_operands for one clock cycle. Assuming mux is clocked, op_1 isn't valid for another clock cycle after that. Your StackOverflow Question indicated this is a kind of multi-stage design, so you might be operating on invalid inputs. – Kevin Kruse Apr 16 at 18:50
• @KevinKruse done with editing the question. Port mapping was a typo and corrected as well in the question. – Muhammad Kashif Apr 16 at 19:15
• Still, since you don't assign a value to select_ALU_operands until the first clock cycle after reset, your squarer will not see the correct operand until one cycle later. Have you simulated this design and checked the waveform viewer as I suggested? – Kevin Kruse Apr 17 at 12:06
• yes i did simulate using the test bench and in test bench i gave clock and reset values. Now what should happen is that squarer should get the operand at posedge of clk right after when the reset is released, but that is not happening and thats the issue. After releasing the reset the output stays zero for next three clock cycles, and thats the reason behined wrong output. @kevin kruse – Muhammad Kashif Apr 17 at 15:36
• I need a solution to this, if anyone can help please. – Muhammad Kashif Apr 18 at 9:28

As pointed out twice in my comments, you need to understand the squarer won't see the correct operand on the first clock edge after reset. This is because of the fact that you drive select_ALU_operands with the first clock edge. Turn on time delta expansion in your waveform viewer and you should see that select_ALU_operands gets the value of 0 after the first clock edge.
Either change your design to present a valid value of select_ALU_operands before the first clock edge, or add a "start" signal to your squarer and drive that "start" signal at the same time as your "select" signal. This would ensure your squarer doesn't start operating until its input is valid.