FROM
THE EDITOR
This week, Amy Malagamba takes a look at the options for debugging software along with hardware in FPGA-based embedded systems. As design complexity increases and those software guys start hovering around “our” project with all their compilers, debuggers, breakpoints, and “local variables,” we need an organized approach to the verification process that will help us isolate and solve problems in the gray area between the two engineering disciplines.
Next, Xilinx’s Ham Ha Ng, and Dan Isaacs weigh in on the embedded-systems-on-FPGA front with an examination of software acceleration using Xilinx’s APU interface and ESL tools for software/hardware co-design.
If you haven't checked out our new rapidly growing Journal Jobs employment site ( www.journaljobs.com) stop by for a visit. New jobs are being added every day. Registration is free, and it’s a great place to start your search for that next promotion.
We are also breaking all of our records with signups for our upcoming sister publication, Embedded Technology Journal ( www.embeddedtechjournal.com). It’ll be just like FPGA Journal, only for embedded design. Subscriptions are free, so click and register.
Thanks
for reading! If
there's anything we can do to make our publications
more useful to you, please let us know at: comments@fpgajournal.com
Kevin
Morris – Editor
FPGA and Programmable Logic Journal
|
|
Death, Taxes, and Debug
Dealing with Life's Certainties
They say that there are two things we can count on in this life. For chip designers, the list is just a little bit longer.
In the early days of FPGA design, you may have been able to “spin” your way around debug a bit – tempting fate with a devil-may-care attitude - burning and turning your design several times in one day and never slowing down to plan a “verification strategy”, but not any more. These days, your FPGA designs are too complex for that dance. You no longer create the bulk of your design from scratch, zooming through debug almost without looking at the HDL code you knew better than the back of your hand. Instead, you’re moving your system onto your chip, often in the form of large blocks of commercial IP, the contents of which may be a total mystery to you. Your FPGA is now officially a system-on-chip design, or FPSOC.
From a debug perspective, things just got a little trickier. On the hardware side, you’ve been dialed in for a while now, using a virtual logic analyzer to peek into your device and see what’s going on. Life’s been good. You’ve been able to easily and effectively locate and eradicate those pesky bugs. Those skills and tools will continue to be valuable, but now that you’re embedding complete systems in your FPGA design, you need to expand your debug strategy to consider the entire system, including (dare we say it?) software. [more]
Closely Coupled Co-processors for Algorithmic Acceleration
by Harn Hua Ng, Senior Systems Design Engineer, Xilinx, Inc. and
Dan Isaacs, Director of Embedded Processor Marketing, Xilinx, Inc.
Introduction
During the early stages of field programmable gate arrays, FPGAs were used primarily as glue logic for chip-to-chip communication or for other bridging type functionality. Current FPGA device solutions encompass complete embedded processors and processing subsystems. The demands on designers continue in the areas of processing performance, new feature content, and reduced cost. With continued requirements towards performance improvement, the inherent parallelism in FPGAs provides the unique capability to accelerate performance through closely-coupled co-processors to achieve significant acceleration through hardware. This is particularly important when managing compute-intensive applications. Systems that can benefit from this type of algorithmic acceleration include wireless communications and image processing platforms such as those seen in medical, video, and other graphic applications that require a large degree of signal processing. [more]
 |
