Spartan-6 -- safe to provide VCC_AUX and VCC_IO only? - Page 1
Forum section: electronics / general

author: ebastler
author_rank: Super Contributor
timestamp: January 05, 2025, 09:41:12 am
content: In a Spartan-6 based hobbyist design, I would like to provide users with the ability to program the configuration ROM without needing the dedicated Xilinx/AMD JTAG programmer (or a clone). I was thinking about a connector to the flash ROM's SPI signals which also provides a pin to hold PROGRAM_B_2 low to disable the FPGA during the external programming cycle.Would it be safe to power the flash ROM (and in parallel, the FPGA's VCCAUX and VCCIO) with 3.3V via my programming connector, while the VCC_INT core voltage isnotsupplied to the FPGA? There is no power-on sequence requirement for the Spartan-6, but Xilinx were probably not thinking of an extended period where only some of the voltages are present...

author: Someone
author_rank: Super Contributor
timestamp: January 05, 2025, 11:52:42 am
content: Quote from: ebastler on January 05, 2025, 09:41:12 amReread UG394, and then UG380.

author: ebastler
author_rank: Super Contributor
timestamp: January 05, 2025, 12:04:13 pm
content: Quote from: Someone on January 05, 2025, 11:52:42 amI have (largely) read those user guides earlier and am not sure what you are trying to tell me:UG394, page 32: "The Spartan-6 FPGA can be powered up and powered down in any sequence. Because the three FPGA supply inputs must be valid to release the POR and can be supplied in any order, there is no FPGA-specific voltage sequencing requirement."UG380 explains how to program the FPGA "properly" via JTAG. I know how to do that, and have a Xilinx JTAG adapter (clone). But as mentioned in the original post, I want to avoid the need for that special programmer. I can't find anything in UG380 that would imply that my idea of accessing the flash ROM externally is forbidden, but might have overlooked something.So what did you imply? That UG394 and UG380 tell me that my approach is fine, or that there is some information in there which I overlooked and which suggests that it won't work? Thanks for clarifying!

author: iMo
author_rank: Super Contributor
timestamp: January 05, 2025, 12:15:10 pm
content: The first thing people will start to tell you is they want to use the jtag for the xilinxe's LA (aka "ChipScope")..

author: ebastler
author_rank: Super Contributor
timestamp: January 05, 2025, 01:18:14 pm
content: Quote from: iMo on January 05, 2025, 12:15:10 pmI will have a JTAG connector on the board too, if only for my own development and debugging purposes. But this "product" is aimed at hobbyists who are not into FPGA development but just want to use the design.Normally, upgrades to the FPGA configuration will be loaded via USB, via a separate USB-to-SPI bridge configuration which the FPGA loads first. But I want to provide a fallback option if things should get messed up. Since general-purpose programmers with in-circuit-programming capability (like the TL866 family) are much more common in hobbyists' toolkits than the Xilinx JTAG adapter, I want to offer that option.

author: asmi
author_rank: Super Contributor
timestamp: January 05, 2025, 09:30:43 pm
content: "Official" Xilinx USB JTAG programmer can be implemented for about $6 in parts, so in most cases it's not worth savings.

author: ebastler
author_rank: Super Contributor
timestamp: January 05, 2025, 10:25:41 pm
content: Quote from: asmi on January 05, 2025, 09:30:43 pmIt's not only the cost of the adapter, but also the annoying Xilinx software that drives it. I don't want to bog my users down with that.But the cost of adding an extra adapter is a consideration too. The USB port for regular FPGA updates is free, since it is part of the design anyway. And so is the flash-programming backup option, since it only consists of a few pads on the PCB.

author: asmi
author_rank: Super Contributor
timestamp: January 05, 2025, 11:12:36 pm
content: In this case why don't just move the QSPI flash device to a tiny daughterboard which connects to the main board via a header? Then you can simply pull the flash off the circuit and do what you want with it, and no FPGA pins will be affected by it. And you can also just swap programming via swapping those boards for those users who don't want to bother with flash reprogramming.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 05, 2025, 11:24:05 pm
content: Quote from: asmi on January 05, 2025, 11:12:36 pmThat's something I have done in one project. The flash contained not just the FPGA bitstream, but also some custom data, and being able to swap it easily was a better option than a means of reflashing it in-circuit.

