Xilinx has supported this feature for quite a few years, but has never made it a mainstream, supported feature of their ISE Design Suite development tools. However, in a recent email update to its customers, Xilinx announced with almost no fanfare that, in version 12 of the Xilinx tools, this important capability would finally be given its proper status as a supported feature. Perhaps the marketing department at Xilinx heard rumors coming from the other side of San Jose?

Corporate intrigue aside, this is an important piece of news. Why? Because software application developers first investigating FPGAs are surprised – even shocked – to learn how long the iteration times are for programming and debugging FPGA applications. And the larger the FPGA is, the worse the problem becomes.

For most software developers, being faced with the equivalent of a two, three, or even eight hour iteration time for compile-link-test is completely unacceptable, no matter how much potential increase in performance there may be.

And if, at the end of that long iteration time all the programmer has is a non-working, difficult-to-debug bitmap and a thousand-lines long report filled with hardware-esque warning messages? Then forget it. They might as well go use GPUs and CUDA.

So, why has it taken so long for this seemingly obvious feature to become mainstream? One can only assume that Xilinx and Altera management, their chip architects, and perhaps even their tools developers are hardware engineers first, and software engineers second. Perhaps they can only think of their devices as the poor-man’s ASIC. And their tools as a poor-man’s EDA.

Reliable, vendor-supported partial reconfiguration, including dynamic run-time reconfiguration, has the potential to solve so many problems for software application developers, and to broaden the market for FPGAs.

Consider:

Partial reconfiguration allows developers to iteratively recompile, re-synthesize, re-map and re-test a specific portion of the FPGA in just a few minutes, rather than a few hours. This in itself is a huge benefit. Instead of having to set up elaborate, hardware-oriented simulations to verify correct behavior before hitting that compile button, you can just try it out, again and again, in the same way you would when developing software. Indeed, this method of design was predominant for FPGAs in the 1980s and early 1990s. But as device densities have grown, iterative design-and-test methods have become impractical. That was good for the hardware simulator business, but bad for software developers.

Run-time reconfiguration allows certain parts of the FPGA to remain intact and functioning, for example the I/O processing, while other parts are being updated on-the-fly. Need to change the filtering of a video signal to respond to a change in resolution? Wham, it’s done, and so fast the viewer doesn’t even see a flicker. Want to change the FPGA’s function without causing a system reboot? How about leaving the PCIe endpoint alone and just changing the core algorithm?

Dynamic reconfiguration can increase the effective size of an FPGA. Loading of partial bitmaps at run-time allows the capacity of these devices to grow in the dimension of time. If you don’t need all the hardware capabilities you have programmed into your FPGA all the time, then use dynamic reconfiguration to swap hardware modules in and out as needed. Use reconfiguration to do more, with less.

Partial reconfiguration opens up new FPGA markets. Using partial reconfiguration, the vendors of FPGA-based platforms for specific types of applications – for financial transaction processing and automated trading, for example – could provide a “minimally programmable embedded system” in which most of the FPGA logic is pre-designed, pre-optimized and locked down, while a small portion in the middle is left available for end-user customization. This potentially opens up whole new application domains that were previously not available for FPGAs; applications in which the platform vendor and the end user both have unique domain knowledge, and have their own critical IP to protect.

Again, these capabilities are not really new; the Xilinx partial reconfiguration features have been used successfully, for years, in domains such as software-defined radio. What’s changing is that partial reconfiguration is finally becoming officially supported. With uncertainties about its future and its supportability reduced, software and platform vendors will now begin using these features to enable new programming, debugging and operating features into their own products.

It’s about time.

In an earlier post, Please pass the dot plots, I described how Greg Edvenson at Pico Computing used an FPGA cluster and C-to-FPGA methods to demonstrate acceleration of a DNA sequence comparison algorithm. The quick success of that project was reason enough for us to attend PAG and learn more about the computing problems in genomics. Where are acceleration solutions needed?

