vs. C/C++/SystemC

While there many details outlined further below, there are three main reasons to use Bluespec over C/C++/SystemC:

• Bluespec is 100% synthesizable and general purpose, so it can be used for high-level modeling, test benches, transactors, algorithms, control-intensive blocks and system-level interconnects.  And, because they can all be synthesized, you can run all of them in FPGAs at 10s of MHz speeds.  Imagine being able to rapidly develop a model but run it on an FPGA -- and, then imagine being able to quickly refine this model into a high quality implementation.  Bluespec enables all of this -- and C/C++/SystemC doesn't.
  
  What's the long-pole in the design project tent?  Is it just algorithmic blocks or is the complete chip design?  What about accelerating software development and system level verification?  With Bluespec, all aspects of a chip design can benefit, instead of just a few.

Many algorithms benefit from tight, specialized integration with memory subsystems, require control-dependent features, and cannot efficiently be implemented with the limited approaches built into behavioral synthesis tools.

• Bluespec delivers consistently better results in apples-to-apples comparisons.  Bluespec often delivers materially better area results while meeting timing. Bluespec keeps the designer 100% in control of the architecture, while enabling the expression of a single design that supports multiple different architectural choices.
  
  
  • In a recent benchmark versus a prominent C-based synthesis solution, the Bluespec design came in 30% smaller than the C-based synthesis solution.  The Bluespec design was completed with less than half the man-weeks and met timing on the first try in the leading target process technology. 

• Bluespec provides a level of abstraction and productivity that often exceeds that of C/C++/SystemC.  Bluespec's high-level types, interface methods and pipeline combinators, for example, provide a higher level of algorithmic expression than C++ without impacting synthesizability.

A Publicly Available Bluespec vs. C/C++ Benchmark: Reed-Solomon

With well-formed, simpler algorithms, behavioral synthesis tools can compete fairly well.  What about more complex algorithms? What kinds of differences could you expect?  On OpenCores, there is a C++ implementation of Reed-Solomon targeted for C++ synthesis. For this same project, there is also a BSV implementation of the same functionality that can be used as a reference implementation.  We'd highly recommend that evaluations of C synthesis include this C reference design as the starting point for a test case.  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.

More Details Comparing Bluespec vs. C/C++/SystemC:

Bluespec technology is unique in enabling a complete top-down methodology that cannot be achieved with high-level languages such as C/C++ or SystemC.  Bluespec provides the ability to use a single powerful paradigm for your entire design flow, from requirements capture to implementation.  This single paradigm - modular atomic transactions - enables refinement from models to implementation in a continuum.  It allows modelers, architects, implementers and verification engineers to speak a common vocabulary, to reuse components across their activities and to have clean, robust handoffs.

Bluespec allows synthesis at every stage, from high-level models to implementations.  This enables:

• Early identification of resource usage and bottlenecks, early estimates of performance, and more effective and wide-ranging architectural exploration.
  
  
• Very fast execution of models and implementations on FPGA platforms and FPGA-based emulators.
  
  
• Much earlier platform availability for software development.
  
  
• Very fast execution of testbenches on FPGA platforms and FPGA-based emulators, which can dramatically speed up verification.
  

Languages such as C/C++ and SystemC may be useful for developing high-level behavioral models, but then there is a disconnect between the high-level models and the final RTL design. The languages are too distant from hardware, making it difficult for designers to utilize their knowledge about the relationship between source code and good hardware design. The models must be rewritten, to take into account hardware concerns such as power trade-offs, complex clock structures, multiple clock domains, and IP integration. Once the models are rewritten to make resource and structure trade-offs, the RTL will look foreign to the algorithm developer, making the models irrelevant to the final design and making reuse of models unlikely.  Alternatively, with Bluespec you can develop a highly parametrized high-level design which can elaborate into multiple architectures for different performance and power environments. Bluespec automates hardware generation, not micro-architecture choices. 

Bluespec provides:

• A single environment spanning modeling, architectural exploration, verification, and implementation.
  
  
• Synthesis at every stage, from high-level model to implementation, helping identify problems earlier in the design cycle.
  
  
• A higher level of abstraction without obscuring the architecture, making it easier to express behavior and manage concurrency.
  
  
• No disconnect between high-level models and RTL.
  
  
• A complete design environment to easily explore different architectures and trade-offs from a single design.
  
  
• A tool which automatically adapts the control logic to the specific architecture.
  
  
• Better communication between modelers, architects, implementers, and verification engineers.
  
  
• Earlier development of FPGA platforms for software development.
  
  
• A highly parameterized architecture, allowing a single Bluespec design to elaborate into a variety of different architectures.
  

But, aren’t algorithms better implemented in C/C++? Here are some recent quotes on automatic parallelization, the term describing parallelization of sequential code:

“... after 25+ years of research, we are no closer to solving the parallel programming problem ...
... Hence, I do not believe Auto-par will solve our problems”
- Tim Mattson, Intel

“Automatic parallelization? Forget about it, at least for performance-critical applications”
- Akash Deshpande, CTO of system design at ARC

Most off-the-shelf C codes (including the reference codes for all standard codecs like OFDM, H.264, ...) need significant rewriting for C-based synthesis tools in order to get reasonable HW quality. It’s a myth to “just write C code, and the tool will produce (good) hardware”.

And these re-writes typically have to be targeted at the nuances and capabilities of a particular tool.

BSV is very high-level, powerful hardware system design language that competes and typically outperforms C synthesis tools for algorithmic designs – but, BSV is also excellent for system interconnects and control-based IPs as well. Compared to C-to-RTL synthesis, a BSV implementation:

• Is universal (no limitations of “synthesizable subset of C”)
  
  
• Can deal with complex control and parallelism
  
  
• Can result in better quality (area, timing)
  
  
• Match hand-coded RTL with more predictability & in less time
  
  
• Can have fewer lines of source code – an HD-quality H.264 decoder was written in fewer than 10K lines of BSV
  
  
• Can interface easily into SoC contexts

• Can deal easily with crucial systems issues such as:
  
  
  • Optimized memory architectures (caches, prefetching, sharing, configuration, ...)
  • Clock control (power control)

• Can result in more flexibility, maintainability and reuse
  
  
  • Because of more powerful parameterization
    
    
• Can represent a whole family of microarchitectures with different members suitable for different contexts (area, speed, latency, throughput), from a single source code
  
  
  • Because of more powerful parameterization

Bluespec has a rich library (written in, and demonstrating the power of, BSV – they are not built-in and thus can be easily extended) of parameterized microarchitecture combinators that can be used to:

• Enable high-level expression of a design representing a family of microarchitectures
  
  
• Generate, through parameter selection, a different degree of pipelining, parallelism, iteration, resource reuse, etc. And, unique to BSV, Bluespec automatically synthesizes (because of atomic transaction semantics) the control logic for each microarchitecture.