Chips and BS

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

2009-07-14T07:58:00.005-04:00

I'm pretty excited about DAC this year, despite the economy. It's back in San Francisco, which is 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

2009-07-07T07:16:00.003-04:00

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

2009-05-09T20:07:00.031-04:00

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

2009-05-01T20:02:00.003-04:00

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

2009-04-11T17:23:00.020-04:00

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

2009-04-02T12:29:00.003-04:00

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"?

Atomic Rules reacts to Deepchip posting

2009-04-02T11:15:00.002-04:00

Shep Siegel wrote a post last night after seeing his letter posted on Deepchip. He felt that his original letter had been diluted by editorial license -- and wanted to provide his original letter as full reference.

(My previous letters have been edited as well -- I believe this is standard editorial policy.)

(No fools! Unlike previous post) Bluespec users react on Deepchip

2009-04-01T17:10:00.003-04:00

This was a long time coming -- Deepchip just posted user reactions to a previous post from last fall.

45 Billion ASIC Gates in a Box -- Whole-System Emulation

2009-04-01T01:00:00.001-04:00

I don't know why anyone didn't think of it before -- why not just build an emulation platform that can easily fit the biggest chips, or even a complete system? Bluespec is introducing a game-changer today -- please check out the press release. :>)

C-Synthesis Benchmarks revisited -- and a proposed design for the benchmark suite

2009-03-06T14:32:00.009-05:00

A few posts ago, I talked about a new benchmark suite being proposed for C-synthesis. I've had a chance to look at one of the benchmarks, specifically the MIPS design. Based on this benchmark, I think it's worth taking a deeper look at some of the other benchmarks.

The MIPS design is basically a small piece of C code that executes a subset of MIPS processor-like instructions -- it's basically an instruction set simulator built mostly as a large case statement on the ops code of the instruction. I'm curious what the synthesis results for this design would mean -- there is no pipeline, no microprocessor architecture, nor would one expect that a C synthesis tool would generate one from this code. Additionally, it's not a particularly complicated design. As a control based example, I'm not sure it would tell you much.

If we are going to have a benchmark suite, it needs to reflect the complexity and functionality of real designs that people would do -- and ideally be of a size that allows design teams to understand differences. A good example of a complex design suitable to benchmarking is Reed-Solomon, which has:

Complexity
Decent size
Practical use -- it's a design that someone might really need to implement

On OpenCores, there are publicly available sources available to Reed-Solomon for both C and Bluespec. And, as the C version was designed with synthesis in mind, it would be the perfect candidate for assessing C synthesis tools (and can be used to compare against what's achievable with a Bluespec design). The entire project and code sets are located at OpenCores (with the C reference code available in the sw-reedsolomon directory of the SVN repository for the project). You must be logged in to OpenCores to see SVN. The project is called bluespec-reedsolomon.�

Hopefully, CHStone might consider Reed-Solomon in its mix. If I were looking at C synthesis, I'd take a look at this design.

The game is afoot

2009-03-02T10:33:00.003-05:00

This year's Memocode design contest just kicked off yesterday.

Abstraction and Control-Dominated Hardware Designs

2009-02-11T22:12:00.037-05:00

I've been saying for awhile that SystemC is not a significantly improved solution for control-oriented designs, at least when it comes to designs targeted for synthesis into RTL (I'm not addressing other uses of SystemC in this post, like simulation-based testbenches, for example). I did a quick look and found this letter I had written to Deepchip covering this subject -- I'm sure I could find many more. And to be clear, as it's been intimated otherwise, I've never claimed that SystemC could not be used for control logic. Anything that you can code in RTL, you should be able to code in SystemC.

My point has been consistent and straightforward: SystemC offers little benefit over Verilog/VHDL/SystemVerilog for the expression of control logic (and, probably, is even a step backward for complex control designs; with SystemC, the description will necessarily be just as low-level and manual, but it will add an additional translation step away from RTL).