It’s clear there are problems aplenty to be solved. As one researcher said to us, “The amount of raw data being generated by DNA sequencers each month is outpacing Moore’s Law by a wide margin.” He went on to describe how his group routinely undocks and hand-carries their hard drives down the hall because the time required to move the generated sequencing data across their network is too long. Solutions are needed for accelerating data storage throughput, and for the actual computations to do such things as assemble whole genomes from the small chunks of scrambled DNA that currently emerge from sequencing machines.

Why all the data? The human genome is about 2.91 billion base pairs in length*, and it’s not the longest genome out there, not even close. We have more base pairs than a pufferfish (365 million base pairs) but far less than a lungfish (130 billion base pairs).

Evolution is a curious crucible.

Sequencing technologies have advanced quickly. Machines and software offered by Illumina, Life Technologies, Roche and others can generate enormous amounts of genetic data. The bottleneck at present is in assembling all that data – like a billion-part jigzaw puzzle thrown to the floor – into a meaningful, searchable DNA sequence. The methods of doing this assembly, using algorithms such as ABySS and Velvet, may require parallelizing the problem across many CPUs, and using large amounts of intermediate memory – potentially terabytes of it.

If you are a researcher trying to figure out, for example, how to increase crop yields in sub-Saharan Africa, then you might be very interested in knowing how to breed a more pest-resistant and productive variety of barley (5 billion base pairs) or wheat (over 16 billion base pairs).

And if you’re Dupont or Monsanto, you may want to actually create and patent such a grain to have a competitive advantage.

To figure out such things, you may want to perform sequence comparisons of other species that appear to have the characteristics you are interested, and find the relevant genetic variances. You won’t have a chance of doing this unless you can sequence many varieties and perform detailed analysis of what you see. This takes lots of computing time and bags of money.

And so the gemonics industry looks for faster solutions for cracking the codes of life. The solutions involve cluster and cloud computing, GPUs and FPGAs, and perhaps exotic hybrid computing platforms to come.

Last week at the Chaos Communication Congress in Berlin, Dr. Karsten Nohl announced that his team, a group of hackers working collaboratively to create a distributed computing cluster, had cracked the encryption code by creating an enormous, 2-terabyte “rainbow table” of hash values. In simplistic terms, the rainbow table provides a cracking program with a reverse-lookup scheme that can quickly decrypt the wireless voice data.

I’ll leave aside any prediction of who might want to use this kind of cracking technology, and where they might want to do it. In the United States GSM is used for only a fraction of communications, most notably by AT&T and T-Mobile.

GSM dominates worldwide, however, carrying the overwhelming majority of phone calls. (And if you are an iPhone user like I am, you should know that AT&T most probably sends your voice via the 2G GSM standard using A5/1 encryption, even though you are paying for presumably more secure 3G service. And if you think your iPhone data is secure… read this.)

From a computing perspective, what’s interesting about this project is that it required two types of computational acceleration. The first computing problem was the creation of the rainbow tables. This only needed to be done one time, but represented a massive computing problem. Nohl estimated that to generate these tables using a single traditional PC or server would have required many years to complete. To make this problem practical, Nohl and his collaborators set up a distributed computing system similar to the SETI@Home project in which the spare computing cycles from many different computers on the Internet were harnessed to calculate the needed tables. In some of the computers GPUs were also used to accelerate the problem, which was completed in three months of calendar time.

The second computing problem occurs at the point of decryption, in whatever server or laptop PC is being used to snoop and crack the wireless signal. That problem is also computationally intensive, but with ready access to the 2-Terabyte rainbow tables the crack can be performed in minutes, or seconds if GPU and/or FPGA accelerators are added into the mix.

During his talk, Nohl stated that a person (or agency?) wanting to eavesdrop on GSM calls would currently need to spend around $100,000 on hardware in order to crack an A5/1 encrypted call in one second or less. And the hardware to use? A cluster of 64 or more FPGAs. For less money and slower cracking times (still under a minute, and under $30,000) a smaller number of FPGAs or GPUs would do the job just fine.

Slides from Nohl’s talk are here.

…I call programs that don’t take into consideration legacy systems and that are obscenely difficult to integrate, “pornographic” programs — you can’t always describe them exactly, but you know them when you see them. In 1984, I converted a FORTRAN program from CDC to ANSI FORTRAN to see what they were doing and it was awful. In the contemporary world, CUDA is the new pornographic programming language.

http://bit.ly/pv2da

Nonetheless, there are certain domains in which FPGAs are clear winners over GPUs, particularly when power consumption is factored into the results. Two of these domains are crypto-analysis (code cracking) and bioinformatics.

The CHREC group at the University of Florida, and Pico Computing of Seattle, have both recently announced benchmark results for DNA sequencing algorithms. Both groups used FPGA clusters to perform massively parallel computations and to accelerate the comparing and scoring of DNA base pairs by orders of magnitude.

The Florida group, led by Dr. Alan George, implemented a Smith-Waterman sequencing algorithm on a cluster of 96 Altera high-capacity FPGA devices, using PCI Express FPGA cards supplied by GiDEL.

The Novo-G cluster used for this project consists of 16 Linux servers, each housing a quad-FPGA accelerator board from GiDEL. According to the CHREC team, Novo-G’s performance was compared with an optimized software implementation executed on a single 64-bit, 2.4GHz AMD Opteron core. A speedup of 40,849X was observed. The implication is that a bioinformatics calculation that would take days to run on a single desktop workstation or server would require just seconds to complete using the Novo-G FPGA cluster.

In Seattle, Pico Computing implemented a similar algorithm that performs sequence analysis and scoring to create a 2-dimensional figure called a dot plot. The Pico team reported that they had achieved greater than 5000X acceleration of their algorithm, using a cluster of 112 Xilinx Spartan-3 FPGA devices. The Pico cluster consumed less than 300 Watts of power, with all FPGAs fitting comfortably into a single 4U server chassis.

Perhaps more interesting about the Pico Computing project was how it was developed. Greg Edvenson of Pico used a single FPGA device during initial algorithm development. The FPGA was encapsulated in a Pico Computing E-17 card attached directly to Greg’s laptop computer via an ExpressCard interface. After the algorithm was tested and working as a single hardware process, Edvenson then scaled up and replicated the algorithm for deployment on the FPGA cluster. Greg used C-to-FPGA tools provided by Impulse Accelerated Technologies during the development of the algorithms, reducing the need to write low-level HDL code.

In summary, bioinformatics is one application domain in which FPGA acceleration offers clear and compelling benefits. And as well, there are multiple FPGA cluster approaches that can be taken to meet the needs of the application, and to meet the constraints of budget and power consumption.

School system to use Algolith Profanity Cleaner and Delay System for live broadcasts

Okay, so maybe it was a slow news day when this got picked up. But digging deeper, what Algolith is offering is a reconfigurable, FPGA-based delay and filtering application for audio and video.

In their literature, Algolith is promoting the concept of One Card, One Price, More Choices. This is fundamentally what reconfigurable hardware is all about, and it makes sense for both the customer and for Algolith.

Why? Because video filtering and other broadcast video applications require hardware solutions, but don’t have static requirements. What’s needed for broadcasting, say, the Superbowl with 50 or more HD cameras, chaotic real-time action and thousands of opportunities for verbal and visual naughtiness, is probably quite different than the requirements for broadcasting a heathcare town meeting with a few unruly seniors.

How does reconfigurable hardware come in? A vendor such as Algolith can design and produce a hardware based solution, such as an HD-compatible video card, that has at its core one or more FPGAs. Some of the logic in these FPGAs is fixed and rarely updated, handling those parts of video processing that don’t change. Interfacing with video and network I/O devices, for example. Other parts of the video processing, however, are reconfigurable, allowing new types of clever delay filtering and other video gymnastics to be performed by the customer. Want to fuzz out someone’s unfortunate wardrobe problems with one mouse click, and track the offending [insert noun here] even as it moves around the scene? How about hiding all those annoying non-sponsor brand logos? Hey, somebody’s got to keep the viewers safe.

I don’t know if Algolith offers such high-zoot features in its video products, but these sorts of capabilities are certainly possible to implement in FPGAs today.

From a marketing perspective, the really attractive thing about reconfigurable hardware is the ability for a company like Algolith to become more than a hardware vendor – which is not a particularly scalable business – into a vendor of IP and services that use their reconfigurable hardware product as a platform for value-added options and reconfigurable firmware upgrades. And that’s a way $&@%*%! better business to be in.

And all in the pursuit of market efficiency, of course. Hopefully all this money-shuffling is good for my meager retirement portfolio.

Editorializing aside, there has been a lot of buzz about the role of accelerators, including FPGAs, in financial applications. XtremeData this week generated some press regarding their new accelerated database for analytics. Their solution is attractive because it combines an FPGA module with an industry-standard HP Proliant server to accelerate specific algorithms (in this case SQL queries) by 15X over software-only equivalents.

As an industry, we need more turnkey solutions that highlight the benefits of FPGA acceleration. With enough such applications out there, the demand for programming and hardware platform solutions for other, possibly unrelated applications will increase.

Assuming, of course, all this financial alchemy doesn’t once again turn gold into lead.

DeepChip is the website of John Cooley and home of the perennially unofficial and irreverent ESNUG (East Coast Synopsys Users Group). DeepChip has evolved over the years – almost two decades now – into a highly popular site for discussing design methods and tools of all flavors, with a particular focus on ASIC and, to a lesser extent, FPGA hardware design.

In recent weeks and months there have been a flurry of comments on DeepChip from vendors of C-to-FPGA tools, and from users of those tools, culminating with a long-overdue acknowledgement from John that such tools really are gaining traction. See “I Sense A Tremor In The Force”.

I found the dialogue somewhat heartening; it’s good to see the conservative world of ASIC design finally starting to embrace these tools. But I also found the theme of the whole debate – that these tools are new, untested and exotic – a little amusing. And so, during the week of the Design Automation Conference, here is my open letter to the DeepChip community:

Subject: C-to-FPGA Users: Who Are These People?

Here are some perspectives on the recent C-to-hardware debates….

Are there actual users of this stuff? Absolutely. The real question is, who are these people?

C-to-hardware tools are not yet common among traditional hardware designers. Yes, there are successful ASIC tapeouts and some scattered successes in, for example, consumer video processing on FPGAs. We are hearing more of these successes every year. But for the vast majority of hardware designers, RTL methods using VHDL and Verilog are still the preferred route. Particularly in a downturn, what project leader wants to risk their career on a new design method?

The move to higher level methods of design will happen; it’s just a matter of time, and of getting a critical mass of success stories with clearly stated benefits. We’ve seen this before, by the way… VHDL and Verilog did not take over from schematics overnight, and that move was less of a leap of abstraction than the current push from RTL into ESL.

So where is the action in C-to-hardware?

It’s on the software side of the world. It’s in embedded systems for defense and aerospace, it’s in reconfigurable computing research groups. it’s in financial computing and life sciences. It’s in places that do not have significant hardware development expertise. It’s in places where Deepchip.com is not widely read, and where “EDA” and “ESL” have little or no meaning.

I can state emphatically that C-to-FPGA tools really do work. Impulse C, for example, has users worldwide who are applying their C programming skills to create hardware coprocessors for embedded systems-on-FPGA, or to move processing intensive algorithms into dedicated FPGA logic, using the newest FPGA-accelerated computing platforms.

