Author Topic: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?  (Read 2884 times)

0 Members and 1 Guest are viewing this topic.

Offline ebastlerTopic starter

  • Super Contributor
  • ***
  • Posts: 7395
  • Country: de
Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« on: January 05, 2025, 09:41:12 am »
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 is not supplied 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...
 

Offline Someone

  • Super Contributor
  • ***
  • Posts: 5186
  • Country: au
    • send complaints here
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #1 on: January 05, 2025, 11:52:42 am »
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...
Reread UG394, and then UG380.
 

Offline ebastlerTopic starter

  • Super Contributor
  • ***
  • Posts: 7395
  • Country: de
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #2 on: January 05, 2025, 12:04:13 pm »
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...
Reread UG394, and then UG380.

I 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!
 

Offline iMo

  • Super Contributor
  • ***
  • Posts: 5649
  • Country: gw
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #3 on: January 05, 2025, 12:15:10 pm »
The first thing people will start to tell you is they want to use the jtag for the xilinxe's LA (aka "ChipScope")..
Readers discretion is advised..
 

Offline ebastlerTopic starter

  • Super Contributor
  • ***
  • Posts: 7395
  • Country: de
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #4 on: January 05, 2025, 01:18:14 pm »
The first thing people will start to tell you is they want to use the jtag for the xilinxe's LA (aka "ChipScope")..

I 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.
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2872
  • Country: ca
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #5 on: January 05, 2025, 09:30:43 pm »
"Official" Xilinx USB JTAG programmer can be implemented for about $6 in parts, so in most cases it's not worth savings.

Offline ebastlerTopic starter

  • Super Contributor
  • ***
  • Posts: 7395
  • Country: de
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #6 on: January 05, 2025, 10:25:41 pm »
"Official" Xilinx USB JTAG programmer can be implemented for about $6 in parts, so in most cases it's not worth savings.

It'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.
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2872
  • Country: ca
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #7 on: January 05, 2025, 11:12:36 pm »
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.

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15954
  • Country: fr
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #8 on: January 05, 2025, 11:24:05 pm »
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.

That'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.
 

Offline ebastlerTopic starter

  • Super Contributor
  • ***
  • Posts: 7395
  • Country: de
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #9 on: January 06, 2025, 12:59:50 pm »
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.

Yes, 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 that every board 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.
 

Offline langwadt

  • Super Contributor
  • ***
  • Posts: 4884
  • Country: dk
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #10 on: January 06, 2025, 01:22:01 pm »
"Official" Xilinx USB JTAG programmer can be implemented for about $6 in parts, so in most cases it's not worth savings.

It'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. ::)

you 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
 

Offline pbernardi

  • Contributor
  • Posts: 20
  • Country: br
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #11 on: January 06, 2025, 08:23:19 pm »
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.
 
The following users thanked this post: ebastler

Offline laugensalm

  • Regular Contributor
  • *
  • Posts: 135
  • Country: ch
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #12 on: January 06, 2025, 09:07:24 pm »
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.
 

Offline ebastlerTopic starter

  • Super Contributor
  • ***
  • Posts: 7395
  • Country: de
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #13 on: January 06, 2025, 09:22:47 pm »
Why not just drop a FT2232H on the board

Nice solution, but that chip is more expensive than the Sparetan-6 itself.  ???
 

Offline langwadt

  • Super Contributor
  • ***
  • Posts: 4884
  • Country: dk
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #14 on: January 06, 2025, 09:39:14 pm »
Why not just drop a FT2232H on the board

Nice solution, but that chip is more expensive than the Sparetan-6 itself.  ???

sipeed uses some dirt cheap  wizzabang usb/bluetooth mcu and simulates an ftdi
 

Offline sd

  • Supporter
  • ****
  • Posts: 47
  • Country: ro
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #15 on: January 06, 2025, 10:31:56 pm »
If you're pulling PROGRAM_B_2 low while externally programming the flash, why not also supply VCCINT to the FPGA?
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15954
  • Country: fr
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #16 on: January 06, 2025, 10:34:56 pm »
Why not just drop a FT2232H on the board

Nice solution, but that chip is more expensive than the Sparetan-6 itself.  ???

You 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.
 

Offline ebastlerTopic starter

  • Super Contributor
  • ***
  • Posts: 7395
  • Country: de
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #17 on: January 07, 2025, 05:47:28 am »
If you're pulling PROGRAM_B_2 low while externally programming the flash, why not also supply VCCINT to the FPGA?

Normally 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.
 

Offline ebastlerTopic starter

  • Super Contributor
  • ***
  • Posts: 7395
  • Country: de
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #18 on: January 07, 2025, 05:58:37 am »
You 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?

Thanks, 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?
 

Offline xvr

  • Frequent Contributor
  • **
  • Posts: 573
  • Country: ie
    • LinkedIn
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #19 on: January 07, 2025, 12:35:42 pm »
Quote
Yes, I was looking at LCSC pricing (via JLCPCB PCB assembly).
May be CH347T then? Not in stock, unfortunately, but available for preorder for €2.6883
 

Offline laugensalm

  • Regular Contributor
  • *
  • Posts: 135
  • Country: ch
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #20 on: January 07, 2025, 04:11:31 pm »
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.

 

Offline ebastlerTopic starter

  • Super Contributor
  • ***
  • Posts: 7395
  • Country: de
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #21 on: January 07, 2025, 04:31:11 pm »
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.

I 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.

Quote
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.

Could 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.
 

Offline laugensalm

  • Regular Contributor
  • *
  • Posts: 135
  • Country: ch
Re: Spartan-6 -- safe to provide VCC_AUX and VCC_IO only?
« Reply #22 on: January 08, 2025, 09:20:35 am »
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.
 
The following users thanked this post: ebastler


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf