FTDI based Xilinx programmer supported by ISE

[NorthGuy]

The reason is not difficult to see. Say, if you want to sell your board to people who won't  have a cable, or even don't know anything about FPGAs.

Well considering the "solution" offered here is essentially a piracy, you won't be selling these things for very long before you get a lawsuit.

How's that piracy? Piracy is when you buy a programming cable which contains a fake or stolen Vivado license. If you use open source programming software, or write your own, instead of using Vivado, you don't need the Vivado license any more.

[asmi]

How's that piracy? Piracy is when you buy a programming cable which contains a fake or stolen Vivado license. If you use open source programming software, or write your own, instead of using Vivado, you don't need the Vivado license any more.

I was talking about using Digilent's dumped EEPROM. Devboards without support of Vivado's debugging facilities are almost completely useless, since debugging is the main purpose of devboards. My own custom boards would also be not very useful for me if I wouldn't have debugging facilities.
It sucks that Xilinx essentially made Digilent a monopolist in this area, and the latter is certainly taking full advantage of it by charging a fortune for programming modules (JTAG-SMT2 module which costs <$5 in BOM is sold for the whopping $54 ), but piracy is never the answer.
In the long run it's cheaper to buy their cable once, and then use it to program all boards you intend to make for your projects - this way you still have full HW debug capabilities, and don't spend any of money on programming-related parts. So while this kind of eliminates simpler boards making them not competitive with Digilent's own boards (and this is clearly anti-competitive move on their part), boards designed for more advanced use cases can assume their users likely already have such cable (either Digilent's or Xilinx platform cable).

[NorthGuy]

I was talking about using Digilent's dumped EEPROM. Devboards without support of Vivado's debugging facilities are almost completely useless, since debugging is the main purpose of devboards. My own custom boards would also be not very useful for me if I wouldn't have debugging facilities.
It sucks that Xilinx essentially made Digilent a monopolist in this area, and the latter is certainly taking full advantage of it by charging a fortune for programming modules (JTAG-SMT2 module which costs <$5 in BOM is sold for the whopping $54 ), but piracy is never the answer.
In the long run it's cheaper to buy their cable once, and then use it to program all boards you intend to make for your projects - this way you still have full HW debug capabilities, and don't spend any of money on programming-related parts. So while this kind of eliminates simpler boards making them not competitive with Digilent's own boards (and this is clearly anti-competitive move on their part), boards designed for more advanced use cases can assume their users likely already have such cable (either Digilent's or Xilinx platform cable).

That is all true, but only a tiny percentage of all PCBs made are devboard. If you want to sell an actual product which you have developed, it's a very good idea to install FT232H or alike on the board. Then your customers would only need a cable to update the firmware. You can also re-use it for any kind of communications through JTAG, and 30 MHz is not that bad. If you use your own software, you don't need to steal Digilent EEPROM licenses.

[asmi]

That is all true, but only a tiny percentage of all PCBs made are devboard. If you want to sell an actual product which you have developed, it's a very good idea to install FT232H or alike on the board. Then your customers would only need a cable to update the firmware. You can also re-use it for any kind of communications through JTAG, and 30 MHz is not that bad. If you use your own software, you don't need to steal Digilent EEPROM licenses.

I'd rather them not touch a bitstream if I can help it. If I need my solution to have field updates capability, I'd rather build this functionality into the application so that I would keep tight control over the bitstream, because wrong bitstream can cause some serious issues, including physical damage in some cases.

[NorthGuy]

I'd rather them not touch a bitstream if I can help it. If I need my solution to have field updates capability, I'd rather build this functionality into the application so that I would keep tight control over the bitstream, because wrong bitstream can cause some serious issues, including physical damage in some cases.

Of course. There's no need to touch anything. They press a button and everything configures. FT232H is just the mean to achieve communications. That's way better than making them buy overpriced cables and installing Vivado.

[asmi]

Of course. There's no need to touch anything. They press a button and everything configures. FT232H is just the mean to achieve communications. That's way better than making them buy overpriced cables and installing Vivado.

That's not how I like to do it, but whatever takes your fancy. The question is - how is that relevant to this thread, which is explicitly saying "<...>supported by ISE" right in the title?

[NorthGuy]

That's not how I like to do it, but whatever takes your fancy.

How do you like to do it?

[asmi]

How do you like to do it?

Like I said above, I build this functionality into the application, which takes a new bitstream from some external source (usually microSD card), flashes it alongside "the golden copy" and utilize MultiBoot (XAPP1247) to ensure that a board will still work if something goes wrong during update. The goal here is to avoid a situation when update fails for whatever reason and a customer ends up with a dead board. Multiboot ensures that at least a OEM bitstream will always boot.
But again, this discussion is not really relevant to this thread.

[NorthGuy]

Multiboot ensures that at least a OEM bitstream will always boot.

Multiboot ensures that you never brick your device and it works very well until it doesn't. Say, a bug in your design, or a glitch on the DAT line when you transmit an address to the configuration flash will cause write to a wrong place overwriting the master bitstream and bricking the device. In contrast, JTAG lets you configure the FPGA even if your configuration flash dies completely.

BTW: SD cards are things of the past. You connect your phone, you press a button, and the correct bitstream gets automatically downloaded to the device. That's how things are done now.

[asmi]

Multiboot ensures that you never brick your device and it works very well until it doesn't. Say, a bug in your design, or a glitch on the DAT line when you transmit an address to the configuration flash will cause write to a wrong place overwriting the master bitstream and bricking the device.

This is impossible because it requires you to have exact same glitch appear twice - first time when you erase the section, and second time when you write it. In my practice I've programmed flash chips many-many times, and I've never had anything like that happen.

In contrast, JTAG lets you configure the FPGA even if your configuration flash dies completely.

How many customers have you had that actually did that? As opposed to RMA the board to you and you sent a replacement one?

BTW: SD cards are things of the past. You connect your phone, you press a button, and the correct bitstream gets automatically downloaded to the device. That's how things are done now.

Again - how many designs like that have you actually deployed to the field? None of my designs even have hardware to connect to the phone, not to mention I have absolutely zero intentions to make bitstream updates easy - actually the exact opposite is true. As a matter of fact, I had only ever performed field upgrades few times due to issues with external hardware that was beyond my control, because I don't release anything that is not 100% performing to the specs. I'm not in business of turning my customers into paying beta-testers.

[NorthGuy]

This is impossible because it requires you to have exact same glitch appear twice - first time when you erase the section, and second time when you write it. In my practice I've programmed flash chips many-many times, and I've never had anything like that happen.

If you write over unerased flash you still damage it. The '0' remain '0' until the erase, but '1' may be flipped to '0', so you get

Code: [Select]

flash &= new_content;

Again - how many designs like that have you actually deployed to the field?

With the phone? Still working on the first one.

[asmi]

If you write over unerased flash you still damage it. The '0' remain '0' until the erase, but '1' may be flipped to '0', so you get

Code: [Select]

flash &= new_content;

And post-write verification will not see it?
Have you actually had this ever happen, or you're just making things up?

With the phone? Still working on the first one.

Good luck with that! Good thing my customers don't buy all this hipster BS.

[NorthGuy]

And post-write verification will not see it?

If you accidentally write (or erase) even a single block in the image of you master bitstream, it is busted, whether you detect the error or not.

Have you actually had this ever happen, or you're just making things up?

Of course. I wrote over non-erased flash many times, both accidentally and intentionally. You can try that too.

[asmi]

If you accidentally write (or erase) even a single block in the image of you master bitstream, it is busted, whether you detect the error or not.

Oh, so you didn't use write protection for the original bistream? Well, here is the answer Pretty much all QSPI flash chips I came across allow to write-protect part of array.

[NorthGuy]

Oh, so you didn't use write protection for the original bistream? Well, here is the answer Pretty much all QSPI flash chips I came across allow to write-protect part of array.

No. Never used it. Never used the dual boot neither.

[asmi]

No. Never used it. Never used the dual boot neither.

Give it a try. It's a very simple concept - you make a "golden image" by enabling the feature and specifying address of secondary bitstream in the bitstream settings, and program that into flash at address zero. The way it works is that once FPGA starts reading the "golden image", it will encounter a "jump" command of sorts so it attempts to load a secondary image first, and falls back to the golden one if it's unable to configure itself using the secondary one.
As for write protection - I program my production flash ICs before soldering, so I've made a jig of sorts using FTDI's MPSSE cable which works in SPI mode and connects to a SOIC-8 burn-in socket, and written a little program using D2XX API that programs the chip (including memory protection). I have a couple of ideas about improving this jig as I transition to larger devices (one of projects I'm working on will be using K7-160 or K7-325 device, will see if it will fit into smaller one), so I would like to add support for BGA24 flash ICs (the socket is already on it's way from China) as well as use QSPI instead of regular SPI to shorten programming time. I prefer BGA for larger capacity because they are smaller than SOIC-16, as SOIC-8 for some reason is not used for 256+Mbit devices.
BTW if you want to get your hands on cheap Spanson/Cypress/Infineon 256MBit flash ICs, check this out. Grab it quickly though as not many are remaining in stock!

[tmbinc]

Before you rely on write protection too heavily, please understand that logical flash sectors are not necessarily physically separated, and often an erase of one sector will trigger a state-machine in the flash chip that re-writes neighbor sectors because they get affected by the erase as well and eventually degrades. So unless you pay attention to the physical layout of the data, the write protection isn't going to stop corruption in out-of-spec scenarios (such as sudden power loss during erase).

I've seen write-locked bootloaders being destroyed due to power glitches on Intel StrataFlash a lot. I may or may not have worked on one design that had a particularly high failure rate so we eventually shipped JTAG adapters (with pogo pin needles!) to distributors so they could fix the issue themselves to reduce RMA cost.