FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 12-05-2005, 04:21 PM
Brian Drummond
Guest
 
Posts: n/a
Default Virtex-4 DSP48 placement restrictions?


Hi all,

I'm looking for ideas why a design using 43 DSP48s as multipliers might
not fit a V4LX25 with 48 DSPs...

Symptoms are PAR failing with ten PLACE:119 warnings and a PLACE:120
error.

Most of the DSP48s are cascaded, but only in pairs (for 24x<16 mults),
so it doesn't look like AR20093 and AR20851 should apply. I'm not
(knowingly ) using BUFRs, so I don't think 20511 applies. And I can't
see any other AR that seems relevant; nor comp.arch.fpga posts.

The design does use some RAMB36_36 blocks (I need wide I/O and not much
depth); so I wondered about the Spartan-3 RAMB/Mult packing restriction,
but I haven't seen any similar warnings about V4...

Before I try floorplanning the DSPs, has anyone seen any similar
failures?

- Brian
Reply With Quote
  #2 (permalink)  
Old 12-05-2005, 09:51 PM
Brian Drummond
Guest
 
Posts: n/a
Default Re: Virtex-4 DSP48 placement restrictions?

On Mon, 5 Dec 2005 15:21:07 +0000 (UTC), Brian Drummond
<[email protected]> wrote:

>
>Hi all,
>
>I'm looking for ideas why a design using 43 DSP48s as multipliers might
>not fit a V4LX25 with 48 DSPs...

[...]
>The design does use some RAMB36_36 blocks (I need wide I/O and not much
>depth); so I wondered about the Spartan-3 RAMB/Mult packing restriction,
>but I haven't seen any similar warnings about V4...


And a definitive statement that there are no shared routing problems.

>Before I try floorplanning the DSPs, has anyone seen any similar
>failures?


Some progress: floorplanning the DSPs yields different errors; I have
been caught by the shared C bus into the subsequent addition logic.

It seems XST has been aggressive enough in packing adders into the DSP
blocks to make the resultant design unfittable.

Since XST is told the target device, and must be aware of this basic
limitation, I regard this as an XST bug. XST counts and reports the DSPs
used; it must be equally easy to count the independent C buses...
Yes I know: open a webcase. Well, if I can spare another day soon to
make an easy testcase, I will.

Meanwhile, there must be some way to control XST's use of DSP blocks; if
I can find it in Answers, panic over.

- Brian
Reply With Quote
  #3 (permalink)  
Old 12-05-2005, 10:02 PM
Ray Andraka
Guest
 
Posts: n/a
Default Re: Virtex-4 DSP48 placement restrictions?

Brian Drummond wrote:
> Hi all,
>
> I'm looking for ideas why a design using 43 DSP48s as multipliers might
> not fit a V4LX25 with 48 DSPs...
>
> Symptoms are PAR failing with ten PLACE:119 warnings and a PLACE:120
> error.
>
> Most of the DSP48s are cascaded, but only in pairs (for 24x<16 mults),
> so it doesn't look like AR20093 and AR20851 should apply. I'm not
> (knowingly ) using BUFRs, so I don't think 20511 applies. And I can't
> see any other AR that seems relevant; nor comp.arch.fpga posts.
>
> The design does use some RAMB36_36 blocks (I need wide I/O and not much
> depth); so I wondered about the Spartan-3 RAMB/Mult packing restriction,
> but I haven't seen any similar warnings about V4...
>
> Before I try floorplanning the DSPs, has anyone seen any similar
> failures?
>
> - Brian


A couple of possibilities:
First, check to make sure you don't have a C port conflict. The two
DSP-48's in a single DSP48 slice share the C-Port, so either both must
use the same value on the CPort, or one must not use the CPort. The
software looks for a specific combination of controls for the CPort to
flag it as unused. If you don't match the template, it may not allow
the two DSP48's to occupy the same slice. The magic incantation for a
disabled CPORT is Cport input bits all equal '0', CREG attribute=0, CEC
control='1' and RSTC control='1'. The tools supposedly look at the
opmode to determine if the CPort is used or not: if it is a static
opmode (all opmode bits connected to constants), then it should
determine the Cport is unused without the magic incantation. If any
bits of the opcode are not static, then the magic incantation is required.

The second possibility is that if you are using ISE7.1, you have to have
service pack 4. The earlier service packs had a bug with placement of
instantiated DSP48s. If you are not using service pack 4, upgrade to it
before you do anything more. Ironically, ISE6.3 didn't have the placer
bug. I wound up using 6.3 exclusively until SP4 for 7.1 was released
because of this issue.

