Details on Ettus E100?

Josh or Matt,

Would you please tell me which TI OMAP processor is exactly used in
E100, OMAP3530 or OMAP 3525 or other?

Also, is there some hardware architecture diagram available somewhere?
What software support is currently available?

Thanks,
Andrew

On Mon, Dec 13, 2010 at 4:43 AM, Andrew Ge [email protected] wrote:

Josh or Matt,

Would you please tell me which TI OMAP processor is exactly used in E100,
OMAP3530 or OMAP 3525 or other?

I can only guess, but it was mentioned in the announcement thread that
the board has 512 MB RAM, which suggests it it the Overo Tide with
OMAP3530 - all other boards come with 256 MB RAM + 256 MB flash.

Alex

On 12/12/2010 07:43 PM, Andrew Ge wrote:

Josh or Matt,

Would you please tell me which TI OMAP processor is exactly used in
E100, OMAP3530 or OMAP 3525 or other?

We use the Gumstix Overo Tide module which has an OMAP3530 at 720 MHz
with 512 MB of RAM.

Also, is there some hardware architecture diagram available somewhere?

There is a preliminary datasheet on our ordering page:

http://www.ettus.com/order

A block diagram is coming soon.

What software support is currently available?

The UHD and any software which uses UHD (including GNU Radio) works on
it.

Matt

On 12/12/2010 07:43 PM, Andrew Ge wrote:

Josh or Matt,

Would you please tell me which TI OMAP processor is exactly used in
E100, OMAP3530 or OMAP 3525 or other?

Also, is there some hardware architecture diagram available somewhere?
What software support is currently available?

We have updated the datasheet with a block diagram. You can find it on
our ordering page or here:

http://www.ettus.com/downloads/USRP_E100_Series_temporary_datasheet.pdf

Matt

Why was the ADC dropped back to 64 MSPS (from the 100 MSPS of the USRP)?

On Mon, Dec 13, 2010 at 6:53 PM, Matt E. [email protected] wrote:

We have updated the datasheet with a block diagram. You can find it on our
ordering page or here:

http://www.ettus.com/downloads/USRP_E100_Series_temporary_datasheet.pdf

Matt

Thanks Matt - that’s very helpful. Interesting in that the Gumstix
configures the FPGA. I see the fpga-downloader program in
host/lib/usrp/usrp_e100 that does the work, and presumably with the
stock linux distribution you’re shipping it has the image file in some
default location, and it looks like the uhd driver calls a magic
find_image_path function to find it. Are you all working on an
E-Series Application Note like the rather nice ones already existent
for the USRP1/2/N-series? Perhaps you could include some notes for
those of us who would want to create a custom distro image for our
E100’s. Do you plan to share/host a repository of the default distro
loaded on the Gumstix? Are you using Angstrom to build that image?

As a side note it looks like there is no aeMB/microblaze loaded in the
fpga for the e100 (at least not in the fpga/usrp2/top/u1e directory,
which I assume is the correct place to look), so no firmware file to
create/load - which also presumably leaves more room for DSP work,
yes?
Thanks again,
Doug


Doug G.
[email protected]

On 12/14/2010 08:34 AM, Douglas G. wrote:

Thanks Matt - that’s very helpful. Interesting in that the Gumstix
configures the FPGA. I see the fpga-downloader program in
host/lib/usrp/usrp_e100 that does the work, and presumably with the
stock linux distribution you’re shipping it has the image file in some
default location, and it looks like the uhd driver calls a magic
find_image_path function to find it.

Yes.

Are you all working on an
E-Series Application Note like the rather nice ones already existent
for the USRP1/2/N-series? Perhaps you could include some notes for
those of us who would want to create a custom distro image for our
E100’s.Do you plan to share/host a repository of the default distro
loaded on the Gumstix? Are you using Angstrom to build that image?

We have based our distro on Angstron and OpenEmbedded. The vast
majority of packages come from the standard repositories, and we have
our UHD and kernel driver work added to that.

