XST Verilog - Casting real to integer constants

Question

When I try to synthesize the following Verilog code using Xilinx XST, I get the error, "Unsupported real constant". If I try wrapping that expression in an $rtoi function, XST gives a different error: "Unsupported System Function Call".

Using the Xilinx synthesis tools, is it possible to cast a real constant to an integer constant? If so, how?

module example(clk, n_rst, tick, done);
  parameter CLOCK_HZ  = 50_000_000;
  parameter BAUD_RATE = 3_000_000;
  input clk, n_rst;
  output reg tick, done;

  reg [31:0] counter;

  always @(posedge clk, negedge n_rst) begin
    if (!n_rst) begin
      counter <= 32'h00000000;
      tick <= 0;
      done <= 0;
    end
    else if (counter == (0.5*CLOCK_HZ/BAUD_RATE) ||    // ERROR:Xst:850 - Unsupported real constant
             counter == (1.5*CLOCK_HZ/BAUD_RATE) ||    // ERROR:Xst:850 - Unsupported real constant
             counter == (2.5*CLOCK_HZ/BAUD_RATE) ||    // ERROR:Xst:850 - Unsupported real constant
             counter == (3.5*CLOCK_HZ/BAUD_RATE) ||    // ERROR:Xst:850 - Unsupported real constant
             counter == (4.5*CLOCK_HZ/BAUD_RATE) ||    // ERROR:Xst:850 - Unsupported real constant
             counter == (5.5*CLOCK_HZ/BAUD_RATE) ||    // ERROR:Xst:850 - Unsupported real constant
             counter == (6.5*CLOCK_HZ/BAUD_RATE) ||    // ERROR:Xst:850 - Unsupported real constant
             counter == (7.5*CLOCK_HZ/BAUD_RATE) ||    // ERROR:Xst:850 - Unsupported real constant
             counter == (8.5*CLOCK_HZ/BAUD_RATE) ||    // ERROR:Xst:850 - Unsupported real constant
             counter == (9.5*CLOCK_HZ/BAUD_RATE))      // ERROR:Xst:850 - Unsupported real constant
    begin
      counter <= counter + 1;
      tick <= 1;
      done <= 0;
    end
    else if (counter == 10*CLOCK_HZ/BAUD_RATE) begin
      counter <= 32'h00000000;
      tick <= 0;
      done <= 1;
    end
    else begin
      counter <= counter + 1;
      tick <= 0;
      done <= 0;
    end
  end
endmodule

Answer 1

Since no other answers are forthcoming, I'll suggest an alternative approach.

Instead of two parameters CLOCK_HZ and BAUD_RATE, just use a single parameter DIVIDE_RATIO.

Then the values for comparison can be calculated as DIVIDE_RATIO[n:1], DIVIDE_RATIO, (3*DIVIDE_RATIO)[n:1], etc. and no floating point value is ever created.

The disadvantage of this relative to what you have is that if the divide ratio isn't an exact integer, your approach would smooth out the errors in the tick rate over 10 cycles, whereas mine would have slightly more error in the tick rate compared to the "ideal" divide ratio.

In addition, although its not what you asked about, I'd suggest looking at alternate ways of arranging your counter all together. As your code stands you're using a 32-bit register to hold (and doing 32-bit comparisons on) a counter that will never count above 600 assuming the default values you used for the parameters aren't overridden by the caller. I think you could get all the same states with 9 or 10 state bits.

Edit -- an alternative approach:

Another way to go that solves both the floating point problem and the accuracy problem, is to use a jump counter. (freehand code, not tested):

parameter jump = xxx; /// jump = 2^32 * BAUD_RATE / CLOCK_HZ
reg [32:0] ctr;

always @ (posedge clk) begin
   ctr <= ctr[31:0] + jump; 
   tick <= ctr[32];
end

By allowing the counter to just roll over instead of resetting to 0 after the terminal count, you get a tick rate that averages out correctly to the limits of 32-bit integer math, but you don't have any floating point to confuse the Verilog compiler or synthesizer.

You'll need to add the reset logic and a second counter to count ticks and generate the 'done' signal. To get exactly what you had before you'll also need

wire real_tick;
assign real_tick = tick & ~done;

If the tick output has to be glitch-free, you'd have to do that in sequential logic.

Answer 2

The tool is trying to tell you, politely, "Hey, dude, I'm not a C compiler." :)

In addition to picking an appropriate fixed-point representation for the numbers you're working with, you shouldn't synthesize counters in terms of additions and comparisons to a terminal count. Instead, start the counter at the terminal value and test it against zero. This will save an adder and shorten the logic path.