ISE WARNING Xst:647

Hi,

I have a design that works fine in Quartus.

In the process of porting it to ISE, I'm getting a series of these
warnings and can't for the life of me work out why...

An example:
WARNING:Xst:647 - Input <vblank> is never used.

But it clearly _is_ being used!?! Same for all the other signals that it's
complaining about.

Normally I'd suspect a missing clock but that doesn't appear to be the
case. (For the record the clock for this process isn't actually meeting
all timing constraints at the moment.)

Any tips would be appreciated - it's driving me (more) insane!
Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Mark McDougall

Have you checked to see if ISE hasnt optimised the logic connected to
those signals away (like you said, often caused by an unconnected
clock)? Use a post synthesis RTL and Technology veiw to have a look.
Quartus has them, Im sure ISE must have them too.

Tricky

Tricky wrote:
> Have you checked to see if ISE hasnt optimised the logic connected to
> those signals away (like you said, often caused by an unconnected
> clock)? Use a post synthesis RTL and Technology veiw to have a look.
> Quartus has them, Im sure ISE must have them too.

I'll check out the RTL viewer - thanks!

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Mark McDougall

Tricky wrote:

> Have you checked to see if ISE hasnt optimised the logic connected to
> those signals away (like you said, often caused by an unconnected
> clock)? Use a post synthesis RTL and Technology veiw to have a look.
> Quartus has them, Im sure ISE must have them too.

OK, now I am officially insane!

I have 2 projects with a lot of common modules which I have been porting
to Xilinx. The 1st has no video output, the 2nd works perfectly.

I was looking at the RTL viewer for the video controller (common to both)
for the 1st project with no video. It shows the X pixel output as being
tied to GND, and NO y pixel output at all! I can't explain why it has
decided to do this, but it would explain why there is no video.

So I go to the working project, and view the RTL for the same controller.
It TOO shows X pixel output tied to GND and NO y pixel output!!!! Let me
reming you, this project works perfectly!

So there you have it, I am certifiably insane! Either I have no clue what
I am looking at, or Xilinx RTL viewer is complete and utter garbage!?! I'm
willing to accept either hypothesis as being true at this point...

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Mark McDougall

Have you assigned output to actual output pins? are the outputs at the
top level? If you havent assigned pins, it should, by default, assign
the output to the next available pins. Did it run out of pins to
assign the signal too?

If its not there in RTL view, it sounds like theres been some serious
logic removal - go back through the synthesis logs; it should warn you
that logic has been removed. The removal of 1 register could have
caused all of this to happen.

Tricky

Mark McDougall wrote:
>
> WARNING:Xst:647 - Input <vblank> is never used.
>
> But it clearly _is_ being used!?! Same for all the other signals that it's
> complaining about.
>

I've seen a number of cases where XST mistakenly optimizes
away necessary logic in working and tested code, causing symptoms
like you've described.

Once XST improperly trims one signal, the mistake often snowballs
as XST merrily optimizes away other useful things connected to it.

Tracking these problems down usually involves isolating one signal
that you KNOW should be used, then deleting everything else one
chunk at a time until the problem disappears or you're down to a
repeatable testcase. ( The RTL viewer is also a bit buggy, often not
properly displaying signals and wires )

Recently I've seen these problems in migrating old code
due to confusion on XST's part in a multibit comparison, such
as an address decode of a bus against a constant, when XST loses
track of whether one side or the other is signed/unsigned.
Adding a dummy '0' MSB in front of each term usually will
band-aid this particular problem away.

E.g., the following chip select decode will be mistakenly
optimized away in recent XST versions :

alias decode_field : std_logic_vector(3 downto 0) is address(15
downto 12);
constant CS2_ADDRESS : std_logic_vector(3 downto 0) := B"1010";
....
cs2_l <= '0' when ( io_enable = '1' ) AND ( decode_field =
CS1_ADDRESS )
else '1';

But only when:
- decode_field is an alias (signals work ok)
- the constant CS2_ADDRESS has the MSB set
- the old std_logic_signed package is used
( numeric_std, or just std_logic_unsigned."+" is ok)

