FTDI based Xilinx programmer supported by ISE

[ali_asadzadeh]

Hi,
Please see this JTAG HS3 Programming Cable from digilnet
http://digilentinc.com/Products/Detail.cfm?NavPath=2,395,1298&Prod=JTAG-HS3

I'm sure they have used FT2232 chip for making this happen, I want to know what are the contents of the attached SPI flash to the FTDI chip, so we could have a cheap way of USB programmer that Xilinx software will support it.

[Bassman59]

Hi,
Please see this JTAG HS3 Programming Cable from digilnet
http://digilentinc.com/Products/Detail.cfm?NavPath=2,395,1298&Prod=JTAG-HS3

I'm sure they have used FT2232 chip for making this happen, I want to know what are the contents of the attached SPI flash to the FTDI chip, so we could have a cheap way of USB programmer that Xilinx software will support it.

According to THAT VERY PAGE TO WHICH YOU LINKED, "It can be attached to target boards using Xilinx’s 2x7 connector*, and is compatible with all Xilinx tools, including iMPACT, Chipscope, and EDK."

So you don't really need to know what sort of chip they used in the thing, nor the contents of its flash, because it works with the Xilinx software.

[andersm]

So you don't really need to know what sort of chip they used in the thing, nor the contents of its flash, because it works with the Xilinx software.

I think he was asking about how to clone the cable.

[ali_asadzadeh]

Thanks, Ok how to clone the cable? or I personally find that it should be possible to use FTDI chips to do the job, for example FT2232 has the hardware support for it, the question is how to use ISE tools to do the job and detect them as a supported programmer, so we could use it for debugging purposes too. like chipscope etc...

[electro-logic]

Are you sure there isn't also a CPLD?
FT2232 can do JTAG without Flash, commands are from pc that recognize PID/VID of the device.

[Moondeck]

Use a microcontroller maybe?

[Gyro]

Not related to this is it?

http://openschemes.com/2011/10/25/bit-bang-jtag-programming-of-xilinx-cpld-using-ft232-homebrew-svf-player/

[ali_asadzadeh]

I have found these links, It seems they have done the job!
But I do not have any FTDI chip around to verify that for now, could you verify the idea?

http://www.mlab.cz/Modules/CPLD_FPGA/XILINX_XVC/XVC_FT220X02A/DOC/HTML/XVC_FT220X02A.cs.html
http://www.mlab.cz/Modules/CPLD_FPGA/XILINX_XVC/XVC_FT220X01A/DOC/HTML/XVC_FT220X01A.cs.html
http://debugmo.de/2012/02/xvcd-the-xilinx-virtual-cable-daemon/
http://forum.gadgetfactory.net/index.php?/topic/1747-board-support-in-xilinx-impact/

[mark03]

If you are using Vivado, there is another possibility.  The JTAG comms are network transparent thanks to something called TCF (target communications framework).  I don't have the links handy, but in principle you could make your own JTAG adapter, which need not be USB-compatible with the Xilinx one.  Then write a matching TCF server for it that speaks the same TCF protocol to the rest of Vivado.

[free_electron]

Thanks, Ok how to clone the cable? or I personally find that it should be possible to use FTDI chips to do the job, for example FT2232 has the hardware support for it, the question is how to use ISE tools to do the job and detect them as a supported programmer, so we could use it for debugging purposes too. like chipscope etc...

i personally find that all electronics should be sold for 1$ ... no matter what it is.

why don't you buy that cable and take a look ? oh right , it's got to be free ...

[mark03]

My two cents...

In an ideal world, the "plumbing" of embedded development would be fully open and documented.  JTAG falls into that category.  I see no reason why I should not be able to have ONE vendor-independent JTAG adapter which works in any FPGA or MCU development environment.  They all have USB on one end and JTAG on the other (modulo the traditional/SWD choice, and a handful of pinouts).  I see no essential differences between them, except for secrets and vendor lock-in.

The intrinsic cost of these widgets is also very low.  Anything higher than $20-$50 (wild guess) is pure vendor lock-in gouging, DRM's evil hardware twin.  If it saves a handful of jobs in the US/Europe that is a silver lining, but IMO this practice is at its root unethical.  In some cases it actually feeds the crap Chinese clone market, because engineers are smart enough to know when they're being taken for a ride, and look elsewhere.

It all seems a bit pointless, frankly.  Most companies making both tools and widgets the tools are designed to work with, have discovered that making the tools free is the way to go.  I wonder how much revenue Xilinx, e.g., derives from Vivado vs the chips themselves, and what would be the economics of making the full Vivado suite completely free (as in beer, not speech), stealing a bunch of Altera customers in the process.

Sorry for the OT rant.

[free_electron]

JTAG is open and standardized. the problem is the 'other side'

you want to use what on the other side ? usb ? firewire ? rs232 ? printerport ? that requires a bit of translational hardware and some software....

so bummer there. some dude does it with an ftdi , some others do it with a cypress 8051 with usb , some to it with pics or other mcu's.
everyone rolled his own , history ... the first xilinx cables were printerports and 4 resistors. later , to speed up download they did parallel to serial conversion in a dongle. then serial came along , then usb... rehash ,rewash .

same with the config proms. xilinx rolled their own historically cause noone had this.... now they use simple SPI devices.

it's all history. xilinx or altera would rather not have to make these downloaders and focus on rolling out new silicon. all this 'support' is non-revenue work.

they could easily go : buy this tool form xyz and we work with that. but then the cheapo users complain....
as a company i do not want to dick around making a usb to jtag dongle. my engineering time is more valuable. i will buy the 50$ usb jtag box from altera and be done with it.

