In Part 1, Mark Pierpoint, Vice President and General Manager for Keysight's Internet Infrastructure Solutions team, left off with a description of the sandbox. The purpose of the sandbox is to provide an area of the FPGA to customize without impacting the operation of the digitizer. In Part 2 below, Richard Comerford relates the concept back to the VXT.
BY RICHARD COMERFORD
Contributing Editor
Comerford: If we can match [the sandbox] back to the VXT: the VXT was never designed with that kind of programmability concept in mind. Correct?
Pierpoint : Certainly at this point, the principal application that our VXT is aimed for is active device measurement, and specifically power amplifier test, in a production-line environment. In most cases, the engineers that our customers have in these functions are not familiar with programming FPGAs at this level of detail. What the customers typically are really interested in achieving are the kinds of throughput and reduced cost-of-test that they need. Their job is to be able to ship parts off a production line that's operating at volumes that could be millions a week or a month.
Typically, what they're looking for is the fastest way to develop their test system, get it up and running, and reliably and repeatedly delivering results. What we've ended up doing, the value contribution that we're making, is to build the necessary IP into these products by default without any low-level user programming needed. In a VXT, there are both ASICs to do signal path work and FPGAs, so it isn't just an FPGA area. This is one of the ways that we get the kind of speed that we can achieve. Basically, we deliver those as turnkey functions, fully backed up by Keysight-warranted performance and results at the level you would expect from a Keysight instrument.
What we have been working on in the whole PXI area is actually to add a separate, standalone FPGA accelerator module, our M9451A, without impacting the basic functionality in another module. Essentially what we have is a totally open sandbox that allows you to stream data off the backplane and with our new PXI Gen 3 chassis, which can operate in the 4+ GB/s range. Into that module, put your own custom processing, and then stream the results out at the end. There's a version of this that implements real-time digital pre-distortion (DPD) measurements, for example.
Comerford : What you've created in this case is a way of adding on to that sandbox, if you will, to an existing purpose-built instrument that is not designed to be screwed around or played around with, but still allowing somebody who is familiar with the instrumentation to have the sandbox, to be able to do the kind of programming they need, the processing of data that they need in this place, and have it, if you will, stand alone, so that it does not interfere in any way with the operation of the instrumentation.
Pierpoint : Absolutely. Think of it as an augmenter to existing functionality, or you could think of it like adding a supercharger to your car.
Comerford : That makes perfect sense, and it's a very good approach to that idea of providing the user with the ability to perform the measurement and types of signal processing that they need to do.
Pierpoint : Yes. You could do a wide range of functions in there. The first version of things that we've done, because we don't like to really use our customers as real guinea pigs, is to try this ourselves. The phrase that I use inside the company is it's important for us to “eat our own dog food,” and basically, we've launched a version of the M9451A as a DPD, an envelope tracking co-processor. In principle, there's nothing that would stop that product from being much more general-purpose, and so we do, in fact, tweak it around to do different things that are specific for customers.
We haven't opened it up yet in terms of a true open-development environment, but we're working in several different areas to enable that kind of thing to happen. You may be aware of the fact that, earlier this year, we purchased a company called Signadyne and are in the process of offering a couple of different approaches here to move customers from this more complex, hardware-defined programming of FPGAs to an area where they can get the kinds of performance and results that they're looking for with these accelerator cards. This could be anywhere from 10 to 100 times sped up without having to roll your sleeves up and get down into HDL programming.
One of those areas is a whole offering called PROCESSflow. PROCESSflow essentially allows you to use the FPGA as a co-processor. It has an API in it, so you can then program it and create software from your desktop. It has a really nice, easy-to-use user interface: you drop a flow diagram down of the kinds of measurements you want. And it's really intended to enable you to synchronize measurements, both within a single FPGA and across FPGAs, to get certain measurement performance. This is not processing the results, per se, but it is definitely triggering and syncing measurements across multiple cards.
Comerford : Nice.
Pierpoint : With PROCESSflow, you can draw out a flow diagram of what you want to have happen in your test system and that flow chart is exactly the user interface that you define in software. You then press a button and that essentially drops straight into the FPGA and executes what you wanted down to nanosecond-range synchronization levels.
Comerford : Wow. That's impressive.
Pierpoint : We've had a lot of very positive feedback on this and customers are finding it extremely easy to use. That really addresses where some of the more graphical tools are today, in that they're very good at enabling you to synchronize and coordinate different measurements. It doesn’t address the question of how you efficiently program a brand new algorithm into the FPGA. If you spent several thousand dollars for a high-speed processor, you'd like to be able to get the performance out of it. There's another product that's a sister product to that called FPGAflow, which allows you to link different elements of FPGA code together in a simple way within your sandbox. We're looking to integrate that with PROCESSflow so that essentially you can control the two things together.
Comerford : Very interesting. Do you have a time frame on that?
Pierpoint : You can see some of the software elements already. FPGAflow is available today, but some of the linkages that I think will really add the value to it will start to roll out over the next 12 months. We are still working on exactly what the specific plan is. I know that, for example, some of the software linkages are going to be available in the next two or three months.
Comerford : Absolutely.
Pierpoint : What we're trying to do in the software is to address two problems with FPGAs. One is to easily define what you want to run in it. The second is to actually enable that capability from your software. This would be setting up the interfaces to the outside world and so forth. One of the biggest challenges with FPGA development is coordinating those two things together. Typically, they're done by different people, and as the software in the FPGA changes, the software in the control system has to change. What we're doing is essentially standardizing a library in a series of interfaces that will allow you to write that software independent of the FPGA code, and vice versa. You will be able to call functions into that API which will operate and run. They will deliver results. Because you can run any of these algorithms on a CPU, you can start there. It is just that they will not run as fast. When you have an accelerator card that you could plug in, it would recognize this and use the added hardware for the functions that you defined. You'd get the acceleration without having to re-code anything.
Comerford : Right. You're decoupling the flow from the actual implementation in the FPGA, providing the ability of changing FPGAs as they upgrade and change. You can, therefore, add in different FPGAs and still have the performance improvements using the flow chart that you've already done, the program you've done.
Pierpoint : Yes, that is absolutely the intent. Of course, I would be remiss not to point out that, if this was easy, somebody would have done it already. It doesn't exist in the market today. There are people who claim to be able to do it, but the reality is that it isn't possible when you want to operate at the kinds of speeds that our customers are asking us to deliver results.
Comerford : I think that's the perfect place to stop for now, because I think you've answered all the questions, essentially, that I had. You’ve given us a great idea where you're going with this.
Pierpoint : To wrap it up, the challenge I have laid out for the engineering team, my goal here, is for any engineer to be able to say, “I can do this” and do it without having to be an expert in low-level FPGA programming and without having to give up on performance or time-to-market.
Advertisement
Learn more about Keysight Technologies, Inc.
