feature article
Subscribe Now

ESL Gambit

Xilinx Acquires AutoESL

In 1995, I strutted my marketing suit onto the stage at the Design Automation Conference and told the world that a revolution was afoot.  I had seen the light – the path to engineering enlightenment, the road to the future of design – and I wanted to share.  No longer would designers have to toil and struggle with the arcane anachronisms of register-transfer-level descriptions and clock-accurate timing.  Now, thanks to the amazing capabilities of high-level synthesis, thousands of lines of detailed and incomprehensible RTL would be replaced by a few elegant lines of ordinary C or C++, with clear and self-explanatory loops and conditionals, that would magically be transformed and re-transformed into whatever hardware configurations best suited our requirements for latency, power, chip area, and throughput.

With that kind of incredible capability built into our tools, I was certain that RTL design would be dead within 5 years and all engineers would be happily sipping cocktails on the beach while their high-level synthesis tools crafted perfectly-balanced works of art – the likes of which could never even be envisioned by old-school RTL designers.  Yes, a new era was upon us and I was the messenger – announcing the arrival of the new age.

I even had PowerPoint slides.

AND a demo.

Ten years later, in 2005, 99.9 percent of people were still designing with plain-old RTL.  I was still convinced that high-level synthesis was the design technology of the future – and always would be. 

Now, in 2011, it turns out that some people really are using high-level synthesis – and it works.  For some things.  You see – all those years that high-level synthesis was trying to win us over, it had quiet but effective competition from another high-level abstraction – IP-based design.  Way back in the old days, we designed our custom circuits with schematics – using powerful IP blocks like AND, NOT, and OR.  With that methodology, the 10,000-gate design became tedious.  The 100,000-gate design became somewhat impractical, and the 1,000,000-gate design was ridiculous.  The problem, we surmised, was the schematic.  So we left the schematic world and went off into the land of language-based design and logic synthesis.  Language-based design at the register-transfer level also became tedious, however, when the code required mushroomed into the tens of thousands of lines.

One school of thought was that we needed to raise the level of abstraction of our language-based design – dropping the cycle-accurate architecture-specific RTL descriptions in favor of un-timed, higher-level behavioral descriptions.  The other alternative was to raise the level of our building blocks – and revert to a netlist-based model akin to our former schematic-based design flow.  This time, however, our blocks would be much more complex than AND, NOT, and OR.  We would be connecting up processor cores, memory-management units, video subsystems, Wi-Fi and USB blocks, and the like. 

Option B won the match. 

Today, most of us design with large, complex IP blocks for most of our design.  There is almost a one-to-one mapping of available IP for just about any standard capability we want to include in our design projects.  Want a Wi-Fi connection?  There’s IP for that.  How about SSD storage?  Yep – in seven flavors.  Need a 32-bit RISC processor subsystem?  Just plug-and-play.

We did, however, say “most” of our design.  It turns out that you can build a lot of stuff by snapping together large IP blocks and assembling a system-on-chip to be implemented in your choice of ASIC or FPGA technology… and so can your competitors.  Then, it’s just a contest to see who can manufacture the cheapest, distribute the best, and succeed at the other intangibles that determine success with a non-differentiated product. 

If we want to differentiate our product, it is usually by some “secret sauce” design block that contains our own special magic.  In many designs today, that “secret sauce” is some kind of high-performance datapath – like a DSP or video algorithm – that can’t be accomplished in software.  That “secret sauce” is the ideal target of high-level synthesis (or ESL synthesis).  We can describe our secret sauce in the essence of its algorithm – without regard for the specifics of hardware implementation – and use the power of the high-level synthesis tool to explore alternatives and find the perfect architectural compromise that meets our design goals.

It is that secret sauce that leads us here to the location where our headline has been buried, because it is here that we find the motivation for Xilinx acquiring AutoESL, and it is here that we can examine the latest move in a two-decade game of design-tool chess and estimate the value of the ESL gambit.

FPGAs have enormous potential for accelerating datapath-type algorithms.  We’ve waxed on ad-nauseum about the thousands of hardware multipliers – just sitting around waiting to be parallelized – on our latest FPGAs – if only we had the wherewithal to use them.  Unfortunately, getting 100x the performance of a DSP from an FPGA also requires about 100x the engineering work – unless you have something like a high-level synthesis tool.  With high-level synthesis, we can describe complex algorithms much as we would for a DSP processor – in C or C++ code, and synthesize the result into FPGA hardware.  High-level synthesis could truly be the silver bullet that enables FPGAs to break through the barrier and dominate the DSP scene.

Using high-level synthesis, we can describe our algorithm in C or C++, (yes, I see you back there with your hand up, OK,  “OR SystemC”), then use the power of the tool to explore hardware architecture alternatives and hone in on the one that meets our needs.  It should be noted here that “we” generally refers to hardware designers.  While one of the dreams of high-level synthesis has always been to enable software developers to create hardware simply by throwing down some C code and pressing a button – today’s HLS technologies are most definitely not “compilers” that take C code and magically generate hardware.  These tools must be guided with hardware engineering expertise – and that’s where “we” come in.

There has been just one problem.  High-level synthesis technology is extremely difficult to come by.

