icebin2nvcm: tool to generate .nvcm file from iCE40 .bin

[majbthrd]

I've tested this by verifying its output compares with pre-existing matching .bin and .nvcm files from Lattice tools. I've also been able to use the generated .nvcm with Lattice Diamond Programmer.

It should be obvious to anyone familiar with 25 series PROMs that the .nvcm is a text version of the SPI transactions to program the NVCM. Lattice's app note acknowledges that this is the case. Note that the page size is 8 bytes.

IMPORTANT: the NVCM is ONE-TIME PROGRAMMABLE!!! Just because it is programmable doesn't make it re-programmable.

Hopefully, this tool will enable yosys iCE40 users to generate .nvcm files. It might also help Lattice users who only have a .bin and need a .nvcm; the Lattice tools don't seem to provide such a conversion.

[djedditt]

Great tool! You might want to replace #include <malloc.h> with #include <stdlib.h> as it won't compile on OS X otherwise. The malloc.h header is non-standard and not available in OS X.

[majbthrd]

Thanks @djedditt. I have added the suggested change.

[PsiStarPsi]

I would like to add that I have programmed an NVCM generated in this fashion from @majbthrd 's fork and it worked as expected on a design with an iCE40 UP5K in the 30-ball WLSCP package.

It would be very nice to have this feature merged into the main line. =)

[cibomahto]

Thanks! With Diamond Programmer 3.12.1.454.2, trying to load a file for an iCE40UP5K target, I got the following error:

WARNING - Cannot get the device name from the file.
File C:/Users/matt/Other-Repos/tillitis-key1/hw/production_test/binaries/top.nvcm:
 is invalid for expected iCE40UP5K  device.

Adding a stub comment to the beginning of the NVCM file allowed Diamond to accept the file, and NVCM Program,Verify succeeded after that:

#DN a      <--added
06    <--previous start of .nvcm file
02 00 00 00 7e aa 99 7e 51 00 01 05 
02 00 00 08 92 00 20 62 02 b3 82 00 
02 00 00 10 00 72 01 50 11 00 01 01 

I think Diamond programmer is supposed to validate both the #DN and #PT fields, but it doesn't appear this is the case.

I was also able to generate this higher up in the toolchain by adding the comment to my .asc file:

.comment from next-pnr
Part: device-part

but it doesn't appear that nextpnr has a feature to do this automatically:
https://github.com/YosysHQ/nextpnr/blob/48b0025732f7b5b1b7b091691bb5a26634ae5069/ice40/bitstream.cc#L301