odd warning in Xilinx ISE webpack

At the XST-synthesize stage, I'm getting this weird warning: "Property use_dsp48" is not applicable for this technology. I don't have anything in my code that I know of that calls for any such thing.. it doesn't affect the program actually running on my board, but I'm curious anyway.

Anyone know what this means?

Thanks,

Steve

Reply to
Steve Battazzo
Loading thread data ...

Steve,

Can you tell me a little bit more about what device you are targeting and the version of WebPACK you are using. Are you using any multiplier blocks or doing any multiplication operations and pipelining the output?

-David

Reply to
davide

I just installed 9.1 (was using 7.1). I got the same warning. Spartan II, no multipliers, no pipelining.

Dan

Reply to
None

Thanks for the reply! Sorry it took me a while to get back, I haven't had time to check the newsgroup for a couple days. I'm using a Digilent Nexys board with a Spartan3 1000k gate chip, no multiplication, just some DFFs, MUXs, decoders, and simple logic. WebPack 9.1i on this computer.

Steve

davide wrote:

Reply to
Steve Battazzo

If your code uses some CoreGen function that was mis-targetted to a Virtex4 part you might get this. Essentially, SOMEWHERE in your code... probably hidden away in something automatically generated that you didn't even write... SOMETHING is telling ISE to target a DSP48 slice, which doesn't exist in your part.... start stripping out sub- blocks of the design until it goes away is my best suggestion.

Reply to
Paul

I'm getting the exact same pointless warning for a Spartan 3E design that's all VHDL. I've gone through all of the docs looking for where it's set and all that, and I came up with nothing. Apparently, it defaults to "no" (which is reasonable, because S3E doesn't have DSP48 blocks) but since the tool has a default for that attribute, it's still applied, and you get the warning. The tools should be smart enough to know this. It would be reasonable to get a warning if you actually set the use_dsp48="yes" attribute for S3E.

Xilinx' notion of "what's a Warning, what's an Info, and what should be ignored" is often perverse. Here's an example (and I've opened a support case about it):

VHDL has the "open" keyword, which you use on a port map to indicate that a port is not being used. (You use this a lot when instantiating DCMs,) So when you use "open," you're explicitly telling the tools: "I know I am not using this port." However, you get a nice, big yellow "WARNING!" triangle in your synthesis report, and a message saying, "Unconnected output port 'foo' of component 'bar.' " Yeah, I know this, and I used the keyword "open" to tell you to not tell me that the port is not connected!

On the other hand, I reused some old code that was supposed to infer a BRAM, and the inference didn't work and instead the tool built the memory out of slices and ate up all of the resources in my chip. I was kind of suprised when the mapper failed, saying that I was trying to use 200% of the slices. I went back to the synthesis report, and noticed an innocuous "Info:" line with a message about "due to asynchronous read, described memory could not be used with BRAMs, so it will be put into distributed RAM instead."

Seems to me that something that could affect the size and performance of a design should be a WARNING, and something where the tools are told "I know what I'm doing" shouldn't even be an Info!

-a

Reply to
Andy Peters

I've recently been trying to synthesize some well simulated VHDL code from years past, that works fine in XST 6.x, but fails horribly when using XST 9.1SP2

I've seen some of these {same} annoyances/problems so far: 1) spurious DSP48 warnings 2) 'open' keyword problems 3) 'alias' bugs cause huge chunks of logic to be "optimized" away

Details below.

Brian

------------------------

1) spurious DSP48 warn>

I've seen that bogus warning as well, for S3's and S2's targeted in 9.x; in addition to multiplies, the DSP48's also are inferred for add/subs in targets having them.

Just for fun, try clicking the "HELP" button in the synthesis/properties dialog box of 9.1SP2 XST : " " DSP Utilization Ratio (Advanced) (Virtex-4, Virtex-5, and Spartan-3AD only) "

Hypothetical Question of the Day:

If the "N" in S3-AN stands for "non-volatile", what might the "D" in "S3-AD" stand for ;)

------------------------

2) '>

This one gets even worse than the bogus warnings.

The "open" keyword is _needed_ to use certain primitives like BUFGMUX, which otherwise error out in PAR due to shared input routing restrictions when the adjacent BUFGMUX is in use.

Using "open" on an input is perfectly legal, as long as there is a default value specified for the component's input port.

Unfortunately, someone at Xilinx thinks otherwise, having removed the default values from certain library primitives, rendering them unusable, and placing the following misinformation in the latest 9.1 XST user Guide, pp445: " " According to the IEEE VHDL specification, input ports cannot be " left unconnected. As a result, XST always gives an error if an " input port is not connected; even the open keyword will not " suffice for an unconnected input port. " Which is just plain wrong.

Workaround for BUFGMUX:

LOC them all,then attach each of the unused BUFGMUX inputs, that formerly were 'open', to the input net that's being used by the adjacent BUFGMUX.

------------------------

3) 'alias' bugs cause huge chunks of logic to be "optimized" away

XST 9.x sometimes "optimizes" conditionals using aliases out of existence, resulting in an ever-growing cascade of logic removal.

Replacing the aliases with signals fixes the problem.

This error is consistent in my actual code, but I haven't managed to reproduce it yet in a simple test case, as it seems related to something else ( tool settings, constant aggregates in packages, ??? )

Reply to
Brian Davis

Agreed - and the RAM simulation libraries have the marvellous feature of checking for a read on one port with a write on the other to the same address. This would be OK, but they report it as an *error*! So my TB "fails". Surely that's a warning - there's lots of times I don't care that I've done that!

Anyway, I just turn them all off in modelsim by overriding a generic on them!

Cheers, Martin

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
 Click to see the full signature
Reply to
Martin Thompson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.