XST Verilog - Casting real to integer constants
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 &lt;= ctr[31:0] + jump; 
   tick &lt;= 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 &amp; ~done;


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