Spartan3: Multiplier Madness

Probably you need to sign-extend when stuffing the high bits...

Could you sign-extend the upper 2 bits, basically tie the bits 17, 16 and 15 together on both inputs? It really then is still a 16-bit multiply. On the other hand, if the 2 LSB's are always zero, the propagation time shouldn't get worse than if it was the 2 MSB's that are zero.

Jon

I tried that, but that didn't solve the problem and made meeting the timing constrains even harder.

Sign extend the inputs to the uper bits, but keep your active 16 bits in the bottom. The timing analyzer doesn't figure out you have the bottom bits tied to zero, so it gives you timing for an 18x18 if you are taking outputs from the top bits of the product. You might also consider registering the multiplier output with flip-flops and place them immediately adjacent to the multiplier rather than letting the auto-placement do it. THe autoplace doesn't do so hot a job at placing registers around the multipliers, so you can fail timing due to a long route combined with the relatively slow clock to out of the multiplier.

The output timing is the more critical for a pipelined multiply. You may also find you need to pipeline the inputs, in which case those should also be hand placed near the multiplier (but put the output registers closest) to get the peak performance.

Hi Nico,

I recently had a very similar problem. The cause of my problem was that I cut and paste the vhdl template and didn't change the library it was uing. So it was using the unsigned library! Needless to say, that didn't work too well. I changed to using the signed library and it worked fine.

Cheers,

James.

Hi James,

Only a multiplier madman would use other than numeric.std ! :-)

You might find Jim Lewis's excellent paper useful, I know I do.

HTH, Syms.

Thanks for the responses. Extending the sign makes timing even worse so I guess I'm stuck with using the top bits of the multiplier.

Can't you use a multi cycle constraint ?

Thanks for the pointer to the paper, Symon.

MAPLD always has some interesting presentations. One of these days I'm going to attend, provided my cheap boss will pay for the trip.

Bob Perlman Cambrian Design Works

No, I really need the answer in the same cycle and there is no way around it. However, if I use a speed grade 5 device instead, the circuit will meet timing.

Any chance that the sign doesn't change on a given input? Hardwiring sign bits to 1 or 0 would help timing a lot vs. connecting them to the high order bit.

No, unfortunately both inputs may be positive or negative.

Nico,

I looked into this, and haven't heard back yet for the whole story.

But, so far:

V4 and V5 delay is flat (doesn't matter how many bits are used).

S3, V2 and V2 Pro may be the only way to get fastest speed is to sign extend (but I am still checking).

Austin

Nico,

OK, here it is: (for S3, V2, and V2 Pro)

"It is likely that the delay will be marginally smaller if you tie the 2 LSB inputs and use the upper 16 inputs only. However, the software model is pretty simple and won't model that as far as I can remember. Also, since one of the inputs goes through the Booth encoder it might not be as substantial of an improvement as it would be with an "original recipe" multiplier."

So, there you go. Looks like sign extension is the only 'official' way to go, but there will be some fat (overestimation of delay) in the set the lsb's to 0 solution, and the software will not model it, and yet it may be a small improvement over what is predicted.

Sorry if this is just too slow,

Austin

So what you are saying is that the multiplier is faster when the upper inputs are being used, but the place & route software assumes the upper bits are slower?

I can move to a speed grade 5 device and I'll be fine.

The software assumes the LSBs of the inputs are toggling and affecting the MSBs of the outputs. The timing model doesn't take into account the fact that the MSB outputs have shorter propagation delays from the higher up input bits, so it doesn't reflect the advantage of using only the upper bits when you do the timing analysis. Instead, I believe the model just assumes a certain delay from any of the inputs to a specific output.

Ray,

Correct.

Aust> Nico Coesel wrote: