Development Tools for ASPs

Virtual Platforms from Xilinx and Altera Support Development on ASPs

Application Services Platforms combine a hard CPU with an FPGA fabric on a single die. Developing applications requires the combination of software programming with programmable logic development. Two rival vendors have created virtual tools to support such development.


  • Page 1 of 1
    Bookmark and Share

Article Media

Everybody has a different name for them: Programmable SoC (PSoC) from Cypress, SmartFusion from Microsemi, Extensible Processing Platform (EPP) from Xilinx and, most recently, SoC FPGA from Altera. In these pages we have named them Application Services Platforms (ASPs). All this varied nomenclature focuses on a new class of devices that combines a hard-wired CPU with a set of configurable or programmable logic on the same silicon die. In the case of Cypress, the latter consists of generally defined configurable logic elements. In the case of Microsemi, Xilinx and Altera, it is an FPGA fabric to which have been added a small number of hard-wired interfaces.

In the case of Xilinx and Altera, which are the major topics here, the two arch-rivals have developed ASP devices based on a common CPU architecture—the dual-core ARM Cortex-A9 MPCore processing system—combined with FPGA fabric selections based on their own advanced programmable logic technologies. Both are implemented in a 28nm process technology. It is the implementation of the FPGA fabric that differentiates the specific device offerings both between the two vendors and within their own product families.

In general terms, the idea of such an ASP integrates the major components of an embedded system design, with the exception of memory and storage, onto a single device. This brings two distinct technologies together on the same die. It also brings two distinct development disciplines onto a single die. The CPU section, along with the complement of normal peripherals, is programmed using the rich offering of ARM development tools available on the market using widely understood programming languages like C. The FPGA fabrics can be configured with IP and/or programmed using the tool suites available from Xilinx and Altera respectively. Using two different tool environments and programming disciplines for such a tightly integrated device is, however, not the optimal solution.

Both Altera and Xilinx have now introduced virtual environments that are initially aimed at getting users started with software development in advance of actual hardware availability. At the time of this writing neither device family is actually on the market, but both are anticipated in the near future. The Xilinx offering is called the Zynq-7000 EPP Extensible Virtual Platform (Figure 1), and the Altera offering is the SoC FPGA Virtual Target (Figure 2). Both companies have also teamed with major EDA companies in the creation of their virtual environments—Altera with Synopsis, and Xilinx with Cadence.

Figure 1
The System Creator level of the Xilinx Zynq-7000 EPP Virtual Platform models the ARM core, its peripherals and other needed interfaces. In addition, it supports TLM models of interfaces to functionality that will be placed in the FPGA fabric such that both software and logic designers can develop to the common interface definition.

Figure 2
The Altera SoC FPGA Virtual Target models the ARM core and its peripherals as well as the interfaces and devices on a development board. Additionally, it supports an optional extension to an actual FPGA on a hardware development board.

At this point, both virtual environments appear to emphasize the development of software on the device both in terms of how it functions as code on the ARM processor and how it interacts with functions that will be implemented in the FPGA fabric of the respective devices. 

The Altera Virtual Target implements a binary- and register-compatible PC-based simulation model of the ARM Cortex-A9 and its peripherals along with the system peripherals found in its Cyclone V and Arria V-based ASPs. It also models board-level components including DDR SRAM, flash memory and virtual I/Os. 

Similarly, the Xilinx Zynq-7000 EPP implements a register-level accurate model of the ARM processor and its peripherals plus memory and I/O. The Xilinx platform comes in three levels. The QEMU system model is aimed at early open source development for porting the operating system, device drivers and application development that interacts with the processing system peripherals. The two other levels are called extensible virtual platforms and are able to boot Linux in under ten seconds as well as boot and run other RTOSs. It also has a fast simulator for floating point and support of the advanced SIMD extension known as NEON.

The third Xilinx level, known as the Virtual Platform for System Creators, includes all the elements of the first two levels plus advanced verification, analysis and profiling and is integrated with the Cadence System Development Suite. SystemVerilog and VHDL are supported with additional licenses. The Platform for System Creators is also extensible with device and platform models as transaction level models written in TLM/SystemC and C. This allows it to support custom devices that will ultimately be instantiated with the ZYNQ-7000 ASP’s programmable logic.

From this it seems clear that both the Altera and the Xilinx virtual platforms are primarily aimed at giving the software developer, who will be writing application code for the ARM core, a head start in advance of the availability of silicon. And of course there is a wide variety of quality ARM development tools and IDEs for programmers to choose from. To do this he or she must be able to interact with not only the processor and its peripheral environment but also at some level with the functionality to be implemented in the programmable logic of the device. 

Where Xilinx supplies TLM modeling ability, Altera offers a PC interface, specifically a PCIe express link, to an Altera FPGA development board. They call this the FPGA-in-the-loop extension to the virtual target. This allows the developer and the processor application code to interact directly with the IP programmed into the FPGA—albeit via the PCIe link, which will not be the interface in the actual device, but rather a 100 Gbit/s (Cyclone V) or a 125 Gbit/s (Arria V) ARM AMBA AXI interface. One consideration, however, is that in order to use the FPGA-in-the-loop option, the IP for the logic must already be developed.

The Xilinx platform will also be able to interface to PCIe device models, but not the actual FPGA fabric, via a PCIe interface. The TLM model defines the interface, not the functionality of the logic. That at least gives the programming side and the logic development team a common interface to use, with the registers, etc., defined. Functionality can at least be stubbed by creating a lookup table with several known results for several known inputs and the software team can proceed as can the logic team.

What they—intentionally—do not include in the platforms is the development of the programmable logic on the respective devices themselves. They do have individual solutions for allowing the programmer to interact with the functionality implemented or to be implemented in those FPGA fabrics. It appears, however, that the actual development of the FPGA will not take place through the user interface of the respective virtual platforms, but via the IDE of each company’s development tool suites.

Now, these FPGA development suites are certainly very powerful and sophisticated tools, and those skilled in their use can develop a vast variety of IP functionality for the programmable logic. In the case of Altera, this included the Quartus II software and the Qsys system integration tool. For Xilinx, it is the ISE Design Suite, Embedded Edition. Both companies also support their own soft processors, which can be implemented in the FPGA fabric: for Altera, the Nios, and for Xilinx, the MicroBlaze.

So why did we say earlier that this is not the optimal solution? From our perspective, an optimal solution would be one that brought both disciplines—application software development and FPGA hardware design—into a single development environment, one that has a high-level user interface for developing both code and logic at least at the architectural level. As it stands, the two technologies are combined on the same die but not the two development disciplines. There is not a single metaphor in which the system architect can at least express the high-level design of a system.

Such a high-level tool would have a number of advantages. For one thing, it would facilitate communication between the software and the programmable logic specialists. They would have a single system definition to refer to. For another thing, it would lend itself to the development of tools for evaluating trade-offs. For example, is it better to implement a given function in software or programmable logic? What are the performance and latency considerations; what kind of space does it take up on the logic array? What amount of flexibility does one gain or sacrifice for a given decision?

We can always create wish lists, but the advent of the ASP is creating a huge opportunity for developers to take advantage of what would earlier have required a custom ASIC or SoC—with the attendant risks and mandatory high volumes. As time goes on we can expect more developments, not only in devices but also in development environments, which will take these innovative advances even further.  



San Jose, CA.

(408) 544-7000.





San Jose, CA.

(408) 559-7778.




Cadence Design Systems

Bracknell, Berkshire, UK.

+44 1344 360333.





Mountain View, CA.

(650) 584-5000.