Eight-Core 64-bit Processor for Mobile Devices

MediaTek has announced the MT6795, which the company is targeting at the high-end Android 4G smartphones and tablet segment. According to the press release, the eight-core processor also supports 2560 × 1600 resolution displays, FDD/TDD LTE technology, 802.11ac WiFi, Bluetooth, GPS, FM Radio, and 2G and 3G wireless networks.mediatek

The chip also supports video recording and playback at Ultra HD (4K2K) resolution using the H.265, H.264 and VP9 formats, supporting high-speed 1080p video recording at up to 480 frames per second allowing slow-motion playback on screens with 120 Hz refresh. An integrated 16-MP camera image signal processor handles video input and MediaTek’s ClearMotion technology eliminates motion jitter to ensure smooth video playback at 60fps.

The MT6795 uses eight ARM Cortex-A53 processors, based on a 28-nm process that clocks at 2.0 GHz and a Mali-T760 GPU to handle display control. MediaTek also supplies its CorePilot technology, which provides multicore processor performance and thermal control of the chip. The MT6795 also supports dual-channel LPDDR3 memory at 933 MHz.

According to MediaTek, we can expect to see 4G smartphones using MT7695 chips before the end of  2014.

[Via Elektor]

 

All-Programmable SoC Solution

Anyone creating a complex, powerful digital design may want to turn to a single device that integrates high-speed processing and programmable logic.

In Circuit Cellar’s April issue, columnist Colin O’Flynn explores using the Xilinx Zynq  Z-7020 All Programmable SoC (system-on-a-chip) as part of the Avnet ZedBoard development board.

“I used a Xilinx Zynq SoC device, although Altera offers several flavors of a similar device (e.g., the Cyclone V SoC, the Arria V SoC, and the Arria 10 SoC), and Microsemi offers the SmartFusion2 SoC FPGA,” O’Flynn says in his article. “The Xilinx and Altera devices feature a dual-core ARM Cortex-A9 processor, whereas the Microsemi devices feature a less powerful Cortex-M3 processor. You may not need a dual-core A9 processor, so ‘less powerful’ may be an advantage.”

While O’Flynn’s article introduces the ZedBoard, he notes many of its specifics also apply to the MicroZed board, a less expensive option with a smaller SoC. Xilinx’s Zynq device has many interesting applications made highly accessible through the ZedBoard and MicroZed boards, he says.

O’Flynn’s discussion of the Zynq SoC device includes the following excerpt. (The April issue, which includes O’Flynn’s full article, is available for membership download or single-issue purchase.)

WHERE’S THE BEEF?
Originally, I had planned to describe a complete demo project in this article. I was going to demonstrate how to use a combination of a custom peripheral and some of the hard cores to stream data from a parallel ADC device into DDR memory. But there wasn’t enough room to introduce the tools and cover the demo, so I decided to introduce the Zynq device (using the ZedBoard).

A demo project is available at ProgrammableLogicInPractice.com. Several tutorials for the Zynq device are available at xilinx.com and zedboard.org, so there isn’t any point in duplicating work! I’ve linked to some specific tutorials from the April 2014 post on ProgrammableLogicInPractice.com. Photo 1 shows the hardware I used, which includes a ZedBoard with my custom OpenADC board connected through the I/O lines.

An Avnet ZedBoard is connected to the OpenADC. The OpenADC provides a moderate-speed ADC (105 msps), which interfaces to the programmable logic (PL) fabric in Xilinx’s Zynq device via a parallel data bus. The PL fabric then maps itself as a peripheral on the hard-core processing system (PS) in the Zynq device to stream this data into the system DDR memory.

Photo 1: An Avnet ZedBoard is connected to the OpenADC. The OpenADC provides a moderate-speed ADC (105 msps), which interfaces to the programmable logic (PL) fabric in Xilinx’s Zynq device via a parallel data bus. The PL fabric then maps itself as a peripheral on the hard-core processing system (PS) in the Zynq device to stream this data into the system DDR memory.