But, in this week's EETimes, Gabe Moretti quotes Gary Smith as saying that "Now we have ESL synthesizers from Forte Design Systems and Cadence that target both the Algorithmic and Control logic domains. Because of that we are moving away from the three domains (algorithmic, processor/memory, and control logic) view of ESL to a more traditional look at the methodology. The ESL methodology is indeed maturing."

I'd love to understand how things have matured in the control area -- as I'm not sure that much has beyond the messaging. Another piece this week might provide some clues:

John Sanguinetti of Forte has a contributed article for EDADesignLine called Abstraction and Control-Dominated Hardware Designs. Anyone considering SystemC for control logic should take a critical look at the example provided, particularly as it's the only example supporting the thesis. A cursory look at the example would indicate that there's a good code savings with the SystemC implementation -- a closer look highlights that this is a very special example, and one that doesn't particularly support the notion that SystemC provides unique abstraction for control logic. Here are some things I noticed:

The code illustrated is a basic sequential set of steps, with no flow control, no conflicts with shared resources, no conflicts with other FSMs in the system -- sure, it's "control" code, but it's hardly representative of what makes control complex.
The article mentions that this is illustrating a cooperating FSM (because it "cooperates" with a memory, I guess). Well, this is a pretty special (not to mention convenient) case of a "cooperating" FSM: the interactions are deterministic and stepwise and mirror images of each other. This is hardly an illustration of cooperating FSMs that have any usefully interesting interactions.
Isn't this showing abstraction? It definitely is -- and, in general, it's powerful to be able to hide code in a library and reuse it. It's especially elegant to overload operators as illustrated in this example. In SystemVerilog RTL, you wouldn't be able to do this type of overloading (I don't believe) and have it synthesize. That said, I believe you could do almost the exact same thing -- and provide almost the identical succinctness -- by using SystemVerilog tasks (I'm not an expert at SystemVerilog RTL -- so I'm not sure I'm using the right terminology). Basically, the point is that there's nothing about RTL that precludes this type of abstraction -- and I believe you could closely mimick it. Does that make SystemVerilog ESL?
The code that's "eliminated" in this example has to be written elsewhere in a class library -- so, for a single use, there's no code succinctness
What does the code in the library look like? Is it much better than what's illustrated in the RTL in this example? Or, is it RTL-like SystemC code put away in a library so that you write it once instead of at every instance?
What if the memory subsystem had different behaviors every time? For example, it completed transactions in differing numbers of cycles. What would that code look like?
How flexible is this code -- and how prone to error is it for an engineer to use, especially now that it's been hidden away? For example, in this design, it's assumed that only one process accesses the memory at any one time -- who guarantees this and how? Is it only usable in situations where you know it's the only thing accessing memory -- or accessing it "at that time"? What's required to use it if you need to worry about other processes potentially accessing the memory at the same time? So, if multiple processes try to simultaneously access the memory, what would happen? (I presume you'd get a bug, unless the library accounts for this (see the next point))
What would the code look like in the library if it had to account for multiple processes needing to access the single memory resource at the same time? Would the synthesis work for this particular case where the memory access is abstracted with []?

A code abstraction like this example looks good -- but isn't really illustrative of the kind of control logic that really needs to get abstracted. Complex control designs have cooperating FSMs with shared resource contentions, flow control considerations and more. Expressing this type of control (which is seen in most control-based design such as processors/controllers; DMA controllers; memory controllers; communications/networking IP; bus interfaces; system interconnects; etc.) is hard whether you do it in RTL or SystemC. It would be nice to know how SystemC looks and handles these types of issues -- and how it's better than RTL. A couple years ago, I put forth a challenge to see what SystemC looked like for these types of designs -- and published very transparent examples of how and why Bluespec dramatically improves these types of designs. What does SystemC look like for these types of designs? Why don't the behavioral synthesis vendors provide examples of these types of designs?

These more complex interactions are one important area where atomic transactions offer a profoundly better abstraction than RTL, making complex concurrency dramatically simpler to express, easier to change, and much more. Abstraction for control is about addressing and improving shared resource management, arbitration, scheduling, flow control, etc.

I'm not saying that SystemC can't be used to express control logic -- and I'm not suggesting that SystemC doesn't provide benefits over C/C++. It does -- and I'm sure there are many times where a dataflow implementation benefits from finer grained control and concurrency expressiveness. But, these aren't the fundamental questions.

The fundamental question is: what types of designs benefit from synthesizable design with SystemC versus Verilog/VHDL/SystemVerilog? And, how do they benefit? Abstraction buys you little if the quality of the results are not acceptable. Abstraction also buys you little if it improves the 20%, not the 80%. SystemC buys you little when there's little abstraction.

A benchmark suite for C-based synthesis

2009-02-05T18:02:00.004-05:00

An interesting development in the C-based behavioral synthesis space is the development of a benchmark suite. CHStone is a proposed suite for providing a common platform of benchmarks upon which to compare high-level synthesis tools. It's an interesting idea -- as it might be a way for potential customers to assess, compare and contrast different tools, without having to devote as much work. As well, if the suite is really representative, realistic and broad enough in capability, then it will allow customers to understand how the tools might perform in different applications.

At a minimum, it would be another datapoint prospective customers could use. Wouldn't it be interesting if vendors published source code, any support files required by the tool, generated Verilog RTL, and synthesis results (for popular silicon targets, e.g. TSMC 65 nm, Xilinx, Altera, ...) for each design in the benchmark suite?

People using published results should be thinking about an array of considerations:

* What's the source code like and ancillary files, if any

* How usable is the RTL (debug/ECOs/...)

* Can end-users recreate the results

* In the microprocessor space, compilers and processors were tuned to address the benchmark suites. For example, there were compilers that recognized that the Dhyrstone source and spit out a pre-designed, hand-optimized assembly code. Other tricks like optimizations that are narrowly tailored such that the benchmark(s) benefit but other designs almost never do. It's likely that games will be played over time if people start using these designs -- so, end-users will have to change the sources in different dimensions to test for this (features/naming/loop structure/....). And, this may diminish the value of this suite over time -- so new suites will need to get developed.

* I'm sure there are some others... (I've got to run -- I'll probably add some more when I've had time to digest.)

I don't have access to the IEEE paper that the developers of the CHStone suite wrote -- I'd love to read it to understand more. I think it's an interesting idea, as long as it doesn't get gamed. I'm curious about how good the proposed designs are at really pushing the tools -- and pushing them in different directions. Thoughts?

Off topic, but humorous: They didn't study

2009-01-23T13:32:00.004-05:00

I'd seen a couple of these test answers in Nikhil's office, but this has a few more. This post is only peripherally on topic -- as it's nerd humor. Can't remember if this requires a browser plug in:

They didn't study

Bluespec's new website is up!

2009-01-22T20:46:00.011-05:00

It's a great relief to have it finally up (though it is, of course, a work-in-progress). If anyone has ideas for better images (www.istockphoto.com is a good resource) for the pictures on the various pages, I'm open to suggestions!

(I completely forgot to thank Barbara, the designer, for getting it done: www.wavepaint.com)

2009 Memocode design contest

2009-01-20T21:38:00.007-05:00

The third annual design contest for the Memocode conference is coming up this March. Here's information for those wishing to participate (from one of the contest organizers):

MEMOCODE 2009 will again have a design contest. The contest will start March 1, 2009. The deadline for submission is March 31, 2009 and the notification of the results is on May 8, 2009. The conference will sponsor at least two prize categories, each with a $1000 cash award. Each team that submits a complete and working entry will be invited to submit for review a 2-page abstract for the formal conference proceedings; prize winning teams will be invited to contribute a 4-page short paper. For more information, please visit http://www.ece.cmu.edu/~jhoe/mc09.html.

Last year's results are pretty interesting and available here: http://memocode.irisa.fr/2008/designcontest08/everybodywins/index.html

2007's results are available here: http://memocode.irisa.fr/2007/designcontest07/