Are these tools perfect? By no means. Any user of Impulse C would report similar frustrations – but also the productivity benefits – that we’ve seen regarding other C-to-hardware tools. All of these tools have their peculiarities, and all require a certain amount of C-language refactoring in order to achieve acceptable performance. All of these tools require “best practices” training. However, I believe all of our tools have now matured to the point where that level of refactoring can be performed by a skilled software programmer, with little or no prior knowledge of RTL.

To summarize… I believe we are nearing a point at which traditional hardware engineers will begin moving en-masse to higher-level tools, including C-to-hardware. There will finally be a payoff for the ESL vendors that have been pushing these technologies forward, and a bigger payoff in productivity for the development teams that take the leap and use ESL for complex systems. But I also believe the bigger, unreported story is that a new generation of FPGA programmers is emerging, blurring the distinction between hardware and software for embedded and high performance computing systems.

David Pellerin, CEO
Impulse Accelerated Technologies

Loose Threads and Blank Slates

This is unfortunate, a setback for reconfigurable computing overall. But it’s not surprising given the history of new and exotic reconfigurable devices. I still believe that, somewhere out there, there is a reconfigurable device architecture that can find its market. But as I’ve opined before, such a device needs to be programmable using higher-level methods, using established software or hardware programming languages. If I were starting a programmable device company – which I wouldn’t, by the way, because I’m not rich enough, smart enough, or maybe not dumb enough – I would start with a target application first, then decide how to program that application. And then… only then… I would have some very smart people design a programmable hardware device and a set of design tools and libraries that are optimized for that application, and that support that programming method.

There is a very good series of articles covering this topic in EE Times: See FPGA Startup Crunch.

The Novo-G system is being built using FPGA accelerator cards provided by GiDEL and Altera. The system will have 96 Altera Stratix-III FPGA devices, installed into 24 networked servers with 576GB of memory and 20Gb/s InfiniBand for interconnection.

According to Professor Alan George, the purpose of Novo-G is to “advance and prove reconfigurable computing technologies at a level of scale, performance, and productivity unprecedented in this field, for applications from satellites to supercomputers”.

Novo-G is based on PCI Express FPGA cards provided by GiDEL and populated with FPGAs provided by Altera. Support for C programming of these cards has been enabled with an Impulse C Platform Support Package (PSP) developed by Rafael Garcia at the CHREC lab.

More information about this project can be found here.

FPGAs assist medical imaging in two areas, detection and image construction. The detection part of medical imaging is an embedded systems application, with real-time performance requirements and significant hardware interface challenges. Image reconstruction, on the other hand, is more like a high-performance computing problem.

Image capture and display in computed tomography involves synchronizing large numbers of detectors arranged in a ring around the patient, in the large doughnut structure that we associate with CT, MRI and PET scanning. These detectors are often implemented using FPGAs, many hundreds of them, and already represent a large and profitable market for programmable logic devices.

While FPGAs are well-established in the detector part of the imaging problem, they can also help solve a significant problem in image reconstruction. They do this by serving as computing engines – as dedicated software/hardware application accelerators.

Tomographic reconstruction is a compute-intensive problem; the process of creating cross-sectional images from data acquired by a scanner requires a large amount of CPU cycles. The primary computational bottleneck after data capture by the scanner is the back-projection of the acquired data into image space to reconstruct the internal structure of the scanned object.

University of Washington graduate researchers Nikhil Subramanian and Jimmy Xu, working under the direction of Dr. Scott Hauck, recently completed a project evaluating the use of higher level programming methods for FPGAs, using back-projection as a benchmark algorithm. Nikhil and Jimmy achieved well over 100X speedup of the algorithm over a software-only equivalent. The target hardware for this evaluation was an XtremeData coprocessor module. This module, the XD1000, is based on Altera FPGA devices and serves as coprocesser to an AMD Opteron processor running Linux, via a HyperTransport socket interface.

This project, which was funded in part by a $100,000 Research and Technology Development grant from Washington Technology Center, was intended to determine the tradeoffs of using higher-level FPGA programming methods for medical imaging, radar and other applications requiring high throughput image reconstruction.

