DSP48E, What are the internal implementations used?

Hello PPL,

I would like to know what are the current implementations for the
internal blocks inside a DSP48E. This of course applies to the new
Virtex-5 FPGA. How is Xilinx building, at RTL, the 25 X 18 multiplier
(is it a booth?) as well as the 48 X 48 adder blocks?

Thanks for any help
Jacques

Jacques, I think you cannot expect an answer in a public forum like
this.
Part of the answer might divulge secrets that Xilinx tries to keep away
from the competition. Some of it should be kept under wraps to reduce
the support burden, for there are always smart people who then could
poke around in the innards and cause great stress to our support
organization.

When I was Zilog Applications I found all those undocumented Z-80
instruction, and wanted to make them public. But I was told in no
uncertain terms that that would not be in the interest of the company,
since it might cause future compatability problems.

My advice to you is to attend conferences and read papers where
designers proudly talk and write (sometimes too much) about their
achievements. Patents are also a good source of information, but you
never know whether the patented idea really got implemented that way.

The shorter answer to your question would be a question: Why do you
want to know?
Peter Alfke

Jacques,

The actual implementation and circuits of our DSP48E is proprietary
information.

What has been published:
http://www.xilinx.com/publications/xcellonline/xcell_52/xc_pdf/xc_v4topview52.pdf

Austin

jaxato@gmail.com wrote:
> Hello PPL,
> 
> I would like to know what are the current implementations for the
> internal blocks inside a DSP48E. This of course applies to the new
> Virtex-5 FPGA. How is Xilinx building, at RTL, the 25 X 18 multiplier
> (is it a booth?) as well as the 48 X 48 adder blocks?
> 
> Thanks for any help
> Jacques
> 

Hi Peter,

Thanks for your prompt reply to my post. I have been asked by my
professor to write a comprehensive report on the various arithmetic
building blocks which exists in the FPGA world. So here I am probing
here and there. But the thing is that it is most probably a "classic"
implementation that Xilinx is using or maybe with some adaptation. If
such information is too much asking, then I will most probably use a
N/A in my report. I am just starting though and I will try to dig
deeper into papers, in particular, those dealing with the Virtex-4, as
I am sure that most of the DSP48E is based on its predecessor.

Jacques

Jacques,

OK.  That is fair.

If you read the article I sent you, it will tell you that the IP for V4
was licensed from Arithmatica.

If you then go to their website, you may get some idea of what they are
doing, although you will not know what we did with their IP, you can
probably assume we made it work well (which we did).

I can not say more about V5, as it has not been printed anywhere (yet).

Austin

jaxato@gmail.com wrote:
> Hi Peter,
> 
> Thanks for your prompt reply to my post. I have been asked by my
> professor to write a comprehensive report on the various arithmetic
> building blocks which exists in the FPGA world. So here I am probing
> here and there. But the thing is that it is most probably a "classic"
> implementation that Xilinx is using or maybe with some adaptation. If
> such information is too much asking, then I will most probably use a
> N/A in my report. I am just starting though and I will try to dig
> deeper into papers, in particular, those dealing with the Virtex-4, as
> I am sure that most of the DSP48E is based on its predecessor.
> 
> Jacques
> 

On 25 May 2006 14:05:39 -0700, jaxato@gmail.com wrote:

>Hello PPL,
>
>I would like to know what are the current implementations for the
>internal blocks inside a DSP48E. This of course applies to the new
>Virtex-5 FPGA. How is Xilinx building, at RTL, the 25 X 18 multiplier
>(is it a booth?) as well as the 48 X 48 adder blocks?

First of all there is no RTL (one which gets synthesized anyway).
Second I remember Xilinx licensing some IP from a high speed module
generator company a while back. Their design methodology was a little
more public.

Jacques, the days of "normal textbook design methods" for such
highly-tuned circuits are definitely passee. No more simple adder
trees, or -heaven forbid- ripple-carry adders.
It's all far more sophisticated, because there is this enormous
pressure to achieve high performance, while keeping power low.

May make your assignment more difficult, but it gives the user better
results.
Peter Alfke

One question...
Is it correct to say that the A+ and Ax technology was used in the
DSP48, as the V4's DSP is CellMath based? I am confident that Xilinx
improvements were at balancing the power to speed ratio by adapting the
technology to 90nm.

Jacques

jaxato@gmail.com wrote:
> Hello PPL,
> 
> I would like to know what are the current implementations for the
> internal blocks inside a DSP48E. This of course applies to the new
> Virtex-5 FPGA. How is Xilinx building, at RTL, the 25 X 18 multiplier
> (is it a booth?) as well as the 48 X 48 adder blocks?
> 
> Thanks for any help
> Jacques
> 
  One hint to the internal construction lies in the fact that the V4 
documentation tells you that the adder is a three input adder that 
performs the final add in the multiplier plus the C input.  From that, 
you can infer a carry-save architecture (Booth is one possibility).  Of 
course, you still don't know the exact details, but it does narrow it 
down considerably.

On Thu, 25 May 2006 20:47:59 -0400, Ray Andraka <ray@andraka.com>
wrote:

>jaxato@gmail.com wrote:
>> Hello PPL,
>> 
>> I would like to know what are the current implementations for the
>> internal blocks inside a DSP48E. This of course applies to the new
>> Virtex-5 FPGA. How is Xilinx building, at RTL, the 25 X 18 multiplier
>> (is it a booth?) as well as the 48 X 48 adder blocks?
>> 
>> Thanks for any help
>> Jacques
>> 
>  One hint to the internal construction lies in the fact that the V4 
>documentation tells you that the adder is a three input adder that 
>performs the final add in the multiplier plus the C input.  From that, 
>you can infer a carry-save architecture (Booth is one possibility).  Of 
>course, you still don't know the exact details, but it does narrow it 
>down considerably.

Forgive me if I don't understand but what does Booth have to do with
carry-save ? Booth is a partial product generation/reduction techique.
How you add the resulting partial products (carry-save, carry-select,
ripple) has nothing to do with it. Also you can do carry-save without
doing a booth encoding first. Actually there are some studies which
say that booth encoding is not suggested for vdsm technologies.