As a side note it looks like there is no aeMB/microblaze loaded in the
fpga for the e100 (at least not in the fpga/usrp2/top/u1e directory,
which I assume is the correct place to look), so no firmware file to
create/load - which also presumably leaves more room for DSP work,
yes?

There is no aeMB so there is no firmware in the sense that we have on
the USRP2. The OMAP fulfills that role because it has direct
low-latency bus access to the FPGA. The FPGA can directly interrupt the
CPU as well.

Matt

Oops I mean USRP2 at 100 MSPS.

On Tue, Dec 14, 2010 at 1:37 PM, Scott Johnston
[email protected] wrote:


Scott Johnston
MIT Lincoln Laboratory
244 Wood Street, Lexington, MA 02420-9108
(781) 981-8196
[email protected]

Scott,
I believe the Imagination Tech folks have been talking about support
for OpenCL with the PowerVR, but its not clear if the model in the
OMAP 3530 will be supported - and in particular it sounds like TI
would have to release the driver implementation for it.
Doug


Doug G.
[email protected]

On Tue, Dec 14, 2010 at 12:32 PM, Matt E. [email protected] wrote:

We have based our distro on Angstron and OpenEmbedded. The vast majority of
packages come from the standard repositories, and we have our UHD and kernel
driver work added to that.

Ok, thanks.

There is no aeMB so there is no firmware in the sense that we have on the
USRP2. The OMAP fulfills that role because it has direct low-latency bus
access to the FPGA. The FPGA can directly interrupt the CPU as well.

Interesting - those interrupts are through the GPMC bus? I assume then
the kernel module collects the interrupts, and passes the data to
userland (i.e. UHD).

Matt

One more question - about cabling this time. Does the UE100-KIT come
with any adapters to assist with plugging my standard sized USB
devices (keyboard/mouse, flash drive, etc.) into the various USB ports
on the front panel? If not, can you describe which port is which type

  • the serial console port looks like a mini-B, and the USB OTG and
    Host ports look like they might be micro-B’s, but I’m not familiar
    enough with the mini/micro USB ports to tell just from the picture on
    your data sheet.
    Thanks again,
    Doug


Doug G.
[email protected]

On 12/14/2010 01:47 PM, Douglas G. wrote:

One more question - about cabling this time. Does the UE100-KIT come
with any adapters to assist with plugging my standard sized USB
devices (keyboard/mouse, flash drive, etc.) into the various USB ports
on the front panel? If not, can you describe which port is which type

  • the serial console port looks like a mini-B, and the USB OTG and
    Host ports look like they might be micro-B’s, but I’m not familiar
    enough with the mini/micro USB ports to tell just from the picture on
    your data sheet.

For the USB host function I use a cable I bought from Digikey, WM17494,
which is a mini-B to mini-A cable. For the console connection the cable
is a standard A to mini-B.

Philip

On 12/14/2010 01:37 PM, Scott Johnston wrote:

Matt,

Since the OMAP has a GPU incorporated does that mean that we could use
it for processing? Is there a CUDA equivalent for this type of GPU?

Thanks for any guidance,

Important note: I sort of know what CUDA means …

I talked to a guy from Imagination at a trade show a few months back and
he used words that made this sound like it was possible. Although the
later comment about needing some piece from TI sounds reasonable.

He also suggested there are operations in opengl that could be used for
signal processing.

Philip

Matt,

Since the OMAP has a GPU incorporated does that mean that we could use
it for processing? Is there a CUDA equivalent for this type of GPU?

Thanks for any guidance,

Scott

Matt E. wrote:

[email protected]
Discuss-gnuradio Info Page


Scott Johnston
MIT Lincoln Laboratory
244 Wood Street, Lexington, MA 02420-9108
(781) 981-8196
[email protected]

On 12/14/2010 10:45 AM, Douglas G. wrote:

for OpenCL with the PowerVR, but its not clear if the model in the
OMAP 3530 will be supported - and in particular it sounds like TI
would have to release the driver implementation for it.

Doug has it pretty correct here. This is one of those areas I would
call theoretically possible, but unlikely to be worth the trouble. You
would need Imagination Tech and TI to get together to release an OpenCL
implementation for the GPU, and even then it isn’t the world’s fastest.

The way I look at it, you have 3 much better, easier to use options –
the ARM, the DSP, and the FPGA. If you put all those to good use and
still need more power, the GPU is not likely to contribute appreciably.

Matt

On Dec 14, 2010, at 10:47 PM, Douglas G. wrote:

One more question - about cabling this time. Does the UE100-KIT come
with any adapters to assist with plugging my standard sized USB
devices (keyboard/mouse, flash drive, etc.) into the various USB ports
on the front panel? If not, can you describe which port is which type

  • the serial console port looks like a mini-B, and the USB OTG and
    Host ports look like they might be micro-B’s, but I’m not familiar
    enough with the mini/micro USB ports to tell just from the picture on
    your data sheet.

From past experience working with the Overo Earth/Fire COM modules
and various gumstix expansion boards :

a. USB OTG port would require a USB Cable (mini-B to mini-A) which has
a white plastic connector on one end, and a black connector on the other
end.

http://www.gumstix.com/store/catalog/product_info.php?products_id=219

It’s kind of a waste of time trying to create your own, plus this cable
is difficult
to come by, so its better ordering one.

You can then plug the black end of this cable, to a powered USB hub.

I use a nice compact Logitech H-UE5 with 4 USB ports.

http://www.amazon.com/Logitech-Premium-4-Port-USB-Hub/dp/B000RZUV9S

You can hook up a keyboard, mouse or external USB wlan module to this
port.
The power supply accepts a 5V input with a 2.5A current rating, so its
got
sufficient power for most peripherals.

USB OTG means it can act as both a host to other peripheral devices
or as peripheral device when connected to a connectedhost computer.

b. USB Host is the regular interface but with a mini-A end.

c. The console port is a serial debug console port of the OMAP35x
processor.
Internally, the OMAP35x has 3 serial UARTs, of which one is connected to
an
FTDI RS232 to USB converter (on the gumstix expansion boards, not sure
about
the E100).

The debug console is useful for obtaining diagnostic information from
the host
processor during the boot process (MLO, u-boot, kernel uImage), and as
the system
boots into the root filesystem.

Think of this as a linux terminal console for the Gumstix Overo module.

Elvis D.

On Dec 14, 2010, at 11:14 PM, Matt E. wrote:

Since the OMAP has a GPU incorporated does that mean that we could use it
for processing? Is there a CUDA equivalent for this type of GPU?

Doug has it pretty correct here. This is one of those areas I would call
theoretically possible, but unlikely to be worth the trouble. You would need
Imagination Tech and TI to get together to release an OpenCL implementation for
the GPU, and even then it isn’t the world’s fastest.

The way I look at it, you have 3 much better, easier to use options – the ARM,
the DSP, and the FPGA. If you put all those to good use and still need more
power, the GPU is not likely to contribute appreciably.

A quick search on the internet yields some interesting info, but at the
end, you’d probably get much better results off the FPGA.

Some work done by Nokia:

http://www.hotchips.org/archives/hc21/1_sun/HC21.23.2.OpenCLTutorial-Epub/HC21.23.270.Pulli-OpenCL-in-Handheld-Devices.pdf

The OMAP4430 seems to have support for OpenCL as mentioned in this
article:

You can get a Pandaboard from DigiKey for USD$179 which has the OMAP4430
and the required GPMC interface available on the Pandaboard expansion
header, to experiment with.

A statement from TI from this link:

“TI does not support OpenCL for the SGX530. IMG does advertises GP-GPU
applications on the SGX, but TI does not license these OpenCL drivers.
The best available solution would be to use the OpenGL ES 2.0 shading
language (GLSL ES 1.0) to do the single precision matrix operations that
you need. Rather than displaying the output results as pixels in a
framebuffer, your program on the ARM can use the results.”

Another statement from Imagination Technologies from this link:
http://www.imgtec.com/forum/forum_posts.asp?TID=194&PID=2668

"The SGX530 core design that’s in an OMAP 3530 board is an example of
one of our products. This was licenced to TI and is a design with the
capability of supporting the OpenCL Embedded profile. However, it
requires the correct software i.e. drivers to expose this functionality,
just like drivers are required for OpenGL ES, DirectX etc. Once we have
licenced a core like this we work with the customer (in this case TI) to
support them in exposing the functionality that they wish to have
available in their product. So if a customer wants to expose OpenCL then
this work happens, but it requires time and the desire of the customer.
This means that developers don’t always have full access to every
feature that our cores are capable of because the driver support is
still being added or the customer doesn’t wish to expose that feature.

In summary: we advertise an ability of our core design and our customers
get a core design that can do this if they choose to enable it. The
developer gets a core with access to the features that our customer has
exposed. So developers don’t always have access to every feature of our
core.

Licence deals involve a certain amount of confidentiality so I can’t
talk about future products or support from our customers so I can’t tell
you when or if OpenCL will be enabled on specific platforms on this
forum at this time."

Elvis D.

On 12/14/2010 10:47 AM, Douglas G. wrote:

There is no aeMB so there is no firmware in the sense that we have on the
USRP2. The OMAP fulfills that role because it has direct low-latency bus
access to the FPGA. The FPGA can directly interrupt the CPU as well.

Interesting - those interrupts are through the GPMC bus? I assume then
the kernel module collects the interrupts, and passes the data to
userland (i.e. UHD).

The GPIOs generate interrupts. The GPMC is for data transfer. In any
case, our kernel driver handles all of it for you, and you just need to
use the UHD just like on any other USRP.

One more question - about cabling this time. Does the UE100-KIT come
with any adapters to assist with plugging my standard sized USB
devices (keyboard/mouse, flash drive, etc.) into the various USB ports
on the front panel? If not, can you describe which port is which type

  • the serial console port looks like a mini-B, and the USB OTG and
    Host ports look like they might be micro-B’s, but I’m not familiar
    enough with the mini/micro USB ports to tell just from the picture on
    your data sheet.

The serial console uses a standard mini-B which is very common. Micro
connectors are different.

The OTG and host ports use mini-AB connectors. The host needs to have a
miniA cable and the OTG port uses either miniA or miniB.

We are including a mini-A to female A adapter with the purchase so you
can use your standard cables as included with hubs or mice, etc. or as
built into your flash drives.

Matt

Elvis-

The way I look at it, you have 3 much better, easier to use options – the ARM,
the DSP, and the FPGA. If you put
The OMAP4430 seems to have support for OpenCL as mentioned in this article:
in a framebuffer, your program on the ARM can use the results."
feature that our cores are capable of because the driver support is still being
added or the customer doesn’t wish to
expose that feature.

In summary: we advertise an ability of our core design and our customers get a
core design that can do this if they
choose to enable it. The developer gets a core with access to the features that
our customer has exposed. So
developers don’t always have access to every feature of our core.

Licence deals involve a certain amount of confidentiality so I can’t talk about
future products or support from our
customers so I can’t tell you when or if OpenCL will be enabled on specific
platforms on this forum at this time."

A future option is to use OpenMP to annotate sections of user C code
that will run on the C64x+ core. We’ve made some
preliminary mention of this on TI’s e2e forum (CIM OpenMP site:ti.com).
We use “OpenMP style” syntax, basically the
same pragmas with omp replaced by sig.

For compute-intensive C code, TI cores have decent SIMD capability
(especially the new C66x series) and (unlike GPUs)
are also good at irregular code sections.

-Jeff