JEDEC file support

[cr1901]

Some MachXO2 boards (e.g. the STEP-MXO2) have an on-board microcontroller which talks to the FPGA JTAG on the user's behalf. Sometimes, these microcontrollers only accepts Lattice-generated JEDEC files, not .bit or SVD files. So this PR implements JEDEC file generation. I'm marking as draft right now, b/c while the core works, some things are incomplete. However, I would appreciate feedback now that I have something working. I'm also happy to split this into multiple issues/PRs:

• Bail if JEDEC is used without --compress option.
  • This is in line w/ Lattice tools.
• Feature Row, Feature Bits, and USERCODE bits generation.
• ECP5 and MachXO3 support.
  • It is not clear to me that JEDEC programming is meaningful for ECP5. It's probably only used to set Feature Row, Feature Bits (sic, different from Feature Row), and USERCODE, and IDCODE (? I didn't know you could do that). SVF may work just fine for that purpose. The MachXO families really do need JED support, however, thanks to internal flash programming.
  • The "usable pages" on page 49 of FPGA-TN-02155 do not actually add up to the number of fuses on each MachXO2 variant. I assume this is also the case for MachXO3, but have not generated JED files to check yet.
• Diamond compatibility.
  • Both STEP-MXO2 and openFPGALoader expect certain NOTE fields to be present in the JEDEC file. I added a --jed-note field as a limited workaround for STEP-MXO2.
  • STEP-MXO2 relies on parsing the package number in the JEDEC file, for instance: DEVICE NAME: LCMXO2-4000HC-6CSBGA132. Presently, the textual format only includes part and package number as a .comment, rather than a structured field I can rely on not changing. Are there any objections to adding a package field to the textual format?
• User Flash Memory support
  • The MachXO2/3 User Flash Memory probably works with open tools now that MachXO2 #232 is in. However, there isn't currently a great way to program your own file onto the User Flash Memory with open tools. As far as Lattice is concerned, User Flash Memory fuses immediately follow Config fuses in JEDEC files, and are programmed the same way. Despite this, openFPGALoader parses NOTE fields to find the User Flash Memory, so this also ties into Diamond compatibility.
  • Lattice generates User Flash Memory fuses at synthesis time, by reading the file pointed to by the UFM_INIT_FILE_NAME parameter of an EFB primitive instantiation. My proposal is to add a .ufm_init/.ufm_start_page. field to the textual format, analogous to .ebr_init for Lattice compat with UFM_INIT_FILE_NAME, with maybe a command-line override to ecppack to change out the UFM image at packing time.

1. For modifying config bits on MachXO2, Lattice's own official tools seem to like parsing JED files instead of SVFs. SVFs seem to be more of a side effect of JED generation/manipulation in Diamond Programmer.

[gatecat]

Sorry for the delay in getting back on this one!

ECP5 support

I don't think this is much interest personally right now, the few things that you can program with a .JED are OTP and so there's a pretty high risk of bricking parts while testing it...

Are there any objections to adding a package field to the textual format?

Yes, although I'd prefer this to be only generated for MachXO2/3 for now, so we don't have an unnecessary compatibility break for the much larger ECP5 user base.

My proposal is to add a .ufm_init/.ufm_start_page. field to the textual format, analogous to .ebr_init for Lattice compat with UFM_INIT_FILE_NAME, with maybe a command-line override to ecppack to change out the UFM image at packing time.

No objections

[mmicko]

@cr1901 and @gatecat Will probably start taking care of JED support since it is also needed for some XO2/3 features. @cr1901 Will let you know about progress

[cr1901]

@mmicko I already implemented JED support in the PR, so feel free to add to it if you wish.