XC95000XL: Merging the tool into the applet to migrate from .bit to .jed

[brainstorm]

[brainstorm]

I'll be revisiting this soon as I've successfully dumped the target CPLD from my original DNA sequencer repair project :)

I'm posting this comment as self-documentation/thoughts as I go through Glasgow's code to easily context-switch when I retake this task.

Given that I have the contents of isdata.data, i.e:

<glasgow.arch.xilinx.xc9500xl.DR_ISDATA valid=1 strobe=0 data=00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000> <glasgow.arch.xilinx.xc9500xl.DR_ISDATA valid=1 strobe=0 data=00000010000100000000000100000000000000000000000100000000000010100000000000000000000000000000000000000000000000000000000000000000>

I was looking for a JED struct to fill to serialize those fuse states... I found the jesd3 parser within Glasgow protocols, but I didn't find a JED writer (serializer), so I guess I'll have to write a struct that conforms with the official JEDEC spec in PDF. Shall I include this one in the glasgow-archive repo if it's not already?.

The example data shown above are fuses representation, I'm obtaining that via a print() inside _fvfyi function.

[whitequark]

I guess I'll have to write a struct that conforms with the official JEDEC spec (shall I include this one in the glasgow-archive repo if it's not already?)

All you really need for serializing a JED is a bitarray of fuses. Once you can convert the data that has been read out to that, I'll assist you with a JED writer.

[brainstorm]

Thanks Catherine! When I was exploring this, I was wondering to which extent the JED writer had to conform with the original spec in all its facets or just-functional, i.e:

Sorry I missed that JEDEC spec PDF/link on the previous comment when I mentioned the glasgow-archive repo, fixed now.

[whitequark]

All you need to do is to write QF<nfuses>* F0*, and L<nfuse> <data>.

[whitequark]

Obsoleted by #477. Thank you for putting in the effort!