Chips and BS

Deepchip & Mentor/Catapult/Calypto news

2011-09-02T17:57:00.002-04:00

John Cooley posted my thoughts to Deepchip today about the recent news of Catapult C spinning out of Mentor into Calypto.

Xilinx Xcell Journal Article: Amazing MIT FPGA Projects & BSV

2011-08-08T22:33:00.004-04:00

The latest Xilinx Xcell Journal has a great article on MIT's 6.375 digital design course. The students, who only had rudimentary hardware design experience at most and had never seen BSV before the class, build truly amazing projects in only 6 weeks -- after only 2.5 months of class. Read more and get the article here.

The unnamed tool behind Mentor’s optimizing power white paper

2011-08-08T22:26:00.003-04:00

I recently wrote a blog post at Bluespec's website about a Mentor white paper and article on optimizing power. We were a little surprised to see some very familiar quality of results in a table that they used for both pieces.

The 2011 MEMOCODE Design Contest & BSV

2011-07-19T11:31:00.002-04:00

I'm going to be splitting my blogging on both Bluespec's website and here. I just wrote a blog on the 2011 MEMOCODE design contest, which was won this year by Michael Papamichael of CMU. His solution was really amazing -- you can read more about it here.

A BSV-based design has won every time it has been entered in the MEMOCODE design contest.

Blog post on what makes parallel programming so hard

2011-05-27T21:35:00.002-04:00

Here's an interesting blog post on what makes parallel programming so hard.

Amazing projects this year by student teams from 6.375

2011-05-25T20:56:00.004-04:00

6 weeks, from concept to architectural exploration to fully functional, running projects on FPGAs. Not a big deal if you're doing a traffic light controller -- these are no traffic light controllers.

Check out the projects done this year by the students in 6.375 (few of whom had ever done significant hardware designs before, most, if not all, hadn't worked with FPGAs before, and none of whom knew Bluespec). I'll write more about this after DAC, but this shows what you can do when you're not limited by preconceptions about what's possible.

Chilean miners visit Framingham to make pitch for ESL education

2011-05-22T21:20:00.003-04:00

Given that we recently moved to Framingham, MA, someone thought that maybe we'd achieved a big marketing coup... Not quite the same ESL.

16.7 trillion cycles and counting

2011-05-10T09:02:00.003-04:00

Just checked in on our Synthesizable Virtual Platform demo that we left running over the weekend. It models a processor-based SoC and boots and runs Linux -- but runs in FPGAs so that it can run really fast and be arbitrarily mixed with RTL, both legacy and new IP. Just upgraded to run at 50MHz in the Xilinx ML605 board, the demo was running through its paces since Friday and had just hit 16.7 trillion cycles. Very cool -- and, I'm curious, of all the chip tapeouts I've been a part of, what the most number of simulation cycles was.

EETimes coverage of our news today

2011-04-01T10:17:00.000-04:00

Bluespec Now Working to Eliminate the Industrialized World’s Dependence on Oil

2011-04-01T00:01:00.000-04:00

Bluespec Now Working to Eliminate the Industrialized World’s Dependence on Oil

Redeploys Engineers to Work on ‘Promising’ Solution

Framingham, Mass. – April 1, 2011 – Soon to be previously known as The Synthesizable Modeling Company™, Bluespec Inc. announced today that it has redirected its focus to eliminating the industrialized world’s dependence on oil. Specifically, Bluespec is perfecting the use of water as the next energy source. Imagine, soon the people of the world will be both quenching their thirst and powering their SUVs from the same bottle of plain ol’ water.

Read the full press release here

BSV by Example

2011-02-09T19:33:00.003-05:00

Available now on Amazon.

Blurb on the back cover:

The complexities of modern electronic circuits ("chips") demand powerful tools for design. A key prerequisite is a high-level language in which to express not only designs themselves, but also their models and their testbenches. During design and verification, these need to run much faster than software simulation is capable of, and must therefore be fully synthesizable to run on the only platforms capable of delivering this speed -- FPGAs and emulation. BSV is the only language that meets these requirements (alas, C++ falls woefully short!). This book is a gentle tutorial for learning BSV through a series of small examples, focusing on just one feature at a time. All examples, with full source code, are fully synthesizable and executable.

March 1966

2010-08-04T23:05:00.002-04:00

Nikhil recently came across one of his favorite papers entitled "The Next 700 Programming Languages" by P.J. Landin from the March 1966 Communication of the ACM magazine.

In the back of the paper, there's the transcription of a discussion by several people about programming languages. The last comment in the paper is from Strachey, considered one of the fathers of modern, formal semantics for programming languages. His comment is timeless:

One inconvenient thing about a purely imperative language is that you have to specify far too much sequencing. For example, if you wish to do a matrix multiplication, you have to do n^3 multiplications. If you write an ordinary program to do this, you have to specify the exact sequence which they are all to be done. Actually, it doesn't matter in what order you do the multiplications so long as you add them together in the right groups. Thus the ordinary sort of imperative language imposes much too much sequencing, which makes it difficult to rearrange if you want to make things more efficient.

There are reasons why Mathworks doesn't use C or a C-based language for the expression of math. So, what's the best way to express hardware?

Lessons from the software space

2010-07-26T17:31:00.003-04:00

Tim Bray, co-inventor of XML and now working on the Android team at Google, presented at OSCON recently in Oregon. There's a nice summary of his presentation on InfoWorld's website, and, I believe, a link to his presentation which I'll check out later. Here are some great quotes attributed to Tim's presentation from the article:

"Concurrency is hard. It involves a lot of problems that are very difficult to think about and reason about and understand," said Bray, who is developer advocate at Google. Bugs and performance bottlenecks are among the issues with concurrency, he said.

and

Historically, it has been thought that the way to program for concurrency is through threading, Bray said. But programming with threads, which offer multiple access to shared, mutable data, is "something that is not understood by application programmers, cannot be understood by application programmers, will never be understood by application programmers," added Bray.

One of the themes I've talked about in the past (e.g. this piece on "The problem with threads") is how hard it is to design using threads. SystemC, of course, uses threads and events for concurrency.

One might notice how Tim is not advocating software development with C/C++ using threads. We hear from the EDA community that C/C++ using threads makes the most sense for hardware design because everyone knows C. "It's practical." If that's the case, then why doesn't the software community, those who know C the best, advocate for a similar solution?

Momentum in Japan

2010-06-10T14:22:00.004-04:00

Our partner in Japan, Cybernet, has had a great response to their introduction of Bluespec in Japan. This March, we made our first customer announcement in Japan with Panasonic. Today, we announced Fujitsu. We're honored to be in such great company.

Bluespec Required to Accept People with Pre-Existing Conditions

2010-04-01T07:42:00.001-04:00

After the passage of the Health Care Bill, there were some material impacts to Bluespec's business that we felt compelled to disclose TODAY. The text for the press release at our website outlines these issues.

Fascinating new FPGA technology

2010-03-31T20:31:00.002-04:00

Though I have to say that I'm a bit disappointed to see the editor for TechFocus Media, Kevin Morris, break embargo by one day with this breaking news, the two new FPGA technologies that he covers are anything but foolish:

http://www.techfocusmedia.net/fpgajournal/feature_articles/20100330-4d/

http://www.techfocusmedia.net/fpgajournal/feature_articles/20090401_retro/

Sequential versus Parallel

2010-03-29T21:17:00.002-04:00

Here's another post on the same theme as the last (I'm sure it won't be my 'last'): the applicability of C/C++ for hardware design. Whether modeling, verifying or implementing, whenever one is considering synthesis, either as a path to emulation or to get to RTL, the question of the suitability of the language matters.

At CHREC (National Science Foundation (NSF) Center for High-Performance, Reconfigurable Computing), there is a report sponsored by DARPA funding entitled "A Research Agenda for Improving Configurable Computing Design Productivity". (I'm not sure if I'm linking to the executive overview or the final report) It looks like the date of this report is 2008. Here are a few interesting excerpts from section 4.2, Abstraction, on new languages:

"..many of these abstractions are based on inherently sequential languages. The sequential nature of these languages limits the ability to specify and to exploit the massive parallelism available in hardware circuits."

"While these recent tools and languages are a step in the right direction, we believe that they are insufficient for moving hardware design to a significantly new level of design productivity."

"We advocate the adoption of standard, concurrent programming languages for hardware design rather than adopting sequential programming languages and adding non-standard semantic extensions. The use of concurrent programming languages will facilitate the extraction of concurrency for hardware."

Must read for Hardware Designers/Managers Considering C/C++ Synthesis

2010-03-28T20:37:00.004-04:00

A lot of good points were made in Jakob Engblom's blog back in July 2008 in a post entitled, What's the Obsession With C in EDA?. A couple highlights:

Taking a naturally parallel problem, packing it into disciplined sequential C, and then having a compiler discover the parallelism again is really a huge waste of effort.

and

But what I am uncertain about is whether the code provided by embedded developers, generated from domain-specific languages, or obtained as reference implementation is a actually a useful start for synthesis. In my experience, it would likely not be, as all that code is not designed to fit a restricted easy-to-manipulate subset of C.

To me it would look like you would have to at the very least go through the code and do a lot of rewriting and fixing to make it fit for synthesis. Negating most of the gain of reusing “existing” code.

Customer announcement today

2010-03-25T11:06:00.003-04:00

Bluespec just announced Panasonic as a customer. It's been fun trying to understand the Tweets from Japan. I liked the (Yahoo Babel Fish) translation of the following excerpt from Hirano-san (The quote he's got here is from Fujikawa-san of Panasonic):

It is sharp, “as for Bluespec the fact that individual language is adopted is the point”

Dream ESL Language

2010-03-24T22:35:00.004-04:00

I recently discovered Jakob Engblom's blog. I stumbled upon it after seeing a Tweet from Brad Pierce (who's fun to follow on Twitter, BTW) reference an interesting blog entry named Dream ESL Language. The best part was to see a nice Bluespec mention in one of Jakob's comments (thank you Jakob!):

Still, to be fair, there are some really cool things that have come out of the EDA field. Things like BlueSpec and “e” are pretty cool.

Chuck Thacker receives Turing Award

2010-03-10T19:05:00.003-05:00

EETimes has an interview with Chuck Thacker, who just won ACM's Turing Award. It caught my eye as I've talked about transactional memory in previous posts, which Chuck mentions in this interview as one of the areas he's currently exploring in the parallel architecture space.

This made me think, as it came up recently, of an interview he did for the Computer Museum where, talking about Dave Conroy, Thacker says: "Dave is one of the few people I know that’s actually a better engineer than I am." I got a kick out of this quote when I first heard it -- but the funny thing is that someone I respect very much said that there truly are very few engineers better than Thacker.

IEEE SystemVerilog

2010-03-08T16:08:00.000-05:00

Bluespec offers its fundamental enhancements to IEEE #SystemVerilog at Requirements Gathering mtg (slides: http://tinyurl.com/ye62mtp) #EDA

2010 MEMOCODE Hardware/Software Co-Design Contest

2010-02-27T06:25:00.006-05:00

It looks like Monday is the kickoff of the fourth hardware/software co-design contest put on by the IEEE conference, MEMOCODE. Three years running, an MIT team, powered by Bluespec, has won honors in the event, typically in pretty dramatic fashion over alternative approaches, such as using RTL or C.

MEMOCODE Contest 2009
MEMOCODE Contest 2008
MEMOCODE Contest 2007

This year, if I read it right, it looks like the MIT team has been sidelined, opening up the field. Almost everyone involved in previous MIT winning teams is involved in developing this year's reference design -- so, they won't be participating again. I haven't heard about any teams from MIT unrelated to the CSAIL architecture team getting involved.

Here's an excerpt from the announcement email I received:

Who is organizing this year's contest?
-----

This year's contest was coordinated by Joel Emer (Intel) and Forrest Brewer (UCSB). The reference design was implemented by Michael Pellauer (MIT), Asif Khan (MIT), Muralidaran Vijayaraghavan (MIT), Abhinav Agarawal (MIT), and Man Cheuk Ng (MIT). It was tested by Richard Uhler and Kermin Fleming (MIT).

The co-design contest is a really interesting event. The format of the contest is the same every year. On the first day, a problem is published with a reference design. Participating teams get a month to improve the performance of the reference design -- the solutions with the most speedup win. This year's solution is described as a deep packet inspection problem, with a "twist".

If you'd like to participate or you are interested, you can find out more information at: http://memocode2010.csail.mit.edu/redmine/wiki/memocode2010

Here's the full email I received:

Prepare for the 2010 MEMOCODE Hardware/Software Co-Design Contest!
http://memocode2010.csail.mit.edu/

Apologies if you receive multiple copies of this posting. Please distribute further to all interested parties.

* What is the 2010 MEMOCODE Hardware/Software Co-Design Contest?
-----

MEMOCODE is short for the IEEE International Conference on Formal MEthods and MOdels for CO-DEsign. This year's conference will be held in Grenoble, France (http://www-memocode2010.imag.fr/). Every year the conference holds a design contest in order to promote hardware-software interaction and push the envelope of parallel system description.

* How do I participate? Do I have to attend the conference?
-----