A third possibility is that the placer doesn't do a very good job
figuring out placement of DSP48's, especially when there are some
cascaded. Since you have over half of them utilized, there is a good
chance you will have to put LOCs on them to get a suitable placement
solution.

There is no packing issue between DSP48's and RAMB16's. They are not
co-located like they were in S3 and V2.
Reply With Quote
  #4 (permalink)  
Old 12-06-2005, 12:30 PM
Brian Drummond
Guest
 
Posts: n/a
Default Re: Virtex-4 DSP48 placement restrictions?

On Mon, 05 Dec 2005 16:02:43 -0500, Ray Andraka <[email protected]> wrote:

>Brian Drummond wrote:
>> Hi all,
>>
>> I'm looking for ideas why a design using 43 DSP48s as multipliers might
>> not fit a V4LX25 with 48 DSPs...


>A couple of possibilities:
> First, check to make sure you don't have a C port conflict. The two
>DSP-48's in a single DSP48 slice share the C-Port, so either both must
>use the same value on the CPort, or one must not use the CPort. The
>software looks for a specific combination of controls for the CPort to
>flag it as unused. If you don't match the template, it may not allow
>the two DSP48's to occupy the same slice.


Thanks Ray, you were spot on; this was it! I still don't know where to
look for the template, because I am letting the synthesis tools infer
the slice usage.

And it was doing so in a way incompatible with the target part.
So I needed some way of controlling synthesis better than
"mult_style=LUT" or "use_DSP=NO" :-)

And I found it:
(though the label doesn't QUITE describe the problem!)

"Answer Record: 18498
6.3i XST - XST creates incorrect logic with a multiply subtract function
for Virtex-4" suggests

attribute KEEP: string;
attribute KEEP of mult_registered_output : signal is "true";
which forces the internal adder to be bypassed, thus ensuring neither
mult uses the C port.

If I get into capacity trouble I'll find a way to place this on half of
the identical components, to use the C port in alternate mults, but I'm
OK for now.

Xilinx could definitely improve documentation on this problem; "Keep" is
also mentioned (without linking to further info) as a footnote under
"Use_DSP=NO" which I wouldn't normally have considered, since I NEED the
DSPs... it doesn't appear at all in the "hints on using DSPs" documents
OR the "inferring functions in DSPs" documents where it would actually
be useful.

I'm sure the synthesis tool could also count C ports used as well as
DSPs used, to give a better indication of capacity problems AND a
clearer idea of the solution.

>The second possibility is that if you are using ISE7.1, you have to have
>service pack 4.

Check.

>A third possibility is that the placer doesn't do a very good job
>figuring out placement of DSP48's, especially when there are some
>cascaded.


That was my first thought; hand placing them changed the error message
to the C port one; which with your answer, led me to the solution.

Thanks again,
- Brian
Reply With Quote
  #5 (permalink)  
Old 12-06-2005, 07:08 PM
Ray Andraka
Guest
 
Posts: n/a
Default Re: Virtex-4 DSP48 placement restrictions?

Brian Drummond wrote:


>>A couple of possibilities:
>> First, check to make sure you don't have a C port conflict. The two
>>DSP-48's in a single DSP48 slice share the C-Port, so either both must
>>use the same value on the CPort, or one must not use the CPort. The
>>software looks for a specific combination of controls for the CPort to
>>flag it as unused. If you don't match the template, it may not allow
>>the two DSP48's to occupy the same slice.

>
>
> Thanks Ray, you were spot on; this was it! I still don't know where to
> look for the template, because I am letting the synthesis tools infer
> the slice usage.
>


Brian, Not sure for an inference template. The magic incantation I
referred to is documented in v2.0.1 of the V4 DSP guide (oct 18,2005) at
the bottom of page 26. I don't believe it was documented in the earlier
versions of the guide.

This is one of those things that if you want any control over the
design, you are better off instantiating the DSP48s. Of course that
makes your code less portable.

The problem with inferring them is the behavior can change drastically
between versions and vendors of the synthesis tools.

Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Virtex-4 DSP48 - special features (Peter Alfke?) Udo FPGA 2 10-31-2005 06:29 PM
Virtex-4: DSP48 Fmax missing? William FPGA 3 10-22-2004 01:54 PM
Placement vs Map in 6.2i, sp3 Simon FPGA 3 09-10-2004 08:53 AM
Relative placement constraints in VHDL for Virtex multipliers Jack Stone FPGA 1 07-25-2003 10:12 PM


All times are GMT +1. The time now is 03:16 PM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved