Heard today on a social network...

The following was apparently posted today on a social network by an end user (I edited out a line to ensure that the person remains anonymous but it compared something to eating at a raw food restaurant):

"Verilog is like eating at McDonalds. VHDL is like dining at a nice bistro. Bluespec is like eating at a Michelin starred restaurant. .... C to gates synthesis is like chewing on the bark of a tree hoping that somehow your teeth can reassemble the wood fibers into a filet mignon steak."

Synthesizable test benches

If people are going to leverage FPGAs/emulation before RTL is ready, to bring up the verification environment or to do modeling and architectural exploration, they need to be able to write a lot of verification IP (such as models, transactors and test benches) quickly and without all the bugs involved typically with writing RTL.

My last company built storage network silicon. Since the standards we built to were based more on vendor implementations than standards documents, we needed to do FPGA prototyping to test our protocol implementations against other vendors' equipment before tapeout. This was difficult to do because we couldn't do much before a LOT of verification was done on the RTL -- this meant that the prototyping work was an 11th hour effort. It'd be great to start testing things out in the 3rd hour, with early models and test infrastructure.

A while ago, one of our engineers built a high-level synthesizable test bench, based on an example SystemVerilog VMM one. The neat thing was that, while it was about 40% fewer lines of code for comparable functionality, the BSV test bench was synthesizable -- so it could be run in FPGAs and emulation. We've finally gotten it written up as a white paper, which is now on our website.

Everyone needs a Laptop Burka.... not!

Time for a quick aside. I'm a real sucker for two things: cool gadgets and great design (products, graphic design, advertisements, architecture, ...). I thought I'd share my favorite sites for those with similar interests:

http://www.engadget.com/
http://www.likecool.com/
http://dailyyoghurt.blogspot.com/
http://www.wired.com/gadgetlab/
http://www.macrumors.com/iphone/
http://www.boygeniusreport.com/
http://gizmodo.com/
http://www.techcrunch.com/

As with everything, there's a lot of junk to filter through. Today there was on article on Wired's Gadget Lab site about a pretty ridiculous product called the Laptop Burka. As noted by Wired, the name's a bit offensive -- as is the idea in general. It'd be great to have a way to use the laptop in the sun -- but doesn't the Laptop Burka miss the point?

IEEE Design & Test Magazine's Special Issue on High-Level Synthesis

The July/August 2009 issue of IEEE Design & Test Magazine is a special issue on High-Level Synthesis. I've barely scratched the surface reading this issue, but I'm looking forward to spending more time reading it. While most of the articles are written by vendors or university researchers, there's one article that's been written by end-users:

Lessons and Experiences with High-Level Synthesis

by Soujanna Sarkar, Texas Instruments, Shashank Dabral, Texas Instruments, Praveen K. Tiwari, Interra Systems, and Raj S. Mitra, Texas Instruments

This article is a must read for those considering behavioral synthesis (C/C++-based synthesis). There's been a lot of hype about behavioral synthesis and expectations have been set (too) high. And, despite all the talk about openness and standards, there's very little data out there. This article is a step in the right direction -- let's hope there's much more. As well, there needs to be objectively comparable benchmark data.

In the coming weeks, I'm going to cover some of the more interesting lessons from this article. Stay tuned...

Guest Blog by Leon Stok (IBM) for DAC: From Design Platforms to Design Flows

I'm pretty excited about DAC this year, despite the economy. It's back in San Francisco, which is where my heart often is. I spent almost ten years in the Bay Area after going to school there. I've been back in Boston since 1991, but love every trip to the Bay Area.

DAC's doing a lot to get users more involved. This year, there's a user track, which looks very interesting -- and it's the subject of this guest blog from one of the officials from DAC. When I first attended DAC in 2004, I was struck by how "inside baseball" many of the technical presentations were. There are definitely end users keenly interested in this type of presentation -- but there are a lot of design automation issues that are more relevant and useful to the typical end user. Of course, the exhibits target the typical end user, but the new user track is one of the DAC's technical track initiatives targeting the typical end user.

Leon Stok, who works at IBM, is the chair of New Initiatives for the 46th DAC. Here's his post on the user track, entitled From Design Platforms to Design Flows:

Increasingly, the progress in the EDA industry needs to come from better design flows. In the PBC era, for example, point tool inventions like routing, placement and logic synthesis greatly improved productivity. Designers could put a simple linear design flow together where one point tool could rely on reasonable accurate predictions of the downstream design process.

When predictability disappeared from the design process due to submicron effects, a simple linear design flow of point tools stopped working and very complex integrated tools were created to iteratively solve design problems. Timing analysis and synthesis got combined first, followed by integration of placement, routing, clocking and power and signal integrity analysis.

In the last few years, large CAD vendors spend most of their development dollars on integration efforts and have built complex tool platforms. Most startups have not been able to keep pace with investment required to build tool platforms and, in many tool areas, their relevance is disappearing from the EDA scene.

Despite these tool platforms being very powerful, to harness their power questions abound to confound even the most seasoned designer:
• How does one harness the power of these integrated tool platforms?
• How does one ensure that the proper and correct technology definitions are fed to these tools in a consistent manner?
• How do you put a design flow together that understands the proper low-power concepts from system-level design to final physical implementation?
• How do we ensure we end up with a testable design?
• How do we measure the overall productivity of the design teams using these integrated flows?

Where does one get an answer to these types of questions? The three-day User Track at the upcoming 46th Design Automation Conference will focus on how one actually puts design flows together that address these problems. At this forum, 40 presentations from design teams hailing from many companies will share their experiences on how they put robust design flows together.

An Ice Cream Social Wednesday from 1:30-3 p.m. with 42 posters will offer an opportunity for you to mingle with other EDA tool users.

The User Track is included with the full-conference registration. Or, register separately for the User Track and attend the keynotes. For more details, visit: www.dac.com. I look forward to seeing you in San Francisco.

###

Note: This year’s DAC will be held July 26-31 at the Moscone Center in San Francisco. Register today at: www.dac.com.

Free Monday's back on at DAC

According to an email blast by John Cooley this morning, Free Monday is back on at DAC. EDAC is sponsoring it -- which is great news. Here's the letter that Cooley sent out this morning in case you're not on Deepchip's email list:

Hi, John,

Please inform your readers that EDAC has decided to sponsor the return of "Free Monday" to DAC this year. If they want to take advantage of this "Free Monday" registration, your readers must go to:

https://reg.mpassociates.com/reglive/register.aspx?confid=95

and complete all four pages of the registration. On the THIRD page they'll find a newly added "Free Monday Exhibits" option -- they MUST check this box to get this special registration.

On the forth page they should see a web receipt with their unique bar code confirmation on it. They must print this entire page.

To enter the DAC Exhibit Hall on Monday, July 27th, the engineer must present a paper copy of his/her entire bar code page to the Advance Registration desk located in the North Lobby of Moscone Center.

See you at DAC, John!

- Bob Gardner
EDAC San Jose, CA

Setting good expectations about C/C++/SystemC synthesis

I was pleasantly surprised the other day to come across a blog entry on Cadence's website entitled: C-to-Silicon Compiler: A High Level and a Low Level Tool. Although it didn't get into a lot of detail or make many claims about where Cadence's SystemC synthesis tool is "high-level", it did acknowledge some of the areas where SystemC is "low-level" (for synthesis specifically). I found the entry honest and forthright, not to mention pretty consistent with how we've characterized SystemC.

As I noted in previous writings, most recently in February in this blog post, I've never claimed that SystemC isn't general purpose. What I've asserted is the following:

• SystemC (for synthesis) adds value in the same areas where C/C++ adds value: for doing algorithmic blocks that can be expressed at a high-level and efficiently synthesized. We believe the scope of solutions that you can efficiently develop at a high level and efficiently synthesize is limited primarily to block level, simpler algorithms -- but there's no doubt you can develop RTL quickly for datapath centric designs, irrespective of quality of results.
• For control logic, interfaces, and system interconnect, SystemC is very RTL-like. You can describe anything, but SystemC as a language does not add significant value over RTL for these types of designs (and, in fact, may be worse than RTL as the level of abstraction is the same, but it's one step further removed from the hardware, complicating debug). Fundamentally, SystemC's synthesizable model of concurrency and communications is very much that of RTL.
  
  That's not to say that this doesn't add value over C/C++ -- of course, it does. It gives you finer grain control (and a way to express it) when you need it -- but this is done at the RTL level.
  
• Of course, C++ classes offer the ability to develop and substitute pre-built libraries for operators and interfaces. Forte provides an example of this in the article I referenced in my February post -- and, in this post, you can reference my criticisms of what Forte illustrated in their example.
  

Cadence's blog entry is very consistent with this. It acknowledges that "complete systems cannot be described and synthesized if one stays in the 'High Level Only' design paradigm". But, rightly so, they do claim to be able to handle complete systems -- like RTL, SystemC can describe designs of any complexity and type. According to the blog entry, here are some of the items that might need to be expressed at a low level:

• Complex I/O protocols (in fact, it says: "Trying to specify complex protocols at a High Level was the failure of the early High Level Synthesis tools")
• Multiple processes (and "various instances of the same hardware running concurrently")
  
• "Low level" communication between multiple of these concurrent processes (I presume he's alluding to managing access to shared resources)

I'll reiterate a statement I made in the past on Deepchip:

But while they may be good for DSP filters, FFTs,
and audio processors, these algorithmic synthesis
tools don't offer a significant advantage over
Verilog or VHDL for the bulk of gates that are
shipped today, including microcontrollers, DMA
controllers, cache and memory controllers,
bus/switch interconnects, bus interfaces,
network/link layer controllers,
sorting/queuing engines, finite state machines,
processors (whether CISC/RISC/DSP/graphics), etc.

There is plenty of room and need for a solution to deliver hardware from C/C++/SystemC -- especially if you don't need the quality of hand-coded RTL (in terms of latency, area, timing). (Particularly because Cadence allows one to replicate any aspect of a hand-coded RTL design, there's no doubt in my mind that one could replicate the QoR of a hand-coded design with their tool. The only question is how much productivity advantage you get when meeting the QoR of hand-coded design -- this will be entirely dependent on the type of design and how difficult it is to operate at a low-level of abstraction. Of course, with C/C++ solutions, you don't have the fine grained control of Cadence's solution.) And, it's refreshing to see a solution that, at least in this example, isn't claiming that it is more than it is.

But, this all leaves an open question: what about concurrency, complex control, interfaces, and system interconnect? Why do we have to be stuck with RTL for all of that?

Hackers delight -- A history of MIT pranks

Boston.com (the online presence of the Boston Globe) has a neat photo history of "pranks" at MIT on its website. I loved the 1982 prank where a large balloon came out of the ground near the 50 yard line in the middle of the annual Harvard-Yale football game (picture #9).

The Magical Number Seven, Plus or Minus Two

In 1956, George Miller of Princeton University did a famous study entitled: "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information". The conclusion of the study was that people's short term memory can keep track of about seven things plus or minus two.

This may explain why people prefer to think and write sequential software instead of parallel software. Although our brains are constructed with a parallel architecture like hardware -- they seem to prefer to think about a few things at a time. Sequential programming languages enable engineers to build a design one step at a time, enabling them to limit the number of items that need to be coordinated and managed at any one time.

Hardware is different -- it's inherently parallel, like the brain. Developing hardware forces engineers to coordinate many parallel activities -- especially where they intersect. A lot of time is spent managing shared access to resources -- and developing complex FSMs to ensure each resource is accessed by only one operation at a time. This makes hardware much more complex and harder to design.

It's only natural to want to move hardware abstractions to sequential languages like C/C++. These languages have large numbers of users -- and, because they're sequential, they are perceived to be easier to write. But there are some issues:

• Behavioral synthesis tools are good in the small (operating on smaller, simpler blocks) but not so good in the large (where there is hierarchy/modularity/data dependencies/...). So, a simple algorithm can be efficiently synthesized -- but more complex algorithms cannot compete with optimal, hand-coded implementations.
• Behavioral synthesis tools need to auto-parallelize the sequential code -- this technology has been around for years and has very clear, well understood limits. It's not good at system interconnect/composition -- and it's not good at complex control logic. From results we've seen, it's also often not very good at handling many algorithms.

Since C/C++ can't handle concurrency except where auto-parallelization tools can effectively discern it, SystemC was introduced. While SystemC adds concurrency so anything can be expressed, it adds little over SystemVerilog for the abstraction of control logic and system interconnect. As an abstraction, it's basically RTL -- except for the same places where C/C++ provide abstractions --> for algorithms that can be described with tightly nested FOR loops. Sure, you can write in a sequential software style, but you can't synthesize efficient hardware from this style -- and writing complex hardware like memory/DMA/... controllers is just as hard as with RTL.

Enter Atomic Transactions

In order to get efficient hardware, you need to design hardware using a parallel programming language, as with Verilog, VHDL, or SystemC. But, the abstraction levels for these languages aren't allowing us to keep up with design complexity. These languages are sort of like writing software in assembly language. We need a better abstraction for concurrency in order to design hardware faster and with fewer bugs.

Here's where atomic transactions come in. They offer a much higher level of abstraction for concurrency -- while enabling explicit control over parallelism. Because they enable explicit parallel hardware design, engineers can consistently achieve efficient hardware implementations.

But, atomic transactions allow engineers to think about one operation at a time -- without having to manage all the complexities of coordinating accesses to shared resources. The concurrency abstraction of atomic transactions is essentially "one-problem-at-a-time".

Sure it would be great to move to a sequential programming language -- to keep the problem scope for the engineer to a limited number (let's say: 7 +/- 2). But, it's of little use if you can't efficiently generate efficient hardware from it.

Like sequential languages, atomic transactions keep the problem scope down to one-problem-at-a-time (staying easily within the 7 +/- 2 zone that the human mind is good and comfortable with) -- but enable the efficient implementation of hardware by staying explicitly parallel. Atomic transactions provide all the flavor, but without the calories -- that is, they provide abstraction for hardware design (by keeping the problems to one-at-a-time) while enabling efficient hardware implementation (no compromises in QoR).

Coverage of our April 1rst "product announcement" in Chip Design Magazine

Max wrote up/posted our announcement yesterday on Chip Design Magazine's website. It's great that Max recognizes a really big L.I.E. when he sees one.

What's a "chappesses"?