have fun,
Brian

Brian Davis

On Nov 29, 11:29 pm, Mark McDougall <ma...@vl.com.au> wrote:
> Tricky wrote:
> > Have you checked to see if ISE hasnt optimised the logic connected to
> > those signals away (like you said, often caused by an unconnected
> > clock)? Use a post synthesis RTL and Technology veiw to have a look.
> > Quartus has them, Im sure ISE must have them too.
>
> OK, now I am officially insane!
>
> I have 2 projects with a lot of common modules which I have been porting
> to Xilinx. The 1st has no video output, the 2nd works perfectly.
>
> I was looking at the RTL viewer for the video controller (common to both)
> for the 1st project with no video. It shows the X pixel output as being
> tied to GND, and NO y pixel output at all! I can't explain why it has
> decided to do this, but it would explain why there is no video.
>
> So I go to the working project, and view the RTL for the same controller.
> It TOO shows X pixel output tied to GND and NO y pixel output!!!! Let me
> reming you, this project works perfectly!
>
> So there you have it, I am certifiably insane! Either I have no clue what
> I am looking at, or Xilinx RTL viewer is complete and utter garbage!?! I'm
> willing to accept either hypothesis as being true at this point...
>
> Regards,
>
> --
> Mark McDougall, Engineer
> Virtual Logic Pty Ltd, <http://www.vl.com.au>
> 21-25 King St, Rockdale, 2216
> Ph: +612-9599-3255 Fax: +612-9599-3266

When ISE acts weird, clicking on PROJECT/Cleanup Project Files, and
then re-synthesizing often works.
-Dave Pollum

Dave Pollum

Brian Davis wrote:

> But only when:
> - decode_field is an alias (signals work ok)
> - the constant CS2_ADDRESS has the MSB set
> - the old std_logic_signed package is used
> ( numeric_std, or just std_logic_unsigned."+" is ok)

Thanks for the tip Brian! This is certainly a possibility, as I'm a big
fan of aliases... I'll look into it with this in mind!

How you found that, I have no idea, but thanks again!
Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Mark McDougall

Mark McDougall wrote:

> Thanks for the tip Brian! This is certainly a possibility, as I'm a big
> fan of aliases... I'll look into it with this in mind!
>
> How you found that, I have no idea, but thanks again!

Hmmm, no dice. I removed std_logic_unsigned altogether, and there's no
aliases in there that should affect it...

Frustrating, because the design differs only from the Altera project in
the memory block instantiations, and the DCM replacing the PLL. And a
similar project, ported to Xilinx from Altera with much the same
architecture, runs fine.

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Mark McDougall

Mark McDougall wrote:
>
> > But only when:
> > - decode_field is an alias (signals work ok)
> > - the constant CS2_ADDRESS has the MSB set
> > - the old std_logic_signed package is used
> > ( numeric_std, or just std_logic_unsigned."+" is ok)
>
> How you found that, I have no idea, but thanks again!
>

Years of practice!!!
( Plus the divide-and-conquer technique I described earlier )

I've been using XST for 'home projects' since it was released
with Webpack 3.1i in 2000, and Synplify since ~1997 at work.

XST is great for a free synthesis tool, and Xilinx has improved
the language coverage dramatically since its' launch, but XST is
far more likely to produce incorrect logic than Synplify.

Some of the sneakier issues are the never-ending signed/unsigned
bugs, the various logic optimization errors, and the need for a
unique index variable name in every 'for' and 'generate' loop.

Xilinx normally summarizes these problems in an "XST Known Issues"
Answer Record, like 21682, but I haven't seen one of those for 9.x

>
>Frustrating, because the design differs only from the Altera project in
>the memory block instantiations, and the DCM replacing the PLL.
>

XST 9.1 has some nasty bugs (fixed in 9.2) that cause it to
drop pipeline stages near inferred memories, but that doesn't
affect instantiations, nor cause wholesale logic removal.

Brian

Brian Davis