中英文文献翻译-一种基于FPGA的通用数据采集控制器

中北大学 2013 届毕业设计说明书第 1 页 共 19 页An FPGA- Based General-Purpose DataAcquisition ControllerC. C. W. Robson, A. Bousselham, Member, IEEE, and C. Bohm, Member, IEEEAbstractSystem development in advanced FPGAs allows considerable flexibility, both during development and in production use. A mixed firmware/software solution allows the developer to choose what shall be done in firmware or software, and to make that decision late in the process. However, this flexibility comes at the cost of increased complexity. We have designed a modular development framework to help to overcome these issues of increased complexity. This framework comprises a generic controller that can be adapted for different systems by simply changing the software or firmware parts. The controller can use both soft and hard processors, with or without an RTOS, based on the demands of the system to be developed. The resulting system uses the Internet for both control and data acquisition. In our studies we developed the embedded system in a Xilinx Virtex-II Pro FPGA, where we used both PowerPC and MicroBlaze cores, http, Java, and LabView for control and communication, together with the MicroC/OS-II and OSE operating systems.Index Terms：Embedded system, FPGA, networking, object oriented，RTOS, UML.I. INTRODUCTIONNetwork-based controllers have become increasingly popular for control l and data acquisition system as available bandwidth has increased over time. FPGA-based systems are especially interesting because they allow parts of the system to be easily migrated between hardware and software implementations for optimal performance and resource use. These advanced capabilities, however, come at a cost. To develop a network-based controller, especially together with a Real-Time Operating System, RTOS, requires the developer to possess skills in a number of software areas.We have developed a framework for a network-based, controller suitable for FPGA-based systems that can be used on a number of different platforms without any 中北大学 2013 届毕业设计说明书第 2 页 共 19 页major changes. In most cases, only a simple change of header files is necessary. In this paper, we present a suitable development process for embedded software controllers, and how our framework supports this process. We will show a suitable object-oriented architecture for such a controller.II. CHALLENGES IN EMBEDDED DEVELOPMENTIn embedded development one is often developing the hardware- and the software components of the system at the same time. When problems inevitably arise, this dual development environment often makes it difficult to determine whether they are due to hardware or software errors.Network programming is also a major challenge. While a number of small TCP/IP stacks are freely available, they are not trivial to use, and do not always implement the full Berkeley Socket Application Programming Interface (API). To bypass the higher layers for increased execution efficiency and a smaller memory footprint requires a deeper understanding of the subject. Poor documentation is unfortunately very common.Embedded development with an RTOS adds another layer of complexity, requiring the developer to make decisions about such issues as how many tasks should be run and whether all resources should have their own task, stack sizes, priority levels, and scheduling.Real-time systems also require the developer to have expertise in concurrent programming, dealing in topics such as deadlocks, sharing of data, race conditions, and priority inversion.III. A FRAMEWORK FOR PROTOTYPINGThese challenges can become an overwhelming obstacle, especially if the goal is to quickly build a prototype for testing and development. Our solution was to study where potential problems might arise while developing a controller prototype and develop a framework that effectively removes the need for programming skills in these areas. The 中北大学 2013 届毕业设计说明书第 3 页 共 19 页result is a collection of objects implemented as APIs and modules that encapsulate the most difficult tasks and remove many of the potential pitfalls.We have used an object-oriented approach , resulting in an architecture that is easy to adapt, understand, and maintain. By dividing the system into objects we also make it easier in the future to implement some of the parts in hardware without having to change the architectural view.IV. HARDWARE PLATFORMSOur FPGA-based development work so far has been based on hardware platforms using two different embedded CPUs.The Xilinx MicroBlaze is an established soft-core IP. It is based on a 32-bit RISC architecture and is a natural choice in smaller projects where CPU power is not essential. It is also the only choice for Xilinx FPGAs without an embedded hardcore CPU. The MicroBlaze can be run at speeds up to 200 MHz and can be extended with additional coprocessors, instruction sets,and so forth.Fig. 1 shows the architecture we used for MicroBlaze with our controller.The IBM PowerPC 405 is a full 32-bit RISC CPU that is embedded in the Xilinx FPGA Virtex-II Pro and Virtex-4 FPGA families. It can be run at speeds up to 450 MHz and is the best choice for CPU-intensive tasks in Xilinx FPGA-based systems.Fig. 2 shows the architecture we used for PowerPC with our controller.When developing embedded software, we are always facing the host-target problem, meaning, we are developing the system on one machine, the host, and running it on another, the target. In order to solve this problem, we decided to also support the times 86 architecture from Intel. By doing so, it is possible to develop a large part of the system on an ordinary PC running Windows or any variant of Unix. By simulating IP cores(firmware modules) as software objects, a system can be developed to an advanced state before it needs to be tested on the actual target. Another benefit of this approach is that it allows concurrent development of multiple projects on a single target.中北大学 2013 届毕业设计说明书第 4 页 共 19 页V. SOFTWARE ARCHITECTUREThe controller architecture design is based on four modules: the Server, Model, Protocol, and Resource modules, which is shown in Fig. 3. They are designed as classes and interfaces, and we have deliberately designed the Server, Model, and Resource modules to have loose dependencies between them.The Server class is responsible for communication with the client. It can be implemented with different TCP/IP stacks, as long as they implement the Socket interface. We have implemented it as a common API for Winsock1, Unix, Xilnet2, and LWIP3, and to choose between them is a simple matter of selecting the desired header file. The Server behavior is the same for different stacks, except for the XilNet case.XilNet is simple and small, but not easy to work with. It lacks a connect function, so if a client module is required, a connect function must be written. XilNets accept function is different from that of Berkeley sockets in that it isnt blocking, probably because it is designed for simple controllers without interrupts or RTOS.The server can operate in three modes: Ithe client connects, the server receives a command, sends data to the client and then closes the connection. IIthe client connects, and then the server repeats the sequence of receiving a command, sending data until the client disconnects the connection, it then closes the connection.IIIthe client connects and the server receives a command. It then repeats sending data to the client until the client disconnects the connection. It then closes the connection. The client can choose the mode at run time.The Model class is the core logic, the “business logic” of the controller. The model interprets incoming commands from the server with the help of methods defined in the Protocol interface. It determines what resource in the embedded system the client is addressing, and executes the command from the client together with its parameters.The Protocol interface defines a number of methods that all protocol classes in this architecture must implement. In this way it is possible to develop and use many different 中北大学 2013 届毕业设计说明书第 5 页 共 19 页protocols at the application layer without needing to change anything in the rest of the controller. Currently, we are using http with a web browser as a thin client, and we have developed an application layer protocol suitable for LabVIEW4 and Java, allowing us to use LabVIEW and Java applications as a client.The Resource class represents objects, functions and IP cores in the system. A resource can, e.g., implement a client, connected to another server, allowing the controller to distribute commands from the original client and exchange information with other network-based controllers, thus making the system highly scalable. A resource can even be another server or a full controller; for example, one could implement one server for distributing control signals and another for exchanging data in the same embedded system.Fig. 4 shows a dynamic view of how the controller handles a simple request, running as standalone.The object-oriented approach simplifies migration from a standalone to an RTOS-based system. The objects represent conceptual parts of the controller with loose dependencies between them. The loose dependencies make it possible to divide the system into separate tasks without any major changes. Fig. 5 presents an example of how this is done. This design has been successfully tested with MicroC/OS-II as an RTOS, but any RTOS could be used. To promote simplicity in development, intertask communication has thus far been implemented by shared variables. We solved many of the inherent problems in this approach by turning off interrupts when addressing these shared variables. This has a large negative impact on system performance, but the benefit of it is a much faster prototyping cycle.VI. IMPLEMENTATION AND RESULTSWe have implemented MicroBlaze and PowerPC-based systems in a Xilinx Virtex-II Pro (XC2VP7) on a development board from Memec, FF672 Rev 2. The 中北大学 2013 届毕业设计说明书第 6 页 共 19 页firmware part of the system was developed and implemented with the Embedded Development Kit, EDK, version 6.3 and 7.1 from Xilinx.The software controller was designed with Objecteering/UML v5.3.05. When implemented in an FPGA, it was possible to limit the size of the controller to below the 64 kB of BRAM.The controller has successfully been tested on several different processors (MicroBlaze, PowerPC, x86, SPARC, and ETRAX) and operating-systems (Windows, Solaris, Linux, MicroC/OS-II, Xilinx Xilkernel, and OSE6).This framework has been successfully used to implement network based controllers on embedded systems based on MicroBlaze and an ETRAX 100LX7 from Axis Communications.We have studied the data throughput in different situations. With a MicroBlaze running at 100 MHz and executing three parallel threads in Xilkernel we have achieved 1.6 MBit/s, when requesting data of small sizes, well within the Maximum Transmission Unit (MTU) of 1500 Bytes for Ethernet. With larger data sizes, this figure will increase due to smaller communication overhead.VII. CONCLUSIONWe have developed a framework suitable for rapid development of an embedded controller. This framework circumvents many of the difficult issues associated with network-based controllers, making it usable even by less-experienced developers. The most valuable part of this approach, however, is probably that such a framework encourages a coherent, standardized design method. This allows effective re-use of design elements in new projects, and reduced development time.These advantages, however, come at the cost of decreased performance when it comes to execution speed and code size for the prototype controller. Further optimization will require a more in-depth understanding of system and software issues.We are currently using this framework in our own projects and we plan to develop 中北大学 2013 届毕业设计说明书第 7 页 共 19 页it further. The distributed potential is of particular interest to us, as it is the key to developing large, scalable, independent data acquisition systems.ACKNOWLEDGMENTThe authors would like to thank S. Silverstein for initial help with LabVIEW.Fig. 1. The MicroBlaze based hardware architecture we used for our controller. The MicroBlaze is connected to the Block RAM (BRAM) through the Local Memory Bus (LMB). The rest of the peripherals are connected to the CPU by the On-chip Peripheral Bus (OPB). EMC and MDM are acronyms for External Memory Controller and Microprocessor Debug Module.Fig. 2. The PowerPC-based hardware architecture we used for our controller. The PowerPC can make use of the Processor Local Bus (PLB), which is faster than the OPB. Both are part of the IBM CoreConnect bus architecture.中北大学 2013 届毕业设计说明书第 8 页 共 19 页Fig. 3. The controllera standalone static view of the controller as a UML class diagram. Here we can see how the basic parts relate to each other.中北大学 2013 届毕业设计说明书第 9 页 共 19 页Fig. 4. The controllera standalone dynamic view. In this UML sequence diagram we can see how messages are exchanged in the controller as a result of a request by a client.中北大学 2013 届毕业设计说明书第 10 页 共 19 页Fig. 5. The controlleran operating system static view of the controller as a UML class diagram. In this design we are running the server, model, and the resources as individual tasks. Another approach could be to run the server and the model in the same task.1Winsock is a part of Microsoft Windows.2LibXil Net - A networking library which is a part of the Embedded Development Kit, EDK, from Xilinx.3LWIP is a light-weight implementation of the TCP/IP protocol suite that was originally written by A. Dunkels of the Swedish Institute of Computer Science中北大学 2013 届毕业设计说明书第 11 页 共 19 页一种基于FPGA的通用数据采集控制器C. C. W. Robson, A. Bousselham, Member, IEEE, and C. Bohm, Member, IEEE摘要无论是在开发还是生产使用中，先进的FPGA系统开发都要求相当的灵活性。混合固件/软件解决方案允许开发人员选择应当用到的固件或软件，并且允许研发人员在进程的中后期作出决定。然而这种灵活性增加了复杂性。我们设计了一个模块化的发展框架，以帮助克服产生复杂化的问题。这个框架包含一个通用控制器，它可以通过简单地改变软件或固件部分来适应不同的系统。根据要开发的系统的要求，该控制器可使用软、硬处理器，可带或不带一个RTOS。由此产生的系统来实现控制和数据采集。在我们的研究中，我们在一个Xilinx Virtex- Pro FPGA上开发了一个嵌入式系统，其中我们使用了PowerPC和MicroBlaze内核，HTTP,JAVA还有LabView，与MicroC/OS-和OSE操作系统一起实现控制和通讯的功能。关键词：嵌入式系统、FPGA、网络、面对对象、RTOS、UML.引言随着可用宽带的与日俱增，基于网络的控制器在控制和数据采集系统中越来越受欢迎。基于FPGA的系统是非常有趣的，因为他们允许部分系统很容易地在硬件和软件之间迁移以获得最佳性能和资源利用。然而，这些先进的功能需要花费很多。开发一个基于网络的控制器，特别是与一个实时操作系统（RTOS）并列在一起，要求开发商软件领域拥有一定的技能。我们已经为基于网络的控制器制定一个框架，它适合基于FPGA的系统，能使该系统在许多不同平台下工作而不发生任何重大变化。在大多数情况下，只有头文件的一个简单变化是必要的。在本文中，我们提出了一个合适嵌入式软件控制器的开发过程。我们将为这样一个控制器展示一个合适的面向对象框架。.嵌入式开发中的挑战在嵌入式开发中，常常是在同一时间开发该系统的硬件组和软件组。当问题不可避免地出现时，这种双重发展环境往往很难确定它们是由于硬件错误还是软中北大学 2013 届毕业设计说明书第 12 页 共 19 页件错误。网络编程也是一个重大挑战。而一些小型TCP/IP协议是可以随意使用的，它们不经常使用，并始终贯彻不完整的Berkeley套接字应用程序编程接口（API）。绕过提高执行效率和较小的内存足迹的更高层次，需要更深入了解这门科学。不幸的是文件缺乏是很普遍的。嵌入式RTOS的发展，又曾加了一层复杂性，要求开发商对应执行多少任务，所有资源是有应该有自己的任务、堆栈大小、优先级和调度等问题做出决定。实时系统还要求开发商在并发编程方面拥有专业知识，能够解决像死锁、数据共享、竞争条件、优先级翻转这类问题。III.一个原型设计的框架这些挑战可以成为压倒一切的障碍，特别是如果我们的目标是快速建立一个用于测试和开发的原型。我们的解决方案就是研究在开发一个控制器时潜在问题可能出现的地方，并制定一个框架，有效地消除这些领域编程技能的需要。其结果是一个像封装最困难任务，并能够消除许多潜在的隐患的API和模块一样的实施对象的集合。我们已经使用了面向对象的方法，构造出一个易于适应、理解和维护的框架。通过把系统划分为对象，我们也使执行一些硬件部分功能更容易，而无需改变框架视图。IV.硬件平台迄今，我们基于FPGA的开发工作已在使用两种不同的嵌入式CPU的硬件平台的基础上开展。赛灵思MicroBlaze是一个既定的软核IP。它是基于32为RISC构架，并在较小的项目中是一个自然选择，这里CPU电源是没有必要的。它也是在没有嵌入式硬核的情况下Xilinx FPGA的唯一选择。MicroBlaze的运行速度可高达200MHz，配合协处理器、指令集等还可加快其速度。图1显示了用我们的控制器的MicroBlaze的体系结构。中北大学 2013 届毕业设计说明书第 13 页 共 19 页IBM的PowerPC 405是一个完整的32位嵌入在赛灵思FPGA的Virtex-II Pro和Virtex-4 FPGA系列中的RISC CPU。它的运行速度可高达450MHz，是在基于Xilinx FPGA系统中执行CPU密集型任务的最佳选择。图2显示了我们的控制器用于PowerPC的架构。发展嵌入式软件时，我们总是面临着主机-目标问题，也就是说，我们正在一个机器上开发系统，就是主机，同时使它在另一个机器上运行，也就是目标。为了解决这个问题，我们决定也使用Intel的times 86 框架。这样做，是使在一个普通的PC运行Windows或任何不同Unix中制定一个系统的大部分成为可能。通过模拟IP内核（固件模块）作为软件对象，系统需要在实际的目标上进行测试之后，就可以发展到更高的阶段。这种方法的另一个好处是，它允许在单一的目标上的并行开发多个项目。V.软件构架控制器架构的设计是基于四个模块：服务器，型号，协议和资源模块，如图3所示。它们被设计为类和接口，同时我们特意设计了服务器、模型和资源模块，它们之间依赖不多。服务器类是负责与客户的沟通。它可以实现不同的TCP/ IP协议栈，只要它们实现Socket接口。我们已经将它作为一个通用的API Winsock1，UNIX，Xilnet 2和LWIP3，然后在它们之间选择，这就是一个简单的选择所需的头文件的事情。对于不同的堆栈来说，服务器行为是相同的，除了Xilnet 情况。Xilnet 简单、体积小，但是不容易使用。它缺乏一个连接的功能，所以如果需要客户端模块，必须写入连接功能。XilNet的accept函数与Berkeley sockets的不同，它不会阻止。可能是因为它没有中断或RTOS简单的控制器设计。服务器可以工作在三种模式：.客户端连接，服务器接收到一个命令，将数据发送到客户端，然后关闭连接。. 客户端连接，然后服务器重复序列接收命令，发送数据，直到客户端断开连接，然后关闭连接。三，客户端连接和服务器接收到一个命令。然后重复发送数据到客户端，直到客户端断开连接。然后关闭连接。客户可以在运行时选择模式。中北大学 2013 届毕业设计说明书第 14 页 共 19 页模型类是核心逻辑，是控制器的“业务逻辑”。该模型在协议接口定义的方法的帮助下翻译了从服务器传入的命令。它决定客户在嵌入式系统中指定的资源，并从客户端执行命令及其参数。议定书接口定义了一套方法，在这个架构中的所有协议必须实现这些方法。在这种方式下，开发和使用许多在不同层次的协议成为可能，而无需改变控制器中其余的任何东西。目前，我们正在使用HTTP与Web浏览器作为一个瘦客户端，我们已经开为LabVIEW4和Java开发出合适的应用层协议，允许我们使用LabVIEW和Java应用程序作为客户端。资源类代表系统中的对象，功能和IP内核。例如，资源可以实现一个客户端，连接到另一台服务器，允许控制器从原来的客户端分发指令，并且允许与其他基于网络的控制器交换信息，从而使系统具有较高的可扩展性。一种资源甚至可以是另一台服务器或一个完整的控制器，例如，一种由在同一嵌入式系统中一台用于分配控制