FPGA PROCESSOR DESIGN 101
Even if you’re experienced in FPGA design, you may not have used Xilinx tools for processor-specific design. These tools include the Xilinx Platform Studio (XPS) and the Xilinx Software Development Kit (SDK). Before the advent of hard-core processors (e.g., Zynq), there have long existed soft-core processors, including the popular Xilinx MicroBlaze soft processor. The MicroBlaze system is completely soft core, so you can use the XPS tool to define the peripherals you wish to include. For the Zynq device, several hard-core peripherals are always present and you can choose to add additional soft-core (i.e., use the FPGA fabric) peripherals.

In a future article I will discuss different soft-core processor options, including some open-source third-party ones that can be programmed from the Arduino environment. For now, I’ll examine only the Xilinx tools, which are applicable to the Zynq device, along with the MicroBlaze core.

The ARM cores in the Zynq device are well suited to run Linux, which gives you a large range of existing code and tools to use in your overall solution. If you don’t need those tools, you can always run on “bare metal” (e.g., without Linux), as the tools will generate a complete base project for you that compiles and tests the peripherals (e.g., printing “Hello World” out the USART). To give you a taste of this, I’ve posted a demo video of bringing up a simple “Hello World” project in both Linux and bare metal systems on ProgrammableLogicInPractice.com.

The FPGA part of the Zynq device is called the programmable logic (PL) portion. The ARM side is called the processing system (PS) portion. You will find a reference to the SoC’s PL or PS portion throughout most of the tutorials (along with this article), so it’s important to remember which is which!

For either system, you’ll be starting with the XPS software (see Photo 2). This software is used to design your hardware platform (i.e., the PL fabric), but it also gives you some customization of the PS hard-core peripherals.

This is the main screen of the Xilinx Platform Studio (XPS) when configuring a Zynq design. On the left you can see the list of available soft-core peripherals to add to the design. You can configure any of the hard-core peripherals by choosing to enable or disable them, along with selecting from various possible I/O connections. Additional screens (not shown) enable you to configure peripherals addressing information, configure I/O connections for the soft-core peripherals, and connect peripherals to various available extension buses.

Photo 2: This is the main screen of the Xilinx Platform Studio (XPS) when configuring a Zynq design. On the left you can see the list of available soft-core peripherals to add to the design. You can configure any of the hard-core peripherals by choosing to enable or disable them, along with selecting from various possible I/O connections. Additional screens (not shown) enable you to configure peripherals addressing information, configure I/O connections for the soft-core peripherals, and connect peripherals to various available extension buses.

MAKING THE CONNECTION
For example, clicking on the list of hard-core peripherals opens the options dialogue so you can enable or disable each peripheral along with routing the I/O connections. The ZedBoard’s Zynq device has 54 multipurpose I/O (MIO) lines that can be used by the peripherals, which are split into two banks. Each bank can use different I/O standards (e.g., 3.3 and 1.5 V).

Enabling all the peripherals would take a lot more than 54 I/O lines. Therefore, most of the I/O lines share multiple functions on the assumption that every peripheral doesn’t need to be connected. Many of the peripherals can be connected to several different I/O locations, so you (hopefully) don’t run into two peripherals needing the same I/O pin.

Almost all of the peripheral outputs can be routed to the PL fabric as well under the name EMIO, which is a dedicated 64-bit bus that connects to the PL fabric. If you simply wish to get more I/O pins, you can configure these extra pins from within XPS. But you can also use this EMIO bus to control existing cores in your FPGA fabric using peripherals on the Zynq device.

Assume you had an existing FPGA design where you had an FPGA core doing some processing connected to a microcontroller or computer via I2C, SPI, or serial. You could simply connect this core to the appropriate PS peripheral and port the existing code onto the Zynq processor by changing the low-level calls to use the Zynq peripherals. You may eventually wish to change this interface to the peripheral bus, the AMBA Advanced eXtensible Interface (AXI), for better performance. However, using standard peripherals to interface to a PL design can still be useful for many cores for which you have extensive existing code.

