Virtex 4 Multiplier RPM Constraints?

Maybe you could tell us why shape is important, and why you do not want to use the much faster and more efficient dedicated 18 x 18-bit multiplier circuits? Peter Alfke, Xilinx Applications

Hi, Thanks for replying. I want to design 32 bit to 64 bit multipliers, so I can not use just one 18x18 bit XtremeDSP slice.

In my experiments, I am looking at how the shape of multipliers affect their partial reconfiguration. This is when we do difference based partial reconfiguration of the multiplier. If these multipliers do not mix with other components and routing remains same, then when they are reconfigured to new multiplier of same shape, lots of reconfiguration bits can be saved.

Dsp slices based multiplier will be location-constrained which I do not want, as I want the multiplier to be placed anywhere in the area.

I know that ISE 8.1 is now supporting module-based partial reconfiguration using PlanAhead 8.1. But I am looking at saving the reconfiguration bits inside the PRM part (which may internally consists of multipliers and other components) of the design using difference-based scheme.

Hence, I need to specify to Xilinx floorplanner to not to mix the logic of multiplier with other logic. Is there a way to specify such constraint in UCF file without explicitly specifying location constraints? For getting similar shapes of multiplier, I wanted to specify RPM constraints for the multipliers but I could not do it for Virtex 4. So I was curious if this is a known limitation.

Thanks, Love Singhal

Interesting... You know of course that 32 x 32 bits generates 1024 partial products, and 64 x 64 generates 4096 partial products that have to be added together. Looks like a formidable (and inevitably slow) job to me, unless you somehow do this sequentially. In which case you could use the 18 x 19 multipliers as building blocks. Is one of your factors a constant? You somehow lost me. I don't think I can help. Peter

Hi,

If your purpose is to just run "experiments on partial reconfig" than fabric may be ok. But in order to achieve any kind of reasonable speed it would be much better to build your 32x32 or 64x64 multipliers out of the 18x18 Multipliers available in the DSP48. The DSP48 has built in 17 bit shifts on PCIN that allow larger multipliers to be built by using several cascaded DSP48 slices.

It seems from your email that you are trying to reuse the multiplier resource. I don't think you need to put the multiplier in the fabric to do that. It would be better to implement the multiplier in the DSP48s and just reprogram the connections to the multiplier resource. You could also just use a mux to share the resource at different points in time (The DSP48 can also function as a large bus mux).

Even if you did want to move the multiplier all around the chip - its going to cost you a lot of slices (not to mention power) to implement a soft 64x64 multiply. I am not sure if it will be worth it even after Booth Encoding it. If you switch to an V4 SX chip then there will be several DSP48 columns allowing you to move your multiplier around to different parts of the chip.

I am not sure about the specific RPM limitation that you have run into. With the DSP48 cascades - you can connect BCIN/BCOUT PCIN/PCOUT between DSP48 slices that you want placed next to each other. The cascade connections will force the tools to use adjacent DSP48 slices - so this is a quick way of constraining the placement of DSP48 slices in your design.

Hope that helps,

- Vic

Love S> Hi,

Hi all, Thanks for the help. Yes, my purpose for now is to run experiments on partial reconfiguration. For that I am looking at commonly occuring large modules (that take up lot of slices) even if their implementation is not optimal. I will look into the DSP implementation of multiplier to see if it serves my purpose as well.

I figured out a way to separate the logic of various components (like multipliers, adders, etc.) from each other. This could be done by using pblocks in Planahead. Planahead does hierarchical placement as well so it is better suited to do component-based placement.

I am also trying to figure out a way to provide relative placement constraints for each component. I guess one way would be to floorplan the component alone and then export its floorplan as RPM. The RPM can then be used for the placement of the common components in the bigger design by putting the RPM in the ucf file..

Regards, Love Singhal