[hamster_nz]

@ali_asadzadeh This post might be of interest to you....

http://forum.gadgetfactory.net/index.php?/topic/1747-board-support-in-xilinx-impact/

It points that if you use a FT2232H and connect it up as on page two of:

http://www.saanlima.com/download/pipistrello-v2.0/pipistrello_v2_schematic.pdf

And you put the correct information in theFT2232H's ROM

And you have the Digilent Impact H/W drivers installed, then it just all works...

[ali_asadzadeh]

Thanks all, free_electron please notice that xilinx platform cable cost a fortune (225USD)...

http://www.xilinx.com/products/boards-and-kits/hw-usb-ii-g.html

And Also I have lot's of Jtag cables around like J-link, AVR dragon ,STK600 and etc... why I should have the same tool for every other company! fortunately ARM solve the problem some how, so At least for doing my Cortex devices from NXP, Atmel, ST, Freescale I do not need different Jtag probes!  I do not understand why J-link Does not support Xilinx and Altera though!

[Moondeck]

Ever heard of GoodFET?

Thanks all, free_electron please notice that xilinx platform cable cost a fortune (225USD)...

http://www.xilinx.com/products/boards-and-kits/hw-usb-ii-g.html

And Also I have lot's of Jtag cables around like J-link, AVR dragon ,STK600 and etc... why I should have the same tool for every other company! fortunately ARM solve the problem some how, so At least for doing my Cortex devices from NXP, Atmel, ST, Freescale I do not need different Jtag probes!  I do not understand why J-link Does not support Xilinx and Altera though!

[oPossum]

EEPROM contents and programming instructions: https://gist.github.com/rikka0w0/24b58b54473227502fa0334bbe75c3c1

[ebclr]

The Chinese already discover how to do that

https://www.aliexpress.com/item/1648220779.html?spm=a2g0o.productlist.0.0.494a764eZd94oB&s=p&ad_pvid=202005220444441162878232454400000641435_1&algo_pvid=03cd6a3b-4a13-4e95-ae49-1877ab301323&algo_expid=03cd6a3b-4a13-4e95-ae49-1877ab301323-0&btsid=0ab6f8ad15901478841251183ee98e&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_

[NorthGuy]

I installed FT232H on my board and wanted to program it through Vivado. Turns out, the FTDI has an external EEPROM which must have a license for use with Vivado. No place where you could buy the license though. What a bummer.

But this is all documented - JTAG, configuaration, FT232H. It took me about 3 days to create my own software to configure FPGA (was Artix-7 in my case) and create a design to program built-in flash. Later I discovered that this wasn't necessary - openOCD can configure FPGAs through FT232H. But it was too late.

[SiliconWizard]

Later I discovered that this wasn't necessary - openOCD can configure FPGAs through FT232H. But it was too late.

Yes. For those interested: take a look in the share/openocd/scripts/cpld subdirectory.
There are config files for the Xilinx 6 and 7 series.

[asmi]

Yes. For those interested: take a look in the share/openocd/scripts/cpld subdirectory.
There are config files for the Xilinx 6 and 7 series.

The greatest advantage of Digilent cables is ability to use ILA and Vivado HW manager for live debugging and monitoring. Configuration is the easiest part IMHO as there are many ways to get it to work, and there are published specs & code examples for getting it to work.
That said, I see no reason to include this circuitry into each and every board, instead I bought a single HS3 cable, and include 14 pin JTAG connector that this cable connects to. I'm also thinking about moving onto TagConnect cable as that solution will allow to remove JTAG connector altogether from future boards.

[SiliconWizard]

That said, I see no reason to include this circuitry into each and every board, instead I bought a single HS3 cable, and include 14 pin JTAG connector that this cable connects to. I'm also thinking about moving onto TagConnect cable as that solution will allow to remove JTAG connector altogether from future boards.

Oh, agreed.

[tmbinc]

You could use https://github.com/tmbinc/xvcd to bridge Xilix labtools to an FTDI, but it's a bit ugly. You could also bridge to a RPi (https://github.com/tmbinc/xvcd/tree/tmbinc/xvcd-rpi) or some other custom board. This fully works with Vivado HW manager/ILA etc.

As others have mentioned, an FT2232H only works with the digilent driver if the right eeprom contents are there... https://shop.trenz-electronic.de/en/TE0790-03-XMOD-FTDI-JTAG-Adapter-Xilinx-compatible for example sells FT2232H with the right EEPROM contents (as well as a cheaper version without that, for use with OpenOCD etc.).

Or of course you can drive JTAG on your own - it's really simple and well documented.

[ali_asadzadeh]

You could use https://github.com/tmbinc/xvcd to bridge Xilix labtools to an FTDI, but it's a bit ugly. You could also bridge to a RPi (https://github.com/tmbinc/xvcd/tree/tmbinc/xvcd-rpi) or some other custom board. This fully works with Vivado HW manager/ILA etc.

As others have mentioned, an FT2232H only works with the digilent driver if the right eeprom contents are there... https://shop.trenz-electronic.de/en/TE0790-03-XMOD-FTDI-JTAG-Adapter-Xilinx-compatible for example sells FT2232H with the right EEPROM contents (as well as a cheaper version without that, for use with OpenOCD etc.).

Or of course you can drive JTAG on your own - it's really simple and well documented.

Thanks for sharing, how should we do it with your repo?

[NorthGuy]

That said, I see no reason to include this circuitry into each and every board, instead I bought a single HS3 cable, and include 14 pin JTAG connector that this cable connects to.

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.

[asmi]

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.

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