author: ebastler
author_rank: Super Contributor
timestamp: January 06, 2025, 12:59:50 pm
content: Quote from: asmi on January 05, 2025, 11:12:36 pmYes, I had thought about that option. Might even use a flash ROM in a plain old DIP-8 package and populate a socket on the board.Regarding the original manufacturing process, there's a slight advantage to having an SMD package soldered right onto the board (together with all other SMD components), then quickly push on a pogo pin adapter for the original programming -- compared to paying extra for some through-hole socket to be populated and having to handle a separate IC or daughter board. Given thateveryboard will have to go through that initial programming, while the field re-programming capability is just provided as a fallback, I'd prefer to optimize for the former.Any more insights whether my idea to program the flash in-circuit is in line with the FPGA specs? I can't find any spec it would violate.

author: langwadt
author_rank: Super Contributor
timestamp: January 06, 2025, 01:22:01 pm
content: Quote from: ebastler on January 05, 2025, 10:25:41 pmyou don't need to use the Xilinx software, it's just and FTDI and the code to config an fpga in c you can find easily

author: pbernardi
author_rank: Contributor
timestamp: January 06, 2025, 08:23:19 pm
content: I do not see problems into powering the flash without powering the FPGA core voltages, if the datasheet does not explicitely deny it.In my experience, the Spartan-6 is quite robust (but not indestrutible). If Xilinx does not say anything about power voltage, probably it really means that any voltage can be powered in any order at any time.But you can separate two different P3.3V signals (one for FPGA, other for flash) separated by a low dropout diode or a transistor, for example. This way ou can power the flash without powering the FPGA.

author: laugensalm
author_rank: Regular Contributor
timestamp: January 06, 2025, 09:07:24 pm
content: Why not just drop a FT2232H on the board, you get a USB-JTAG plus UART connection. xc3sprog will do the rest, downloading and SPI flash programming included (plus faster than Impact). And still, you can get the FTDI recognized by Xilinx tools with the proper firmware image, when needed.I had also designed in a TagConnect footprint for boards with unpopulated USB-JTAG. For reference:https://hackaday.io/project/162259-netpp-node. Kicad design data available.

author: ebastler
author_rank: Super Contributor
timestamp: January 06, 2025, 09:22:47 pm
content: Quote from: laugensalm on January 06, 2025, 09:07:24 pmNice solution, but that chip is more expensive than the Sparetan-6 itself.

author: langwadt
author_rank: Super Contributor
timestamp: January 06, 2025, 09:39:14 pm
content: Quote from: ebastler on January 06, 2025, 09:22:47 pmsipeed uses some dirt cheap wizzabang usb/bluetooth mcu and simulates an ftdi

author: sd
author_rank: Unknown
timestamp: January 06, 2025, 10:31:56 pm
content: If you're pulling PROGRAM_B_2 low while externally programming the flash, why not also supply VCCINT to the FPGA?

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 06, 2025, 10:34:56 pm
content: Quote from: ebastler on January 06, 2025, 09:22:47 pmYou can use a FT232H which is cheaper. (The FT2232H is dual channel, which you don't need for just JTAG.)I was gonna ask, in what world is it more expensive than a Spartan-6. And then I'm guessing you order from LCSC or some asian source, where oddly indeed the FTDI chips are pretty expensive, and the Xilinx ones, oddly inexpensive. Am I right? If you look at Mouser (which is certainly not the least expensive distributor in the West), the FT232H is 3.89 eur/1 wheras it's 5.13 eur/1 at LCSC (and the FT2232H, 4.87 eur/1 vs. 7.32 at LCSC). Go figure.Some of the western parts are very cheap at LCSC (that's usually more the "older" parts, for which I suspect they have large stocks and/or manage extremely good deals with vendors), but some others are much more expensive than when you buy them from Europe or the US. Just something to know.

