| Pronouns | He/him |
My jaytag library SPI flash programmer does a CRC-32 of each sector rather than a full readback for speed reasons.
Any reason this is a terrible idea? I don't consider malicious flash a concern. It does have normal readback support, just takes longer.
Rather than swap my bandsaw to a metal blade, I tried the jigsaw. Worked great.
Also, after getting the copper, I realized that for probably not much more money I could have had the parts laser cut.
Next up, I need to make some copper collets to hold the feed probes allowing adjustment of insertion depth. Then I should be able to test it with clamps instead of solder. The coupler will need to be cut down a bit but we should get the TE015 resonance at a lower frequency with it unmodified.
There's also a .rcdo file which appears to be a glorified hexdump of the .bit file with a text header. I'll be ignoring that one as the .bit is faster to parse and already implemented.
The open source bootgen tool is used to combine the .rcdo and .elf according to the directions in the .bif file to create a .pdi file. In project mode, it does that for you.
I tried generating the flash loader bitstream for Spartan Ultrascale+ XCSU10P. No errors and it seems access to the configuration flash is still available in the usual way via STARTUPE3. That's pleasantly unexpected.
In non project flow, it outputs a .bit file, a .bif file, plm.elf. The latter is just a copy of data/parts/xilinx/spartanuplus/plm_elf/plm.elf from the Vivado install.
I was expecting that to be Microblaze. It's RV32. Should be interesting to poke at.
I'm ordering an SU10P.
Local news headline: "No injuries after chemical release, fire at Bradley County Wacker plant"
Seemed a bit familiar. There's a USCSB video "Chemical Release at Wacker Polysilicon" from a 2020 accident at the same facility. Thankfully, I don't live anywhere near that place.
I'm working on flash programming for Jaytag. Should I provide flash programming bitstreams for all supported parts? If so, I'm not sure how best to distribute them. Potentially hundreds of MB. I'm not seeing a great answer with Rust's Cargo, don't even really want them in the main Git repo, don't want a Vivado build dependency.
There will be a flash programmer that can be included in your actual FPGA project too which uses minimal LUTs, 1 BRAM.
The Alveo promptly sold on Ebay for $400 more than I paid for it last year so I came out ahead even with tax and fees and shipping.
There's some tempting lower cost e-waste on there with VU35Ps but I'm going to wait. Don't really have time to make a board any time soon and the VU+ e-waste seems to be getting better with time. Maybe I can find a few VU47Ps.
The XCZU7s will be good reballing practice then will end up on a board intended for testing the Jaytag library with a bunch of different FPGA families so I don't have to cycle through many test boards to test. Probably ZU+, SU+, XC7, ECP5, XC7Z, etc.
I don't think I need an AU+/KU+ part as I can fully test that code on ZU+ as that contains the same FPGA configuration logic once unlocked. Also, have lots of boards with those so it's frequently tested.
I'd done a test run a while back with milling the PCB away from an FF676 package Kintex-7 that went well.
Tried the same thing on the two XCU30/XCZU7 FBVB900 parts on a cheap Alveo U30. It didn't go as well. Two pads cracked on this one which is the better of the two. Both are still able to be reballed and good to find this on something less valuable.
The Alveo U50 I was planning to remove the XCU50/XCVU35P from is now on Ebay. Not worth risking it. Value went up too since I bought it.