The conference happens in July, but the contest itself happens from March 1st to April 1st. Participation is done in a distributed manner via the Internet. The problem will be sent out to participants via the webpage (http://memocode2010.csail.mit.edu/). Teams do not need to attend the conference in order to participate, although in years past the winners have attended and given talks on how they solved the problem.

* Do I need to be a student or graduate student in order to participate?
-----

No. Anyone can participate. We welcome participation from industry teams as well.

* Can I join multiple teams?
-----

No. The only limitation is that each person can only be a member of a single team.

* What is this year's contest problem?
-----

This year's contest problem will be revealed on Monday March 1st, at 12:01 US Eastern Time (GMT-5). At this time we are prepared to reveal that the problem will involve Deep Packet Inspection... with a twist!

* What are the official supported platforms?
-----

This year the official platforms are the Xilinx University Program XUP boards, which include a Virtex 2 version, and a newer version with Virtex 5 FPGAs. The contest organizers have ported the reference design to these platforms, and tested the result.

* Can I use a different platform?
-----

Absolutely. We welcome submissions using whatever platform you think is best. The only thing to keep in mind is that by using a different platform you take on the responsibility of porting the reference design to that platform. While the contest organizers can provide some advice about porting based on our knowledge of the reference design, the majority of the burden of the porting process will fall on your shoulders.

* Does my platform need to include an FPGA?
-----

Nope. Feel free to use a GPU, a vector computer, a multicore, or anything else that you think would be a good platform for this year's problem.

* Can I do a software-only implementation, like making a multi-threaded parallel software version?
-----

Absolutely. The reference design this year includes a single-threaded software-only X86 implementation. This version is meant to serve as a starting point for all software-only solutions.

* Since the problem involves Deep Packet Inspection will my platform need include Ethernet?
-----

No. To increase portability and lower the implementation burden on contestants we have decided to simulate all interactions with Ethernet. The details of this will be announced with the contest.

* What are the prizes?
-----

The exact prizes are still under determination. The winning team will be awarded a significant cash award. A total of $2000 was awarded in prizes last year. 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; winning teams will be invited to contribute a 4-page short paper.

* Are there separate prizes for "normalized" and "absolute" categories?
-----

Past contests have used a normalization technique in order to try and make an "apples to apples" comparison between different platforms and FPGAs. This lead to disagreements over what the normalization function should be and if it artificially favored certain platforms over others. This year we have decided to do away with normalization. While we may have a separate prize for the best design using an officially supported platform, the exact details are currently still being determined.

* Who is organizing this year's contest?
-----

This year's contest was coordinated by Joel Emer (Intel) and Forrest Brewer (UCSB). The reference design was implemented by Michael Pellauer (MIT), Asif Khan (MIT), Muralidaran Vijayaraghavan (MIT), Abhinav Agarawal (MIT), and Man Cheuk Ng (MIT). It was tested by Richard Uhler and Kermin Fleming (MIT).

* What can I do if I have any questions or concerns?
-----

Please e-mail the organizers at organizers@memocode2010.csail.mit.edu

Great Tweet!

2010-02-22T09:20:00.002-05:00

Loved seeing this Tweet this morning:

Hardware & Architecture

2010-01-14T21:17:00.001-05:00

Nikhil had tweeted the following earlier today. I saw it this evening and liked it:

Hardware designers who avoid considering architectures are like software designers who avoid considering algorithms.

TechBites

2010-01-08T22:48:00.003-05:00

I've been enjoying Max Maxfield and Brian Bailey's posts on TechBites, a new kind of site for the system design and EDA communities. I really like what they're going for -- a blend of editorial content and social community.

My last company was in the storage networking space, which had a strong presence by an online website called www.byteandswitch.com. One of the things I liked about Byte and Switch was the tight integration of commentary with articles, which was fairly unique at the time.

TechBites has the ingredients to build a community in our space. I'm watching closely.

Nice note today

2009-12-09T16:32:00.004-05:00

Because of our university program (very flexible and easy to apply to), our tools are in over 50 universities now -- in countries like U.S., Canada, Australia, New Zealand, India, Japan, Korea, Taiwan, China, U.K., Finland, Romania and Brazil. A professor at one of the universities relatively new to our program called right before Thanksgiving to get some thoughts about lab exercises for a class he was teaching. We threw out some ideas and then asked when he was going to be covering Bluespec -- it was funny as he said he'd already given the first few lectures (we try to keep the application process dirt simple and the program experience painless for the universities, so often we don't know what they're up to).

Today, Nikhil and I received this very nice note from the Professor:

I wanted to write and thank you for your help with
getting going with BSV. We are nearing the end of
the semester and the students are turning in their
cache projects today. The student were in agreement
today in our discussion that the BSV unit was a
strong success.

I thought I would drop you a note to describe what
we did and how it worked.

I spent about 5-6 lectures on BSV and they also
watched 4 of the demos on demand lectures. They
did 3 assignments. To get started with the tools
they did the Hello tutorial as well as a Pipelining
tutorial. Their second assignment was to work
through the 4 different multiplier tutorials. Their
third assignment was the cache project you helped
me pull together.

There were 7 parts to the cache project. The first
part was to create a null cache - I actually
removed the null cache code lines from what
Nikhil sent me. Rather, I made the students dig
the information on how to do the client/server
interconnections out of the Lecture 09 slides
from your website - that forced them to
understand a lot more about interfaces than
they otherwise would have.

Parts 2-7 of the assignment were things
like to create a direct mapped cache (one
word per cache line), enlarge the cache line
to be multiple words wide, do multi-way set
associativity, do write-back instead of
write-through, have the cache return the
requested word as soon as returned from
memory rather than waiting for the entire
line to arrive from memory, add concurrency
(allow multiple outstanding cache requests
be in flight at once).

The students all had to do the null and direct
mapped cache parts. They were allowed to
do more beyond that for extra credit, many of
them did many of the additional parts. They
had nothing but praise for the experience as
they turned in their final assignment. They felt
that they were 4-5x more productive in the
assignment than they would have been using
Verilog. I am hoping that one or more of them
will figure out how to work it into their
graduate research projects in the future.

So, thanks again for all your help. You were
very kind to take time with me on the phone
before Thanksgiving, and that made all the
difference in the BSV unit in our class.

If you're at a university, you can find out more about our university program here.

I'm sure I'm missing something...

2009-12-03T18:53:00.005-05:00

Here's my summary of some interesting data points from a Synfora user experience which is summarized in one of the latest posts on Deepchip (entitled "A User's 5 week block design using Synfora PICO C synthesis"):

Started with: ~400 lines of C code

Design consulting firm "re-wrote" C-code to target
Synfora's tool resulting in: ~1600 lines of code
(Interesting quote: "How you write your C-code
influences the block-level architecture that will
be generated by PICO in the final RTL")

Tool generated: 131,000 lines of RTL across 120
Verilog files

Time relative to a manual C-to-RTL flow: same or a
little less (no big win on this block, but this was a
smaller (my word) design)

Okay... I'm missing a couple things. First, exactly where in this process was a manual re-write avoided? Second, I thought that C synthesis was all about algorithm and not about architecture. If so, then why the massive re-write? And, why: "how you write your code influences" the architecture generated by the tool?

Heard today on a social network...

2009-11-06T10:02:00.005-05:00

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

2009-11-02T11:29:00.003-05:00

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!

2009-09-23T22:06:00.006-04:00

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

2009-09-05T21:49:00.006-04:00

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

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

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

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.).

Reuse - the difference between hardware and software

2008-07-27T12:51:00.009-04:00

I wanted to share a perspective I heard while in the Bay Area last week. We've made some of these points, but I liked the way it was wrapped.

The context was in discussing issues with hardware design. The engineer's viewpoint was that a fundamental issue was design reuse, or the adequate lack thereof in hardware design.

He made a comparison to the software space, where most software applications are largely built on top of pre-existing libraries. In the software space you stand on the shoulders of those before you. These software libraries aren't application specific, but are general libraries of all sorts of useful building blocks and capabilities. It wouldn't be atypical for a GUI software program to consist of only a fraction of new code, with the bulk built using libraries. And, in the software space, as libraries grow, reuse grows commensurately.

In contrast, reuse in the hardware space consists of large, application specific blocks, e.g. PCIe, processor, etc. You just don't see a lot of general purpose libraries that can be easily used in different situations to build your designs. And, when you do, typically they're very brittle -- it's difficult to interface to them, to change them and to leverage them for specific needs.

I think there are two fundamental reasons for this:

1. There are no standard interface conventions (analogous to calling conventions in the software space) -- this means that it's very hard to use hardware IP blocks. Each instantiation requires a custom, manually-intensive, situation-dependent implementation.

2. Shared resource conflicts must be manually handled. Hardware is parallel -- and the biggest complication is avoiding (scheduling around) race conditions where two operations might try to access the same resource (such as a register or an interface, such as enqueue and dequeue on a FIFO).

These two items prevent IP from being reused as a black box. The semantics of RTL (I include SystemC, SystemVerilog, Verilog, VHDL) prevent this from ever happening -- just like assembly language prevents the type of libraries that you see at a higher level in languages like C/Java/...

Atomic transactions address both these problems -- and enable general purpose hardware libraries, including those that look very much like what you might expect to only see in the hardware space.

Deming and dependence on mass inspection

2008-07-21T10:18:00.007-04:00

I got into a discussion last night with someone about the parallels between auto manufacturing (that is, U.S. auto manufacturing of the 70s) and chip design -- about how there is a focus on improving verification, without considering the impact that design has had on this. This person mentioned a slide that he used to have with a quote by W. Edwards Deming on it -- I've used the same quotes from Deming, I am guessing:

Inspection with the aim of finding the bad ones and throwing them out is too late, ineffective, costly. In the first place, you can't find the bad ones, not all of them. Second, it costs too much. Quality comes not from inspection but from improvement of the process.

The old way: Inspect bad quality out.

The new way: Build good quality in.

People have said that design is not the long pole of the tent. I presume that they mean that verification or software development is the long pole. I believe we have a design problem. We need to find ways to build good quality in -- there is nothing like avoiding bugs in the first place. You can never find all the bugs if you depend on inspecting the bad quality out. Low level design forces a protracted specification/architecture phase where micro-architecture details are too often planned out and prematurely committed -- and this delays verification integration/bringup. A plethora of bugs causes too much time doing debug and not enough time writing and running tests during verification.

There's no doubt that verification is killing us -- but it's important to diagnose the root cause of this. Continuing to add more verification engineers will not stem the root cause.

The U.S. auto industry thought they could inspect for quality in the 70s -- it took the Japanese to prove them wrong.

How the MEMOCODE design contests were won

2008-07-12T15:31:00.005-04:00

Recently, there was a nice plug on the programming language website Lambda the Ultimate for both this year and last year's MEMOCODE codesign contest winners -- which involved hardware acceleration of a cryptosorter design and a matrix multiplication, respectively. From this Lambda the Ultimate page, you can also get links to download writeups about the designs as well as copies of the designs themselves.

Both winning teams were powered by Bluespec. The 2008 team competed against eight other designs and beat second place by 11X. The 2007 team had only one competitor, which it beat by 5X.

I found the writeup describing this year's winning design to be a lot of fun. It's a quick read describing what they accomplished in only three weeks -- truly amazing. Aside from the complexity of the design and alternatives they explored, I found it most interesting that they skipped system simulation and went right into FPGA.

FPGAs will revolutionize embedded development, modeling and verification (let alone hardware design) when the two sources of drag caused by low-level design get squashed:

Bugs - complex designs today spend far too much time in simulation while bugs get wrung out until the quality is to the point that FPGAs can be safely used
Changes - design changes, such as for micro-architectural exploration, feature enhancements, or even (what should be) small refinements, take much too long. Consequently, designs must be overly carefully planned to get them right first time -- which takes a lot of time planning architectural and micro-architectural details and too often low-level details are fixed far too early in the process

New blog on scalable atomicity for reconfigurable computing

2008-06-23T21:02:00.003-04:00

I just got a heads up from an engineer on his new blog called Scalable Atomicity. I'm not entirely sure what he's up to (outside of leveraging atomic transactions as a competitive advantage). Reading between the lines, it looks like his focus will be around enabling a new way (that emphasizes time-to-solution, scale and correctness) to do multicore solutions and architectures in the FPGA world.

Are C to RTL solutions proprietary?

2008-06-16T16:10:00.007-04:00

The C/C++/SystemC to RTL solutions continually emphasize to the press and analysts (as well to prospective customers) that they are based on standards. When I saw John Cooley seeming to repeat this position in his Cheesy DAC list, I wanted to respond. I sent an email to John outlining the 5 questions that I'd ask any one of these vendors before buying into this "we're a standard" position.

In addition to these five questions, I've since thought of a sixth:

6. How much training and/or applications support is required to learn how to properly structure and write code for efficient synthesis results?

I'm not claiming that we are more "standard" than these solutions are -- but I am claiming that, with only one exception, there is no fundamental difference in how proprietary these solutions are.

There are a lot of potential terrific benefits to going with a standard, e.g.:
* Training
* Portability and reusability of designs

I don't think these apply to the C/C++/SystemC synthesis solutions. I think there's only one real "standards"-related benefit to the C/C++/SystemC to RTL technologies: you can functionally simulate the designs with standard compilers and, in the case of SystemC, free simulators. But this has nothing to do with the tools nor with the "hardware" aspects of a design: cycle-accurate simulation and synthesis. None of these solutions have a level of standardization that will significantly reduce tool-specific training or deliver design portability across vendors -- which I believe are the main reason you go with standards. Without this, then these solutions are proprietary.

And, once you get past this smoke screen, the interesting questions are around the benefits, applicability and quality of results.

Will "behavioral synthesis" ever be successful?

2008-06-12T13:05:00.002-04:00

A colleague just showed me an interview by SCDSource with Louise Trevillyan, research staff member in the design automation department at IBM's T.J. Watson research center. Louise was this year's winner of the Marie R. Pistilli Women in EDA Achievement Award.

Here's the money quote in response to the question as to whether behavioral synthesis will ever be successful in the future:

I would never say never, but I don't foresee it happening. There's always been a prediction that we'll have so much real estate we can use, and technology will move so fast, and time to market will get so important, that you might be able to accept suboptimal solutions in the name of getting a design out the door. If that ever happens, behavioral synthesis will become more acceptable. But remember, that day was predicted 20 years ago and it hasn't come yet.

Automatic parallelization is all but impossible for general purpose applications -- and only effective for those sub-blocks that can be described with tightly nested for-loops. The software space has abandoned automatic parallelization for parallel software design -- in favor of explicit parallel designs. That's not to say that they don't still have a huge challenge, but at least there's an acknowledgment that it isn't a panacea.

The EDA industry hasn't yet come to the same conclusion. I think it's just a matter of time.

Our 2008 DAC Giveaway - I want one!

2008-06-06T14:01:00.009-04:00

We're giving two things away at our booth this year. For free, we're giving away an electronic Sudoku game -- some of you may have gotten this from us before. But the one I'm excited about is free, but we have to draw names. We've got something like eight of them -- and, I'd love to get one but don't think it would be quite right if I drew my own name.

Every year, we try to pick something that's unique, useful for more than a few minutes, and, hopefully, desirable. In the past we've given away R/C cars, light-up super balls, fans with LEDs on them that display a Bluespec saying, and electronic Sudoku. I've wanted to do this for a couple of years: give away what may be the lightest indoor R/C airplane on the market -- it weighs just 3.6 grams. And, because it is somewhat fragile, it comes in its own carrying case (which is pretty cool) -- it looks like a padded camera or rifle case. Here are some pictures which link to the website for videos and more information. Some day I'll get one of these puppies for myself -- next week over a handful of you will get one. Stop by the booth and drop your business card in our box (or fill out an entry).

DAC: Bloggers Meeting Wed Night at DAC

2008-06-06T13:47:00.003-04:00

I'll be at DAC next week -- and I am planning to attend the Birds-of-a-Feather session on blogging in our industry next Wed night at 6P in room 201B at the Anaheim Convention Center. I've gotten to know John from John's Semi Blog a bit through blogging -- which has been fun. Turns out we share alma mater's and degrees, though not identical years. I'm looking forward to meeting some of the others that I've run into -- most of whom are far more diligent than I am.

EDP Conference in Monterey

2008-04-23T09:25:00.003-04:00

I didn't attend Electronic Design Process 2008 (EDP) in Monterey recently. The keynote was entitled Parallel Computing: Can We PLEASE Do It Right This Time? by Timothy G. Mattson of Intel. The focus of the talk was about software languages for multi-core hardware platforms.

I think there is a key point made in his presentation that people in the hardware design and EDA communities will find interesting. And, this is coming from someone talking about software development -- a community particularly interested in using traditional, sequential C/C++ software. Timothy's conclusions are not a surprise to anyone looking at how automatic parallelization tools have historically performed -- in a long history starting in the parallel computing market (Cray/Thinking Machines/KSR/...). He concludes:

* Automatic parallelization will not solve the software community's problems (that is, be a solution for developing parallel software for multi-cores)

* And, so: "Our only hope is to get programmers to write parallel
software 'by hand'."

I completely agree with this viewpoint -- and I think it equally applies to hardware design (actually, MUCH more so). We've seen a lot of "high-level" hardware design tools focused around automatically parallelizing C/C++/SystemC. And, there's no doubt that a certain class of smaller IP blocks (loop-and-array style code) can be effectively and efficiently synthesized automatically from these languages. But, these tools require a lot of tailoring to make efficient hardware -- and can't effectively address the bigger problems:

* Software development -- these tools do nothing for software -- isn't that the biggest chip design challenge? Don't we need models and implementations earlier and that run faster for software? It seems to me that behavioral synthesis tools are like trees in the forest for addressing this fundamental problem. Aside from there being many vendors hyping algorithms, since when did they become the long pole in the tent?
* Algorithmic subsystem performance -- Just staying specific to the "algorithm" subsystem, these tools can't easily comprehend, express or tailor memory and switch subsystem performance, which can often be the dominating architectural consideration for power, performance, area, ... And, impedance matching these blocks to memory and switch subsystems or impedance matching multiple of these smaller blocks can be a bear.
* Loop-and-array algorithms are a small part of designs. Looking at a system, these tools do nothing for the rest of the system: DMA controllers, memory controllers, processors, controllers, communications IP, etc.

Hardware designers need to develop the parallel aspects of their design by hand. That doesn't mean it needs to be at the RTL level. Simplifying concurrency is the only way to improve this process -- automatic parallelization just isn't a general solution (so C/C++/SystemC is not a path). This is where atomic transactions come in. (I know a lot less about how atomic transactions will and can work in the software space. That said, I have some thoughts about what Timothy says about the value of transactional memory in this keynote. I am in CA and my day is starting so I have to run).

Macbeth and RTL

2008-04-14T15:36:00.006-04:00

I was speaking with Nikhil, our CTO, about the issue people often run into with RTL where one gets committed inexorably to a particular direction. When it becomes clear that there might have been a better approach, you don't have the flexibility to switch directions. You are too mired in your current approach -- and no longer have time to approach it freshly. Nikhil immediately thought of the following quote from Shakespeare's Macbeth, in Act III, Scene IV, which provides a terrific description of this situation:

"I am in blood
Stepp'd in so far, that, should I wade no more,
Returning were as tedious as go o'er."

Macbeth is in too deep -- he's already committed murder. To go back is just as tedious as just to trudge forward.

When you get to this point with RTL, the only choice is typically just to continue. You get one shot -- it better be aimed in the right direction.

Algorithmic Myopia

2008-04-12T20:18:00.014-04:00

I was reading the summary presentation from last year's (2007's) MemoCODE codesign contest winners and thought it highlighted an important point about algorithmic design. (Last year, the winning team beat second place by 5X. This year, which was recently announced, the winning team beat second place by 11X).