author: ebastler
author_rank: Super Contributor
timestamp: January 07, 2025, 05:47:28 am
content: Quote from: sd on January 06, 2025, 10:31:56 pmNormally the 1.2V and 3.3V are both derived from a 5V supply (USB). If that supply is connected, everything is fine. But I would like things to work also when only 3.3V are provided via the in-circuit programming connector.

author: ebastler
author_rank: Super Contributor
timestamp: January 07, 2025, 05:58:37 am
content: Quote from: SiliconWizard on January 06, 2025, 10:34:56 pmThanks, the FT232H makes that approach more affordable.Yes, I was looking at LCSC pricing (via JLCPCB PCB assembly). Their price for the Spartan-6 is a fraction of Mouser's, but indeed the FT232H is more expensive there. Wonder whether they don't have direct supply contracts with some semiconductor manufacturers, so they buy those from Mouser/Digikey and resell with a markup?

author: xvr
author_rank: Frequent Contributor
timestamp: January 07, 2025, 12:35:42 pm
content: QuoteMay be CH347T then? Not in stock, unfortunately, but available for preorder for €2.6883

author: laugensalm
author_rank: Regular Contributor
timestamp: January 07, 2025, 04:11:31 pm
content: Seriously, for small hobbyist PCB numbers you don't want to waste your or other's time on quirky programming solutions.I don't see why you should mess with any of the supply voltages (you should not have to). UG380 and in particular the HSWAPEN pin section elaborates on the configuration procedure. BUT:Apart from serious doubts that you will get a LX9 guaranteed cheaper than a FT2232H in production numbers, it's a) a bad idea to save on a proper debugging interface, b) a better idea to do the math and cost optimization once you happen to go into numbers and when pricing matters. Simplest variant is just not populating the JTAG debugger part, which in worst case only requires a technician to appear with a programmer cable if someone happened to have bricked the board.And one more remark: I've had to work with a solution that did some pin muxing and PROG_B pulling in order to reprogram the SPI flash from an external controller, because someone intended to save costs on a flash. The software development for a reliable solution costed a lot more.

author: ebastler
author_rank: Super Contributor
timestamp: January 07, 2025, 04:31:11 pm
content: Quote from: laugensalm on January 07, 2025, 04:11:31 pmI think we are in full agreement on most of the above. As mentioned earlier in the thread, I will provide a USB programming interface for regular configuration updates by the user, and a proper JTAG interface for debugging and development (normally unpopulated header).The SPI flash programming option is planned for initial programming in "production" and as a fallback for users, in case the USB-to-SPI bridge via the FPGA should run into problems. I hope it will never need to be used in the field, but if so, it is meant to be straightforward -- behaving just like the regular in-circuit programming interface for the SPI flash, i.e. usable with any cheap programmer like the TL866.I was nervous about the surprisingly low LCSC pricing for the Spartan-6 initially, wondering whether this is just a limited batch of parts they happen to have on the shelf. But seeing that their pricing structure is consistent across the various packages and versions, it seems they indeed have a supply contract with favorable conditions in place.QuoteCould you elaborate where the problem was? As mentioned above, I expect this solution to be very simple from the user's perspective: Set a jumper to hold reset low, connect any old programmer in its regular SPI flash (in-circuit) programming setting, power my board either via its regular USB power input or via the programmer. No dedicated software involved, neither on the PC side nor on the PCB.

author: laugensalm
author_rank: Regular Contributor
timestamp: January 08, 2025, 09:20:35 am
content: The problem was mainly to get the timing right under an embedded Linux and make sure the SPI flash would not get stuck. The effect in the first place was that every now and then, the FPGA would not boot correctly.With bare metal, timing problems boil down, but getting some glitch safety into the system so that the FPGA can not hang the system (there was another feedback issue with a pin going high), took a bit of fiddling anyhow. Eventually, the ICAP_SPARTAN6 dual boot option helped. But since these are effects relevant in the field rather, they're probably not much of concern for you.