[Fpga-synth] Very Odd Error Message from WebPACK ISE

[Scott Gravenhorst]

"The making of synthesizers in FPGAs." wrote:
>Scott Gravenhorst wrote:
>> "The making of synthesizers in FPGAs." wrote:
>>> Scott Gravenhorst wrote:
>>>> "The making of synthesizers in FPGAs." wrote:
>>>>> Scott Gravenhorst wrote:
>>>>>> While working on this latest synth, I am getting this error:
>>>>>>
>>>>>> ERROR:Portability:74: - 
>>>>> ************************************************ 
>>>>> Port_Compress::UnCompress() : (Z_DATA_ERROR) input data was 
>>>>> corrupted. 
>>>>>
>>>>> What stage of the build process were you in when you saw this? XST, 
>>>>> NGDBUILD, MAP, PAR, BITGEN?
>>>>>
>>>> I didn't notice before, but I've now ran just XST - it happens there.
>>> Odd. I was thinking maybe it was Bitgen trying to compress the 
>>> bitstream. Afraid I've got nothing for you here...
>>>
>> 
>> Krap.  I was hoping it was some bonehead thing that is known by some and that I can
>> safely ignore it.  While the compile completes and the design appears to work, I
>> certainly don't like the error.  If I know I should ignore it that's one thing...  
>> 
>> At some point in time, I will uninstall ISE, download a fresh copy of everything for
>> ISE, and reinstall.  I will then test it before and after applying updates in case
>> this is an issue with one of the updates.
>> 
>> Or do you have another, perhaps better thing to try?
>
>I've never had to re-install ISE to solve a problem, but then I do 95% 
>of my Xilinx development on Linux which seems to be more robust in the 
>way apps, libraries & permissions are handled than most WinXX versions.
>
>I've been using 10.1.03 for the last few weeks trying to get a number of 
>large designs ported over from VIIPro to V5. In general it's working 
>well and I'm pretty happy with it. There are glitches though, including 
>some cryptic errors that aren't well documented on the Xilinx support site.
>
>Some of these problems cause XST to bail out before generating the final 
>.ncg file and the only solution I've found is to re-write some of the 
>Verilog source code to require less complex inference. I've found that 
>it's especially sensitive to the way SRL and DSP48 blocks are treated. I 
>haven't had to fall back to bare instantiation in most cases, but coding 
>the Verilog so that it has a 1:1 match to the resources really seems to 
>help.
>
>That's not to say that this is what you need to do, but if you can track 
>down where in the development process you started to get these 
>errors/warnings you may want to consider an alternate way to express the 
>logic that was introduced when they appeared.
>
>Just my $0.02. YMMV

Quite honestly - it started when I got the thing to compile and make sound.  Until then, there were
issues with the code that either prevented it from finishing the compile or it wouldn't make sound.
 I noticed the error after I got sound out of it and honestly hadn't paid much attention to the
summary display.  I use a set of scripts to process .syr and other files that give me up-front
information about really bad things I may have done.  And of course, this is the only copy of the
source, I don't have previous nonworking attempts archived.

Thus I shall plod and slog as usual until the beast is revealed...

At least I've go a fiber optic internet connection and ISE will take only about 40 minutes to download.

I may try reducing the size of the project to see if it goes away.

BTW, this is for a Spartan-3A DSP 1800.


-- ScottG
________________________________________________________________________
-- Scott Gravenhorst
-- FPGA MIDI Synthesizer Information: home1.gte.net/res0658s/FPGA_synth/
-- FatMan: home1.gte.net/res0658s/fatman/
-- NonFatMan: home1.gte.net/res0658s/electronics/
-- When the going gets tough, the tough use the command line.