Thanks!

I can understand differentiating them by speed. But feature defects is a whole different ballgame. They'd have to declare what parts of the die are the official 4k subset. Else the PAR tool would have to know which parts of the FPGA to avoid. Without a 2-way communication path, that seems like a pretty complex 'feature'.

@@JohnsBasement There are ways to deal with this. For example, you can have config logic program one of several routes depending on fuses which are lasered off before packaging, or they can connect one route to multiple block RAM (or other HW blocks) and laser trim excess connections after testing. For example, I know for a fact that Xilinx laser trims off multi gigabit transceivers and PCIE blocks on dies for packages which do not bond them out so that they won't waste power, so maybe Lattice is doing something similar.

However it's done, the toolchain still has to know how much of the hardware on the chip being targeted is actually functional, and how to address it. That's the weird part. And I can't see it being practical to read that info from the chip itself, otherwise the design would need to be recompiled for each individual chip. That would be okay for prototyping, but not for mass production.

@@gcewing I agree. Hopefully someone has a solid answer. It is possible that a buyer wanted a 4K chip & Lattice decided it was cheaper to make one with the 8K die... maybe the timeline or a prototype 4K yield was bad?

​@@JohnsBasementu didn't touch in the DSP's!!!

Yes we can. FOSS tools are what I use with the ICE40 chips. Huge plus indeed.

Thanks for letting me know! I gotta check that out. We should be seeing plenty like that on the horizon.

@@JohnsBasement They are quite high performance and so pricey, and there is a potential problem with license for the toolchain (I don't know their licensing model, but that is definitely something to figure out before buying anything). The latter is especially important for folks like me who like designing and assembling their own boards.

@@asmi06 yeah. I am with you! But this is early days... The future looks bright!!!

The Spartan6 uses 6-input LUTs and has a number of larger options and hard-IP like memory controllers, PCIe and such. In the simplest of terms, a big ICE40HX is like a small Spartan6.

I know. 😞. I'm still moving to a new house. The new place is an acoustic mess and I can't find my good microphone.

Good question. Look at the Lattice HX programming guide. It tells you what SPI commands the flash gas to support. Also look at the flash programming app I used on the PI. If you want to use it then make sure the linux app supports it too

@@JohnsBasement I'm looking in the 'iCE40 programming and configuration' (FPGA-TN-02001-3.4), section '9.2. SPI PROM Requirements', where, among other things it states that the SPI PROM must support: 0x0B Fast Read 0xB9 Deep Power Down 0xAB Release from Deep Power-down Am I on the right track? Sure glad we have you John, because I'd likely never have thought to check this sort of detail. Anyway, I looked in the 'Winbond W25Q64JV datasheet' pdf (which annoyingly has no index), and all of these commands are listed, and I didn't see anything else disqualifying. So I'm guessing, the Winbond chips should work okay, except of course for the pin configuration (in case anyone missed that point.) ... Another story, off topic but not entirely unrelated: I recently built some RP2040 boards and was having a bugger of time trying to track down the problem. I had put some W25Q128JV flash on them and ... nothing. Well not entirely nothing, they went through the motion of uploading, but then immediately reset themselves without executing the code. And several chips failed the same way. Since the Raspberry pi pico uses 16Mb flash, I tried one of these and it worked fine. But then on a different board one of the 128Mb flash chips also worked, so I was getting confused. After replacing the flash and uController ICs 'multiple' times, I found the issue. It wasn't my soldering, I hadn't fried the RP2040, and the chips were not defective. They all came up clean when I ran a diagnostic. But, it turns out, they were not empty. Now, I'm thinking this shouldn't have prevented the RP2040 from programming them, but it did. Apparently the AliExpress seller had shipped perfectly good, but 'used' flash chips. Once I erased them ... they worked just fine. Live and learn.

@@KZfaqBorkedMyOldHandle_why 🙄.. If I recall correctly, some FLASH chips have a configurable sector size too. That might confuse things too.

@@JohnsBasement It gets a bit confusing ... for sure. I see India is just about to attempt a Lunar landing, 24 minutes from now.

I Believe that Winbond's W25Q64 is going away, so not good for new designs.