FPGA Internal or external USB PHY/SIE ??

[SJA]

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 ?

 

[KJ]

On Sunday, March 27, 2016 at 11:25:52 AM UTC-4, SJA wrote:

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 ....)

You'll probably find that it is not cost effective to use a full USB implementation inside an FPGA, unless it comes as hard logic already in the device. If you use an external PHY, use something with a ULPI interface to minimize 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 better off using an external USB UART like this http://www.ftdichip.com/Products/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 have a relatively small, simple interface to the part.

Kevin Jennings

 

[Theo Markettos]

KJ <kkjennings@sbcglobal.net> wrote:

You'll probably find that it is not cost effective to use a full USB
implementation inside an FPGA, unless it comes as hard logic already in
the device. If you use an external PHY, use something with a ULPI
interface to minimize the pin count (12 pins if I recall correctly).

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.

If you can get by with a relatively 'slow for USB 2' speeds, you might be
better off using an external USB UART like this
http://www.ftdichip.com/Products/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 have a relatively small, simple interface to
the part.

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

 

[GaborSzakacs]

SJA wrote:

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 ?

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

 

[Theo Markettos]

GaborSzakacs <gabor@alacron.com> wrote:

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.

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

 

[rickman]

On 3/31/2016 6:16 AM, Theo Markettos wrote:

GaborSzakacs <gabor@alacron.com> wrote:
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.

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.

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

 

[Tim Wescott]

On Thu, 31 Mar 2016 11:16:32 +0100, Theo Markettos wrote:

GaborSzakacs <gabor@alacron.com> wrote:
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.

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.

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
http://www.wescottdesign.com

 

[Theo Markettos]

Tim Wescott <seemywebsite@myfooter.really> wrote:

On Thu, 31 Mar 2016 11:16:32 +0100, Theo Markettos wrote:

GaborSzakacs <gabor@alacron.com> wrote:
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.

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.

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.

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

 

[rickman]

On 4/4/2016 8:24 PM, Theo Markettos wrote:

Tim Wescott <seemywebsite@myfooter.really> wrote:
On Thu, 31 Mar 2016 11:16:32 +0100, Theo Markettos wrote:

GaborSzakacs <gabor@alacron.com> wrote:
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.

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.

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.

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.

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 didn't look into it much, but the Smartfusion OTG core rickman mentioned
looks simpler and seems like a much better fit.

I can't say for sure, I have not tried working with the USB on the
SmartFusion2 yet.

--

Rick

 

[Theo Markettos]

rickman <gnuarm@gmail.com> wrote:

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?

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

 

[rickman]

On 4/5/2016 7:07 AM, Theo Markettos wrote:

rickman <gnuarm@gmail.com> wrote:
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?

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.

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

 

[Theo Markettos]

rickman <gnuarm@gmail.com> wrote:

I thought specifically this was about using the USB port. Are you
saying the USB port on the rPi is not fully documented?

Yes. (Not publically anyway)

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.

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)

 

[rickman]

On 4/5/2016 4:06 PM, Theo Markettos wrote:

rickman <gnuarm@gmail.com> wrote:
I thought specifically this was about using the USB port. Are you
saying the USB port on the rPi is not fully documented?

Yes. (Not publically anyway)

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.

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 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.

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.

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.

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)

--

Rick

 

[Theo Markettos]

rickman <gnuarm@gmail.com> wrote:

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.

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.

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.

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

 

[Les Cargill]

Theo Markettos wrote:

rickman <gnuarm@gmail.com> wrote:

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.

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.

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.

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.

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

--
Les Cargill

 

[Theo Markettos]

In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:
> On 4/7/2016 6:23 AM, Theo Markettos wrote:

[On the undocumented parts of the Raspberry Pi]

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.

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.

All of them.

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?

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:
https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bcm2835/BCM2835-ARM-Peripherals.pdf
or
https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bcm2836/QA7_rev3.4.pdf
- you won't find them.

Theo

 

[rickman]

On 4/7/2016 6:23 AM, Theo Markettos wrote:

rickman <gnuarm@gmail.com> wrote:

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.

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.

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.

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.

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

 

[KJ]

On Thursday, April 7, 2016 at 5:25:04 PM UTC-4, Theo Markettos wrote:

In comp.arch.fpga rickman wrote:
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?

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.

Another example is the Texas Instruments AM3352 processor. That part has a freely available ~5000 page technical reference manual that lists all of the 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 fields are totally undefined as to their function. TI supplies an RTOS as well 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 at the software device driver level is that uncommon. Obviously 'someone' would have to have the hardware documentation in order to write the device driver(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 code or contracting out the work only under NDA.

Kevin Jennings

 

[Waldek Hebisch]

rickman <gnuarm@gmail.com> wrote:

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.

Have you lookead at the manual at all? I have BCM2835-ARM-Peripherals.pdf
which seem to be the only official documentation and it has 205
pages. This is tiny compared to other chips. For example main
i.MX6 manual from FreeScale has 5739 pages and there are additional
smaller manuals for i.MX6.

USB part in BCM manual tells you that they use Synopsys IP,
what configuration options they use with Synopsis core and
list registers that Broadcom added. In a sense Broadcom
released all _their_ information, but you need to get
Synopsys information from other source.

--
Waldek Hebisch

 

[rickman]

On 4/9/2016 6:48 PM, Waldek Hebisch wrote:

rickman <gnuarm@gmail.com> wrote:

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.

Have you lookead at the manual at all? I have BCM2835-ARM-Peripherals.pdf
which seem to be the only official documentation and it has 205
pages. This is tiny compared to other chips. For example main
i.MX6 manual from FreeScale has 5739 pages and there are additional
smaller manuals for i.MX6.

USB part in BCM manual tells you that they use Synopsys IP,
what configuration options they use with Synopsis core and
list registers that Broadcom added. In a sense Broadcom
released all _their_ information, but you need to get
Synopsys information from other source.

Yes, I looked at the manual. I think I already said I didn't read the
entire manual, so why do you even ask? I was only looking for info on
the part I was using. I don't read 205 page manuals for fun.

Seems weird that there is open source driver code for the various parts
of the chip that has no released documentation. I guess you can figure
out some aspects of how the chip is being used by looking at the driver
code, but anything not being used would still be unknown.

--

Rick