ISE WARNING Xst:647

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,

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,

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.

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

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

-Dave Pollum

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,

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,

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

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

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