The signal ..._IBUF has no load. PAR will not attempt to route this signal.

[Leep]

I'm working through the book FPGA Prototyping By Verilog Examples (by Pong P. Chu) and I've had no problems up until the end of chapter 3 with the fp_adder example. I'm getting warnings that I can't figure out (I've even synthesized directly from the .v files for the chapter from the book's website, with my .ucf file [the book is for different board, pins are different]). The warnings I'm getting are during Place & Route:

WARNINGar:288 - The signal sw<2>_IBUF has no load. PAR will not attempt to route this signal.
WARNINGar:288 - The signal sw<3>_IBUF has no load. PAR will not attempt to route this signal.
WARNINGar:288 - The signal sw<4>_IBUF has no load. PAR will not attempt to route this signal.
WARNINGar:283 - There are 3 loadless signals in this design. This design will cause Bitgen to issue DRC warnings.

The source is below. I included disp_mux.v and hex_to_sseg.v for completeness, but I've used those in several other projects and they seem to be working fine (simple controller for 4-digit seven-segment display with common anode).

fp_adder_test.v

module fp_adder_test
  (
    input wire clk,
    input wire [1:0] btn,
    input wire [7:0] sw,
    output wire [3:0] an,
    output wire [7:0] sseg
  );

  wire sign1, sign2, sign_out;
  wire [3:0] exp1, exp2, exp_out;
  wire [7:0] frac1, frac2, frac_out;
  wire [7:0] led3, led2, led1, led0;

  assign sign1 = 1'b0;
  assign exp1 = 4'b1000;
  assign frac1 = {1'b1, sw[1:0], 5'b10101};
  assign sign2 = sw[7];
  assign exp2 = btn;
  assign frac2 = {1'b1, sw[6:0]};

  fp_adder fp_unit
  (
    .sign1(sign1), .sign2(sign2), .exp1(exp1), .exp2(exp2),
    .frac1(frac1), .frac2(frac2), .sign_out(sign_out),
    .exp_out(exp_out),.frac_out(frac_out)
  );
  
  hex_to_sseg sseg_unit_0
  (
    .hex(exp_out), .dp(1'b0), .sseg(led0)
  );

  hex_to_sseg sseg_unit_1
  (
    .hex(frac_out[3:0]), .dp(1'b1), .sseg(led1)
  );

  hex_to_sseg sseg_unit_2
  (
    .hex(frac_out[7:4]), .dp(1'b0), .sseg(led2)
  );
  
  assign led3 = (sign_out) ? 8'b11111110 : 8'b11111111;
  
  disp_mux disp_unit
  (
    .clk(clk), .reset(1'b0), .in0(led0), .in1(led1),
    .in2(led2), .in3(led3), .an(an), .sseg(sseg)
  );

endmodule

fp_adder.v

module fp_adder
  (
    input wire sign1, sign2,
    input wire [3:0] exp1, exp2,
    input wire [7:0] frac1, frac2,
    output reg sign_out,
    output reg [3:0] exp_out,
    output reg [7:0] frac_out
  );

  reg signb, signs;
  reg [3:0] expb, exps, expn, exp_diff;
  reg [7:0] fracb, fracs, fraca, fracn, sum_norm;
  reg [8:0] sum;
  reg [2:0] lead0;

  always @*
  begin

    // Stage 1 - Sort
    if ({exp1, frac1} > {exp2, frac2})
    begin
      signb = sign1;
      signs = sign2;
      expb = exp1;
      exps = exp2;
      fracb = frac1;
      fracs = frac2;
    end
    else
    begin
      signb = sign2;
      signs = sign1;
      expb = exp2;
      exps = exp1;
      fracb = frac2;
      fracs = frac1;
    end
    
    // Stage 2 - Align
    exp_diff = expb - exps;
    fraca = fracs >> exp_diff;
    
    // Stage 3 - Result of Add/Subtract
    if (signb == signs)
    begin
      sum = {1'b0, fracb} + {1'b0, fraca};
    end
    else
    begin
      sum = {1'b0, fracb} - {1'b0, fraca};
    end
    
    // Stage 4 - Normalize
    if (sum[7])
      lead0 = 3'o0;
    else if (sum[6])
      lead0 = 3'o1;
    else if (sum[5])
      lead0 = 3'o2;
    else if (sum[4])
      lead0 = 3'o3;
    else if (sum[3])
      lead0 = 3'o4;
    else if (sum[2])
      lead0 = 3'o5;
    else if (sum[1])
      lead0 = 3'o6;
    else
      lead0 = 3'o7;
    
    sum_norm = sum << lead0;
    
    if(sum[8]) // carry out
    begin
      expn = expb + 1;
      fracn = sum[8:1];
    end
    else if (lead0 > expb) // too small to normalize
    begin
      expn = 0;
      fracn = 0;
    end
    else
    begin
      expn = expb - lead0;
      fracn = sum_norm;
    end
    
    // Stage 5 - Form output
    sign_out = signb;
    exp_out = expn;
    frac_out = fracn;

  end

endmodule

disp_mux.v

module disp_mux
   (
    input wire clk, reset,
    input [7:0] in3, in2, in1, in0,
    output reg [3:0] an,   // enable, 1-out-of-4 asserted low
    output reg [7:0] sseg  // led segments
   );

   // constant declaration
   // refreshing rate around 800 Hz (100 MHz/2^17)
   localparam N = 19;

   // signal declaration
   reg [N-1:0] q_reg;
   wire [N-1:0] q_next;

   // N-bit counter
   // register
   always @(posedge clk,  posedge reset)
      if (reset)
         q_reg <= 0;
      else
         q_reg <= q_next;

   // next-state logic
   assign q_next = q_reg + 1;

   // 2 MSBs of counter to control 4-to-1 multiplexing
   // and to generate active-low enable signal
   always @*
      case (q_reg[N-1:N-2])
         2'b00:
            begin
               an = 4'b1110;
               sseg = in0;
            end
         2'b01:
            begin
               an =  4'b1101;
               sseg = in1;
            end
         2'b10:
            begin
               an =  4'b1011;
               sseg = in2;
            end
         default:
            begin
               an =  4'b0111;
               sseg = in3;
            end
       endcase

endmodule

hex_to_sseg.v

module hex_to_sseg
(
  input wire [3:0] hex,
  input wire dp,
  output reg [7:0] sseg
);

  always @*
  begin
    case (hex)
      4'h0: sseg[6:0] = 7'b0000001;
      4'h1: sseg[6:0] = 7'b1001111;
      4'h2: sseg[6:0] = 7'b0010010;
      4'h3: sseg[6:0] = 7'b0000110;
      4'h4: sseg[6:0] = 7'b1001100;
      4'h5: sseg[6:0] = 7'b0100100;
      4'h6: sseg[6:0] = 7'b0100000;
      4'h7: sseg[6:0] = 7'b0001111;
      4'h8: sseg[6:0] = 7'b0000000;
      4'h9: sseg[6:0] = 7'b0000100;
      4'ha: sseg[6:0] = 7'b0000010;
      4'hb: sseg[6:0] = 7'b1100000;
      4'hc: sseg[6:0] = 7'b1110010;
      4'hd: sseg[6:0] = 7'b1000010;
      4'he: sseg[6:0] = 7'b0010000;
      default: sseg[6:0] = 7'b0111000;
    endcase
    sseg[7] = dp;
  end

endmodule

fp_adder_test.ucf

Net "clk" LOC=V10;

Net "sseg<6>" LOC = T17;
Net "sseg<5>" LOC = T18;
Net "sseg<4>" LOC = U17;
Net "sseg<3>" LOC = U18;
Net "sseg<2>" LOC = M14;
Net "sseg<1>" LOC = N14;
Net "sseg<0>" LOC = L14;
Net "sseg<7>" LOC = M13;

Net "an<0>" LOC = N16;
Net "an<1>" LOC = N15;
Net "an<2>" LOC = P18;
Net "an<3>" LOC = P17;

Net "sw<0>" LOC = T10;
Net "sw<1>" LOC = T9;
Net "sw<2>" LOC = V9;
Net "sw<3>" LOC = M8;
Net "sw<4>" LOC = N8;
Net "sw<5>" LOC = U8;
Net "sw<6>" LOC = V8;
Net "sw<7>" LOC = T5;

Net "btn<1>" LOC = B8;
Net "btn<0>" LOC = D9;

The target board is a Digilent Nexys 3 with a Xilinx Spartan-6 FPGA. Has anyone else worked through the book FPGA Prototyping By Verilog Examples (by Pong P. Chu) and had similar problems? If anyone could look at the source and see if you spot something obvious that I'm missing, or if you have a Nexys 3 if you could try to synthesize it to the board and see if you get the same warnings, I'd greatly appreciate it! Thanks!

 

[mrflibble]

It means you 3 of the 8 switches are not used. Or more precisely, your design does not care whether your SW<2> input has a 1 or a 0 input. Similar for Sw<3> and SW<4>. These warnings could be harmless, depending on the design...

---------- Post added at 03:25 ---------- Previous post was at 03:23 ----------

If you can attach the complete project file as .zip (I'm lazy ), I'll try synthesizing.

 

[Leep]

Here's the zip file with the ISE project: View attachment fp_adder.zip

It's a simplified floating point adder (1 bit sign, 3 bit exponent, 8 bit significand). As far as I can tell, all 8 switch inputs are used and (should) affect the output of fp_adder_test. I've included a (very) summarized flow of sw (inputs) to an and sseg (outputs) as I understand it.

In fp_adder_test.v, frac1 and frac2 (both [7:0]) are the two significands being added. The chapter text explains that the switches are used for multiple bits of frac1 and frac2 and some bits are binary literals since there are 16 bits (plus 6 bits of exponents) and there are only 8 switches on the board. Looking at the flow below and the actual source (zip above), I can't see anything that singles out sw[2:4]. sw[1:0] and sw[6:0] are both used. What's special about sw[2:4]? I'm not seeing it. Unless it's something in hex_to_sseg or disp_mux, but they're fairly straight forward and have been working in several previous projects.

...
assign frac1 = {1'b1, sw[1:0], 5'b10101};
...
assign frac2 = {1'b1, sw[6:0]}; // sw[2:4] are certainly being used here...
...
fp_adder fp_unit
(
.sign1(sign1), .sign2(sign2), .exp1(exp1), .exp2(exp2),
.frac1(frac1), .frac2(frac2), .sign_out(sign_out),
.exp_out(exp_out),.frac_out(frac_out) // frac_out is the output from fp_adder (flow below)
);
...
hex_to_sseg sseg_unit_1
(
.hex(frac_out[3:0]), .dp(1'b1), .sseg(led1) // led1 is the output from hex_to_sseg
);

hex_to_sseg sseg_unit_2
(
.hex(frac_out[7:4]), .dp(1'b0), .sseg(led2) // led2 is the output from hex_to_sseg
);
...
disp_mux disp_unit
(
.clk(clk), .reset(1'b0), .in0(led0), .in1(led1),
.in2(led2), .in3(led3), .an(an), .sseg(sseg) // an and sseg is the output from disp_unit
);

// an and sseg are outputs from fp_adder_test are are connected to the seven-segment display on the board



In fp_adder frac1 and frac2 (both [7:0]) are the two significands being added.

....
fracb = frac1; // (or fracs = frac1
fracs = frac2; // (or fracb = frac2
....
fraca = fracs >> exp_diff;
....
sum = {1'b0, fracb} + {1'b0, fraca}; // (or sum = {1'b0, fracb} - {1'b0, fraca}
...
sum_norm = sum << lead0;
...
fracn = sum[8:1]; (or fracn = 0; or fracn = sum_norm
...
frac_out = fracn;

 

[Leep]

I've tried replacing all my source files with the source files from the book's website (fp_adder_test.vs, fp_adder.v, hex_to_sseg.v, and disp_mux.v), with the exception of the .ucf file (the one from the book is for a Spartan-3 board, I'm using a Nexys-3 w/Spartan-6) and still get the same warnings. I've looked over and over and over the .ucf and don't see anything wrong. I've even tried rebooting, standing on one leg and chanting while synthesizing... No luck. ;-)

 

[Leep]

If you can attach the complete project file as .zip (I'm lazy ), I'll try synthesizing.

Have you had a chance to try synthesizing the project yet? I'm really just curious to know if the problem is something with my environment or the code itself. I've done several (small) projects since then and they've worked fine, so I have to assume it's something with the code, but I'm just not seeing it.

Family: Spartan6
Device: XC6SLX16
Package: CSG324
Speed: -2 (I've never been able to find anything stating what this SHOULD be set to for my board... options are -3, -3N, and -2)

 

[mrflibble]

Just did synthesis, and can confirm the exact same warnings.

In general however, this type of warning is not directly a problem. Which is why it's a warning and not an error... It's good to keep reading this kind of warning, because as soon as you are not able to say "oh yeah, that's because such and such" there might be a problem in the design.

Why things get optimized is pretty obvious though... In module fp_adder
you have:

  always @*

  begin
    // Stage 1 - Sort
    if ({exp1, frac1} > {exp2, frac2})
    begin

    //stuff
    end
    else
    begin

  // other stuff
  end
  // ...

That if statement evaluates to only 1 single instace, always.

if ({exp1, frac1} > {exp2, frac2})

Why is that? Well, as inputs to fp_adder you provide:

  assign exp1 = 4'b1000;
  assign exp2 = btn;

And btn is a 2 bit array, soooo effectively exp2 = {2'b00, btn[1:0]} , thus the if always takes 1 branch particular branch, and optimization ensues.

I did a quick test by adding two extra entries to the UCF for btn<3> and btn<2> , and made btn a 4 wire input. Le voila, those warnings go away.

On the subject of warnings ...

      expn = expb + 1;

... throws truncation warnings. To avoid that you can use:

      expn = expb + 1'd1;

Hope that helps.

 

[Leep]

Ah, optimizations! I don't know why I didn't think of that. I "grew up" in the c programming world and was (decades ago) very familiar with the software equivalent, compiler optimizations. The thought that "synthesis" optimizations could be occurring never occurred to me. Thanks for that tip, I'll keep that in mind from now on. And thanks for the truncation warning tip.