The key to accelerating back-projection is to exploit parallelism in the computation. Working in cooperation with Dr. Adam Alessio of the UW Department of Radiology, the two researchers converted and refactored an existing back-projection algorithm, using both C-to-FPGA (the Impulse C tools) and Verilog HDL, to evaluate design efficiency and overall performance.

This conversion, which included refactoring the algorithm for parallel execution in both C and Verilog, took 2/3 of the time when working in C than when working in Verilog. Perhaps more importantly, the two researchers found that later design revisions and iterations were much faster when working in C, with as little as 1/7 the time being required to make algorithm modifications when compared to Verilog.

The quick success of this project showed how even first-time users of C-to-FPGA methods can rival the results achieved from hand-coding in HDL, with surprisingly little performance penalty and faster time-to-deployment.

The results of this study have been published as Nikhil’s Master’s Thesis, which is available here: A C-to-FPGA Solution for Accelerating Tomographic Reconstruction.

I like to fantasize that our two Impulse C demonstrations running in the Xilinx booth had something to do with this. Or perhaps it was the video processing workshop featuring C-to-FPGA methods that impressed the distinguished panel of judges.

More likely it was the timing of announcements from Xilinx of their new Virtex-6 and Spartan-6 devices.

As the economic slowdown takes its toll on development budgets, embedded-system designers are turning to FPGA (field-programmable-gate-array) technology to shorten design cycles, combat obsolescence, and simplify product updates.

These new devices, while not yet having the density needed for high performance computing, nonetheless represent a rare success in the creation of a new FPGA architecture, in particular by providing low-power devices that are appropriate for mobile devices, and that are programmable using well-understood HDL methods.

More information here.

David Manners of Electronics Weekly asks this week, Does the FPGA need a re-design?

Instead of narrowing the market applicability of its products by focusing on specific customer needs, the programmable logic industry would do better to address its fundamental problems: FPGAs use too much power and are too expensive.

It is certainly true that FPGAs are not optimal for any specific application. Lack of application optimization means there is going to be overhead – the cost of providing flexibility in the device. Overhead in size/cost, and overhead in power.

There have been quite a few alternative programmable architectures proposed and funded that would, in theory, reduce this overhead through clever interconnect strategies and through dynamic, run-time reconfiguration. And there have been an almost equal number of casualties along the way. Companies that have entered and exited this space include MorphICs, Chameleon, IP Flex, PACT, Quicksilver, Mathstar… the list goes on.

Do we need a fundamentally different kind of FPGA? Probably. But the lesson of the somewhat battered reconfigurable computing industry seems to be, take it slowly and don’t change too many things at the same time.

For example, you can change the device architecture and its mix of internal resources to reduce its power consumption, without fundamentally changing how it’s programmed. Or you can change the programming method to increase design productivity, but don’t try at the same time to dramatically change the underlying architecture.

The reason? Design teams considering FPGAs (or FPGA-like reconfigurable devices) are risk-averse. The most appealing platform for these teams will have well-proven methods of programming and the safety of a broader market – the economies of scale.

Even in their adult years, FPGAs as we know them continue to provide a competitive level of performance (relative to, say, a DSP device), with reasonably low risk to the average design team. And so they will be with us for quite a while, even with their drawbacks.

When producing higher-level design tools for FPGAs, it’s important to know the true “pain points” of application developers – what aspects of software-to-hardware are most critical in actual projects, and what barriers there are to success with a given tool flow. There is no better way to learn this than by actually completing a project yourself, with your own tools, on a tight schedule. 

In software circles this is known as “eating your own dog food”.

About a week before the holidays I had a phone call from our friends at Xilinx, asking if we would like to participate in the Consumer Electronics Show in Las Vegas, highlighting the use of FPGAs for HD video processing.

That sounded like a great opportunity. The trouble was, we didn’t have a CES-quality demo ready to go. Something that would suggest how low-power Xilinx Spartan FPGAs could be used in the newest and grooviest consumer and automotive devices. Something other than the usual, yawn-inducing edge detection filters, decompression engines or picture-in-a-picture demos.

