Division in ultrascale+ devices

[fpgalearner]

Hi,

Is there any way to do better division in ultrascale+ devices?

I have a design running at 125 MHz (8ns Pulse) and I do a large number division (125000000/115200) and it consumes 43 LUTs and 130 CARRY8 and have 34.087ns data path delay and that leading to -26.233ns setup timing violation.

Regards 

P.S. I do such division in my design to calculate clocks per bit for UART and is intended to alter on the fly.

[richardhead]

If the calculation has both numerator and denominator as fixed, why even bother with it at all? does one of these ever change? how are you doing the division? are you using a divide IP core? Or simply a/b in the RTL?

If you can convert it into a A * (1/N) calculation where (1/N) is already calculated in fixed point, it will be much faster and much smaller.

[u4223374]

Pretty much any approach to division will be better than the obvious approach (ie the "/" operator). It's easy (and compact) to make a divider that'll give you one bit of output per clock cycle. The absolute maximum that you'll generate is a 27-bit number, so you could have this division completed in under 30 cycles. I suspect that for a UART, a ~30 cycle setup delay would be irrelevant (30 cycles at 125MHz = ~1/36th of a bit at 115200bps).

[avrumw]

P.S. I do such division in my design to calculate clocks per bit for UART and is intended to alter on the fly.

There are relatively few "legal" Baud rates for a UART - there are something like 14 of them. Rather than do the division, why not just have a table of the proper divider for each of the valid UART Baud rates. 

Furthermore, most of the Baud rates are related - there is a whole stream of them that are 300*2^N, so if you have the divisor for 300, then you just divide it by 2^N for the other rates. Taking the 300*2^N ones out, that leaves you with something like 6 others (a few of which are related).

A divider seems like overkill here...

Avrum

[avrumw]

P.S. I do such division in my design to calculate clocks per bit for UART and is intended to alter on the fly.

[fpgalearner]

@richardhead simply a/b in the RTL.
numerator fixed and denominator varying. What do you mean by this? where (1/N) is already calculated in fixed point

[fpgalearner]

@u4223374 can you explain it little bit?
absolute maximum that you'll generate is a 27-bit number

[fpgalearner]

@avrumw I am using minicom for my test as a uart terminal + 16550 UART from TI and there are possible baudrates:
300, 1200, 2400, 4800, 9600, 19200, 38400, 56000, 57600, 115200, 128000, 230400, 460800, 500000, 576000, 921600, 1000000, 1152000, 1500000, 2000000, 2500000, 3000000, 3500000, 4000000,

[richardhead]

@fpgalearner 

for example.

lets say you had N / 4

Instead of this, you can work out what 1/4 is in fixed point (b0.01) and do a multiplication instead, because a multiply can easily be done in a single clock.

[fpgalearner]

Hi  @richardhead @avrumw and @u4223374 

In ultrascale+ devices there are dsp blocks. Can I use it for this for efficient divison? If yes, Is there any Xilinx example for this? 

[richardhead]

@fpgalearner 

The easiest way is to convert your divide into a multiply, as already suggested.

[fpgalearner]

@richardhead    Multiplying the way you mentioned helped to reduce data path delay from 34.087ns to 30.662 but not completely eliminate what is the requirement.

[richardhead]

30ns is a very slow path, especially for a US+. This implies you have 0 pipelining in a long combinatorial path. 5ns should be an easily achievable path delay in a US+, with the DSPs able to go much faster than that.