FPGA Internal or external USB PHY/SIE ??

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 ?
Reply to
SJA
Loading thread data ...
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
formatting link
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.
Kevin Jennings
Reply to
KJ
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 popular choice.
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.
Theo
Reply to
Theo Markettos
Xilinx Zynq parts have one USB 2.0 or 3.0 port. You'd still need to implement a hub off-chip to connect your peripherals.
--
Gabor
Reply to
GaborSzakacs
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.
Theo
Reply to
Theo Markettos
The Smart Fusion2 devices from Microsemi also support USB in hardware only requiring an external ULPI PHY. The processor is an ARM CM3 and does not require running Linux to use the USB.
--

Rick
Reply to
rickman
I've seen USB host software available as an add-on for embedded systems without Linux.
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 big machine.
--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott
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.
Theo
Reply to
Theo Markettos
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 SmartFusion2 yet.
--

Rick
Reply to
rickman
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 messy.
Theo
Reply to
Theo Markettos
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.
--

Rick
Reply to
rickman
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.
Theo (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)
Reply to
Theo Markettos
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.
--

Rick
Reply to
rickman
Many-KLOC drivers are not the same as documentation, even if they're open source.
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 GPU': 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) Hardware encoders/decoders 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.
Theo
Reply to
Theo Markettos
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 perspective ).
*or something...
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 GPL liability.
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.
--
Les Cargill
Reply to
Les Cargill
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?
--

Rick
Reply to
rickman
[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 documentation.
Look for them in:
formatting link
or
formatting link
- you won't find them.
Theo
Reply to
Theo Markettos
B
In
the
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.
Kevin Jennings
Reply to
KJ
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 surprised. :)
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.
--

Rick
Reply to
rickman
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,
bob prohaska
Reply to
bob prohaska

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.