USB Blaster obselete?

The use of the FT2232 and CPLD to emulate onboard USB blaster seems to be common on many of the newer development boards, and I wondering if discontinuing the USB blaster is a reflection of this. It is easier and more compact to just use a standard USB cable to program your FPGA. ~James

--- Quote Start ---

I guess that Altera might bring out an "USB Blaster II" with USB HS interface in the next years, but there aren't any official statements. The note about USB Blaster Rev. C being the replacement for previous types has been recently updated at altera.com. Even if discontinued at Altera, various clones and the official second source (from Terasic) will me most likely available for many years.

--- Quote End ---

Hi James,

--- Quote Start ---

The use of the FT2232 and CPLD to emulate onboard USB blaster seems to be common on many of the newer development boards, and I wondering if discontinuing the USB blaster is a reflection of this. It is easier and more compact to just use a standard USB cable to program your FPGA. ~James

--- Quote End ---

Which boards have you seen that use the FT2232? I've only ever seen the BeMicro use it. The "Arrow USB-Blaster" is significantly slower than a standard USB-Blaster when working with SignalTap II. I have a BeMicro and BeMicro-SDK interfaced to external FTDI UM245R and UM232H modules, and SignalTap II capture using the BeMicro is way slower than using the BeMicro-SDK. The FT2232C MPSSE mode can be operated at the same frequency as the bit-mode/byte-modes on the standard USB-Blaster, so I'm not sure what causes the speed difference ... probably software/driver support.

I've seen that some of the newer development kits now come with a USB-Blaster II = Cypress EZ-USB FX2 + MAX II. This implements a USB-Blaster plus a higher-speed comms channel to the on-board FPGA.

Cheers,

Dave

Dave,

I am not exactly sure which device is being used (FT2232 or FT232R for example) but many of the Terasic boards are FTDI controller + Max II CPLD for the on board USB blaster. Interestingly enough, the schematics for the DE-Nano, for example, do not show the circuit in schematic detail. Only a higher level block diagram is shown. From what I have looked at on the Terasic dev boards, this is generally true, as well as the recent and new Altera dev boards.

The frustrating part to me is the lack of transparency with a proven solution for this approach. I know, there have been several discussions of writing drivers, etc. on the forum, but the fact that this is not an "easy" process is a bit disappointing. So if Altera is going to discontinue the USB blaster, then as the pendulum swings this way, I would like to see more transparency on this driver and on board JTAG hardware.

The closest thing that I've seen to a really nice driver is something written in Python, which will program the Altera FPGA through JTAG, obtained at: https://github.com/progranism/ft232r-jtag

Maybe a group project to take the code and wrap a PyQt/PySide gui around the code that I just referenced with the previous link?

Thanks, James

--- Quote Start ---

Hi James,

Which boards have you seen that use the FT2232? I've only ever seen the BeMicro use it. The "Arrow USB-Blaster" is significantly slower than a standard USB-Blaster when working with SignalTap II. I have a BeMicro and BeMicro-SDK interfaced to external FTDI UM245R and UM232H modules, and SignalTap II capture using the BeMicro is way slower than using the BeMicro-SDK. The FT2232C MPSSE mode can be operated at the same frequency as the bit-mode/byte-modes on the standard USB-Blaster, so I'm not sure what causes the speed difference ... probably software/driver support.

I've seen that some of the newer development kits now come with a USB-Blaster II = Cypress EZ-USB FX2 + MAX II. This implements a USB-Blaster plus a higher-speed comms channel to the on-board FPGA.

Cheers,

Dave

--- Quote End ---

Hi James,

--- Quote Start ---

I am not exactly sure which device is being used (FT2232 or FT232R for example) but many of the Terasic boards are FTDI controller + Max II CPLD for the on board USB blaster.

--- Quote End ---

The on-board USB-Blasters are FT245B+MAX II. The BeMicro-SDK uses an FT245R (which has an internal EEPROM).

