PentekApr0505_RogerHHosking
(music)
DAVID:
Hello, I would like to welcome everyone from around the world. Thank you for joining us today for this webcast on COTS Software and System Techniques to achieve Extreme Real-Time Performance, brought to you by Pentek and TechOnLine Webcast. Your presenter today is Rodger Hosking, Vice President at Pentek. This webcast software allows you to sit back and have the navigation advance automatically. As a user participating in this webcast, you will be able to enter questions at any time during this presentation by clicking on the Ask A Question button and then typing your question in the pop-up window that appears and clicking submit. Rodger will be taking questions at the end of this presentation so please feel free to enter them at any time. Also included in this webcast is a survey. Please take the time to open, fill out and submit this presentation survey. You can access the survey at any time in the print documents and view links pull down menu on the left hand side of your interface. The survey will also pop open when you choose to close your viewer window or when the viewer window closes automatically at the end of this webcast. By submitting this survey you will be providing Pentek and TechOnLine with valuable feedback on the subjects covered in this webcast and also on how we can improve this webcast product and now it gives me great pleasure to introduce you to Rodger Hosking.
Rodger Hosking:
Thank you very much David. Hello and welcome to our seminar today. If you've attended our seminars in the past, you know that we often focus on--
David:
OK, Rodger, if I can ask you to hold on one second, for some reason I have some minor headset problems. Try now.
Rodger Hosking:
Hello.
David:
Still doing it. Hold on one sec.
(pause in tape)
Rodger Hosking:
Slide 1:
Thanks David. Hello, and welcome to our seminar today. If you've attended our seminars in the past you know that we often focus on the hardware aspects of putting together high performance real-time systems using off the shelf catalogue products. However, since systems are getting more complicated each day, choosing the right software architecture and development tools is more important than ever. It not only determines how effectively and efficiently the hardware is used, it also can have a big impact on development time and costs. For more than eighteen years Pentek has been successfully helping customers implement real-time systems for a wide range of applications. In the process we've learned a lot about what works and what doesn't. Today we will share some of those insights and winning strategies and present some specific software products and systems examples.
Slide 2:
We will start with the review of real-time requirements and general principles for intelligent allocation of the hardware and software resources. We will compare the two worlds of real-time and non-real-time environments and show ways you can avoid conflict between the two. Next we will look at an example software architecture called SystemFlow that targets both work station and real-time environments with a carefully chosen collection of complimentary software products. We will look at a few examples of how this SystemFlow software architecture meets the needs of a real-time data acquisition application. Then we will see how the modularity of this architecture lets you easily substitute custom functions without sacrificing performance. Since FPGAs are becoming an essential part of most real-time systems today, we will take a quick look at the gate flow FPGA design resources. Last we will look at some actual real-time hardware development platforms fully supported by the SystemFlow and Gateflow tools and then close with a summary of some helpful website links.
Slide 3:
I'll start with my definition of real-time. It's a guaranteed level of performance for data acquisition, data processing, data movement and system control to meet the specific needs of a given application. In short, real-time simply means fast enough to get the job done no matter what. Here is my laundry list for real-time systems. Real-time systems need specialized hardware interfaces to peripherals like A/Ds for example with fast direct connections to processors. Transfers need to be managed by DMA or Direct Memory Access controllers so processors can have more time. You need a tight, real-time operating system and good effective development tools. An efficient network hook to a host work station or controller helps you during software development and simplifies booting and run time control.
Slide 4:
Now, let's look at some strategies for our system architecture. First, we'll keep the real-time hard and software separate from the work station. Use modular software components and a consistent application programming interface between modules. A TCP/IP Ethernet link between the work station and the real-time system is a great way to isolate them and yet still provide an excellent method for connecting development tools, for loading and debugging programs and for performing software upgrades and maintenance. During run time it also lets you pass commands, data and control. The protocol for all of this traffic should be flexible and portable across the operating systems and different hardware environments. Now, let's split the hardware and software for the work station from the hardware and software of the real-time system.
Slide 5:
What we wind up with is two different worlds each with their own set of roles and responsibilities to meet the needs of the deployed system. The non-real-time world on the left showing the work station is where the operator sits, usually with a virtual instrument GUI for monitoring and controlling the system. He also has access to display and analysis tools, to printers, network drives, e-mail and other desk top resources. Of course, large multi-tasking operating systems are the rule here. The real-time world should be lean and mean. Data transfer paths must be fast and direct. The operating system should be small, tight and scaleable for supporting only the essential functions. DSPs and FPGAs may be required for extreme number crunching. Most important, the real-time environment must be highly deterministic for the guaranteed performance we need every time.
Slide 6:
This chart further illustrates the profound differences between these two worlds. With such a contrast, especially in the operating system environments, you can imagine why the tools that run on each side must be inherently different and yet, be compatible and communicate with each other. Before we see an implementation of such a suite of software tools for both worlds, let's pick an example application.
Slide 7:
Here we have a typical real-time data acquisition system with two 105 MHz A/D converters and optional digital down converters all feeding in FPGA. The FPGA can implement a signal processing task or simply pass data through to the PCI Bus and bridge. Data can then stream through the fibre channel adaptor into the hard disk. A local power PC processor acts as a real-time executive and also supports TCP/IP communications through Ethernet to the non-real-time work station host PC. The work station must be able to control all operations of the real-time hardware using commands passed across this Ethernet link. It also must be able to transfer data recorded on the hard disk over to the work station file system also using the Ethernet link.
Slide 8:
Now let's take a look at the software architecture called SystemFlow that handles all of these requirements and meets all of the recommendations we've just outlined.
Slide 9:
SystemFlow is a complete software tool suite for the work station and the real-time hardware. It's fully compatible with FPGA development tools to add custom intellectual property algorithms. SystemFlow is modular and scaleable and offers high level application programming interfaces for both work station and real-time environments. Use of sockets makes it extremely portable across operating systems, networks and platforms. Source code is provided to simplify custom requirements and specialized optimization. And one of the most important benefits, SystemFlow is extremely economical since it provides both a low-cost development requirement and a minimum of run-time restrictions or costs.
Slide 10:
Here are the basic building blocks of the SystemFlow tool suite. In this example for the work station environment on the left we've chosen a Pentium PC desk top system running windows. For the real-time environment on the right we've chosen the popular power PC single board computer running eCos Operating 'System which we'll learn a little more about in just a minute. Notice that the Ethernet connection which joins the two sides is the only point of contact between the real-time, the non-real-time system.
Slide 11:
Now, let's take a look in detail at the software components on the work station side. First, we'll start with the Visual C record/play client libraries.
Slide 12:
Visual C plus, plus was chosen for developing a library of high-level C callable routines to configure and control the real-time operations involved in the recording application. Since Windows includes native support for sockets, a TCP/IP stack and Ethernet ports, the Visual C DLLs can directly call these resources for passing commands and data to the real-time eCos system. We also define a complete set of data structures, commands and parameters that can be used consistently within the host environment as well as the real-time environment. The client API functions include hardware initialization, status monitoring, record and play back modes, up-loading and down-loading files between the real-time hard disk and the windows file system. We also added some additional functions for viewing data streams on the host. Full source code is provided for all of these functions right down to the lowest level. Now let's take a look at some of the data structures we just mentioned.
Slide 13:
The top data structure contains all parameters required for configuring and initializing the real-time system. This includes the real-time socket server, name and port, the number of data channels, the quantity and size of disk drives, drive parameters. There's also a return parameter for checking status. The second example at the bottom is a structure for passing recording parameters including the record start position, the recording length and status. Now, let's see how these structures are used in the API function calls.
Slide 14:
In this record function example, the first argument, that's FNCT, is a command identifier for record. The second argument is the record data structure parameters including the start position and the recording length. The last argument is the update data structure for sending and retrieving disposition and data rates. All in all, there are eight data structures and nine API functions covering all standard modes of operation. Again, since source code is provided, it's these API functions that are easy to be modified or extended so you can handle new modes and features.
Slide 15:
Now let's take a look at the very useful resource the LabVIEW Signal Viewer.
Slide 16:
This graphing server is a stand-alone application written under LabVIEW from National Instruments. It's controlled from the Visual Basic GUI through an API that supports time or frequency domain plots. The Visual Basic GUI sets up the data to be displayed in two steps. It first makes a Visual C client API call to the open socket server in the real-time system and then forms a specialized -- it determines a -- specifies rather a data source from the real-time system to be sent back to the host for viewing. This can be from the hard disk or from the A/D converter for example. Secondly, it makes a LabVIEW server call to open up a socket client on the LabVIEW application to receive data for plotting. When this socket link is established, data flows from the real-time source across the Ethernet link over to the host and in to the viewer application.
Slide 17:
The Visual Basic graphical user interface which you see on top sits on top of both the LabVIEW signal viewer and the Visual C record/play client API and it gives the operator full control of the entire system.
Slide 18:
Visual Basic was chosen for this application because of it's low cost, popularity and extremely intuitive implementation of control panels, pull down menus, data entry windows, check boxes, indicators and radio buttons. By using these resources to select all of the desired features, parameters and modes, the data structure parameters are populated accordingly. When you click on an execute button like the record button, for example, the Visual Basic GUI sends the properly formed API calls to the Visual C record/play client API to start the operation. The Visual Basic GUI also directly controls the format and the data source for the LabVIEW signal viewer as we had said earlier.
Slide 19:
Real-time system configuration screens make it easy to enter system parameters, hardware board parameters, data *** parameters for A/Ds and D/As including clocking, gating, triggering and all synchronization modes. A separate window also allows easy data entry for every programmable, digital down converter parameter.
Slide 20:
Once these parameters have been entered and the modes have been selected, you can store the whole set up under a profile name effectively creating a unique instrument for each profile. Profiles can be stored, loaded and archived with the real-time data records that were captured for each of those instruments so you can insure repeatability and document the instrumentation. You can even assign profiles to hot keys where one mouse click can completely reconfigure the system to a new instrument.
Slide 21:
There are four basic operational modes supported by the Visual Basic GUI. The preview mode invokes the LabVIEW viewer so you can look at live, A/D data before recording so you can check your connections and adjustments. The record mode starts the fibre channel disk recording using all the parameters and set up information. The play back mode lets you play back the real-time hard disk recording for review and confirmation. The save to disk mode transfer the real-time recording from the fibre channel disk to the windows file system for archiving, analysis or for additional processing.
Slide 22:
That covers the workstation components you see on the left. Now let's look at the real-time components on the right. We'll start with a brief introduction to the eCos real-time operating system which we covered in more detail in the September 2003 Webcast.
Slide 23:
To start, eCos stands for embedded configurable operating systems. eCos is a free, open source, highly scalable operating system with excellent real-time performance, a small footprint and plenty of features. There are no run-time licenses or royalties. The development tools are also free, open source and user configurable. Support is provided by an active community of developers and by commercial consultants and developers. Pentek has been using eCos for more than six years for embedded control functions on DSP boards and because it offers so many benefits, we began distributing it as part of our ReadyFlow board support libraries that shift with every Pentek product.
Slide 24:
For complex real-time applications the eCos kernel has an extensive set of advanced features. These include numerous strategies for threat scheduling and synchronization, interrupt and exception handling, counters, clocks, alarms and timers. ECos also offers compatibility layers for POSIX. It supports RAM and ROM file systems, PCI Bus transactions and, most important for us, TCP/IP networking. Other open sources -- open resources include web browsers, Bluetooth and other type of network devices. In addition to the popular open source tool set, there are two other eCos development tool offerings.
Slide 25:
One is the important tool called Insight. This is a graphical front end for the GNU GDB debugger. It provides a source code window, an editor, a memory viewer, a stacked monitor, a breakpoint control panel and a message window. The eCos configuration tool on the right is another important resource. It offers a graphical interface that allows you to configure all of the eCos components just the way you want to. Standard templates are available for specific hardware platforms to help you get started for popular supported boards. Like all of the eCos tools, both of these are open source so you can configure the screen and customize the window functions to suit your particular needs.