Wednesday, December 09, 2009

Nice note today

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.

Thursday, December 03, 2009

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

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?