06:41 <d1b2> <brainstorm> "wait, you took it from the -datasheet-?"... argh, I just realised that I was wrongly reading the XC9572XL I had opened instead of my XC95288XL that was open in another tab, facepalm... anyway, I put that word_size=128 in place and managed to dump (seemingly legit data) 101KiB from the Aliexpress board! 😄 https://hardbin.com/ipfs/QmXgR7ATaofiz2JSpthEDxuLWsqsfGuyEFwhdL6HKdwVQi/#EbgNPNpwGzN2NpRamjAra9ur5p1VS58VBMjnrwkTwUxy That

06:41 <d1b2> Aliexpress board has a binary counting example pre-loaded (by looking at the flashing builtin board LEDs) that seems to allow readout 🙂 Thanks for the guidance/hints, @whitequark ! Next step is to make sense of the bitstream and fix the glasgow CLI backtrace... will study the usercode_low/high parameters after that.

10:30 <_whitenotifier-1> [glasgow] brainstorm opened pull request #285: XC95288XL support - https://git.io/JicYx

10:39 <_whitenotifier-1> [archive] brainstorm opened pull request #7: Add datasheet for Xilinx XC95288XL CPLD - https://git.io/Jic3s

10:40 <_whitenotifier-1> [glasgow] brainstorm synchronize pull request #285: XC95288XL support - https://git.io/JicYx

10:44 <d1b2> <brainstorm> After discovering what the archive is about, things start to make a bit more sense: https://github.com/GlasgowEmbedded/archive/tree/main/G00015 🙂

10:48 <d1b2> <brainstorm> The USERCODE attribute entity for the xc95288xl_tq144 .bsd file seems to be 11111101, which is 253, trying to determine the low/high (bounds?)... that's the only thing left to finish up the PR and move on to the original target CPLD.

10:48 <whitequark> it has nothing to do with the BSDL files

10:49 <whitequark> usercode_low is the start fuse number for usercode low byte

10:49 <whitequark> usercode_high is the same for the high byte

10:50 <d1b2> <brainstorm> "to get usercode_{low,high} I asked azonenberg to generate a pair of bitstreams" ... got it

10:50 <_whitenotifier-1> [archive] whitequark commented on pull request #7: Add datasheet for Xilinx XC95288XL CPLD - https://git.io/JicsM

10:53 <_whitenotifier-1> [archive] brainstorm synchronize pull request #7: Add datasheet for Xilinx XC95288XL CPLD - https://git.io/Jic3s

10:53 <_whitenotifier-1> [glasgow] brainstorm synchronize pull request #285: XC95288XL support - https://git.io/JicYx

10:53 <_whitenotifier-1> [GlasgowEmbedded/archive] whitequark pushed 1 commit to main [+1/-0/±0] https://git.io/JicGq

10:53 <_whitenotifier-1> [GlasgowEmbedded/archive] brainstorm 5a57c30 - Add G00081.

10:53 <_whitenotifier-1> [archive] whitequark closed pull request #7: Add datasheet for Xilinx XC95288XL CPLD - https://git.io/Jic3s

10:53 <_whitenotifier-1> [archive] whitequark commented on pull request #7: Add datasheet for Xilinx XC95288XL CPLD - https://git.io/JicGm

10:58 <_whitenotifier-1> [glasgow] whitequark reviewed pull request #285 commit - https://git.io/JicGa

10:58 <d1b2> <brainstorm> Alright, I'm no Andrew Zonenberg by any stretch, but having ISE I hope I'll be able to generate a bitstream somehow 🙂 I need to familiarise myself with the software.

11:02 <_whitenotifier-1> [glasgow] brainstorm synchronize pull request #285: XC95288XL support - https://git.io/JicYx

11:04 <whitequark> it's quite possible that USERCODE is always at 90,105

11:07 <d1b2> <brainstorm> I'm re-reading your docs to see how you determined it, don't want to mislead anybody 😒

11:08 <whitequark> so, generate a bitstream with USERCODE at 00000000 and one at 11111111

11:08 <whitequark> that should show you whether it's at those offsets

11:08 <whitequark> er, make that 00000000 00000000 and 11111111 11111111

11:09 <whitequark> if it's at the same offsets that's good enough, i don't think they swizzled the bits or anything

11:30 <d1b2> <brainstorm> Ah, cool, that makes sense, will do... also, how advanced is the RE tooling to determine functional blocks/gates from a .bit file from one of those Xilinx CPLDs? Now reading through prjbureau, need to become more fluent with all this.

11:30 <whitequark> prjbureau is targeting a completely different CPLD

11:30 <whitequark> i've not done any work with xilinx

11:31 <whitequark> ask on the ##openfpga IRC channel, perhaps?

11:32 <d1b2> <brainstorm> Thanks for the pointers!

11:42 <d1b2> <brainstorm> Is it ok to ask on #fpga on this 1BitSquared Discord server? Or is it better #openfpga over freenode/liberachat?

11:43 <whitequark> i don't use the discord server and have no idea whether the relevant people are in the #fpga channel

11:43 <whitequark> (also, note that it's ##openfpga, not #openfpga)

11:45 <d1b2> <brainstorm> Gotcha, I'll give it a shot on ##openfpga

11:59 <whitequark> oh, and i just got an XC9572 and an XC95288 devboard

11:59 <whitequark> the latter the exact same model you have

12:05 <d1b2> <brainstorm> Hah, how come? 🙂 ... are those really still useful in production? They seem to be rather power hungry compared to others according to the datasheet(s).

12:05 <whitequark> well, need something to test the applet on

12:06 <whitequark> most of the devboards i have are like that

12:09 <d1b2> <brainstorm> Thanks for today's super informative session @whitequark , I love to learn this stuff 🙂 It's getting late over here in Australia and tomorrow there's #dayjob again, going to sleep a bit, cheers!