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

[Eric Brombaugh]

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

Eric