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
Best Answer
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):
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
If the tick output has to be glitch-free, you'd have to do that in sequential logic.