Off topic, but humorous: They didn't study

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!

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

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

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

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

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

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.