The MIO/EMIO pins can even be used in a bit-banging fashion, so if you need a special device or core control logic, it’s possible to quickly develop this in software. You can then move to a hardware peripheral for considerably better performance.

O’Flynn’s article goes on to discuss in greater detail the internal buses, peripherals, and taking a design from hardware to software. For more, refer to Circuit Cellar‘s  April issue and related application notes posted at O’Flynn’s companion site ProgrammableLogicInPractice.com.

Client Profile: Lauterbach, Inc

1111 Main Street #115
Vancouver, WA 98660

Contact:
sales_us@lauterbach.com

LauterbachFeatured Product: The TRACE32-ICD in-circuit debugger supports a range of on-chip debug interfaces. The debugger’s hardware is universal and enables you to connect to different target processors by simply changing the debug cable. The PowerDebug USB 3.0 can be upgraded with the PowerProbe or the PowerIntergrator to a logic analyzer.

Product Features: The TRACE 32-ICD JTAG debugger has a 5,000-KBps download rate. It features easy high-level Assembler debugging and an interface to all industry-standard compilers. The debugger enables fast download of code to target, OS awareness debugging, and flash programming. It displays internal and external peripherals at a logical level and includes support for hardware breakpoints and trigger (if supported by chip), multicore debugging (SMP and AMP), C and C++, and all common NOR and NAND flash devices.

For more information, visit www.lauterbach.com/bdmusb3.html.

Real-Time Trailer Monitoring System

Dean Boman, a retired electrical engineer and spacecraft communications systems designer, noticed a problem during vacations towing the family’s RV trailer—tire blowouts.

“In every case, there were very subtle changes in the trailer handling in the minutes prior to the blowouts, but the changes were subtle enough to go unnoticed,” he says in his article appearing in January’s Circuit Cellar magazine.

So Boman, whose retirement hobbies include embedded system design, built the trailer monitoring system (TMS), which monitors the vibration of each trailer tire, displays the

Figure 1—The Trailer Monitoring System consists of the display unit and a remote data unit (RDU) mounted in the trailer. The top bar graph shows the right rear axle vibration level and the lower bar graph is for left rear axle. Numbers on the right are the axle temperatures. The vertical bar to the right of the bar graph is the driver-selected vibration audio alarm threshold. Placing the toggle switch in the other position  displays the front axle data.

Photo 1 —The Trailer Monitoring System consists of the display unit and a remote data unit (RDU) mounted in the trailer. The top bar graph shows the right rear axle vibration level and the lower bar graph is for left rear axle. Numbers on the right are the axle temperatures. The vertical bar to the right of the bar graph is the driver-selected vibration audio alarm threshold. Placing the toggle switch in the other position displays the front axle data.

information to the driver, and sounds an alarm if tire vibration or heat exceeds a certain threshold. The alarm feature gives the driver time to pull over before a dangerous or damaging blowout occurs.

Boman’s article describes the overall layout and operation of his system.

“The TMS consists of accelerometers mounted on each tire’s axles to convert the gravitational (g) level vibration into an analog voltage. Each axle also contains a temperature sensor to measure the axle temperature, which is used to detect bearing or brake problems. Our trailer uses the Dexter Torflex suspension system with four independent axles supporting four tires. Therefore, a total of four accelerometers and four temperature sensors were required.

“Each tire’s vibration and temperature data is processed by a remote data unit (RDU) that is mounted in the trailer. This unit formats the data into RS-232 packets, which it sends to the display unit, which is mounted in the tow vehicle.”

Photo 1 shows the display unit. Figure 1 is the complete system’s block diagram.

Figure 1—This block diagram shows the remote data unit accepting data from the accelerometers and temperature sensors and sending the data to the display unit, which is located in the tow vehicle for the driver display.