As an organization we’ve done a fair amount of video processing work, most of it customer-funded and military/aerospace related. We’ve created configurable filters, combined dual embedded processors with custom video coprocessors, streamed video between TI DSPs and FPGAs, and all kinds of other fun stuff. There are some folks on our team who are real hotshots at this kind of thing.

But what could we build in two or three weeks that would be really fun and different? Could we use the new Xilinx Video Starter Kit, with its DVI input and output interfaces and its Embedded Development Kit (EDK) reference designs, and actually put something together in time?

To make this more interesting, it was two weeks before the holidays, and we were already jammed up with critical customer deliverables. There was nobody available who was actually qualified to do the work. Everyone was busy.

There was only me.

By way of background: I have significant past experience with VHDL, primarily as a synthesis tools developer. And I have plenty of past experience with C programming. But to be honest, I have not written a production-quality line of code in a very long time. I’m in more of a marketing and executive management role. We have very good engineers here who probably laugh at my feeble, occasional efforts to help with new features and bug fixes.

My exposure to the modern Xilinx tools is relatively limited. I know just enough to stumble through our own Impulse CoDeveloper / EDK tutorials, by carefully following the instructions that our more expert staff have written.

I talk a good story, but I am not by any means a professional FPGA developer.

This is all a long-winded way of saying that when we received the new VSK package from Xilinx (a loaner sent the very next day) we had very little time in the lab to bring up a baseline project and begin coding an Impulse C demonstration example for it. Mostly the work would have to happen over the holiday break. In my dining room at home. With curious kids and an impatient spouse hovering nearby. (“So, this is a week off?”)

The demo I had in mind was object recognition in a 720p video stream. One evening I had come across a copy of Finding Nemo in the stack of DVDs, and it had occured to me that Nemo was probably not so hard to pick out of a video frame in real-time, given his bright colors and stripes. Could I actually ”Find Nemo” using the Xilinx hardware and Impulse C, starting with a Xilinx DVI reference example?

Fortunately the bring-up of the EDK reference examples was painless. The ACE files provided in the Flash card worked flawlessly with multiple input and output devices, verifying the hardware setup within minutes. The provided Platform Studio project for DVI passthrough built in EDK (the Xilinx Platform Studio environment), downloaded and came up perfectly the first try. I also tested the camera-input reference example and it worked, although I did not make use of that reference example for this project. (A live-action “Clown Fish in a Fishbowl” demo would have been nice… perhaps next time.)

My first effort (with the help of Mei Xu, Applications Engineer here at Impulse) was to hack into the reference example and its System Generator 2D FIR code, to attempt to insert a pre-existing Impulse C 5X5 filter in place of the FIR filter. This was moderately successful (we had edge-enhanced video output with less than two days of effort) but not particularly impressive from a functionality standpoint. Or as a high-level method of design. As I said earlier, edge detect has been done by everyone, and it’s not all that interesting. And to be honest, the HDL code that was provided in the reference example (created apparently by Xilinx System Generator) was rather obscure and probably very difficult to follow for a software person. We don’t really want Impulse C users having to muck around in that stuff.

It was then that I got the Finding Nemo idea. Mei (who had quickly gotten the edge detect working) said something like “good idea, good luck with it” and promptly left on holiday. Joe at Xilinx had also made a comment during our first call, something like “you guys should generate a pcore from your compiler”. That seemed like a good idea for productizing the design method, though maybe a bit of extra work setting up (a few days as it turned out… we already generate EDK pcores for use with MicroBlaze and PowerPC embedded processors).

During development in the subsequent week at home, I spent nearly all my development time using C and wrote no application HDL, apart from some trivial wrapper code customization for the pcore generation (based on our existing MicroBlaze PSP). 

