Virtex 4 Multiplier RPM Constraints?

Hi,
I am trying to create a Xilinx Core Generator multiplier for Virtex 4
with RPM constraints. However, neither ISE 7.1 (IPCore 7.1) nor ISE 8.1
(IPCore 8.0) allows creation of Virtex 4 multiplier with RPM
constraints, even if multiplier is completely LUT based. Such
constraints on multiplier are allowed in Virtex 2.
What is the reason for this limitation in Virtex 4?
I wanted some multipliers in my design to have similar shapes and to
not get mixed with other components in different shapes. Is there a way
to provide such constraints in ucf file? 

Thanks in advance.

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
http://www.ics.uci.edu/~lsinghal

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 Singhal wrote:
> 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
> http://www.ics.uci.edu/~lsinghal
> 

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
http://www.ics.uci.edu/`lsinghal