There are only a handful of players in the high-level synthesis game.  It takes years, or some would even say decades, of development to get a high-level synthesis tool to “production ready” status.  In addition to AutoESL’s AutoPilot (which is being acquired by Xilinx), there is Cadence’s C-to-Silicon Compiler, Synopsys’s Synphony C compiler (originally developed by Synfora), Cynthesizer from Forte Design Systems, Catapult C from Mentor Graphics, PowerOpt from ChipVision, C-to-Verilog from C-to-Verilog, CoDeveloper from Impulse Accelerated Technologies, and eXCite from Y Explorations.  Of these, several are not focused on FPGAs, and those from large EDA companies tend to be very expensive – think five or six digits per year per seat.  When one whittles down this list to those that are proven to have high quality-of-results, those that are affordable to most FPGA design teams, and those that actually target FPGA technology, the list gets very small.  Compound this with the fact that most of these companies are bare-bones startups, and the options for FPGA designers wanting high-level synthesis in their flow are sparse at best.

Last year, we talked about how BDTI had begun a certification program for high-level synthesis tools – specifically targeting FPGAs with signal-processing algorithms.  In that program, they had two tools – Synfora (now owned by Synopsys) and AutoESL (now being acquired by Xilinx).  BDTI showed that for this class of problem, high-level synthesis tools can significantly improve productivity while giving results comparable and often superior to hand-coded RTL implementations of the same design.  They also demonstrated that the FPGA version of that same design could then deliver many times the performance of traditional DSPs running that same design – with a smaller form factor, lower power, and less total cost.

A few weeks ago, in “Elephant in the Room” we talked about how synthesis technology was crucial to the use of FPGA technology.  We chronicled how the FPGA companies have almost completely succeeded in wresting control of this critical technology away from the EDA industry, and how that threatened to leave the EDA industry mostly out in the cold in the fastest growing segment of the semiconductor industry – FPGAs.  The next great hope for EDA in the FPGA world – past RTL synthesis – is high-level synthesis.  All three EDA companies have high-level synthesis technology that could be effectively deployed for FPGA design, but all three charge an ASIC-like premium for the product, and they seem to be primarily aiming the product at their traditional custom-semiconductor, ASIC, SoC audience.  

By acquiring AutoESL, Xilinx does two things:  First, they guarantee that an affordable high-level synthesis technology will be available to Xilinx customers.  Second, they guarantee that one of the primary, proven tools will not be available for competitors’ FPGAs.  If high-level synthesis is the next lynchpin in the FPGA tools game, then Xilinx may have made a strong strategic move locking them in.  The remaining contenders on the tool side now have to contend with the fact that all three big EDA companies already have offerings, and one of the two large FPGA companies does as well.  Their options just narrowed.  For Xilinx’s rival Altera, the question is now whether they want to depend on EDA to supply a potentially critical tool technology or try to lock in one of the remaining independent tools to restore detente in the high-level synthesis for FPGA wars.

Xilinx says they have big plans for AutoESL – and while it’s too early to judge specifics, the opportunities to optimize high-level synthesis for specific IP libraries and specific target technologies are many.  By eliminating some of the huge variables that challenge high-level synthesis tools, it should be possible to make a tighter, better performing tool – after some tuning time.  It will be interesting to watch.

Leave a Reply

featured blogs
Sep 28, 2022
Learn how our acquisition of FishTail Design Automation unifies end-to-end timing constraints generation and verification during the chip design process. The post Synopsys Acquires FishTail Design Automation, Unifying Constraints Handling for Enhanced Chip Design Process app...
Sep 28, 2022
You might think that hearing aids are a bit of a sleepy backwater. Indeed, the only time I can remember coming across them in my job at Cadence was at a CadenceLIVE Europe presentation that I never blogged about, or if I did, it was such a passing reference that Google cannot...
Sep 22, 2022
On Monday 26 September 2022, Earth and Jupiter will be only 365 million miles apart, which is around half of their worst-case separation....

featured video

PCIe Gen5 x16 Running on the Achronix VectorPath Accelerator Card

Sponsored by Achronix

In this demo, Achronix engineers show the VectorPath Accelerator Card successfully linking up to a PCIe Gen5 x16 host and write data to and read data from GDDR6 memory. The VectorPath accelerator card featuring the Speedster7t FPGA is one of the first FPGAs that can natively support this interface within its PCIe subsystem. Speedster7t FPGAs offer a revolutionary new architecture that Achronix developed to address the highest performance data acceleration challenges.

Click here for more information about the VectorPath Accelerator Card

featured paper

Algorithm Verification with FPGAs and ASICs

Sponsored by MathWorks

Developing new FPGA and ASIC designs involves implementing new algorithms, which presents challenges for verification for algorithm developers, hardware designers, and verification engineers. This eBook explores different aspects of hardware design verification and how you can use MATLAB and Simulink to reduce development effort and improve the quality of end products.

Click here to read more

featured chalk talk

Expanding SiliconMAX SLM to In-Field

Sponsored by Synopsys

In order to keep up with the rigorous pace of today’s electronic designs, we must have visibility into each step of our IC design lifecycle including debug, bring up and in-field operation. In this episode of Chalk Talk, Amelia Dalton chats with Steve Pateras from Synopsys about in-field infrastructure for silicon lifecycle management, the role that edge analytics play when it comes to in-field optimization, and how cloud analytics, runtime agents and SiliconMAX sensor analytics can provide you more information than ever before for the lifecycle of your IC design.

Click here for more information about SiliconMAX Silicon Lifecycle Management