LUT vs. hard IP based multipliers on Spartan-3 FPGA for constant coefficient multiplication

Question

Before I get to my question, here are the specs for the board and synthesis tool I am using:

• Family: Spartan3
• Device: XC3S200
• Speed: -5
• Synthesis Tool: XST

My 4-bit multiplier is in my design's critical path. I would like to reduce the time multiplication takes so I can reduce my critical path and increase my clock frequency.

I can use CoreGEN to instantiate LUT based multipliers, LUT based constant coefficient multipliers, hard multipliers, and hard constant coefficient multipliers (which I think might just be hard multipliers with one input hard wired).

I am thinking that if I use 15 LUT based constant-coefficient multipliers (or maybe 11, can take care of cases 2,4,8 with shifting and 0,1 are trivial) that I can break this critical path down a bit. My design constraints prevent me from pipelining these multipliers; I need them to just integrate into my combinational logic path.

Would this be faster than just using a hard multiplier? Or would a normal LUT based multiplier be faster than either option?

Answer 1

According to the datasheet the hard multiplier takes between 4 and 5 ns to propogate from inputs to outputs in combinational mode. You'll lose a few more 100s of ps getting to and from the multiplier to the rest of your logic. If that's fast enough, then just make use of it.

If not, build your LUT-based multiplier by just writing some code with the * operator in it, synthesise it, place and route, and see if that's fast enough. You may needs an attribute to force it to not use the hard multipliers (see the MULT_STYLE attribute in the XST manual). You could even try just forcing a single LUT-based (non-constant) multiplier with that constraint and see what the result is - that's a very quick test.

Only if those fail should you go down the route of hand-building a LUT-based structure - and even then only if you've looked at the output of the synthesiser and are pretty sure you can beat it for some reason. The synthesisers have been tuned to work out constant coefficient multipliers very well in my experience - I doubt coregen will gain much.

---

Wet finger estimate: A LUT delay is ~0.7ns. Assuming routing delays are of a similar magnitude, you can afford a chain of only 3-4 LUTs in the delay of the hard multiplier. It seems unlikely to me that you'll achieve what you need in that depth of logic.

Answer 2

the fasteest multiplier you can use is one that performs the number of operations in as a few a clock cycles as possible.

Typically this would be one clock cycle.

To achieve this you generally have to use more logic cells. The tradeoff comes down to space vs speed for this example.

You have not stated any space requirements so use any multiplier that achieves the result in one clock cycle.

Not having looked at the two different multipliers I cannot advise on which one is more suited for you application.

If you are unsure which is faster, than write a test bench with the two in parallel and see how many clock cycles each of them takes.

Answer 3

If you want hard DSP multipliers to operate at anything like their full speed (maximise fMax) you usually need to use input and output registers located in the DSP slice. This means adding a surplus register at both ends of your operation in RTL and making sure synthesis does not eliminate any bits (by propagating constants through it) or pushing it back into driving logic (say upstream RAM block gets output latches turned on). This allows mapping to absorb the free reg into the DSP slice and gives the multiplier the full cycle, eliminating signal routing times.

This kind of optimisation is usually required when you are trying to push fMax to the maximums on the datasheets, in which case you'll need to follow the synthesis/DSP guide exactly and use the instantiation templates. Hopefully they use the * operator inside so give no problem in simulation. Watch async reset signal handling of the pipeline/in/out regs as those are not as versatile in DSP slice regs as general slices and can thwart your attempt, resulting in a pointless external reg being used and the multiplier inputs put into bypass. Looking at the technology schematic of your design will help see what you got.

More generally, it's not clear why pipelining the design isn't an option for you. Normally you would re-sync the rest of your signal paths to match the pipelining you've allowed to be absorbed into DSP. The pipelined design still produces one result per cycle, and your fMAX will be higher as a result of reducing logic on the critical path, increasing throughput.