-1
\$\begingroup\$

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;
  parameter CONSTANT_b    = 32'hadfecbba;

  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
\$\endgroup\$
4
  • \$\begingroup\$ 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. \$\endgroup\$ Apr 16, 2019 at 18:50
  • \$\begingroup\$ @KevinKruse done with editing the question. Port mapping was a typo and corrected as well in the question. \$\endgroup\$ Apr 16, 2019 at 19:15
  • \$\begingroup\$ 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? \$\endgroup\$ Apr 17, 2019 at 12:06
  • \$\begingroup\$ 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 \$\endgroup\$ Apr 17, 2019 at 15:36

1 Answer 1

-1
\$\begingroup\$

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.

If this doesn't solve your problem, you need to post a minimal, working example of your squarer and an image of the waveform viewer during simulation.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.