The project was a complete success. Once I had a reliable video generation setup and had build the reference example it was mostly smooth sailing, with just the expected process of debugging and testing C code using GCC, compiling to RTL with our tools, optimizing and synthesizing, downloading and testing… and repeating this process until the demonstration was working to an acceptable level. I estimate that, not counting the time waiting for place and route to complete, I spent a total of 20 hours on the actual demo coding and testing, and then perhaps that amount in addition refining the design to make the smoothly moving ”spotlight” effect that is shown in the screen capture image above.

A block diagram of the system is shown below:

The demonstration will be shown tomorrow and Friday at CES. There is certainly more that can be done in this application, such as providing run-time configuration from MicroBlaze, improving support for alternate resolutions, and using more intelligent pattern recognition methods. But given the time constraints and the number of tools and hardware “fiddly bits” in the complete system, the speed of bring-up was impressive and encouraging to say the least. We intend to leverage the VSK in our own product promotions.

Next step: finding my car keys.

Thank you, Xilinx!

German processor firm alleges Xilinx, Avnet infringe patents

PACT is a reconfigurable computing company that has worked for eight years to promote and sell its XPP reconfigurable device technology, most recently focusing on intellectual property (IP) licensing for HD video applications. The lawsuit appears to be aimed squarely at the DSP48 blocks that now appears in every FPGA family sold by Xilinx. Obviously there is a lot at stake here for Xilinx if the suit has merit. But don’t hold your breath for a result: the case is not scheduled in court until 2011.

The workshop on Monday had 100 or so attendees, with a mix of academic papers and FPGA industry presentations and panels. The key takeaway for me was that reconfigurable computing for HPC applications (scientific computing, bioinformatics, finance, etc) is now well-proven but there are still issues with platform and tool maturity that we all need to work out before RC is mainstream. GPU-based acceleration has gained traction fast because GPUs are viewed as safe and widely available. Everyone has a graphics card of some sort, so using one to accelerate algorithms does not seem exotic. That’s not yet the case with FPGAs.

Steve Wallach presented the Convey technology in a Monday morning session. Wallach also won the Seymour Cray award this year. For those who don’t know his history, Wallach was a character in Tracy Kidder’s “Soul of a New Machine” as well as a key innovator at Convex and HP. I like the Convey approach because it emphasizes the use of commodity processors, commodity FPGAs, and well-understood C-language and Fortran programming flows. The FPGAs in the system are used to implement accelerator “personalities” that are described by Convey as follows:

“Personalities are extensions to the x86 instruction set that are implemented in hardware and optimize performance of specific portions of an application. For example, a personality designed for seismic processing may implement 32-bit complex arithmetic instructions — and at performance levels well beyond that of a commodity processor.”

The goal appears to be a library-based approach, in which developers do not directly program the FPGAs. Convey indicates that a Personality Development Kit will be available, presumably for more advanced users or system integrators.

siXis Technology was also presented during the workshop. Their platform is called the SX1000 and is a stacked FPGA module architecture with a toroidal interconnect. Very dense, with 16 or more high-end FPGAs in a small cube. Very cool. Or very hot, as the case may be. If there is a secret sauce to the siXis approach, it must be in the sauce they use to cool all those FPGAs stacked so close together.

siXis SX1000 FPGA-based supercomputer

NVIDIA had a larger presence this year than last. The TESLA platform is getting a lot of attention. But I also overheard more than a few comments regarding Intel Larrabee being a possible NVIDIA killer. And AMD is making a lot of noise (including large advertisements in WSJ) about Fusion. 2009 could see a knock-down fight between Intel, AMD and NVIDIA for acceleration business. I’m not making any predictions here.

The Pico Computing booth featured two Impulse demos including an edge detection video demo, and our 16-FPGA options valuation demonstration. The options demo looked very nice, with 16 graphs generated by the 16 FPGAs, each of which was running an accelerated Monte Carlo simulation. Check it out:

Options valuation running on 16 FPGAs using Pico Computing EX-300