The problem last year was a Blocked Matrix-Matrix Multiplication. It was designed to have both a software and a hardware portion. The core of the hardware piece is a classic "algorithmic" design. Tightly nested for-loops -- the type of solution that one *might* target with traditional behavioral synthesis (algorithmic synthesis) technology:

void mmmBlocked(Number* A, Number* B,
Number *C, int N, int NB) f
int j, i, k;
for (j = 0; j < N; j += NB)
for (i = 0; i < N; i += NB)
for (k = 0; k < N; k += NB)
mmmKernel(&(A[i*N+k]),
&(B[k*N+j]),
&(C[i*N+j]), N, NB);

As is not atypical for these types of problems, however, the real magic lies in the system considerations -- not the core loop-and-array architecture. If you just focused on the portion that algorithm synthesis solutions can address, you would have missed the key architectural consideration -- which was memory bandwidth.

The challenge was not only to recognize that this was the core architectural consideration, but focus the innovation and exploration around the memory subsystem -- AND ensure that the algorithmic piece was tightly coupled and scheduled to work with this subsystem. The first place team delivered 5X the performance of the second place team because they could rapidly explore tradeoffs in this area -- and their environment encompassed not just the "algorithm" but the system as well. (I put quotes around "algorithm" because this term is often mis-used -- and I'm mis-using it a bit here. An algorithm is not just the functional description of the problem (as it might be expressed in C), but also the cost-model for how that function is solved. A C function is not "the algorithm", but one "algorithm" for solving a problem -- it never expresses a particular hardware algorithm for solving the problem.)

Algorithmic synthesis solutions may be able to automatically produce different pipeline micro-architectures for loop-and-array hardware pieces, but the total algorithm isn't just this piece -- it's the entire system. This is a problem that has been repeatedly learned in history -- a good example is IBM's computer systems, which didn't always have the fastest processor, but didn't have to. Their architects focused on the entire system -- including the memory and disk subsystem -- which delivered mainframes that outperformed their competition.

Algorithmic design that focuses solely on the loop-and-array areas fails to take into account inter-loop-and-array-block interactions -- and interactions with the rest of the system. You need both the ying and the yang -- and they should be tightly intertwined so that you can easily optimize and match both. System, memory and inter-block interactions are often more important than pipeline choices in sub-blocks. They are not separate -- to treat them so is to be short-sighted.

Unfair advantage

2008-04-09T23:37:00.005-04:00

The results of the 2008 MemoCODE Codesign contest were just released (yesterday, I believe). There were 8 teams with a total of 9 entries -- only one team and entry used Bluespec. No doubt a very strong team -- but the results are stunning. This is the difference between thinking and fluidly expressing architecture and doing RTL. In the hands of a very strong team, you get an especially powerful, mutually-reinforcing combination.

Team ID	Normalized Speedup	Platform	Design Languages
team kermin	1102.4	XUP	Bluespec
team brian	100.2	XUP	C
team marco	85.4	XUP	C + HDL
team uljana	49.8	XUP	C + HDL
team sunita (1)	41.1	XUP	C + HDL
team vijay	33.0	XUP	C + HDL
team rob	23.5	XUP	C + HDL
team eric	12.8	XC2VP100 Amirix	C + HDL
team sunita (2)	11.0	XUP	C + Impulse C

Bluespec Acknowledges DOE and IAEA Probes into its Atomic Transactions

2008-04-01T00:01:00.003-04:00

Apparently when you innovate, people take notice. Unfortunately, this time, it's both the Feds and U.N. showing a bit too much interest in our technology. We're expecting to clear up their misunderstandings quickly, but until then, Bluespec felt compelled to explain the situation and our perspective in a press release today. Please read the complete press release here.

Atomic Transactions in Processors

2008-03-11T22:12:00.003-04:00

Sun's announced their new processor called the Rock. It's the first multi-core processor that uses atomic transactions (the first of many I anticipate) -- specifically, it implements support for transactional memory that is used to support the implementation of atomic transactions.

Atomic transactions are the highest way to specify complex concurrent behavior. Atomic transactions attack the root issue behind what makes hardware and concurrent software so:

Error-prone
Brittle
Complex
Costly to develop and verify

That core issue is managing concurrent accesses to shared resources. This is THE issue in programming multi-core processors -- how do you manage shared memory in a coordinated way? Atomic transactions make it tractable.

MIT Open Source Hardware Designs (OSHD) and Slashdot

2008-02-13T12:51:00.002-05:00

MIT recently launched their website providing some pretty sophisticated, free, open source hardware designs. At this point, they've got three items, though one is a superset of one of the others:

1. HD-quality H.264 video decoder - there are a couple interesting things about this design aside from meeting the performance, quality of HD-quality H.264:
a) The design is about 10,000 lines of code. The C/C++ UNSYNTHESIZABLE reference code for this function is 20K+ lines of code -- this shows how succinct and elegant Bluespec is for datapath intensive designs
b) This design illustrates how you can use Bluespec to parameterize on structure. A single design can generate lots of different micro-architectures -- and all the control logic adapts to the new micro-architecture

