We need to interface 8 to 16 embedded USB 2.0 devices to an FPGA.
We could just use external ULPI transceivers but am wondering
what FPGAs have transceivers that are USB 2.0 compatible and if
the internal USB SIE gate count is low enough to make it cost
effective to wire the USB devices directly to the FPGA. (Would save
lots of pins ....)
Any suggestions ?
You'll probably find that it is not cost effective to use a full USB implem
entation inside an FPGA, unless it comes as hard logic already in the devic
e. If you use an external PHY, use something with a ULPI interface to mini
mize the pin count (12 pins if I recall correctly).
If you can get by with a relatively 'slow for USB 2' speeds, you might be b
etter off using an external USB UART like this
ucts/ICs/FT232R.htm from FTDI. The ones I've seen will top out at around 3
MBaud, but they are USB 2, the FPGA logic to support is trivial and you ha
ve a relatively small, simple interface to the part.
It's a bit of a headache because I'm not aware of any FPGAs with a hard USB
MAC. There are commercial soft IP cores for USB, but I have no experience
of them and suspect them to be large. I don't know of any FPGA vendors who
provide their own USB IP. Maybe somebody does a relatively compact USB 1.1
MAC as a starting point?
If you want to put the USB off-chip, there are few USB parts particularly
friendly to FPGAs - most are expecting PCIe or similar. Currently we use
the SAF1761 / ISP1761 but that feels like it's approaching end of line.
Note the OP wants a USB host not a USB device part, so the above won't do.
If a USB device is required, the problem is much easier: there's a variety
of USB microcontrollers - the Cypress EZ-USB FX2 family (CY7C68013) is a
The other troublesome part is the software side: how much of an OS are you
running on or near the FPGA? USB needs a substantial software stack, and
most of the code out there for host controllers assumes a heavyweight OS.
Likewise Altera's SoC parts. It does mean running Linux on the ARM for
driver reasons. But that's probably the most sensible way to go if you
really need an FPGA with USB host support.
However the main issue is it limits you to a range of SoC silicon: there are
Cyclone V and Arria V SoC parts, but no Stratix currently. Arria 10 SoC
production silicon is on long lead time at the moment.
I've seen USB host software available as an add-on for embedded systems
That's the extent of my knowledge. It ought to work, and may be sensible
if you just need a little dingus with USB host capabilities, and not a
The reason it's nontrivial is the IP cores used are typically complex, and
the driver stack assumes a full-fat OS (threading, virtual memory, DMA etc).
If you have a simple IP core, it's possible to write simple software. With
a complex IP core it is possible to stray 'off piste' and write your own
software, but that depends on the vendor providing documentation. In the
case of the Synopsys core used on the Cyclone V SoC, which happens to be the
same core as the Raspberry Pi, the core documentation is very confidential.
A few people have reverse engineered it, but every OS I know about uses the
Synopsys driver - which is 40K LOC.
I didn't look into it much, but the Smartfusion OTG core rickman mentioned
looks simpler and seems like a much better fit.
What confidential info in the rPi core? My understanding is that the
GPU has proprietary aspects, but the core is ARM which is fully
documented. Do I not understand this properly?
I can't say for sure, I have not tried working with the USB on the
We're talking peripheral IP cores. The Pi has a bunch of IP from third
party vendors - Synopsys (USB), Arasan (SDHCI), maybe others (DDR2
controller?). Those are proprietary and documentation is not public.
(though the SD core mostly obeys the SDHCI spec so is less of an issue)
Any SoC is much more than the CPU, and it's the I/O where it always gets
I thought specifically this was about using the USB port. Are you
saying the USB port on the rPi is not fully documented? Like I said, my
understanding is that the only portion of the rPi processor (the
original rPi, I haven't discussed the new rPi 2 or 3 processors with
anyone) that is not fully documented (that means as well as anyone ever
documents complex cores) is the GPU. This has been discussed widely
about the rPi and I'm sure it would have been brought up if any other
portions were not fully documented.
Yes. (Not publically anyway)
That is incorrect. This is a misapprehension because most people are
running Linux, and Linux has drivers for these peripherals, so they don't
care. It only comes to bite you when you want to write drivers for an OS
(or lack of OS) that isn't Linux.
The situation with the Pi is actually somewhat better than that because a)
the Arasan core is (more or less) SDHCI, which is a documented standard even
if this particular core isn't. The next usual problem then relates to
clocks, resets and power control which are frequently controlled external
to an IP core (so not in its documentation), quite often by a pile of GPIOs
in a dark corner. In this case the GPU handles those so we just use its API
(config.txt or mailbox) and don't have to worry. But it's not the same as
understanding what it's doing inside.
(who notes that ability to cut and paste random IP into an SoC frequently
makes for a mess that software people have to deal with)
The issue was open source software. The drivers for the GPU were
binary. If the drives for any other part of the chip were binary I'm
sure it would have come up.
What part of the CPU chip on the rPi is not documented in the manual?
It is large and I have not read it all of course, but I'm sure I would
have heard in these discussions if there were any other part than the
GPU that was driven by closed source code.
Many-KLOC drivers are not the same as documentation, even if they're open
You'll find many many SOCs where source code is available but documentation
is not. Most Android phones for example. The OSS people moan about binary
blobs, they do not moan that about undocumented hardware or hardware that is
unusable without the vendor-provided OSS driver. That driver keeps the
Linux OSS folks happy, but is not helpful if you want to write your own
driver (for an OS that isn't Linux, for example).
The moral of the story is that a lot of the debate about OSS is framed by
software people with a very strong Linux focus. They aren't hardware
engineers. It may have OSS but not be open hardware - indeed most devices
that run Linux aren't open hardware.
There is no 'CPU chip', it's a system on chip, ie a paste together of
silicon and HDL IP from different vendors. Off the top of my head:
The VideoCore GPU 'scalar/vector' processor (VPU)
The VideoCore GPU 'shader' processors (QPU)
The graphics pipeline (DMA, DAC, HDMI tranceiver, etc)
The DSI display output
The imaging pipeline (CSI, camera hardware)
Cache internals and memory controller
The Syonpsys USB core
The Arasan SDHCI core (any differences from the standard SDHCI)
Internal power control
Internal clock generation
Internal resets (if any, I'm unclear)
There are probably other bits.
The Linux people aren't that happy about it but the experience with
graphics cards has led to acceptance of this.
Linus is on record as saying all drivers should trigger a full on GPL
cascade - that all drivers, and any* other code that runs in kernel
mode is part of the kernel ( which is true from a support/accountability
But graphics card makers have set the standards and practices. The
OSS folk made their peace with the Philistines.
The problem then becomes - you may hear from
corporate counsel that the drivers for your FPGA may be a
It's a bit more unsettling that say, an Allwinner A20 requires
a blob. My understanding is that this is an extension
of the same principle but because those SOICs are not available
with seperable graphics cards,
The generation that remembers what happens when all hardware is
proprietary is going into the sunset. And phone makers re at
least attempting to exploit this. Pure IP
ploys rarely work out, however.
Which of these bits are not fully documented (by "not fully" I mean as
fully as digital logic is ever documented). I know the GPU is
proprietary and only supported by an closed source binary module.
I find it hard to believe the cache and memory controller are not fully
documented for example. Is the USB core only supported with a binary
core? How about the clock generator? You are saying there is source
code, but no documentation?
[On the undocumented parts of the Raspberry Pi]
All of them.
You can find it hard to believe if you like. To repeat myself, in the USB
case the driver is open source but documentation of the hardware is not. In
the SDHCI case the core is based on a standard but the documentation for the
specific IP core is not available.
All the rest are controlled by the GPU with the ARM sending commands via the
'mailbox' interface: ie there is a software API, there is no hardware
Look for them in:
Another example is the Texas Instruments AM3352 processor. That part has a
freely available ~5000 page technical reference manual that lists all of t
he myriad registers for all of the various subsystems (such as the two USB
cores) as well as the bit fields within the registers, but many of those fi
elds are totally undefined as to their function. TI supplies an RTOS as we
ll as Linux for the device. Unless you reverse engineer to create your own
documentation, using the OS is the only way to use that device.
Unfortunately, I don't think undocumented hardware that is only supported a
t the software device driver level is that uncommon. Obviously 'someone' w
ould have to have the hardware documentation in order to write the device d
river(s), but that can be taken care of without divulging the documentation
outside of the company's control by writing and owning the device driver c
ode or contracting out the work only under NDA.
I was talking about this because of the rPi and the controversy around
the lack of source for the GPU. I thought that was the only binary code
in the Linux package. Theo is saying that even though there are source
codes for various other pieces of the chip, the pieces are not actually
documented. That surprises me. But it's not the first time I've been
BTW, I apologize to Theo if I sounded a bit stiff about this. I just
don't like to fully believe something if there is doubt. But now that I
have heard this from several people, I guess I should believe it.
Not so long ago there was a much-ballyhoo'd "release" of GPU documentation
and a "contest" to use the GPU. The implication seemed to be that we'd
see a GPU-accelerated X server in the not-too-distant future.
Was that entirely of smoke and mirrors?
Thanks for reading,