The Bluespec solutions are only as good as the architecture envisioned by the team using it. Like the BASF advertisement ("We don't make a lot of the products you buy; we make a lot of the products you buy better!"), Bluespec doesn't make the architectures you design; it let's you express/build them faster and with many fewer bugs -- and have time to explore them.

(Bluespec provides free tools to universities for research and teaching purposes. If you want to consider using Bluespec for the contest, we'd suggest not waiting until the last minute.)

A couple good quotes about programming languages

2009-01-16T10:11:00.004-05:00

I like the following two quotes about programming languages.

The first was referenced by user wychen in a post on our discussion forums (to highlight why someone should elevate the expression level of their design. wychen's comment was: "It would be much more meaningful if you can design your hardware in a bluespec way. If you want to learn from examples, the MIT WiFi/WiMax design is a better starting point than the MIT H.264 design. The H.264 one seems pretty much like RTL and doesn't make full use of these advantages provided by bluespec."). wychen also included this quote in his post:

"Language that doesn't affect the way you think about programming is not worth knowing"

by Alan Perlis

The second was referenced by Nikhil, our CTO, in a comment he had made on Ron Wilson's recent editorial, How languages influence design, and why we should care: a tale of C, Verilog, and trouble:

The quote is from a great mathematician/philosopher Alfred North Whitehead in his book "Introduction to Mathematics":

“By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and, in effect, increases the mental power of the race. Before the introduction of the Arabic notation, multiplication was difficult, and the division even of integers called into play the highest mathematical faculties. Probably nothing in the modern world would have more astonished a Greek mathematician than to learn that ... a large proportion of the population of Western Europe could perform the operation of division for the largest numbers. This fact would have seemed to him a sheer impossibility ... Our modern power of easy reckoning with decimal fractions is the almost miraculous result of the gradual discovery of a perfect notation. [...] By the aid of symbolism, we can make transitions in reasoning almost mechanically, by the eye, which otherwise would call into play the higher faculties of the brain.”

The example of how a change to the notation of numbers drastically changed what people are capable of doing is very powerful -- and illustrative of what good languages should be capable of.

IBM PowerPC Design in Bluespec

2009-01-15T10:43:00.003-05:00

Amazing what Google will find. I've been really busy working on our new website. In the process, we'd like to bring a few stale webpages up-to-date. One of these is the technical paper reference page (which we last updated in 2005!).

Anyway, in the process, Kathy came upon a recent paper on IBM's website outlining the model of an IBM PowerPC design done with Bluespec: IBM PowerPC Design in Bluespec. This is part of a project to provide a processor modeling environment where many different architectural dimensions can be explored rapidly -- and assessed at high-speed on an FPGA subsystem.

I'll provide an excerpt (the intro) below. In the paper, there's a neat table showing the number of lines of BSV for the Core+Cmd interface for a single threaded design -- and the corresponding number for a design with four threads (the design is highly configurable). The stats are pretty interesting considering the design is 100% synthesizable:

Lines of BSV for version of CPU core with one thread: 12,433
Lines of BSV for version of CPU core with four threads: 12,433

There are six different code excerpts in the back of the paper which illustrate the style/level of abstractness of code (keep in mind that this model is executable on an FPGA).

Here's an excerpt from the paper which describes what's presented (bold added by me):

"We describe here the structure and principal components of the design of a multi-threaded powerPC processor using Bluepsec. The focus is on the generality and flexibility of structure, using the high-level nature of Bluespec language, so that the resulting design facilitates rapid experimentation with incremental changes to the architecture. Hence, the code is highly parameterized so that the design can be easily tailored to vary the number of threads, cores, various table sizes, etc. The implementation presented here is of a very primitive processor that has no cache subsystem and is directly connected to a memory. A preliminary design of an address translation mechanism is included. We describe the structuring of some salient components and give some code fragments to illustrate the flavor of coding style. The complete processor is synthesized successfully and is currently being ported onto an FPGA platform."

The system integration opportunity

2009-01-14T09:22:00.006-05:00

There's an interesting guest blog by Jim Hogan, on EDN's website last week. He talks about the importance of IP, and, specifically, the opportunity for block level interconnect and memory control IP:

"In my opinion, there is a substantial untapped System-Level IP opportunities in block level interconnect and memory control–the architecture through which IP is integrated and IP interoperation is achieved.
"The new platform opportunity for what EDA becomes lies in the successful integration of third party blocks in a System on Chip (SOC) or an FPGA."

While this problem has been attacked with IP -- the approaches haven't been very flexible. In order to achieve a sophisticated level of parameterization, it's required tremendous development and maintenance of scripting and tool infrastructure. Interconnects need to be a lot more nimble in architecture/features and protocols and more sophisticated in design -- and need to be able to quickly support the needs of both modeling and implementation. I don't believe that RTL can easily or efficiently deliver on this.

How Languages Influence Design

2009-01-13T16:11:00.005-05:00

There's a great, thought provoking editorial by EDN's Ron Wilson entitled: How languages influence design, and why we should care: a tale of C, Verilog and Trouble. It makes many of the same points that we (at Bluespec) often make -- in fact, our CTO, Rishiyur S. Nikhil, made a comment on Ron's blog.

In the piece, Ron makes an analogy with APL, which is a language for expressing certain types of math algorithms. Apparently, it's very difficult to write a good compiler for APL. He compares that to C, which may be nice for describing things, but it's just as difficult to do a good compiler for it for multi-cores or for hardware (outside of basic datapaths). In contrast, Verilog and VHDL are easy to write compilers for, but are too low level.

Unfortunately, the world of hardware is not simply datapaths -- even algorithms get complex and, many times, intermingle datapath and control. And, their implementations often need to be tightly coupled with switch interconnects, data moving units, and memory dynamics for optimal implementations.

And, what about system interconnects and other complex control related IP?

Automatic parallelization is neat technology, but it's not a general solution -- instead, we need solutions that are common to system interconnects, complex control and algorithmic IP so that we can elevate all projects in a design, especially the ones that are required to develop software.

Promising new addition to DAC next year: User Track

2008-10-28T15:22:00.005-04:00

As a relatively new person in EDA, I was surprised at how 'inside baseball' many of the technical tracks can be at DAC. I've been hoping that the technical tracks could become much more relevant to the average design engineer.

There's a new track for next year's DAC entitled the DAC User Track. It sounds very promising -- here's an excerpt from the call for extended abstracts:

This year, DAC is introducing a new User Track to address the issues facing designers, application engineers, and design flow developers. User Track papers describe the use of EDA tools to design a novel electronic system, or to produce a design flow or a methodology to produce such systems. A User Track paper may be problem-specific in scope (e.g., analyzing substrate coupling during floorplanning) or may address a specific application domain (e.g., designing wireless handsets), though applications to other types of designs and design flows could be inferred.

BEE3: Putting the Buzz Back into Computer Architecture

2008-10-22T21:52:00.002-04:00

My last post was about RAMP. The hardware platform they'll be using for their computer architecture research is called BEE3 -- and the link above is to an article on Microsoft's role in developing (with a focus on Chuck Thacker).

There are some neat details on the BEE3 here. Each one has four Xilinx Virtex-5's (Virtex-5 LX110T, LX155T, or SX95T). Each BEE3 has a lot of expansion. And up to 64 BEE3's can be interconnected together.

There should be some very interesting computer architecture research driven from this.

RAMP

2008-10-21T22:01:00.004-04:00

RAMP stands for Research Accelerator for Multiple Processors. It's a research effort that involves many universities and companies, with a home based at Berkeley. The thrust of the effort is to build a platform to do research with 1000 CPU systems -- John Wawrzynek's A Project Introspective presentation summarizes the challenge: the many processor design trend has a problem in that compilers, OSes, and architectures are not ready for 1000s of CPUs per chip. So, RAMP is building an FPGA-based infrastructure for doing cycle-accurate multi-core/many-core architecture emulation.

Because simulation (software-based models) just won't scale -- they're moving the modeling platform to hardware. This is a trend that I am seeing more and more where people are executing models on hardware (FPGAs) rather than in simulation -- because they perform better and scale with multi-core growth (by adding more hardware).

There are a bunch of interesting areas enabled through Bluespec -- including RAMP infrastructure, James Hoe's research into multi-core simulator technologies, Derek Chiou's research into cycle-accurate architecture emulation, ... The publications area has lots of very interesting presentations summarizing work and status. I'll cherry pick a couple of the public industrial projects involving MIT (and others) -- I'll highlight others (which are just as fascinating) when I have time:

IBM's PowerPC project

Intel's HAsim project

In order to move models into hardware, you need higher-level abstraction -- and in order to make effective use of FPGAs, you need to avoid both the bugs and brittleness inherent in RTL design. This can only be done for processors, caches, memory models, DMA, switches, etc. with general purpose high-level synthesis languages that don't suffer quality of results issues.

Why not C/C++? There's no notion of concurrency (for synthesis, it's good with loop-unrolling, but not for other applications)

Why not SystemC? It doesn't raise the level of abstraction of concurrency for hardware design over RTL. So there's no benefit for complex control applications. Again, for synthesis, it's good with loop-unrolling, but not other applications.

ESL article on EDN

2008-10-20T22:01:00.003-04:00

I'm so behind -- I've got some items that I've been collecting. One is an ESL article by Ron Wilson of EDN called: Electronic-system-level design, is there fire beneath the smoke?

Ron interviewed Grant Martin, of Tensilica, for this article. While there's been a lot of hype from some of the C-to-RTL vendors about using C for control logic, Grant makes some good points. Here are some highlights from the article:

Grant Martin, chief scientist at configurable-processor vendor Tensilica, has for years been working on the control-logic-synthesis problem. "For the current tools, the sweet spot for ESL synthesis is still datapath logic," he says. "If there is a clear exception, it might be in the networking space, where some design teams have been using [ESL-synthesis-tool set] BlueSpec in areas such as packet-classification engines."

Martin points to several issues with C-to-RTL control-logic synthesis. One is that the strategies that have so far worked best have been less dependent on C sources and not as algorithmic in their approach as the tools for datapaths. It's not that C is a poor language for expressing control logic, Martin says. Some people are comfortable using C dialects in this way. But, in C, he points out, execution time for a control algorithm is generally not an issue. In control-logic hardware, every cycle matters.

I'll add that Bluespec is being used in many areas outside of networking -- many of them in areas traditional behavioral synthesis could never add value, given the datapath-centric focus of those tools. I think Grant hits on one key -- that control logic generation from C suffers tremendously in quality of results, primarily due to the limitations of automatic parallelization technology.

The other point I'd make is that the abstraction for control logic in these other approaches offers little over RTL. Hardware is concurrent -- but these C languages don't raise the level of abstraction of concurrency or advance design in this dimension. I think that's the ultimate issue with these approaches -- and what will impede their use for design beyond datapath centric applications.

FIFO madness

2008-09-11T13:47:00.004-04:00

One of the engineers sent the following blog entry around, which relates one embedded software engineer's frustration with FIFOs. He claims he's never written a driver for a system that didn't have a FIFO problem in it. He starts out with:

"I’ve never seen a FIFO that worked. Period. Every piece of hardware I’ve had to write a driver for has had a buggy FIFO."

It's no wonder given that RTL-level design requires every FIFO instantiation to have context-specific control logic designed for it -- every single time. It's like Bill Murray in the Groundhog movie -- every day is the same and has to be done all over from the beginning. Every single time you use a FIFO, you can get all sorts of things wrong with it.

Atomic transactions tightly coupled with high-level interface semantics are the only things that I'm aware of that virtually eliminate this issue. As the engineer who sent it around said, if only they'd been using Bluespec (once you verify a FIFO to be correct at the unit level, there's no special context-specific control logic you have to write for each instantiation -- the compiler gets it right without any added weight of implementation. FIFO problems solved.).