( ESNUG 480 Item 10 ) ------------------------------------------- [04/01/09]
Subject: ( ESNUG 477 #10 ) "Working with Bluespec is faster than with RTL"
> I will just say what is the biggest lie in ESL space. It is Bluespec and
> their entourage.
>
> First of all, they are not ESL, because they specify design at the level
> of register transfer, with the exact register/state elements already
> specified by the designer. The only thing they provide are rules that are
> atomic (each rule is an @always block in Verilog except that in Verilog
> you are not guaranteed atomicity during simulation, but in real hardware
> the atomicity is not even relevant because there is no interleaving when
> real hardware executes).
>
> The examples Bluespec shows to designers are contrived. Consider their
> 2x2 switch example, where they model the design by making rules for each
> input rather than what is natural -- make rules on each output variable.
>
> I think Bluespec will never make it, but the company is in denial mode.
>
> - Sandeep Shukla
> Virginia Tech Blacksburg, VA
From: Duraid Madina <duraid=user domain=kinoko.c.u-tokyo.ac.jp>
Hi, John,
I have a huge favor to ask. Don't publish comments about tools from people
who have never used them in anger. I know this isn't always easy to
determine, but a quick check here and there would help your readers sort the
wheat from the chaff!
I use Bluespec for real work. Nothing earth-shattering, but I just got one
2 GHz 65 nm part back in the lab last week and a larger design is scheduled
for tape-out Q2 next year. While I think Bluespec is great, this next chip
isn't going to design itself so I don't have the time to debunk Sandeep's
bogus claims in detail right now.
I do, however, have enough time to say this directly to Sandeep:
uuuuuuuuuuuuuuuuuuuu
u" uuuuuuuuuuuuuuuuuu "u
u" u$$$$$$$$$$$$$$$$$$$$u "u
u" u$$$$$$$$$$$$$$$$$$$$$$$$u "u CONGRATULATIONS, SANDEEP,
u" u$$$$$$$$$$$$$$$$$$$$$$$$$$$$u "u YOU HAVE MISSED THE POINT.
u" u$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$u "u
u" u$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$u "u
$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $ NOBODY CARES WHAT YOU
$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $ THINK OF TINY BLUESPEC
$ $$$" ... "$... ...$" ... "$$$ ... "$$$ $ EXAMPLES INTENDED FOR
$ $$$u `"$$$$$$$ $$$ $$$$$ $$ $$$ $$$ $ BEGINNERS' FIRST FEW
$ $$$$$$uu "$$$$ $$$ $$$$$ $$ """ u$$$ $ HOURS. NOBODY WILL EVER
$ $$$""$$$ $$$$ $$$u "$$$" u$$ $$$$$$$$ $ GIVE A DAMN ABOUT YOUR
$ $$$$....,$$$$$..$$$$$....,$$$$..$$$$$$$$ $ "IT'S NOT FORMAL ENOUGH!" &
$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $ "OH LOOK, I CAN USE A MODEL
"u "$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$" u" CHECKER!" PSEUDO-SCIENCE.
"u "$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$" u"
"u "$$$$$$$$$$$$$$$$$$$$$$$$$$$$" u"
"u "$$$$$$$$$$$$$$$$$$$$$$$$" u" WHAT PEOPLE WANT ARE TOOLS
"u "$$$$$$$$$$$$$$$$$$$$" u" THAT WILL HELP THEM BUILD
"u """""""""""""""""" u" BETTER HARDWARE, FASTER.
""""""""""""""""""""
Until the day comes, John, that Sandeep designs a real piece of HW using
either of the languages he claims Bluespec has ripped off, I think you and
your readers would do well to be very, very wary of his comments.
- Duraid Madina
Tokyo University Tokyo, Japan
---- ---- ---- ---- ---- ---- ----
From: Sandeep Shukla <shukla=user domain=vt got edu>
Hi, John,
No one says that you cannot design using Bluespec. You can design with any
language you want. Certainly if you are willing to work with register
transfer level languages then use Bluespec or any other RTL language with
discipline (use always blocks atomically).
The lie is that Bluespec is ESL, not that Bluespec cannot be used for
writing RTL. Also, the claim often made in press that Bluespec has formal
semantics is not true.
That does not mean one cannot write RTL with Bluespec and do synthesis akin
to logic synthesis with some extra steps.
I am not sure what Duraid designed and why he could not do it with regular
RTL languages.
- Sandeep Shukla
Virginia Tech Blacksburg, VA
---- ---- ---- ---- ---- ---- ----
From: Duraid Madina <duraid=user domain=kinoko.c.u-tokyo.ac.jp>
Hi, John,
I designed a processor core, and of COURSE I could do it with regular RTL.
I did my previous one in Verilog, before I had ever heard of Bluespec.
The _advantage_ of Bluespec is that I could design the processor core
FASTER, allowing me more time to iterate, discover, and make architectural
improvements before having to nail down a spec. That's why I use it now.
One last time for Sandeep: working with Bluespec is FASTER than working
with RTL, because I don't have to worry about all the _unimportant_ details.
I only have to worry about the _important_ details: what data is where in my
chip, what happens to it, and how does it happen.
- Duraid Madina
Tokyo University Tokyo, Japan
---- ---- ---- ---- ---- ---- ----
From: Kattamuri Ekanadham <eknath=user domain=us.ibm got calm>
Hi, John,
I am not an expert on design languages, but I had some recent experience
in using Bluespec and based on that I feel Sandeep's opinion is somewhat
contrary to what I saw.
Our project was to do architectural exploration on a multi-core system,
using a reasonably full-fledged PowerPC processor that must support
multiple threads, sophisticated address translation, caches, interrupts
and the whole bit. The internal challenge was to do this from scratch and
port the design to an FPGA and to boot Linux within one year.
I toyed with the idea of writing this in VHDL for a little while, but I was
not comfortable. Then I picked up Bluespec. It took me several months to
come up to speed with it; after which, I completed a major portion of our
processor design in 6 months and took 6 more months to complete the rest of
our project.
The thing that helped most was the productivity with Bluespec. I was able
to think in terms of abstract structures and I was able to express them more
or less directly (i.e. close to my mental abstractions) in Bluespec. Its
types and the mechanisms to manipulate them were extremely helpful in
expressing complex control schemes in a very concise manner.
Another important thing that helped me was Bluespec's strong type checking,
that enabled me to quickly weed out conceptual errors that I had made in the
initial stages of my design.
The fact that I was able to quickly validate parts by simulation, greatly
improved my design speed and I was able to compose pieces very easily.
Of course it would be of great use for us, if the Bluespec language could
also link up formal methods of proving certain parts correct -- but I knew
that this was not the current goal for the language developers. But I do
feel (and I do have some experience in using formal methods on various
systems) that Bluespec's formal foundations are more amenable to add formal
semantics in the future, than to other design languages that I have seen.
- Kattamuri Ekanadham
IBM Watson Research Center Yorktown Heights, NY
---- ---- ---- ---- ---- ---- ----
From: Shepard Siegel <shepard.siegel=user domain=atomicrules got calm>
Hi John,
I'm a longtime Deepchip reader-lurker: thank you for providing this valuable
service. About a decade ago the center-of-mass of my professional focus
shifted from "classic ASIC/SoC design and verification" to "exploiting
complex concurrency with heterogeneous processors". As such, I glossed over
many of the ESNUG posts about the pick and shovel work of the EDA business.
Then along comes Mr. Shukla's convulsion in ESNUG 477 #10.
I don't know Mr. Shukla, or what motivated his attack against both Bluespec
SystemVerilog (BSV) language and Bluespec, Inc. Bluespec SystemVerilog has
changed my life as a digital designer. Across a half-dozen metrics measured
across multiple projects I have personally seen BSV has:
- reduced time-to-solution,
- reduced weight-of-implementation,
- reduced lines-of-source-code,
- reduced defects,
- reduced energy,
- reduced area, and
- increased throughput.
And for me personally, compared to the tedium of Verilog/VHDL RTLs, BSV has
made the business of digital circuit design immensely satisfying.
I founded my company, Atomic Rules, to monetize the productivity gains one
can reap from using "scalable atomicity" to wrestle the problems of complex
concurrency.
- Shepard Siegel
Atomic Rules LLC. Auburn, NH
Join
Index
|
|
