High Level
JEDEC- Map of fuses that get mapped to JTAG commands while flashing.
SVF- Control how JTAG is written via a file.
JTAG- Protocol for talking to a chip (IEEE 1149.1). Also includes provisions for programming ().
Bitstream files- Subset of JTAG commands that the FPGA reads on power-up. Programmed into the chip or SPI flash (to be read on power-up) using a superset of commands found in a bitstream file (e.g. LSC_INIT_ADDRESS shared).
Low Level

* UFM and Feature Row contents can be embedded in JED and SVF files, but not bitstream files.
* JEDEC programs bits from left-to-right (MSb), ascending order.
  Fuse bits match the order bits are stored in .bit file (MSb/MSB first).
* JEDEC doesn't store the comment at the beginning of the bit files.
* Even disregarding the "comment", no guarantee that JEDEC will be a bit-perfect copy of the .bit file.
* JEDEC file has a NOTE which splits Config Data and empty pages not used by config data
* 1 page == 128 bits (16 bytes).
* UFM "L" address begins immediately after config data (number_of_cfg_pages * 128)
* Fuse count is (number_of_cfg_pages + num_of_ufm_pages + 1) * 128. Seems to be 16-bits extra (feature row + feature bits + usercode)
* Config rows are extended to page size, but feature row + feature bits + usercode is not.
* bitgen gets the flash memory contents name from the NCD file (when generating the JED file).


* ddtcmd mildly annotates the input JED file, but doesn't appear to change contents in output.
* ddtcmd also mildly annotates input .bit file, but doesn't appear to change contents in output.

* No guarantee that SVF will be a bit-perfect copy of the .bit or JEDEC file either. In particular, SVF seems to add extra NOOP bits when copying the bitstream for SRAM programming.
* SVF rows (pages) shift out right (so first bit to be written is LSb). Contrast to JEDEC/.bit.
  
* Compressed bitstreams add padding bits per row even if the row is already byte-aligned (8 padding bits).


* SPI and I2C are MSbit first when tx/rx commands.
* JTAG is LSB (IEEE 1149.1).
* JTAG opcode goes to IR. Operands go to DR (if they're even included!).

* SVF JTAG seems to remove required opcode operands. Opcodes used while loading bitstream seem to include them.
  openFPGALoader includes the operands during JTAG programming, but I confirmed that openFPGALoader works w/ a Diamond-generated SVF that omits operands.
  Maybe RUNTEST back to IDLE is what matters?
  TODO: LSC_BITSTREAM_BURST doesn't have an IDLE after sending the opcode _and_ no operands. What happens if I remove a sufficient number of dummy bytes from an LSC_BITSTREAM_BURST's payload? Some of those dummy NOOP bytes are presumably used as operands to LSC_BITSTREAM_BURST?

* Internal Flash: IEEE 1532 plus extensions.
* External Flash: Undocumented instruction 0x3A: https://twitter.com/GregDavill/status/1251786406441086977.
  It appears that instruction 0x79 is REused in the context of a bitstream (in external SPI flash only?) to identify whether SPI flash is single, dual, quad, etc.
  Normally, 0x79 is REFRESH command in the context of JTAG. I don't feel like possibly damaging a part to determine what 0x79 does in internal flash.
* SRAM Programming: Transmit everything in the .bit file except for the comment using LSC_BITSTREAM_BURST command. LSC_BITSTREAM_BURST may be a higher level version of LSC_PROG_INCR_RTI?
* Feature Row, Feature Bits, and USERCODE are separate programming/read commands, even if Lattice puts them logically into the same sector.
  USERCODE seems to be either at end of config sector or in Feature Row.
  Feature bits are 16 bits kept separate from rest of Feature Row (64 bits).

Proposal:

Add .ufm_init, analogous to .bram_init. For .bit output, don't emit a UFM file to be programmed unless asked to.
Look at EBR instantiation for filename.