When it comes to attaching an FPGA to a PC, there are lots of options. First there's JTAG, then there's RS232, then there's ethernet, and PCIe. But there's an elephant in this room: why is USB on FPGA so hard?
Sure, every FPGA can be connected to a PC with USB, but it's usually through a dumb bridge chip that does RS232, or maybe uses USB to bitbang JTAG. USB2 is in 'easy' territory for FPGAs at 480Mbps, while USB3 5Gbps is the same bitrate as PCIe Gen 2. Every PC made in the last 15 years has USB. Meanwhile, being stuck behind a bridge chip we manage single-figures Mbps.
Now there are dev boards out there with USB PHY or USB MAC chips on them, which is all very nice, but all very painful to program. Plus they're never there when you need them. But why should this be necessary? Any $2 junk gadget comes with a USB2 device interface these days - I don't know what fab process they use, but it can't be too fancy. Likewise USB microcontrollers are a few dollars.
I realise the USB stack isn't the most friendly to implementation on FPGA - it doesn't play nicely with FPGA SERDES for example. But if a $2 gadget can have all the functions of a USB device on an antique process node, why don't modern FPGAs have at least native USB2 device mode?
Dne nedelja, 04. maj 2014 15:02:44 UTC je oseba Theo Markettos napisala:
First, USB is crap.
Second, you need license from USB consortium in order to get you manufacturer ID code spans etc. And IIRC it was on the order of EURO 4-5K
If your inteface was a hard macro or built into a microcontroller, you might be able to get an ID or two free of charge from the producer of the chip, but without it you have to plunge the dough by yourself if you want to sell the thing as USB compatible.
Ethernet MAC span is both cheaper and less neccessary.
What a strange comment. It is what it is, not perfect, but nothing is perfect. You could say everything we do or use is crap if you don't state why.
USB is usually a requirement for implementers. For users it's a cheap interface for connecting their gadgets. Think of all the revenue generated for companies through the application of USB.
Dne ponedeljek, 05. maj 2014 16:57:24 UTC je oseba John Speth napisala:
Crap is also not perfect, so no collision there.
It would be far to tedious.
But in short - collective intelligence of its implementing body ranges from braindead to level of average moron.
Its standard haven't so much evolved as it caught tumor which has during the course of its growth simply eaten original intentions and implementation.
It's like one of those news we keep reading about "Doctors removed 100lb tumor".
Except that this patient haven't had the courage to go lie under scalpel yet. When tumor overgrows you, "benign" means just that it prefers having you around as a carrier instead as food...
Use first from the row FPGA SoC kit with linux on board. Then you have not only FPGA but also almost standard ARM subsystem with all ethernet, usb, rs232 and so on. Typically you can start ready to use linux image from sd card. This way you have solved problem with interfacing PC to fpga cause ARM system has pretty wide access to FPGA resources.
I should clarify. I've made many boards over the years, using a variety of interface standards. USB has never struck me as being elegant or efficient. Its ubiquity, low cost (in volume), a robust connector and power on the same cable as the signals seem to be its biggest plusses.
The USB physical layer isn't too bad, IMO. Most of the issues encountered during development are to do with the (software) drivers. That and the reuse of VID / PID values by cheap knock-off clone gizmos that don't quite match the functionality of the original, yet are still expected to work. (That isn't the fault of the USB standard though.)
Other posters mentioned the need to purchase an official VID / PID. The process is too expensive for low volume or hobby projects.
USB isn't alone there - for example my current employer owns an Ethernet OUI (a big block of MAC addresses) as well as an Ethertype (protocol specifier). Both of those cost money, but it's a modest once-off cost unlike the annual charge from USB-IF. Another thing to consider is that for (e.g.) Ethernet, there are MAC addresses and Ethertypes that you can use for your hobby projects and experimental protocols that won't get you into trouble. The USB-IF don't provide VID / PID values intended for a similar purpose. (I understand that if you buy a VID with the purpose of making it "free" they will come after you.)
It's the opposite for me. If one of my boards with an FPGA on it is connecting to a PC, it'll be via Ethernet.
During debugging, I might rarely use USB to connect a JTAG pod to my PC though.
I respectfully disagree. One thing that you might like to consider is the I/O required for USB2. It matches well to the sort of process that you would use for a $2 microcontroller, but not so well to the low voltage I/O that you'd find on a 28nm FPGA. There are also analog functions that are needed that you will not find on an FPGA. FPGA vendors don't like including anything that doesn't have wide applicability.
OTOH USB3 uses serial signalling that might be a good match for FPGA transceivers. I haven't looked closely enough at the standard to know for sure, but I suspect there will be problems with idle or sleep (or something like that). OTOH, FPGA transceivers now have support for the analog signalling for SATA, so if there's enough demand in the marketplace, anything can happen. I only put a USB3 controller into a product once - a (then new) NEC / Renesas part that connected to my system using PCIe, so I can't claim to be a USB3 expert.
I'm also aware that low speed (1.5Mb/s) USB can be bit-bashed in software on a cheap microcontroller. I don't think it would be compliant with the spec but it does seem to work and is extremely cheap. That really sounds like it could easily fit into an FPGA, possibly with the addition of some external level translators.
I know you're talking about boards, but if you were talking about part availability, that would be a good point. USB is used in consumer products, and this means that the parts sometimes have short production lives. Some years ago I designed a USB2 hub from ST-Ericcson into a product. They had been made obsolete before our second production run. Now there's an SMSC one in its place. Since then, SMSC has been bought by Microchip and who knows what's going to happen.
Those issues can apply to any part on your board though, and aren't unique to USB. (Has anyone tried to get DDR3 RAM chips when some company in China is manufacturing a large batch of tablets?)
I don't use dev boards, so I really shouldn't comment.
Substitute the string "PCIe" for "USB2" and you have a question I asked of the local Altera and Xilinx reps about five years ago.
I'm still waiting for a good solution to that problem that doesn't involve putting a "bootloader" NVM on the board to configure the FPGA just so it can talk PCIe to get the rest of the configuration.
My guess: USB2 - never. USB3 - a very remote possibility.
The annual charge is not mandatory, it is only to allow you to license use of their logos on new products. You can simply pay the first year (which g ets you your VID) and never pay again. If having the USB logo is important to your product marketing, then you do have to pay for that privilege. Bo ttom line is that the first year $$ gets you the VID (and the use of logos if you choose); subsequent year's $$ allows you to continue to use logos.
A hobby project can use any VID since they do not need to worry about inter operability with anything that the hobbyist doesn't already know about. Pr oviding something for 'free' takes it a bit outside of the realm of a stric t 'hobby' which may open you up to folks coming after you as you say.
I agree. It's the ubiquity that makes it really hard to ignore. (looks at laptop: available ports are Thunderbolt - an obfuscated version of PCI Express that's impossible for normal mortals to use[1] - and USB3.)
Presumably an FPGA could come with a default manufacturer VID/PID, which is device class FF and has a higher level protocol for arbitrating functionality. If you then want to sell it as a product that implements a standard device class then you need apply for a VID/PID. But you have flexibility to do other things (eg ship the first version of your product as an FPGA, then switch to ASIC using the same driver and VID/PID code. Or impersonate another device for interoperability).
How do you program it? Do you have an onboard Ethernet to JTAG converter?
That sounds plausible. Except every phone SoC has a USB OTG port - and some of those are 28nm and not exactly low performance.
Looking at die shots, USB on the Tegra 2 takes up about 1% of die area on a
40nm process (couldn't find any labelled 28nm photos) - that's roughly
0.5mm2. I suppose that could be too high a price to pay, though I wonder how hard PCIe compares? OTOH a USB hard core wouldn't necessarily have all the features of Tegra's, because you'd want the backend of it to be in configurable soft logic.
That would be interesting.
Is USB3 generally more sane in your opinion?
I've been wondering about that - is there a reference for the minimal spec that needs to be implemented? It might be a nice way of stripping down USB to something easier to understand. At least the FPGA shouldn't have the timing awkwardness of microcontrollers.
BTDT, for very similar 'fun'...
Likewise, I have similar bringup tedium.
Do any motherboards wire up the PCIe JTAG lines in a sensible manner?
I'm all in favour of shooting USB2 and moving on...
Theo
[1] I have evil plans in the Thunderbolt department...
Drivers /can/ be a problem with USB, but they don't have to be.
If you need your device to integrate with the operating system (such as happens for mice, printers, USB speakers, mass storage devices, etc.), then it is easy if you can re-use existing standardised drivers (such as the OS's own HID or MSD drivers). If you need to make your own specialised drivers, then it is a tough job on Linux - you need to learn the details of how USB works on the OS as well as the details for the USB class you are implementing, and distributing the drivers can be a challenge. On Windows, even if you understand everything and can do all the windows driver development, it is still a nightmare of signing, certification, etc.
But if your device only needs to talk to programs /you/ write, or libraries/dlls/so's that /you/ write, then it is a lot easier. On Linux, libusb lets your application have direct access to the endpoints on your USB device - you have full control without any drivers in the middle. Until a few years ago, it was still hard on Windows - but someone helpfully ported libusb from Linux to Windows as WinUSB, and with the simple installer "zadig" you can avoid almost all issues with drivers on Windows too.
The charge for a USB VID is one-off. The charge to use the USB logo, trademarks, etc., is annual.
For a hobby project, there is no problem - pick a VID of a company you would never use, or an unassigned VID, and use that. For any professional product, the $2000 (IIRC) charge to buy a VID is annoying but if you budget it as though it were a piece of development equipment, it is not going to be an issue.
Bit-banging low speed USB should be perfectly compliant with the specs (if it is done right, of course). On an FPGA there should be no problem implementing 12 Mb/s USB directly, or 480 Mb/s using an external PHY (the XMOS devices do that, with the 480 Mb/s USB device running in software). The USB protocol is not /that/ complicated.
I'd guess that at least some of 28nm SOCs require external level-shifter. Actually I'd expect it to be true starting from 65nm.
Unfortunately, it's damn hard to get detailed datasheets for SOCs from Quallcomm, Mediatek, Apple or Samsung.
But we can take a look at USB controllers of Xilinx Zync, Altera Cyclon-V SE/SX/ST, Freescale i.MX 6 series and QorIQ and TI OMAP4 and OMAP5. They use virtually the same technology, but not as secretive as high-volume folks. Both Altera and Xilinx export UTMI+ ULPI interface and need external PHY. Both Freescale families implement PHY on chip. TI OMAP4 needs external PHY. TI OMAP5 implements both interface to external phy and on-chip USB 2/3 PHY. On chip PPY has few limitations, but they are probably irrelevant in your use case.
e of their logos on new products. You can simply pay the first year (which gets you your VID) and never pay again. If having the USB logo is importa nt to your product marketing, then you do have to pay for that privilege. Bottom line is that the first year $$ gets you the VID (and the use of logo s if you choose); subsequent year's $$ allows you to continue to use logos.
If you don't care about logos, you can always license a subset of VID 16D0 from MCS Electronics for around 10 Euros each. They bought their VID before the USB-IF cracked down on resellers.
formatting link
I'm not sure if this would keep you from getting WHQL certified or not, and I'd assume it would rule out your ability to use the official USB logo. B ut for many/most products, nobody gives much of a hoot about either of thes e.
-- john, KE5FX (no relationship with MCS other than as a satisfied customer )
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.