I have seen project where FPGA device was able to reprogram bootrom (in this case EEPROM). There was only problem if the EEPROM or FPGA bitstream was broken wrongly written and FPGA won't start and reprogramm memory. I think USB debug interface in FPGA is stupid idea, JTAG is enought to do anything, and additional cost of USB-JTAG programmer is quite low. Of course if you want to have this capabilities just use small USB processor (like Cypress or Microchip) or FTDI USB chip, to do bit-bang emulation of JTAG or program bitstream memory.
If an FPGA comes with "connector-ready" USB functionality inside it, then there are no cost added to your application design. I am not sure whether there are any FPGAs which comes with built-in USB functionality.
In case of design where you need to add an USB functionality to the FPGA, more than the FPGA space, cost of USB IP to handle the protocol(either buying the IP or time involved in developing the IP) and external USB transceiver chip get added to your design cost and it becomes more expensive. USB protocol in itself is a complex implementaion unlike other communication protocol like SPI, I2C,etc. Please email me in email@example.com or firstname.lastname@example.org if you have clarification questions or doubts regarding the USB protocol implementation in FPGA.
As stated in the article, only the design where an USB interface is already a requirement for general data transfer, this method would be a cost effective solution. I apologize if the article does not convey this information directly.
You are right that if USB data interface is never an requirement to the project, then there are lot many simpler and cost effective methods like JTAG that can be used for programming.
If there was already "connector-ready" USB functionality inside the FPGA, there wouldn't be need for any intermediary device. The article stated as a given that this was an expensive use of FPGA resources -- a statement which you can separately debate depending on how much FPGA meat you've got flog.
I think that the point here is that, in lieu of hard or soft USB functionality inside the FPGA, that such a scheme can be used as a bi-directional USB interface for both bitstream downloading as well as a USB Device (and perhaps Host) interface when the FPGA is running. The interface from the FPGA to the bridge chip can be anything from 1-bit serial to N-bit parallel, because the bridge chip is programmable with a decent number of I/O pins.
I concede that I don't know what all the USB Blaster is capable of, but my understanding is that it was merely a barebones programming device. *If* it could be made to do anything useful post-programming, it would have to come back (in this case, the JTAG channel) out through the fairly dumb serial (or custom) driver on the host.
I think the point is that if you both want a direct USB interface for both programming and execution (starting at 10s Mb/sec), then this is one such solution. If don't care about USB for both uses, then yes, you can do with less.
If there was a complete "connector-ready" USB endpoint on the FPGA device, I would say it's the coolest device I've seen all year. But it doesn't have this.
A USB-blaster connected to an Altera device accomplishes the same thing, and an onboard controller with a JTAG interface would effectively do the same.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.