Forum Discussion

SamPF's avatar
SamPF
Icon for New Contributor rankNew Contributor
11 months ago

quartus sythesize question

Hello,

when I design a project, there are many modules in this project, in one of the modules (not the top module) I mark the wrong io type (for example: input tag to output), and in the module This io doesn't have any value assigned just flags error and then I synthesize it in quartus successfully but in real application it doesn't work my question is:

How can I set quartus to find this error during the sythesize phase?

BR,

Sam PF

8 Replies

  • FvM's avatar
    FvM
    Icon for Super Contributor rankSuper Contributor

    Hi,
    perhaps I didn't yet understand the example. I believe you'll get compilation errors in most cases.

    Connecting an output port to a signal that is expected to drive an input will give a multiple driver error, because the signal is already driven. The reverse situation won't cause an error in the upper hierarchhy level, just leave an undriven signal. But in the lower hierarchy (module implementation) level, you can't drive the erroneously defined input without causing an error.

    So you are apparently talking about a consistently designed module that is connected erroneously in the upper hierarchy. I think confusing in- and output ports is only one of many possible wrong connections and no particular case.

    You'll want some kind of verification, e.g. with a simulator. It an easily mark undriven signals.

    Regards
    Frank

    • SamPF's avatar
      SamPF
      Icon for New Contributor rankNew Contributor

      Hi, FvM

      First of all thanks for your reply, I'll give you an example to describe the problem I'm having.

      You can see the Main_Seq module, PWRGD_a is the input, but I marked it as output. The final result b_EN will become high during simulation, which is also successful in quartus sythesize, but b_EN will not become high in the actual synthesis circuit.

      Do you know how to verify this problem or use some settings in sythesize to avoid this problem?

      module top(
      output a_EN,
      output b_EN,
      input PWRGD_a,
      input POWER,
      input CLK_2M
      );

      // Rst Control
      wire Rst;
      assign Rst = POWER ? 1'b1 : 1'b0;

      // sync signal
      wire w_PWRGD_a;
      sync sync_inst(
      .clk(CLK_2M),
      .Rst(Rst),
      .iSync(PWRGD_a),
      .oSync(w_PWRGD_a)
      );

      Main_Seq main_seq_inst(
      .clk(CLK_2M),
      .Rst(Rst),
      .a_EN(a_EN),
      .b_EN(b_EN),
      .PWRGD_a(w_PWRGD_a)
      );

      endmodule

      module sync(
      input clk,
      input Rst,
      input iSync,
      output oSync
      );

      reg rSync;
      reg [10:0] iSync_delay;
      assign oSync = rSync;

      always @(posedge clk) begin
      if(!Rst) begin
      rSync <= 1'b0;
      iSync_delay <= {11{1'b0}};
      end
      else begin
      iSync_delay <= {iSync_delay[9:0], iSync};
      end
      end

      always @(posedge clk)
      begin
      if(!Rst) begin
      rSync <= 1'b0;
      end
      if(~|iSync_delay)
      begin
      rSync <= 1'b0;
      end
      if(&iSync_delay)
      begin
      rSync <= 1'b1;
      end
      end

      endmodule

      module Main_Seq(
      input clk,
      input Rst,
      output a_EN,
      output b_EN,
      output PWRGD_a
      );

      reg a_EN_ff;
      reg b_EN_ff;

      assign a_EN = a_EN_ff;
      assign b_EN = b_EN_ff;

      always @(posedge clk) begin
      if(!Rst) begin
      a_EN_ff <= 0;
      b_EN_ff <= 0;
      end
      else begin
      a_EN_ff <= 1;
      if(PWRGD_a) begin
      b_EN_ff <= 1;
      end
      end
      end

      endmodule

      `timescale 1ns/1ns

      module tb_top;
      reg clk;
      parameter clk_period = 500;
      initial begin
      clk = 1'b0;
      end

      wire a_EN;
      wire b_EN;
      reg PWRGD_a;

      always @(clk)
      #(clk / 2.0) clk <= !clk;

      reg POWER;

      initial begin
      POWER = 1'b0;
      PWRGD_a = 1'b0;
      #(1000000) // 1ms
      POWER = 1'b1;
      end

      always @(posedge a_EN & POWER) begin
      PWRGD_a <= 1'b1;
      end

      top top_inst(
      .a_EN(a_EN),
      .b_EN(b_EN),
      .PWRGD_a(PWRGD_a),
      .POWER(POWER),
      .CLK_2M(clk)
      );

      endmodule


      BR,

      SamPF

  • sstrell's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor

    Showing your code would also be helpful to see what is happening.

  • sstrell's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor

    You're not seeing an issue because you have an intermediary wire, w_PWRGD_a, so you're never connecting the output of Main_Seq to top. The names can be the same in different levels of hierarchy.

    As for why b_EN goes high in simulation and not in hardware, that's not as clear unless I put it into Quartus.

  • Hi,


    In STP, I'm seeing b_EN high when using input PWRGD_a in Main_Seq.v. While seeing b_EN low when using output PWRGD_a in Main_Seq.v. I think the actual synthesis circuit result is the correct one because need input PWRGD_a to make b_EN high as b_EN depends on the if(PWRGD_a) begin.

    However, I'm seeing same result (b_EN high) for both situation in simulation. I'll further confirm with the internal engineering team.


    Thanks,

    Regards,

    Sheng


    • SamPF's avatar
      SamPF
      Icon for New Contributor rankNew Contributor

      Hi ShengN

      First of all thanks for your reply

      You are right because this is a real problem we have in real systems, when we simulate everything is correct and we load to FPGA it does not work, so the synthesized circuit is correct, but how do I get this in simulation The problem is what we care about, so hopefully you can tell me what I can do in the simulation to prevent this problem, thanks.

      BR,

      Sam

  • Hi,


    I had reported the problem. Will get back to you once any further feedback.


  • Hi,


    The problem is planned in 25.1std. I would suggest you to stick with the result of signal tap for now as it's real-time result.

    Let me know do you have any further concern?


    Thanks,

    Regards,

    Sheng