Virtex-4 DSP48 placement restrictions?

[...]

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

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

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.

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.

Check.

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

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.