--- Quote Start ---

Interestingly enough, the schematics for the DE-Nano, for example, do not show the circuit in schematic detail. Only a higher level block diagram is shown. From what I have looked at on the Terasic dev boards, this is generally true, as well as the recent and new Altera dev boards.

--- Quote End ---

The schematic is not really that exciting. Its just the FT245R in asynchronous FIFO mode connected to the MAX II :)

I've uploaded the BeMicro-SDK schematic, it shows the USB-Blaster circuit. Not very enlightening is it?

What is more important is the USB-Blaster protocol. That was reverse-engineered and published a while ago by Kawk

http://sourceforge.net/apps/mediawiki/urjtag/index.php?title=cable_altera_usb-blaster

--- Quote Start ---

The frustrating part to me is the lack of transparency with a proven solution for this approach.

--- Quote End ---

Yes, it bugs me too. I'm working on a clone ... when it works, I'll write up a tutorial.

The latest FTDI direct access driver allow you to access a USB-Blaster ... I'll also write that up shortly.

Cheers,

Dave

While the development boards are equipped with OnBoard USB I/F, most of the real life production electronics are not (at least "mine" at work aren't). There still exists designs just using an FPGA + EEPROM w/o requiring any USB interface in target application. (In fact I'm not sure, if this USB to EEPROM I/F for programming might be w/o additional circuits useable for system communication I/F...)

In terms of area on PCB as well as production costs it's (in my point of view) a no-go to implement any (proprietary or open source) USB I/F for an one time use during production. Thus there will always be the need for a separate USB <=> EEPROM interface box for production issues.

(Yeah, this "one time required I/F" might (an will most likely) be implemented in an automated teststation for production - but what about prototyping at lab desk or system integration issues at customer site?)

Well, just as a reminder that any discussion of the need to have separate USB I/F programmers like the USB-Blaster should not focus on the need for development boards...

(IMHO the implementation on the Dev.Boards is most likely driven by the need to save the costs for any additional device in the dev.Kit. Selling the kit w/o any interface is no option

Likewise in early days of electronics.... "Connect the device xyz to the unit to establish communication with the PC (device xyz not included) :-)

--- Quote Start ---

Which boards have you seen that use the FT2232? I've only ever seen the BeMicro use it. The "Arrow USB-Blaster" is significantly slower than a standard USB-Blaster when working with SignalTap II. I have a BeMicro and BeMicro-SDK interfaced to external FTDI UM245R and UM232H modules, and SignalTap II capture using the BeMicro is way slower than using the BeMicro-SDK. The FT2232C MPSSE mode can be operated at the same frequency as the bit-mode/byte-modes on the standard USB-Blaster, so I'm not sure what causes the speed difference ... probably software/driver support.

--- Quote End ---

I completely agree to the comment. I was thinking for a while that the pure FT2232 JTAG interface would be an interesting USB Blaster alternative in some situations. It's basically working, but low speed and instability of the driver (I need often need to kill the JTAG driver process after a communication failure) makes it very uncomfortable.

--- Quote Start ---

In terms of area on PCB as well as production costs it's (in my point of view) a no-go to implement any (proprietary or open source) USB I/F for an one time use during production. Thus there will always be the need for a separate USB <=> EEPROM interface box for production issues.

--- Quote End ---

Here's my use case:

• I have a system that will contain 200+ boards. Each of those boards will contain a MAX II + Cyclone IV + Stratix IV GT.

• All 32 x 10Gbps transceivers on all FPGAs will be used

• MAX II devices can only be programmed via JTAG.

• I want to be able to use SignalTapII on any board at any time

• I want to be able to use the transceiver toolkit on any board at any time (for link testing)

• The boards will be housed in CompactPCI serial chassis, and those chassis have USB 2.0 in the backplane.

In this particular design, an on-board USB-Blaster makes the most sense.

Relative to the cost of a Stratix IV GT, the cost of my "improved" USB-Blaster logic is insignificant;

1) USB 2.0 hub Microchip/SMSC USB2412 $1.46

