MachXO3D Security / Feature Row Programming

[ghost]

With the MachXO3LF it was possible to program the device with a JED file containing the Feature Row. However, with the MachX03D an exception is thrown at the end programming, and device is left in a non-working state (all LEDs on and dim).

write to ram Jtag frequency : requested 6.00MHz -> real 6.00MHz Enable configuration: DONE SRAM erase: DONE Open file DONE Parse file DONE Enable configuration: DONE Flash erase: DONE Writing data: [==================================================] 100.00% Done Program features Row: FAIL Error: Failed to program FPGA: std::exception

When generating a JED file without the feature row, the device is programmed OK. However, in this scenario the feature row is generated in a separate file (.fea) and OpenFPGALoader doesn't appear to provide a mechanism to program this?

[trabucayre]

machXO3D has been introduce by @fayalalebrun. In fact I've no board with this FPGA. Could you share a design for this device? Maybe I could fix this without hardware. If hardware is really required will try to get one. Thanks to highlight this issue.

[ghost]

Thank you for your response. I will see if I can get the FPGA guys to create a design that we can share.

I'm just going through the OpenFPGALoader code, along with the programming and configuration guide, and it seems there are quite a few differences (from the MachXO3LF) that haven't been taken into consideration for the MachXO3D.

They [Lattice] have reused commands, but with the operand bits meaning something different... For example, the Erase (0x0E) command: On the MaxXO3LF operand bit 16 => Erase SRAM, whereas on the MachXO3D bit 16 => Erase PubKey. The OFL code doesn't appear to account for / support this difference at present.

Once I've got to grips with the code, I'll have a go at implementing it - should also be able to submit a pull request (providing it doesn't turn out to be a complete hack).

[trabucayre]

Thanks for these informations. Need to compare both instructions sets to see differences. For lattice devices, there is a _fpga_family variable allowing to adapt behaviour according to targeted device. If it's too hard to adapt, I will see how to get an eval board for this device. Thanks

[ghost]

I have it working (except authentication - which I'll work on later). However, the changes are fairly extensive - confined to lattice.cpp, with very minor additions to the JedParser and a new command line arg (--flash-sector). I've created new program functions for the XO3D - as almost every step required a switch based on the _fpga_family variable and the functions became a bit long and messy.

The model of FPGA is also relevant as the flash sector sizes are different, since I'm just working with one model, I've not implemented this, but it would be necessary to support the other models. As the NOTES are unreliable and there are cases where the data doesn't start at the beginning of a flash sector - such as the case where the JED file contains EBR_INIT data (targeted for the start of UFM0) followed by UFM0 data - offset into UFM0 by the length of the EBR_INIT data... Which means that the offset (L) values (previously ignored) are required to determine the correct flash sector / address to program. This also allows a JED file targeted for CFG0 (+UFM0) to be programmed into CFG1 (+UFM1) by specifying the --flash-sector CFG1 on the command line.

I've implemented a new file parser for the .fea file (which contains the feature row and feabits) - and is not in JED format. Worth noting here that the Lattice documentation and technical notes are all incorrect - I ended up having to use wireshark to capture the USB traffic from the diamond programmer (and use the lattice programming file utility) to get this working correctly.

I'll share something soon -

[trabucayre]

--flash-sector is required ? it's not possible to do quite the same thing using --start-offset and --file-size (okay latter has a name not really good) ? For dedicated method for machXO3D if behaviour is too different or add overhead it make sense (I do that for xilinx CPLD). Care must be taken for jedParser: this class is used for lattice but also for xilinx CPLD, but I'm agree note are maybe not best way to knows area (current way is way described by lattice). I've sometime to use wireshark too, it's the only way to check documentation/verify transaction in some situations.

[trabucayre]

Any news? I'm interested by your fixes.

Thanks

[ghost]

I've still got some work to do for the security side (programming key etc), so figured I'd wait until complete - hopefully I'll get back onto this later this week.

[trabucayre]

As you want. But having one PR to fix global behaviour and a second dedicated for security is good too. Thanks

[ghost]

Security has been paused again, may not get back to this....