Figure 1—This block diagram shows the remote data unit accepting data from the accelerometers and temperature sensors and sending the data to the display unit, which is located in the tow vehicle for the driver display.

The remote data unit’s (RDU’s) hardware design includes a custom PCB with a Microchip Technology PIC18F2620 processor, a power supply, an RS-232 interface, temperature sensor interfaces, and accelerometers. Photo 2 shows the final board assembly. A 78L05 linear regulator implements the power supply, and the RS-232 interface utilizes a Maxim Integrated MAX232. The RDU’s custom software design is written in C with the Microchip MPLAB integrated development environment (IDE).

The remote data unit’s board assembly is shown.

Photo 2—The remote data unit’s board assembly is shown.

The display unit’s hardware includes a Microchip Technology PIC18F2620 processor, a power supply, a user-control interface, an LCD interface, and an RS-232 data interface (see Figure 1). Boman chose a Hantronix HDM16216H-4 16 × 2 LCD, which is inexpensive and offers a simple parallel interface. Photo 3 shows the full assembly.

The display unit’s completed assembly is shown with the enclosure opened. The board on top is the LCD’s rear view. The board on bottom is the display unit board.

Photo 3—The display unit’s completed assembly is shown with the enclosure opened. The board on top is the LCD’s rear view. The board on bottom is the display unit board.

Boman used the Microchip MPLAB IDE to write the display unit’s software in C.

“To generate the display image, the vibration data is first converted into an 11-element bar graph format and the temperature values are converted from Centigrade to Fahrenheit. Based on the toggle switch’s position, either the front or the rear axle data is written to the LCD screen,” Boman says.

“To implement the audio alarm function, the ADC is read to determine the driver-selected alarm level as provided by the potentiometer setting. If the vibration level for any of the four axles exceeds the driver-set level for more than 5 s, the audio alarm is sounded.

“The 5-s requirement prevents the alarm from sounding for bumps in the road, but enables vibration due to tread separation or tire bubbles to sound the alarm. The audio alarm is also sounded if any of the temperature reads exceed 160°F, which could indicate a possible bearing or brake failure.”

The comprehensive monitoring gives Boman peace of mind behind the wheel. “While the TMS cannot prevent tire problems, it does provide advance warning so the driver can take action to prevent serious damage or even an accident,” he says.

For more details about Boman’s project, including RDU and display unit schematics, check out the January issue.

I/O Raspberry Pi Expansion Card

The RIO is an I/O expansion card intended for use with the Raspberry Pi SBC. The card stacks on top of a Raspberry Pi to create a powerful embedded control and navigation computer in a small 20-mm × 65-mm × 85-mm footprint. The RIO is well suited for applications requiring real-world interfacing, such as robotics, industrial and home automation, and data acquisition and control.

RoboteqThe RIO adds 13 inputs that can be configured as digital inputs, 0-to-5-V analog inputs with 12-bit resolution, or pulse inputs capable of pulse width, duty cycle, or frequency capture. Eight digital outputs are provided to drive loads up to 1 A each at up to 24 V.
The RIO includes a 32-bit ARM Cortex M4 microcontroller that processes and buffers the I/O and creates a seamless communication with the Raspberry Pi. The RIO processor can be user-programmed with a simple BASIC-like programming language, enabling it to perform logic, conditioning, and other I/O processing in real time. On the Linux side, RIO comes with drivers and a function library to quickly configure and access the I/O and to exchange data with the Raspberry Pi.

The RIO features several communication interfaces, including an RS-232 serial port to connect to standard serial devices, a TTL serial port to connect to Arduino and other microcontrollers that aren’t equipped with a RS-232 transceiver, and a CAN bus interface.
The RIO is available in two versions. The RIO-BASIC costs $85 and the RIO-AHRS costs $175.

Roboteq, Inc.
www.roboteq.com