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.
LP384 is now supported in icepack, it was fairly easy to realize as only the main chip dimensions are required that could be found out from the .bin bitsream file generated by iCEcube.
Tested by creating .asc then packing it back to .bin. The testcase is just a simple LED on/off on a port though but that shows geometries are fine.
Now I'm trying to have and support chipdb-384.txt hopefully with some help from the authors and anyone who already knows the internals of IceStorm well. I need info, how to reverse-engineer iCE40 chips the easiest way. Scripts maybe.
I'm trying to reach my goal in any way coz iCEcube sucks and IceStorm integrates well into commandline...