WARNING:Xst:382 - Why so many?

I've seen a few threads recently about warnings in XST so I thought I'd put in my 2 cents.

I've got a design where I instantiate the IOB flip-flops that drive the output enables. There are three sections with 5, 8 and 59 IOB's respectively that have equivalent IOB output enable timing. I still want all these flip- flops because they need to push into the IOB's to meet the clock-to-out timing requirements.

Now XST decides to warn me that the flip-flops in each group are equivalent to eachother. That isn't too bad because I can ignore the warnings and it builds what I asked. Here's the fun part. In each group the number of warnings I get is 5 times the number of combinations of N things taken 2 at a time, where N is the number of equivalent flip-flops. So for the case of the 59 flops I get 8,555 warnings. Displaying these warnings takes the bulk of the synthesis time for the design.

I can see that the synthesizer may be too dumb to whittle down the warnings to one per flop, but why are there 5 times the number necessary to pair each flop with each equivalent flop?

It would be really nice to have a way to tell the synthesis not to produce this particular type of warning (or other types you've already seen and don't want to see again on the next build).

Reply to
Gabor
Loading thread data ...

In the past I have built large RPMs that incurred warnings that took minutes to generate and scroll through per run.

In the C++ compiler world we have flexible mechanisms like "#pragma warn" that can suppress specific warnings (possibly in selected areas) or even promote certain warnings to errors. A similar mechanism might be of use here.

Jan Gray

Reply to
Jan Gray

Gabor,

Hiding specific messages is a feature that exists in XST 6.Xi and will be enhanced in 7.1i. This feature was added to reduce runtime as well as log file size and clutter.

In the 6.Xi tools, use the XIL_XST_HIDEMESSAGES environment variable to filter all messages that fall into two categories. The set of messages filtered are fixed, but #382 is one of the low level messages. Consult chapter 9 of the XST User Guide for the lists of messages and details about how to enable this feature. The message filtering was implemented in this way to be a stepping stone for the functionality planned for 7.1i.

In ISE 7.1i (due out in a few weeks), there is a message manager that will allow the user to filter out not only specific messages by number, but also specific instances of specific messages. This feature will extend filtering beyond just XST; most of the implementation tools will take advantage of this feature.

As for the messages in the first place, have you tried inferring these registers? XST will pack output and output enable flops in the IOBs, and will replicate the output enable flops if necessary.

thanks, David Dye Xilinx Technical Marketing

Reply to
David Dye

will

well

to

messages

Consult

implemented

7.1i.

Thanks for the tip, this really reduces my build time!

number,

will

So does this mean I'll be able to "mark" warnings in a report file viewer somehow so it doesn't appear on the next build? i.e. can I effectively see only new messages on each successive build?

these

I didn't try inferring the registers, because I took this part of the design from a Xilinx reference design (XAPP 608) so I had this problem from the beginning. Also in this case the warnings were not hard to ignore because they were together in one long section of the report file. Really just the build time was the headache.

Reply to
Gabor

Good to hear. Glad to help.

What you'll see on subsequent runs depends on how you mark the existing messages. For example, if you say "Filter all instances of this message", then it will hide all messages with a particular number, even new ones. You can also say "Filter this instance only", and any new ones will show up. Of course if you have over 8000 instances, you won't want to set the individual filter for each one. We will have wildcard capabilites later this year.

When 7.1i comes out check out the help pages on the message filter to learn about all the new capabilities.

thanks, David Dye Xilinx Technical Marketing

Reply to
David Dye

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.