( ESNUG 458 Item 2 ) -------------------------------------------- [11/16/06]

Subject: ( ESNUG 457 #4 ) Brett trashes Bluespec and their "BS Compiler"

> Contrast the succinctness and level of details in these equivalent Forte
> and Bluespec code fragments.  And this is a simple example!; more complex
> algorithms would show an even wider diverging levels of complexity. ...
> This is where Bluespec shines.  Everything else is just RTL.
>
>    - George Harper
>      Bluespec, Inc.                             Waltham, MA


From: Brett Cline <brett=user domain=forteds got calm>

Hi, John,

First, let me say thanks to George for scouring our website and finding a
2.5 year old example to try to pick on.  Our Cynthesizer technology has
obviously progressed, though we still support the coding style in that
paper.  Second, in his "apple-to-apples" comparison, I found it interesting
that George chose to write System Verilog instead of SystemC - and you
didn't even call him on this, John!

George's example is picking on a specific piece of code in this paper
defining the interface between two blocks.  In reality, this capability is
necessary as many complex SoCs require new design blocks, such as those done
with Cynthesizer and SystemC, to interface with existing legacy RTL in
Verilog.  Forte's methodology make this very easy for the customers.  You
can use the coding style referred to in the application note to implement
any interface quickly.  And, because it's all standard SystemC and C++, it
will work with any vendors' tools -- not only ours.  This is handy for using
SystemC simulators, linting tools, synthesizers, or one of the tools from
the 30+ vendors who support SystemC.

Another way our users deal with complex communications between internal or
external modules is with our CynWare interface IP library - all in standard
SystemC.   For example, our cynw_p2p (point-to-point) protocol shown below
has all the features that George showed in his example, and more.  Here's a
concrete example of what you can do with Cynthesizer today with fully
untimed SystemC/C++ code.

  SC_MODULE(sender)
  {
    cynw_p2p<T>::out output_port; // T could be any data type
    ...
    void thread1() {
    T value;
     while (true) {
        // untimed functionality and calculations...
        output_port.put(value); // guaranteed synch transfer of data
      }
    }
  };

  SC_MODULE(receiver)
  {
    cynw_p2p<T>::in input_port;
    ...
    void thread1() {
    T value;
     while (true) {
        value = input_port.get(); // guaranteed synch transfer of data
                                  // for untimed calculations...
      }
    }
  };

The important point here is that the amount of code you have to write is
determined by the level of abstraction supported, and Cynthesizer supports
just as high a level of abstraction as Bluespec.  That's because Cynthesizer
can take advantage of the abstraction capabilities of SystemC, giving it
power and flexibility in a standard language.

One difference that's important to point out in our example is that the
cynw_p2p interface can be simulated as TLM or protocol accurate with no code
modifications.  This allows our user to run the design at a very high speed
for integration with the rest of the system including software, or run at
slower speed with full cycle accuracy.

In addition, our protocol supports automatic handling of pipeline stalls
without data loss, stall propagation in chained modules, FIFOs, multiple
parallel channels and so on.  We provide a whole range of interface IP, and
are actively working on more, including standard bus/network interfaces.

All of this is done in standard SystemC, without any need for special
Bluespec languages, preprocessors or simulators.  And it is also synthesized
to efficient hardware by Cynthesizer.  Furthermore, to change the interface
protocol (and the resulting RTL code executing that interface protocol) all
one has to do is change the declaration.

This is pretty common stuff for our customers, like Sony, Toshiba, Ricoh,
Sanyo, Epson, OKI, and others.  These customers have completed at least 18
production designs including more than 130 design blocks.  Contrary to
George's wishful thinking that Forte's Cynthesizer only does "pure DSP", he
would realize that these customers are doing designs that contain both data
path and control path based designs as well as DSP -- stuff like HDTV,
network security, set top box, wireless LAN, USB 2.0, serial ATA, and more.
From your own recent EDA census report, John, we have:

   "So far we have completed 5 modules using Cynthesizer, and 4 LSI's.
    With it, we consistently achieve a 1/3 decrease in the overall design
    time compared to hand-coded RTL.  For example, for a recent LSI
    design we had a 17 month LSI development time, which we were able to
    reduce to only 12 months using Cynthesizer!  Oki has a wide variety
    of algorithms to implement in a very short time period, so this is
    an important advantage."

        - Kazuhiko Maki of Oki Electric
          http://www.deepchip.com/items/else06-06.html

So, John, I hope this letter illustrates some of the reasons why people are
picking our Cynthesizer for real hardware & system design and not George's,
seemingly appropriately named, "BS Compiler".

    - Brett Cline
      Forte Design Systems                       Acton, MA
Index    Next->Item







   
 Sign up for the DeepChip newsletter.
Email
 Read what EDA tool users really think.


Feedback About Wiretaps ESNUGs SIGN UP! Downloads Trip Reports Advertise

"Relax. This is a discussion. Anything said here is just one engineer's opinion. Email in your dissenting letter and it'll be published, too."
This Web Site Is Modified Every 2-3 Days
Copyright 1991-2024 John Cooley.  All Rights Reserved.
| Contact John Cooley | Webmaster | Legal | Feedback Form |

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)