《RTC 杂志》文章:“设计ASP 类器件:将采用哪些技术?”

RTC 杂志》三月刊登载了一篇由 Xilinx 的 Greg Brown 撰写的文章:“设计 ASP 类器件:将采用哪些技术?”ASP,也称应用服务平台(An Application Services Platform, or ASP)是一种新的IC,它融合了CPU、标准可配置外设一个一个可编程的架构,这些都在单芯片上实现,这类新器件给设计团队提供了最大的灵活性,让用户可以开发针对他们目标的独特功能,不过,在单芯片上融合软硬件的架构也带来了编程的问题,本文对分析了ASP类器件开发的基本需求以及如何编程和配置这类器件,以下为英文全文。a name coined by RTC Editor-in-Chief Tom Williams, is a new class of IC that combines a CPU, a standard set of configurable peripherals and a programmable fabric—all on a single device. Because they combine logic programming with software programming, these new devices offer design teams the maximum flexibility, enabling users to rapidly develop unique functionality for whatever application they are targeting. At the same time, the combination of hardware and software on one device raises many questions about the nuts and bolts of programming. Let’s take a look at what skill sets are required to program ASP-type devices and how design teams can program and configure these devices.To set the stage, Figure 1 displays the block diagram for the Zynq-7000 Extensible Processing Platform (EPP), an ASP device built around dual ARM Cortex-A9 CPU cores and development architecture, with functionality that can expand by means of the device’s programmable logic resources.[[wysiwyg_imageupload:458:]]Figure 1The Xilinx Zynq-7000 Extensible Processing Platform is an example of an ASP device.In order to better organize and describe the skills and design tasks required, let’s assume our ASP design team consists of the following members: system architects, software application developers, firmware developers, RTL developers and PCB designers. Each of these individuals brings a unique contribution to an ASP design project. Of course, the exact makeup and skill set of your design roster will vary depending on the size of your team and company. In many cases your design team members may wear many hats, or it may be you who wears all of them.System ArchitectsSystem architects are primarily in charge of defining how the ASP will be used in the system and what functionality it will need to have. The ASP architecture requirements will vary greatly depending on the design but can include things such as secure or non-secure boot; configuration and storage architecture; field upgradability; OS and middleware selection; hardware/software partitioning and so on. System architects should become well versed in the capabilities and limitations of the targeted ASP device. Architects who have experience with processor-based ASICs or ASSPs are a real asset to an ASP project. In fact, they will find designing ASPs easier in comparison to ASIC designs, because with an ASP you don’t have to worry about the risks and costs associated with doing a full deep-submicron IC design and fabrication.System architects are also in charge of defining what system functions will go into software and which of them will go into the programmable logic. For this hardware/software partitioning, architects need to have a firm understanding of the various interfaces between the processing system, their latencies and bandwidths, as well as arbitration on the memory controller, quality-of-service, etc. Traffic patterns to and from the ASP—and how these are distributed within the ASP, both in the processing system and in the programmable logic—will need to be sorted out if you need to push not only the design architecture, but also the ASP architecture to its fullest capability. To make hardware/software partitioning decisions, you can employ a variety of techniques from spreadsheet-based models to advanced ESL tools. System architects may be working with a dedicated algorithm team, and understanding their environment, such as MathWorks MATLAB and Simulink, can be useful. Mapping algorithms to a partitioned implementation can require simulation skills and experience with homegrown or commercially available tools using C++, C, SystemC, etc.It’s very likely that advanced ASP projects will include a fantastic FPGA capability called dynamic partial reconfiguration, in which a portion of the programmable logic is reconfigured by the processing system while the entire device is still running. This technique is very similar to the dynamic loading and unloading of software modules done in the software world. Dynamic partial reconfiguration enables teams to build very versatile systems that can reconfigure hardware to speed up tasks as they arise and time-multiplex the hardware to save on costs by using a smaller device. While this is an advanced technique and may not be needed for many designs, having an architect who understands it from both a device and design-tools perspective is a great advantage. Software Application DevelopersFor the most part, software application developers who are using ASSP devices will well understand how to use the processing system portion of ASP devices. A well-designed ASP looks and feels like an ASSP. When using an OS, a standard board-support package should be available either from a vendor (ASP, OS, etc.) or from the firmware team. The same tools they are using for their ASSP should work with the ASP as long as the CPU ISA and debug interface are consistent.To use the hardware acceleration capabilities of an ASP, the software application developers should be versed in how to analyze performance. They must also work with the folks who implement the accelerators (RTL developers) and do the hardware/software integration (firmware developers) as well as the system architects to determine what can and should be accelerated.Firmware DevelopersFirmware developers will need to work closely with the RTL developers on the custom blocks being created for the ASP to determine device driver requirements. They’ll also need to have a good understanding of the processing system hardware as well as how the entire device is being designed. They will need to know and define not only the processing system boot, but also how and when the ASP’s programmable logic bitstreams will be applied based on the system architecture. They will also need to have knowledge of programmable logic configuration, and if the architecture uses techniques such as dynamic partial reconfiguration or secure boot/configuration, they will need to know how to manage them properly.In addition, firmware developers will need to determine how to use the static memory for processor boot code and any OS. They must also be familiar with the design’s bitstream storage requirements and mechanisms. In an ASP, OS code and programmable logic configuration bitstreams can be stored in locations other than a local static-memory device.Firmware developers must also develop a board-support package consisting of the boot code, drivers, the OS, etc. Any APIs that the ASP vendor supplies for the custom features need to be well understood, and may need to be incorporated into an OS or made available to a software application developer. Finally, firmware developers will also need a comprehensive background in using hardware and software debug tools.RTL DevelopersRTL developers who have been developing for FPGAs will find no substantial differences when targeting the programmable logic portion of an ASP. As previously noted, dynamic partial reconfiguration is an emerging programmable logic technique that many companies may want to consider for their ASP designs. Therefore, it’s very helpful if the RTL developers have a good understanding of this design method as well as how and when to implement it.When defining a new project, RTL developers (and the rest of the team, for that matter) should sort out what types of simulation and debug capabilities are available and the impact of each on the development flow. There are many types of modeling, verification and debug tools and hardware available. Your team doesn’t need all of them, but they can be very helpful. Some of these include, but are not limited to, standard-interface bus functional models (BFMs) and processor system BFMs. One necessity, however, is RTL (HDL) simulation, and it’s a rare RLT developer who does not already use these tools today. Then there are a variety of processor system models as well as techniques for both hardware and software domains in SystemC and software virtual platforms.Other forms of modeling include hardware emulation or hardware/software co-simulation. The latter would run the processor system of the ASP on a development board at full speed and can be accessed by software debug and trace tools. The RTL for the programmable logic runs on an RTL simulator and is synchronized with the processing system hardware. This gives visibility into the RTL and the interfaces to the processor system.One thing that designers must consider is the JTAG topology. An ASP can support split or merged JTAG or both, depending on what the ASP vendor designed. In split JTAG, a dedicated JTAG interface is available to the processing system and one to the programmable logic. In merged JTAG, these two JTAG ports are daisy chained, as there is one physical interface. The distinction can be important for capabilities like co-debug: Can the various tools work over a single JTAG connection? RTL developers and firmware developers are the primary users of hardware/software co-debug, while software application developers also should know how to use it.PCB DesignersPCB designers typically find FPGAs a challenge to place on their boards, simply because of the flexibility of FPGA I/O assignment. For example, FPGA designers may move an I/O to improve overall FPGA design timing. This of course can wreak havoc on a PCB layout, and if done very late in the cycle, force the PCB designer to hustle to accommodate the new I/O scheme. Another common scenario is that the PCB layout is fixed and the FPGA developers must adapt to the fixed pinout for their device.With ASP devices, you have a merging of the flexibility of FPGA I/O pinouts, with the limited pinout flexibility (through muxed I/Os) and fixed pinouts (such as for DDR) of an ASSP. Both ASP and EDA vendors offer up-front pin-planning tools that can help the process and reduce risks of last-minute changes. Figure 2 illustrates a simplified ASP development flow.[[wysiwyg_imageupload:459:]]Figure 2Example ASP Development Flow.Programming and Configuring ASP DevicesNow that we’ve looked at the design team, skill sets and some of the tools required for an ASP project, let’s hone in on how to go about programming and configuring this new class of device. The job can be divided into three phases: development (or lab), production, and deployment (or field).During development, it’s useful to think of the ASP as consisting of three components: the processing system, the programmable logic and the ASP as a whole. Programming of the processing system component can proceed in exactly the same way as for an ASSP. You can program a flash device and boot from that, or use JTAG and run-time control tools to initialize and download code.Design teams can configure the programmable logic portion of the device in the same manner as a traditional FPGA with some minor exceptions. When the RTL developers want to download a bitstream and run it in the programmable logic, they can use the standard download cables over JTAG. They can then work with the ASP device in much the same way they work with a standard FPGA today.If the boot stream they want to use is part of the flash image, they need to boot the processing system and have the boot loader or application configure the programmable logic. They can then access the programmable logic portion via JTAG tools.In production, programming/configuration becomes system architecture dependent. For example, if the boot code, OS and bitstreams are all on local flash devices on the board, then the design team will use the standard mechanisms by which the company programs and manages flash.If the boot and OS are local flash images on a line card, and the programmable logic bitstreams are stored on a main board and in operation applied at startup to the line card or via PCIe, Ethernet, etc., then those facts need to be considered.Another thing to consider is the ability to customize the ASP design at shipment time rather than production time. For example, you can mass-produce the base product, which will have programming and configuration differences on a per-customer basis. The system can be designed such that the boot loader on the flash can bring up the system for production test as well as read an SD card, for example. When an order is filled, the custom software and hardware (bitstream) images are stored on the SD card, which is then plugged into the system providing the end customer customizations to the base product.FPGAs have had a strong value for many industries in the ability to fix, upgrade and apply additional features for the hardware in the field and even remotely. (Who wants to send a technician to fix or upgrade a wireless access point in a remote region of the world?) Any processor-based system is capable of doing the same thing for software. ASPs have the capability of both. How they accomplish it depends on the storage mechanisms used (that is, flash writers, USB, SD, local vs. remote storage, etc.). Design teams have multiple mechanisms available and should take advantage of these when appropriate, reaping substantial economic and customer satisfaction benefits. Figure 3 illustrates two of the many possible options you can consider in such an architecture.[[wysiwyg_imageupload:460:]]Figure 3Example Programming and Configuration Architecture Options.If your design team has been designing processor-based ASICs or FPGAs with soft or hard processors, then you probably already have all the skills you’ll need. If a design team has been developing with two-chip solutions, defined in this context as an ASSP plus connected FPGA, then you’ll need to gain an understanding of chip design at the functional and potentially the architectural levels. If you have only been using off-the-shelf ASSPs with no FPGAs, then you will have to acquire, develop or contract to have programmable logic skills available for your project.But even if you don’t have a huge team and all the associated skill sets, you can use an ASP to build those skills. With an ASP, you can test the waters, so to speak, by starting with a very straightforward implementation—building essentially your own specialized microcontroller-like device by simply dragging and dropping in peripheral IP provided by the ASP vendor. Say, for example, you need eight SPI ports, five UARTs, four I2C buses, etc. Drivers and OS support should all be included with the ASP software, which greatly simplifies the hardware and firmware tasks. As you develop or otherwise acquire expertise, you can build in more complexity and customized functions. ASP devices provide you not only with design customization flexibility, but also with flexibility as to when and how you take advantage of the different capabilities—you can adopt them as you see fit given many different parameters.  XilinxSan Jose, CA.(408) 559-7778.[www.xilinx.com

zynp-7000.jpg172.2 KB