Building a custom embedded SoC platform for embedded Linux

When our R&D team set out to develop a custom, embedded Linux optimized platform, we faced major challenges. First, this platform would have to be low cost and without unnecessary NRE and royalty fees in order to fit high volume manufacturing. We design and manufacture different products for our clients, so this platform had to be modular and scalable to fit different embedded applications, ranging from small Internet appliance devices to larger office routers and VPN boxes. And, we wanted to have fast turn around times for new product development, so that meant we need to have all the know-how and source code in house.

It was decided at the beginning that we would design a system-on-chip (SoC) platform, which yields the best unit price when manufactured in high volume. The usual approach would be to license all the technology from third party suppliers, such as the processor IP and the peripherals' IPs from IP vendors and Linux porting from Linux consultant houses, but since we just starting with Linux and SoC, we didn't want to deal with huge NRE and royalty fees. Also, we would not get the necessary know-how that is often a determining factor when designing a new product in today's ever decreasing time-to-market.

So, we decided to follow the Linux open source philosophy and build our first platform on open source technology. We took several open source IPs from OpenCores and integrate them into an underlying hardware SoC platform optimized for running Linux.

One of the most important advantages of Linux is availability of different device drivers. After some analysis of the requirements for our platform and what already existed in terms of open source IP cores and corresponding Linux device drivers, we decided that our platform will be composed out of a PCI interface, Ethernet 10/100 MAC, UART 16550, VGA/LCD controller, AC97 controller, USB 2.0 device controller, SPI, I2C and PS/2 controllers, and a memory controller. As the main processor we chose OpenRISC 1200, a 32-bit RISC processor that comes with a stable GNU Toolchain and a port of small footprint Microcontroller Linux, the uClinux.

The next critical part of the whole project was to set up a scheme on how to connect all the IPs in a modular way so that we could configure the platform for different embedded applications. An Ethernet VPN application would need more Ethernet MACs and more memory bandwidth, so the underlying SoC microarchitecture will be different than for example for PDA application. Different applications have different memory address maps, interrupts maps and bus bandwidth and priority.

We found out that a central configurable block interconnecting the processor and peripheral IPs did the trick. At a later stage in the project, we created a tool that automatically generated this central block based on IPs selected for a particular application and assigned memory and interrupts maps, and automatically configures Linux kernel and device drivers for that particular application.

As embedded developers often find out, it is difficult to start writing and testing software, if hardware designers are still designing the hardware. It is necessary to parallel these two tasks in order to meet today's critical time-to-market schedules. In addition, each group can provide some test cases to the other as we found out.

We took an existing architectural simulator of the processor and extended it with the peripheral IPs. The new architectural simulator was now an exact copy of actual SoC platform that hardware engineers were working on. All the initial work of porting microcontroller Linux to our pla tform was accomplished using the architectural simulator.

Booting up

The first step was to boot Linux on standard UART 16550 serial console. Once this was working, Linux binary was tested on FPGA prototype of the SoC that hardware engineers have built meanwhile. As one group of software engineers were extending architectural simulator with models of new devices, another group was adding drivers for these devices to the Linux kernel. At the same time, the hardware engineers were verifying IP cores of these devices with simple test cases and integrating IP cores into platform SoC. When the software engineers had their drivers running on architectural simulator, they were ready to test them on an updated SoC FPGA platform.

It was interesting to see how well architectural simulator matched the SoC. For example, we could boot Linux with VGA console, and that in fact meant that the simulator was generating near real-time images of simulated VGA console. Another ex ample: we could boot Linux with the networking active, and a real host on our intranet could telnet to a simulated Linux host on our simulator. When all of the software worked perfectly on the simulator, we downloaded it to our FPGA development board and ran it there. On the FPGA development boards, things were running much faster, almost at the speed of the final ASIC product.

At an early stage, there were some problems because we were also testing different design flows and prototyping methodologies. But once we agreed on a simulation and synthesis environment, in our case Cadence and Synplicity, and once we fixed all the problems with our custom-made FPGA development boards, we knew we are on the right track. Our team managed to build entire an SoC and show a couple of different demo applications running on top of Linux with a team of less than dozen engineers in a matter of a few months.

Probably one of the most important factors to our success was that we had all the source codes and we did not have to wait for on any third parties to fix bugs. This is also a strong case when comparing Linux with closed source operating systems such as Windows CE or VxWorks.

We are now building the next generation SoC for running Linux, one that can use any processor IP, including ARM and ARC, and any kind of peripheral IP regardless of interconnect bus.

Within a few months, we gained enough Linux experience so our team can quickly create a custom embedded Linux SoC without significant investment in time and engineering resources. Just recently we completed a project that featured Linux on Hitachi SH4 based project, in that particular instance it wasn't SoC based.