2. OFDM transceiver - this one's very cool because it supports both WiFi and WiMax from a single design (and, MIT's working on support WUSB from the same source as well) -- here, it highlights the power of Bluespec to parameterize on differences in functionality

This Sunday, someone posted a link to this site on Slashdot. Fortunately (unfortunately? :>) ), this was indirect to Bluespec so our website didn't get Slashdotted (brought down with the traffic load).

Have fun!

IIT Bombay course taught this week by Arvind

2008-01-11T16:54:00.000-05:00

Prof Arvind is teaching a short course on Bluespec at IIT Bombay this week. Hopefully when he gets back, MIT will start rolling out their open source hardware designs...

HW State of the Art.... Bluespec!

2007-12-18T10:41:00.000-05:00

Mikko Terho is VP and Nokia Fellow at Nokia. According to his bio:

Mikko Terho heads Nokia's Intelligent Connectivity Group which focuses on the development of the innovations and prototypes for pervasive communication devices with novel internet services. He also advices as Nokia fellow other Nokia R&D Groups in the area of system design, software architecture and component selection.

He recently presented at edaForum 07 in Munich. Unfortunately, I don't have access to his slides, which go in detail about results using Bluespec for hardware/software architecture tradeoffs. The title of this presentation was "Are EDA tools for Systems Architecture, ASIC Design or Agile Software Development".

But, I did find a shorter, but recent, slide (mostly sub-) set here. He first shows the current virtual HW/SW world in slide fifteen. In this slide, he shows that RTL/SystemC generation from algorithms and C is "still flaky". Then he goes to the slide I'm quite fond of, slide twenty. This slide is called "HW state of the art". Using Bluespec, the "concept/algorithm" is fully synthesizable into SystemC models for software development and HW for chip implementation.

The funny thing is we just discovered these presentations. Nice surprise!

