On Windows, attempting to generate a netpbm image of the CRAM with
icepack -b causes the tool to crash after writing only the netpbm
header due to a stack overflow. The bug did not appear on Linux.
This was traced to a large stack-allocated variable length array
(tile_type) inside FpgaConfig::write_cram_pbm. For an 8k ice40 with
4 banks, cram_width = 872 and cram_height = 272 the tile_type
array ends up at 4 * 872 * 272 * sizeof(uint32_t) = 3794944 bytes, or
about 3.6 MiB.
The fix replaces the large stack VLA with an array of 4 (bank) 2D C++
vectors, moving the large amount of data to the heap. Even though the
fix is not in a Windows-specific code path (and hence applies to all
platforms), I think it's wise to eliminate such a large stack allocation
entirely.
The fix has been tested working on both Windows and an Ubuntu WSL
install.
…s #241)
On Windows, attempting to generate a netpbm image of the CRAM with
icepack -bcauses the tool to crash after writing only the netpbm header due to a stack overflow. The bug did not appear on Linux.This was traced to a large stack-allocated variable length array (
tile_type) insideFpgaConfig::write_cram_pbm. For an 8k ice40 with 4 banks,cram_width = 872andcram_height = 272thetile_typearray ends up at4 * 872 * 272 * sizeof(uint32_t) =3794944 bytes, or about 3.6 MiB.The fix replaces the large stack VLA with an array of 4 (bank) 2D C++ vectors, moving the large amount of data to the heap. Even though the fix is not in a Windows-specific code path (and hence applies to all platforms), I think it's wise to eliminate such a large stack allocation entirely.
The fix has been tested working on both Windows and an Ubuntu WSL install.