ISE WARNING Xst:647

M

Mark McDougall

Guest
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
 
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 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.
Click to expand...
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
 
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.
Click to expand...
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
 
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.
 
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.
Click to expand...
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
 
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
Click to expand...
When ISE acts weird, clicking on PROJECT/Cleanup Project Files, and
then re-synthesizing often works.
-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)
Click to expand...
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 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!
Click to expand...
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
 
On Nov 29, 8:36 am, Mark McDougall <ma...@vl.com.au> wrote:
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
Click to expand...


if u connect sub modules with each other (port connection),
and u dont use all signals in 2nd module, ISE ll issue that warning.
even if that port u use in submodules, but if it have no contribution
to your all logic, ISE ll give warning.
because during optimization ISE not create any hardware for unused
logic. (the logic which have no contribution to your path i.e input to
output).
if u also out ur warning ports through ur top module. then no warning
ll b issued.

Regards
Shahid
 
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!
Click to expand...
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.
Click to expand...
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
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top