(On a side, but related, note, MIT/Nokia Research will soon be open sourcing some of the beautiful designs they've done with Bluespec. Currently it looks like H.264 and OFDM for WiFi/WiMax/... will be included in the mix... Stay tuned!)

Faster Chips Are Leaving Programmers in Their Dust

2007-12-17T16:21:00.000-05:00

The NYTimes has this article today about the industry, and Microsoft in particular, needing to develop new languages for parallel architectures. It notes that one of the issues is that there are tasks that cannot be split across processors. This problem is analogous to the one we see in the hardware domain where many hardware designs cannot be automatically parallelized -- this disconnect has made traditional behavioral synthesis a disappointment for many that have tried it. Okay for simple, nested for-loops -- it quickly breaks down for more complex designs, especially ones with control logic intertwined.

In the software domain, they're moving to more explicitly parallel languages -- we advocate the same in the hardware domain. The challenge is picking something that significantly raises the level of abstraction and is still synthesizable with high quality results -- it is just this need that makes SystemC pretty good for modeling, but not great for hardware design.

Another interesting observation by Microsoft's Craig Mundie is that hardware designs are less likely to be homogenous matrices of identical processing elements than hetergeneous, optimized-per-task hardware processing elements.

Microsoft's F# promoting functional languages

2007-12-17T12:59:00.000-05:00

There was an article on Microsoft's F# language in eWeek last month. Microsoft is apparantly going to target those that care about writing software for concurrency and those in scientific/financial/academic/technical areas. It's a functional programming language -- and the money quote (from my standpoint) is:

"It's clear that a bunch of the things in programming that will be becoming more
important over time benefit from a more functional style of programming, like
concurrency, distributed programming and so forth," Torgersen said.

At Bluespec, we not only develop our tool using a functional programming language (Haskell), but we've embodied many functional programming language capabilities for our users to use as well. We're a strong believer in these capabilities -- and have integrated them with atomic transactions for a completely new approach on the hardware side. As I posted before, Microsoft research has been doing some really interesting things with functional languages and atomic transactions -- nice to see us sharing the same technologies with our brethren on the software side.

Alberto Sangiovanni-Vincentelli: The Theoretic Center of Computer Science

2007-12-14T12:47:00.000-05:00

Nikhil came upon this "academic" paper, which seeks to identify the center of computer science from a conference and researcher standpoint. It's written in the form of a serious paper, but doesn't take itself very seriously. It's written by Michael Kuhn and Roger Wattenhofer of ETH Zurich -- it starts on page number 54 of the following link: Column 28, SIGACT News Volume 38, Number 4, (Whole Number 145), December 2007.

In order to find the central 'actor' in computer science, they used an approach similar to that in the mathematics field with the Erdos Number project, by looking at author/co-authorship/references.

And, who do they conclude is at the center of computer science? EDA's own Alberto Sangiovanni-Vincentelli.

Age Determines Technology's Value

2007-12-12T13:43:00.000-05:00

I have been a very delinquent blogger. I recently discovered (a little late to the game) "The Secret Diary of Steve Jobs" (which I find hilarious BTW) -- and, while I know that blog is more a job than a side effort, its multiple entries per day have thoroughly shamed me to get back on the horse.

I've saved up a bunch of items that I obviously haven't gotten to... For some reason I ran across the following article entitled Age Determines Technology's Value. It talks about how people in the workforce communicate completely differently from the latest generation graduating -- and how we need to be more open minded.

I saw parallels to our challenges getting engineers, who are fairly set in existing approaches, to take a fresh, serious look at a new, completely different approach to modeling, verification and implementation of hardware. The problem is different -- but the challenges are similar. Change is hard.

The full series of articles on sequential to parallel programming

2007-09-12T10:41:00.000-04:00

A series of articles is now up by Prof Arvind and Rishiyur Nikhil, our CTO, based on their book on "Implicit Parallel Programming in pH". I had referenced the first of this article series in my last post -- this first article is a great explanation of why it's hard to take a sequential description (a la C/C++) and make it (efficiently) parallel for most hardware and software designs. Here are the links to all the parts on embedded.com:

Part 1
Part 2
Part 3
Part 4
Part 5

Article outlining issues with parallelizing sequential programs

2007-08-18T08:13:00.000-04:00

This article on embedded.com is a great introduction as to why sequential programs are not typically a good beginning if the intent is to parallelize it either as a software program (let's say on multiple cores) or into hardware. This article was written a few years ago as part of a book on parallel programming by Bluespec's CTO Rishiyur S. Nikhil and one of our founders Arvind of MIT.

A lot of people wish that C/C++, given its wide use, could be a specification language for parallel programs or even hardware. A nice thought -- unfortunately, the challenge of automatically identifying concurrency in a sequential software function is intractable for all but a small class of applications (and even with these, algorithms must often be written a particular way for the tools to sift out the concurrency).

This article is a great primer to understand why this is the case. I understand that embedded.com will be publishing more excerpts of this book.

Simon Peyton-Jones's talks at OSCON 2007

2007-08-16T20:28:00.000-04:00

Simon Peyton-Jones gave a few talks that I'm dying to watch when I get a little time. A few of my co-workers (who know him) have suggested he is among the best lecturers they have seen. He gave three talks. There were two that were recorded and available for internet viewing. One provides an overview of Haskell and the other provides an overview of transactional memory for concurrent (parallel) programming. From the Real World Haskell website comes the following summary of the viewership of his lectures now available on the web:

Simon’s Haskell language talks are the most popular of the OSCON videos, and have been viewed over 50% more times than the next ten most popular videos combined.

It looks like my co-workers are probably right. Here's a page with a link to his talks on Haskell and transactional memory for concurrent programming.

Software Transactional Memory - a couple references

2007-07-25T19:29:00.000-04:00

My last post talked about the emphasis on atomic transactions and functional programming for next generation programming languages for multi-core, parallel architectures. Here is an interesting paper talking about software transactional memory (STM) from Simon Peyton-Jones of Microsoft's webpage:

Composable Memory Transactions (about Software Transactional Memory (STM))

There are some additional papers on transactional memory programming on Simon's webpage here.

Wikipedia has a summary, plus some links here.

Microsoft: the Future of Parallel Programming Languages

2007-07-23T19:59:00.000-04:00

There's a great article on the Embedded Systems Design's website, Embedded.com, entitled "M'soft: Parallel Programming Model 10 Years Off". It provides insights into where software languages are going in the future to manage complex concurrency for parallel architectures.

It's personally relevant to me as the two fundamental approaches mentioned in the article are the two foundations for Bluespec (which is for hardware modelers/designers and those building models for embedded software designers and verification).

Citing the views of Microsoft experts in this field, the article is about the need in software development for parallel languages to support future parallel architectures and multi-core designs.

According to the article, there are two main thrusts on defining the future programming language for such software development:

Current thinking about parallel languages falls broadly into two schools. One camp emphasizes functional programming, a style that focuses on mathematical functions and avoids use of system state and variables.

Another approach is emerging around so-called atomic memory transactions, which group many reads and writes into blocks that are executed at one time in shared memory without using traditional locking techniques that can stall other processes.

A high-level hardware modeling and design environment, Bluespec is built fundamentally on the same two things:

* Atomic transactions (for managing complex concurrency)
* Functional programming (for automatically generating and managing structures -- and for extreme reuse)

In fact, in terms of commercially available EDA tools, Bluespec is the only solution that has either of these capabilities in them, let alone both. And, you don't have to wait 10 years for them either!

Cool stuff. It's nice to see further validation of our approach. I like it even better because some of the press/analysts in this space reflexively assume that C/C++ is high level and everything else isn't. What they miss is that while sequential languages are fine for certain math/DSP algorithms -- it's a bad fit and acceptable synthesis is intractable for most other designs. What the Microsoft people are talking about in this article is extremely high-level: functional programming and atomic transactions.

Perhaps seeing software people moving up this way will rub off on journalists/analysts/pundits in the hardware space -- maybe they'll get it better than they have.

There is not much discussion in this article about threads and events as the fundamental basis for next generation parallel programming languages -- why? Threads and events require too much low level coordination to express concurrency. I've had a few previous postings on this:

The Problem with Threads

Ousterhout: Why threads are a bad idea

Auto-Parallelization of C++ is Not a Serious Notion

Next Generation Programming Languages - a Gamer's Perspective

BluDACu - A Bluespec solver and generator for Sudoku

2007-06-04T08:27:00.000-04:00

While our other DAC demos include AXI, AES, transactors, synthesizable testbenches and H.264, and all are running on hardware (both EVE emulation and FPGA), we've got one design that is mostly just for fun. It's a hardware implementation of Sudoku, which we call BluDACu.

The hardware implementation includes both a generator and a solver. The solver isn't a trivial implementation -- the brute force solution would be to guess and backtrack, like a recursive solve. Of course, this type of solution would use a lot more state storage and a lot more power. Instead, the solver is designed to apply tactics like a human -- and, doesn't allow backtracking.

This solution also runs, in both high-speed simulation or on the EVE ZeBu platform (at both our booth and EVE's), together with a software GUI to exercise it and play with it.

It's a very cool implementation -- and a very impressive feat. From our writeup on this design:

So, you might be asking, “Why would anyone create a hardware implementation of Sudoku?” Or even, “What does this have to do with me and what I do?” The simple answer is that we wanted a fun, thoughtprovoking demo for DAC – and, it fit well with an electronic Sudoku giveaway. The more serious answer starts with “we could, and easily, with Bluespec SystemVerilog”, but we’ll get into that a bit later. Most importantly, while this Sudoku implementation is a novelty of sorts, though a very complex one, it nicely illustrates how Bluespec’s ESL Synthesis technology effectively tackles key, contemporary System-on-Chip (SoC) development issues:
How to test software early with accurate hardware representations
How to create intellectual property (IP) blocks that enable extreme reuse because they are highly parameterized and flexible to change
How to quickly implement designs that contain both extremely complex algorithms and complex concurrency, especially those with convoluted control logic and numerous shared resource hazards (it is often assumed that dealing with high complexity is only feasible in software)

If you want to read the source code or the overview of the design, it's all available here.

Nikhil, our CTO, wrote a little song about this design (he's written others in the past). Here it is:

"BluDACu"
(sung to the tune of "Suzie Q", Creedence Clearwater Revival)

Oh BluDACu
Oh BluDACu
Oh BluDACu Baby I love you
BluDACu

I like the way you row
I like the way you col
I like the way you box, I like the way you col
BluDACu

(Guitar solo)

Oh say you´ll parametrize
Oh say you´ll parametrize
Oh say you´ll parametrize to n power two
BluDACu

Oh say you´ll tactic too
Oh say you´ll tactic too
Oh say you´ll tactic too, more than Tic Tac Toe
BluDACu

(Guitar solo)
Oh, BluDACu
Oh, BluDACu
Oh, BluDACu, Baby, I love you
BluDACu

I like the way you row
I like the way you col
I like the way you box, I like the way you col
BluDACu

Oh, BluDACu
Oh, BluDACu
Oh, BluDACu, Baby, I love you
BluDACu

DAC's new program: Wild and Crazy Ideas

2007-05-20T20:40:00.000-04:00

DAC has a new session this year called WACI (pronounced WACKY). I think it's a really interesting session and I'm hoping to get in to see a bit of it amidst my other duties. As I have some inside insight on the genesis of this new session, I asked Steve Levitan, who is the DAC General Chair this year to provide the background:

Credit creative thinking by Bluespec’s Chief Technology Officer Rishiyur Nikhil for Design Automation Conference’s new Wild and Crazy Ideas (WACI) session.

Nikhil proposed this idea to serve as a forum for promising and thought-provoking ideas that are not quite fully formed and I’m delighted to report that it’s come together quite nicely this year.

Surprisingly enough, for a first-time offering, we received 56 papers for WACI and were able to select eight papers. Topics include: “Chip Multi-Processor Generator”; “The Case for the Precision Timed (PRET) Machine”; Quantum-Like Effects in Network-on-Chip Buffers Behavior”; “CAD-based Security, Cryptography, and Digital Rights Management”; “You Can Get There From Here: Connectivity of Random Graphs on Grids”; Line End Shortening is not Always a Failure”; “High Performance and Low Power Electronics on Flexible Substrate”; and “Novel CNTFET-based Reconfigurable Logic Gate Design.”

Innovation is the name of the game at companies that exhibit at DAC. It’s for that reason that DAC is offering a day-long seminar featuring Geoffrey Moore, author of “Crossing the Chasm” and an expert on innovation management. He will join Raul Camposano, chief executive officer (CEO) of Xoomsys Inc., and Jim Smith of Mohr Davidow Ventures, to discuss three phases of innovation at this event meant for global management teams. Topics cover various aspects of innovation, from innovation fundamentals and innovation in the Semiconductor and Electronic Design Automation Markets to investing for innovation. Registration includes entry to Tuesday’s keynotes and the exhibit floor, a copy of Geoffrey Moore’s last book, “Dealing with Darwin,” coffee breaks and the Productivity Impact Luncheon produced by EDA Consortium and Fabless Semiconductor Association (FSA).

Bluespec joins a dynamic Exhibition and Suite floor with close to 250 of the leading and emerging EDA, silicon and IP providers. Don’t miss the opportunity to meet the Bluespec team in Booth #6963.

Please join us in San Diego June 4-8. The WACI Session will be held Tuesday from 4:30-6:30 p.m. The Management Seminar runs Tuesday from 10:30 a.m.-6:45 p.m. Exhibits will be open Tuesday through Thursday.

European versus American openness to change

2007-05-20T20:14:00.000-04:00

I recently started a new book, and it had some interesting observations on the differences between British and American workers. Based on reports, one British industrialist said the following: American "workmen hail with satisfaction all mechanical improvements, the importance and value of which, as releasing them from the drudgery of unskilled labour, they are enabled by education to understand and appreciate."

And this additional observation by another, "Educated up to a far higher standard than those of a much superior social grade in the Old World...every [American] workman seems to be continually devising some new thing to assist him in his work, and there is a strong desire...to be 'posted up' in every new improvement."

These observations may sound a bit dated, and they are. They come from pre Civil War (1861-1865) comments made about America by British observers. At that time, British manufacturing was being held back due to institutional and cultural forces -- many of their systems and approaches were ingrained and institutionalized, and this limited change.

I wonder what regions of the world today are open and closed to change. On balance, we're finding the most aggressive change innovators in India, where managers and engineers understand that they have to move up the value change -- and continue to innovate -- in order to stay ahead and, have much less momentum in existing processes and institutions.

(The above quotes are from "Battle Cry of Freedom: The Civil War Era" by James M. McPherson)

Bluespec Rewrites the Rules for Formal Equivalency Checkers

2007-04-01T14:29:00.000-04:00

Calypto, Jasper, Cadence and Synopsys should be quaking in their boots... Please read the release here. :>)

"Coding up RTL is not the long pole in the tent"

2007-02-26T22:25:00.000-05:00

I just read this comment made by Chiltin of Synopsys at Cooley's DVCon Troublemakers panel last Thursday in EETimes today.

In the sense it seems to be intended, that "design" really isn't that big a deal, I couldn't disagree with the comment more. If RTL coding isn't a significant issue, then why:

* Is it so hard to make changes to RTL once implemented? (When was the last time a spec, feature list, or micro-architecture was frozen solid before RTL coding started?)
* Is it so hard to deliver a quality piece of IP -- AFTER verification has been completed? Is the suggestion that the bugs that were missed were inserted by the verification process?
* Is it so hard to interface to IP blocks? It can't be that control logic is hard to get right -- or, figuring out all the proper conditions under which you interface to a block is easy, is it?

Of course you have to verify every piece to hardware as well as you can. But, if you could code much faster and with many fewer errors, you could improve the ability to:

* Explore micro-architectures faster
* Incorporate changes rapidly and without error
* Interface correctly
* Experience fewer bugs

I've designed chips and overseen chip developments -- almost everything leading up to the RTL coding phase is detailed planning to try to get that phase right, and everything after it is cleaning up the mess. Sure, the "coding" part (at least the initial "coding" part) is relatively quick, but it defines EVERYTHING else.

I've compared current chip design thinking to automotive manufacturing in the 70s -- "coding up RTL is not the long pole in the tent" is similarly suspect thinking... What makes hardware design any different from automotive manufacturing, software development, ...? Quality must be built in -- and with both hardware and software design that's through higher levels of abstraction.

The wrinkle is finding an effective way to do this -- it's straightforward with software (aside from opinions about just which way), but, oh so hard with hardware. The industry, unfortunately, has had too many failed attempts.

Bluespec-Forte on Deepchip

2007-02-15T12:10:00.000-05:00

For anyone following the interchange between Brett Cline and me on Deepchip, John Cooley just posted our design solutions for the "challenge" on his website.

CebaTech's CTO concedes ESL is synonymous with Bluespec

2007-02-08T14:46:00.000-05:00

Was just skimming an editorial by the CTO of CebaTech... He said "... the acronym 'ESL' being synonymous with the acronym 'BS'."

Wow -- nice to get the nod... :>)

Tradesman versus thinkers

2007-01-18T22:13:00.000-05:00

There is a really interesting item on Slashdot debating whether engineers should be tradesman or thinkers -- what should schools be emphasizing? Here's a link to the piece.

I weigh in on the "thinker" side -- technology never stays still. People should learn how to approach problems and understand the underlying concepts and science. If training is too vocational, then learning can easily become outdated -- and, what happens as needs shift within organizations, even when they are not outdated?

One of my favorite professors was Professor Da Rosa who taught the core circuit series of classes in my EE requirements. He summed up the philosophy behind the value of a graduate from my university this way:

* Many engineering grads, those from programs that emphasize vocational/trade style teaching, will start out with some small, albeit positive, net value to the organization -- and this should grow at some ramp rate over time
* Graduates from my school, when they were hired, would be pretty useless. In fact, they'd start initially with a larger negative net value. Why? Because they didn't necessarily know the specifics at the start. But, over time, their value would grow at a high ramp rate and would soon overtake the others. Why? Because you are taught to learn over time -- and have a stronger understanding of the foundations across more disciplines.

Was he right? I don't know, but I always used his speech to justify how useless I was when I started my first engineering job.

This debate is very relevant to Bluespec. I do believe that electrical engineering is less "theoretical" than computer science. EE is closer to pure engineering -- and computer science is more academic/theoretical. But, if you look at what Arvind's doing at MIT with Bluespec, there really is an opportunity to make architecture/hardware design more of a science a la computer science.

There was a time computer architecture was taught more as a history lesson -- then, with Hennessey/Patterson, it was taught with a methodology for analyzing architectures with hard data. What's next? Building and teaching semantics for expressing, exploring and comparing architectures, whether they be processor or otherwise. But to do so, you need a new semantic model that's both high-level and expressive at the same time. Arvind's courses and research focuses on just this.

Moms

2006-11-21T19:42:00.000-05:00

We just recently announced a new addition to our exec team, Charlie Hauck, as VP of engineering. As you might see from the bottom of the press release, there's a mention that a digital photo is available of Charlie upon request. Press will sometimes request a photo for an article -- in fact, for personnel type announcements, local coverage will often include a photo, if available. Hence the motivation for the mention in the bottom of the press release.

The day after the announcement, Charlie laughed and said that his mother saw the press release and immediately contacted Nanette to get a copy of the picture.

Now we just hope his mother doesn't Google... :>)

Are the gloves off?

2006-11-20T21:01:00.000-05:00

In Friday's Deepchip posting, Forte's Brett Cline responded to my previous post on Deepchip. He contends in his post that, with Forte, traditional SystemC can be expressed at just a high a level as Bluespec and be synthesizable. I won't quibble with this contention for "algorithms" (more specifically known as DSP/math algorithms), but I'm just a bit incredulous when it comes to control-based designs, whether that is pure control or datapaths that are complex control-based (such as DMA controllers, processors, memory controllers, ...). We're the only ones that have found a way to both elevate and simplify the expression of control and complex datapaths -- and without removing designers from controlling the micro-architectures so that they can control the quality of results.

Although I expect most people agree with me about traditional SystemC offering an RTL level design environment when it comes to control/complex concurrency, I'm looking forward to responding.

(I was a bit surprised that Brett disagreed with my previous Deepchip posting given his own characterization in an EDACafe interview around DAC timeframe:

Brett Cline (Forte): "When you start writing a design that is 90% control based, where you are writing 'if-then-else', the code you are writing looks a lot like Verilog code. For those customers advancing immediately to a SystemC based design flow or a C based design flow may not provide the same ROI level as the customer who has a mostly algorithmic description.")

Gary's back..

2006-11-10T07:19:00.000-05:00

After the disheartening news of Gary Smith's team at Gartner being shut down, it is great to see that he's started his own research firm. EETimes reported the news this week. Gary's website is www.garysmitheda.com. Except for Daya, I'm not familiar with the rest of the team. It's good to have them back. EDA is whole again.

Rajeev on cheaper chip design & higher levels of abstraction

2006-11-07T21:16:00.000-05:00

Rajeev Madhavan spoke in India about the need to change the cost model for developing chips, as it's gotten untenable to justify many chips today. He was quoted about the need to go up to higher levels of abstraction -- a topic very close to my heart at Bluespec. I agree that RTL's worn its welcome -- chips are too hard to verify and make changes to because we're designing at too low a level. And, I agree that the industry's done little to do this effectively. I don't think it's for lack of trying -- I think it's just so hard to strike the perfect balance.

I've written before about the key aspects that need to be addressed. As a chip designer in 1990, we tossed out the automated datapath compiler developed by our internal CAD group because it couldn't handle the complexity of our datapath. Sure, it was fully automated taking only minutes to run -- but it also couldn't handle adders/barrel shifters/multipliers/... Sounded great on paper! I ended up spec'ing a tool that required a little more guidance by the designer, but delivered perfect results in a day's worth of work for us versus three months of hand layout in our previous project. Sometimes you have to understand what tools can do and what they cannot do. My current company has found the right recipe -- the challenge is overcoming pre-existing prejudices as to what high-level design means and implies so that they'll just take a look at a fresh approach that works.

Deepchip, Cher and me

2006-10-06T19:03:00.000-04:00

For some odd reason I've achieved the distinction of very few, including my company's founder Arvind and rock and popstars Madonna, Prince and Cher. In John Cooley's Deepchip ESNUG post today, the lead summary that links to my email says "George explains his claim that Bluespec is ESL while Forte is RTL". I read that this morning and thought "George? George who?" -- so I can only imagine what other people were thinking. I'll have to check and see how many connections separate Madonna and me on Linked In.

This particular tidbit was the technical part of an email I had sent John earlier that started with a more general point about Cooley's comparison between Gary Smith and his DAC lists. In this technical piece, I was trying to outline why languages don't necessarily equate to abstraction levels. In traditional SystemC (prior to the ESL Extensions that Bluespec's added), the abstraction level you get is based directly on what can be synthesized -- at least when you are trying to implement, and not model, hardware.

For SystemC, you can write tightly nested FOR loops and get decent synthesis results -- but the control related semantics aren't significantly different from RTL. This means that complexity in control description tends to be as hard in SystemC as with Verilog, VHDL or SystemVerilog.

The magic is finding a way to elevate the abstraction level of hardware design that has broader impact than just with algorithms. With SystemC, you get the elevation in algorithms but not much else -- but that doesn't mean you can't do control oriented or complex datapath designs, it's just that you may as well be using Verilog or VHDL.

Hardware complexity is all about complex concurrency and managing shared resources -- nothing simplifies this type of design except rules and interface methods, which allow complexity to scale linearly rather than exponentially with design size.

Panaceas

2006-10-01T21:08:00.000-04:00

There are a few problem areas in EDA where some people expect solutions as though it's just a minor matter of getting the development done. Maybe this is really the case. But I tend to think that people waiting for solutions in these areas are going to be waiting a long time -- and are likely to be unsatisfied with promises made in the mean time. Perhaps it's just that people haven't given a lot of thought to what it'll take to really get these done. I just don't know. Here's a couple that quickly come to mind:

* Fine-grained parallelization of any software implementation

* Ability to take actual hardware implementations (RTL or netlist) and simulate them significantly faster than an RTL simulator can

I'll explore these shortly -- as well as others that later come to mind.

Deconstructing a press release and article

2006-08-22T16:14:00.000-04:00

Whenever I do interviews for an announcement, I anxiously await the articles to see what was captured by the interviewer. This is not the fault necessarily of either the interviewer or the interviewee. Of course, it's our responsibility to get them to clearly understand the message and significance of an announcement -- and, sometimes that's easier than others.

In an earlier blog entry entitled SystemC Interoperability Finally to be Fixed, I had commented on a Summit press release and its associated article from EETimes. In addition to expressing my envy at pulling off what Summit pulled off in terms of coverage and positioning (which has now only increased!), I also poked a little fun at what had been written about, as the article seemed to imply that SystemC IP interoperability would all be solved through the efforts and tools of Summit.

I received the following response by one of the Summit employees. His response clarifies the reality of what was really behind the article and press release putting it into much better perspective. It looks like they've gotten some nice support by people to use OCP-IP interconnect as a rallying point for interworking IP -- though the scope of what they've done is not as broad as portrayed in the EETimes article. (Of course, as I said, my respect (read: envy) only has increased for their EETimes coverage.) Here's Vincent's (of Summit) explanation. It's interesting to read this and then re-read the article and PR:

Well, maybe this comment would have deserved deeper documentation. Of course, the marketing flavor of press releases may not help understanding the real picture behind. Though, let me correct a little bit some of the assumptions and bring my own perspective on this, as a Summit employee, purely technical.

The IPs are integrated in the Summit environment based on the OCP-IP socket library. This is an industry standard used by some big companies. So far, this is the only commonly used standard for IP interoperability. That's why nobody has to 'follow' Summit on this: this is Summit following techniques already in use and based on standards.

The OCP-IP socket library has its limits, they're well known thanks to the experience. But that's, by far, the only open way that is used by more than one ompany in the ESL space to plug different IPs together. Summit is also an active member of the TLM Working Group: this group has for a first objective to address interoperability. When ready, this will be more generic than the OCP-IP library, this standard will help a larger base in the ESL arena. It will not have the limits. When ready, this will be the next good move.

At DAC, Summit just demonstrated a platform with IPs and elements from MIPS, Sonics, Forte, Tensilica, Actis. Since DAC, IBM is added to the list. On the Summit booth (Actis, Sonics) and on their own booth (like Forte), these vendors were confortable presenting this common platform. So this is like this idea of a common interest in following industry (or true) standards has already pleased many actors. Best regards.

- Vincent Viteau, ESL specialist at Summit Design, Inc.

Wish I had gotten this up for DAC...

2006-08-01T13:56:00.000-04:00

Resembling a chicken post-butcher at DAC, I was a bit too busy to put this Q&A online during DAC. I spend a lot of time working with semiconductor companies to clarify offerings in the ESL space -- in particular, as there are a lot of players doing "algorithmic" designs, and no one besides my company doing complex control logic, much of my focus is trying to get my lone voice heard amidst the crowded set of vendors doing algorithmic design. This involves a couple challenges:

* Clarifying what types of problems these solutions attack and why
* Differentiating my company's solution from these vendors, as we are both very different and very complementary

As frustrating as that job is with so many contrary voices, I can imagine it being even more frustrating to differentiate your product as an algorithm vendor. Catalytic is one of the interesting players in this space -- and I thought this Q&A with Larry Melling, their VP of Marketing, was very useful both to educate me, illustrate the types of things algorithmic solutions do, and clarify where they fit. Given the delay in getting this up, I'll give them top billing for a bit:

What's an algorithm?

Let’s start with the definition of algorithm from eeglossary.com: An algorithm is a formula or set of steps for solving a particular problem. Algorithms can be expressed in any language, from natural languages like English or French to programming languages like FORTRAN. Signal processing cover a broad range; things like data compression, encoding, decoding, signal filtering, and image scaling, are some examples. An overwhelming majority of these algorithms are written using MATLAB® by The Mathworks.

What are some typical examples of types of designs your customers would do with your tool?

As you can see from the definition above, DSP algorithms are used in virtually every type of SoC. For Catalytic the segment that seems to be most active in new algorithm development is video and imaging. The push to add multimedia support to portable devices and the expansion of home electronics with HDTV and Digital TV is fueling the need for integrated devices. These devices aren’t just requiring algorithms for image processing, they also require integration of communications algorithms to receive and transmit the images. Because many of these algorithms make use of approximations, the most critical task in the development process is verification of the algorithm and this is usually accomplished by running large datasets through the algorithm to verify the output is acceptable. Because MATLAB interprets M (their language) and is geared toward rapid software prototyping of algorithms, its performance on processing large datasets for verification is typically a problem for customers. Catalytic’s RMS (Rapid MATLAB Simulator) offers a solution that keeps the team working in the powerful MATLAB environment, but gives them faster execution for the critical verification task. The process of quantization is another critical step in preparing an algorithm for implementation that Catalytic improves. Quantization is the conversion of floating-point to fixed-point data types typically needed for implementation. RMS offers a profiler that helps our customers more rapidly assess what type of fixed-point accuracy will be needed for the algorithm. To illustrate the importance of this process the figure below shows the variation of 8, 12, 16 and 24 bit quantization on a FIR filter. This figure is from the article “Coefficient Quantisation and Round Off in FIR and IIR Filters” written by the DSPStore Staff and available on the web at http://www.dspstore.com/$Newsletter/e-newsletters/July2006/Quantisation_Errors.htm.

Where do you sit in the design flow?

Algorithm design and development is almost always done very early in the design cycle up to a point. That point is implementation. Because algorithms are often developed and validated without concern for how they will be implemented (hardware or software), it is common for companies to use algorithm teams to develop this IP and then transfer the algorithm to the implementation team for the SoC and it will be their job to convert the algorithm to hardware (RTL) or software (C-code) to meet the requirements of the SoC. Catalytic products are used in both parts of the flow: for algorithm development and verification, and for algorithm implementation.

Who's your typical user?

Our users fall in two categories: the signal processing scientists and engineers that develop and verify algorithms and the engineers that implement the algorithms.

How do you differentiate your solution from others in this space?

Our differentiation is our technology for processing MATLAB. Catalytic compiles MATLAB giving customers the ability to run MATLAB faster, quantize their algorithm faster and by outputting targeted C code for hardware or software implementation. Catalytic products raise the level of abstraction of the customer’s signal processing design flow from C or RTL to MATLAB.

An even better tradeshow giveaway...

2006-08-01T11:53:00.000-04:00

I liked our giveaway at DAC this year. Unfortunately, we ran out mid-day Wednesday. I had happened upon it while searching for something completely different. It was a blue hand-held fan with an LED strip of seven segments built into the propeller. As the propeller spun around, it flashed slogans. The lines it flashed in succession, before repeating, were:

RTL FLOPS
BLUESPEC
RULES

(Note: we could only do three lines of up to 9 characters, A-Z only, each)

An even better giveway: just like the fan, but much, much better...

While this one was quite popular (and as it turned out we got an unexpected boost due to the unusually warm weather in San Francisco), Steve Allen, one of our senior consulting engineers, found something even cooler (though far too expensive to give away), the PimpStar wheels. These are replacement wheels for your decked out SUV of choice. Just like the fan, the wheels have strips of colored LEDs. However, the PimpStar wheels are much higher resolution and include the full color set using RGB LEDs for fancy pictures. There's a very humorous promotional video on youtube.com showing off the wheels -- I need to get them for my Mini.

Perhaps next year, we'll have to give away a Cadillac Escalade with PimpStar wheels...