2) Two FTDI FT232H $2.95 (one for comms, one for USB-Blaster)

3) MAX II CPLD $13 (the UFM memory can be used to emulate the FT232H EEPROM)

Once I complete my testing with the FT232H as a replacement for the FT245B/R, I'll post details.

If you have a design where the end-user can access a JTAG header, then using an on-board USB-Blaster is less useful. However, if the USB-Blaster was actually "useful" in that it also provided a reasonably fast PC-to-FPGA communications path, then its worth having such an embedded USB-Blaster. The FT232H can be used in synchronous FIFO mode and can hit 40MB/s sustained transfer rates between the PC and FPGA (according to the FTDI data sheets).

The "improved" USB-Blaster needs to be implemented using a hub + 2 x FT232H devices, rather than a single FT2232H device due to a limitation of the FT2232H device and driver issues. The FT2232H can be used as two asynchronous FIFO devices, or as a single synchronous FIFO device - I want both interfaces active regardless of the FIFO mode. The BeMicro uses an FT2232C and it demonstrates an issue with the device driver under both Windows and Linux; if you have the USB-Blaster active, you cannot use the serial port on the second channel. This same problem likely occurs with Cypress EZ-USB designs, eg., FPGA4U has a USB-Blaster clone that can also provide a communications channel, however, the two interfaces are mutually exclusive. Using a USB hub and two separate USB devices causes the host PC to see two separate USB devices and hence it loads two separate drivers. Sometimes hardware has to be used to solve software problems :)

Cheers,

Dave

Dave,

These are very good comments. I have currently built a GUI that talks to a Cyclone IV device through FT232RL device. I employ the PyUSB module to do so . . . it works pretty seamlessly. http://bleyer.org/pyusb/

What is interesting is all the business with libusb, etc. In the case of the pyusb link above, this is a wrapper around FTDI's drivers. Overall, however, I would agree with you and would list my "general" criteria for an on board USB solution:

On Board USB / Programming Solution Requirements:

1. sof and .jic file programming required (JTAG plus programming of EPCS Config Flash through jtag indirect configuration)

2. Employment of standard usb "mini" header

3. Appears as usb blaster to quartus (some flexibility here)

4. "Fast" transfer rates

Best, James

--- Quote Start ---

Hi James,

The on-board USB-Blasters are FT245B+MAX II. The BeMicro-SDK uses an FT245R (which has an internal EEPROM).

The schematic is not really that exciting. Its just the FT245R in asynchronous FIFO mode connected to the MAX II :)

I've uploaded the BeMicro-SDK schematic, it shows the USB-Blaster circuit. Not very enlightening is it?

What is more important is the USB-Blaster protocol. That was reverse-engineered and published a while ago by Kawk

http://sourceforge.net/apps/mediawiki/urjtag/index.php?title=cable_altera_usb-blaster

Yes, it bugs me too. I'm working on a clone ... when it works, I'll write up a tutorial.

The latest FTDI direct access driver allow you to access a USB-Blaster ... I'll also write that up shortly.

Cheers,

Dave

--- Quote End ---

--- Quote Start ---

1. sof and .jic file programming required (JTAG plus programming of EPCS Config Flash through jtag indirect configuration)

2. Employment of standard usb "mini" header

3. Appears as usb blaster to quartus (some flexibility here)

4. "Fast" transfer rates

--- Quote End ---

The third point is the critical one, I think. It effectively ends up in emulating FT245 on the USB side, or using a FTDI chip and a respective configuration that's recognized by the USB Blaster driver, too. I didn't clearly hear from Dave's posts if this is the case with the new HS FTDI chips. Presently I'm under the impression that a solution like the mentioned Cypress USB Blaster emulation devices promise a better functionality.

Needless to say, that a documented programmer frontend interface to the Altera JTAG stack would be the preferred alternative...

Regards,

Frank