April 26, 2004
Behavioral Synthesis
Please note that contributed articles, blog entries, and comments posted on EDACafe.com are the views and opinion of the author and do not necessarily represent the views and opinions of the management and staff of Internet Business Systems and its subsidiary web-sites.
Jack Horgan - Contributing Editor

by Jack Horgan - Contributing Editor
Posted anew every four weeks or so, the EDA WEEKLY delivers to its readers information concerning the latest happenings in the EDA industry, covering vendors, products, finances and new developments. Frequently, feature articles on selected public or private EDA companies are presented. Brought to you by EDACafe.com. If we miss a story or subject that you feel deserves to be included, or you just want to suggest a future topic, please contact us! Questions? Feedback? Click here. Thank you!

Last week's editorial was on Electronic-System Level (ESL) Design. Most vendors in this space have products built upon the SystemC language whose development is being managed by the Open SystemC Initiative (OSCI). The language and the organization are described later in this document.

This week's editorial is about Behavioral Synthesis currently being promoted by Forte Design System and Bluespec, Inc. While they disagree on the choice of language (SystemC and SystemVerilog respectively), they see considerable benefits of employing higher level of abstraction in terms of productivity and correct designs. They differ from ESL vendors in that they are targeting the hardware design engineer. They question whether one can make architectural evaluations and decisions like hardware/software partitioning without considering hardware details.

Bluespec point of view is that attempting to synthesize architecture from a high-level behavioral model is an intractable problem. No matter how good the software, it is no substitute for a hardware engineer's intuitions regarding the top level architecture and design choices. In Bluespec, all state elements are explicitly defined by the designer. “We automate hardware generation, not design choices.”

Brett Cline, VP of Marketing for Forte Design, gave the rather trivial example of a function which accepts four inputs (a,b,c,d) and return the results of the calculation.

Y = (a*b)+c)*(d*e)

If one were to use two multipliers, one could schedule the operational sequence to perform the two internal multiplies (a*b and d*e) in parallel, followed by the addition and then the final multiplication. With only a single multiplier, one would schedule the first multiplication, then the addition and second multiplication in parallel, followed by the final multiplication. One sequence would be faster but with more silicon area than the other.

Bluespec discussed with me a more elaborate example of an IP Address Lookup where packets are routed based upon longest prefix match of the packets IP address. They identified three possible architectural alternatives: statically scheduled memory pipeline, straight pipeline with uncoordinated memory references and circular pipeline for 100% memory utilization. Each approach would have different area and speed characteristics. In any realistic design there would be a myriad of choices that would swamp any automated approach. They argue that the hardware designer must direct these choices.

Both vendors offer Behavior Synthesis that generates RTL code - the path to Silicon. Previous attempts in this space, even by major EDA companies, have failed giving the approach a poor image that these companies must overcome.

Bluespec Inc. was founded in June 2003 and soon raised $4 million in VC funding. The company has 16 employees. I interviewed CEO Shiv Taskir, CTO Rishiyur Nikhil and Director of Marketing George Harper. Shiv had been SVP S&M at Viewlogic. The rest of the management team consists of EDA veterans. The technology is based upon patented work by IBM Professor Arvind, who is Bluespec cofounder and board member. Arvind had been CEO at Sandburst but is now back teaching at MIT after a two year sabbatical. The firm has not yet announced a product but there are a number of pilot studies. The marketing plans calls for focusing on Quality of Results by offering proof points for the
technology. Expect upcoming announcements.

At the core of Bluespec's compiler technology is the introduction of the application of Term Rewriting Systems (TRS) to hardware description, the compilation of TRSs to high-quality RTL and formal verification through mathematical transformation ("correct by construction"). Term Rewriting Systems are a well-understood formalism from computer science. A TRS consists of "terms" which describe hardware states, and "rules" which describe behavior. A "rule" captures both a state-change (an "action") and the conditions under which it can occur. As the rules in a Term Rewriting System have atomic semantics, analysis of hardware can be done even though it may be highly concurrent and complex. TRS
semantics and transformations enable the efficient mapping of the input into scheduled, optimized RTL, where control logic is synthesized for correct-by-compiler construction.

The example below explains the concept of TRS but not the actual syntax. A term represents a state element such as a flip-flop or register. Any legal behavior is explainable in terms of a sequence of atomic actions on the state. If there are N rules, a Scheduler analyzes all the rules, determines the ones that satisfy their conditions and fires them in parallel. The atomicity characteristic of the language supports modeling concurrency, thereby eliminating race conditions.

Bluespec employs the SystemVerilog language to create an industry standards-based design environment that significantly raises the level of abstraction for hardware design while retaining the ability to automatically synthesize high quality RTL, uncompromised in speed, power or area.

The Bluespec compiler accepts code based upon SystemVerilog and certain extensions. Some of these extensions have already been accepted by Accellera for inclusion in the standard. Bluepsec will provide a style guide. The compiler will produce cycle-accurate C models and RTL. The RTL may be seamlessly fed into logic synthesis or into simulation packages from third parties. Existing RTL may be accepted by the compiler as called or calling code.

The company rejects the notion that firms should compromise on quality of results in order to gain productivity from use of higher levels of abstraction. They believe that the results of behavior synthesis must approach the results of hand coded RTL in order for hardware designers to adopt the methodology.

Bluespec believes that previous attempts at behavioral synthesis failed because their level of abstraction was too high and that the language used was not accepted within the standard making community. The earlier failures are seen as an obstacle for future acceptance.

Forte Design Systems

The company was formed by the merger of CynApps Inc and Chronology Corporation in March 2001. Headquartered in San Jose, the firm has ~40 people. In April 2003 Forte raised $9 million in series B funding on top of $4 million initial funding.

Using industry-standard SystemC, algorithms expressed in C or C++ can be used as the basis for implementation. SystemC constructs are used to represent hardware-specific features, such as module hierarchy, bit-accurate data types, interface protocol, and reset behavior. Mike Meridith, vice president of technical marketing at Forte Design Systems, serves as executive director of the Open SystemC Initiative.

Forte's Cynthesizer automatically creates an RTL datapath, Finite State Machine (FSM), and control logic to implement the given algorithm. Information from the target technology library is used to ensure predictable timing closure. RTL can be generated in SystemC for simulation or in Verilog optimized for efficient logic synthesis.

High-level directives, such as latency, pipelining, and loop unrolling, are entered in a separate file so that implementations with differing characteristics may be generated without changing the source code of the original algorithm. This capability combines with the automation in the Behavioral Design Workbench to make it easy to create 5, 10, or more fully verified RTL implementations using different micro-architectures to achieve different latency and area characteristics. Cynthesizer also integrates with downstream logic synthesis tools. It produces RTL with a consistent style that is optimized for efficient logic synthesis

By designing at the highest possible level of abstraction throughout the design process, problems with the algorithm or implementation can be found much earlier. For example, it is much easier to isolate, debug, and fix a protocol error at the algorithmic level than it is at the register-transfer level.

Stages of the behavioral synthesis process
Lexical processing parses the high-level language source code and transforms it into an internal representation

Algorithm optimization using techniques such as common subexpression elimination and constant folding

Control/Dataflow analysis yields a Control/Dataflow Graph (CDFG)

Library processing reads the available libraries and determines the functional, timing, and area characteristics of the available parts

Resource allocation establishes a set of functional units

Scheduling introduces parallelism and the concept of time. It transforms the algorithm into an FSM representation

Functional unit binding assigns the operations of the algorithm to specific instances of functional units from the library

Register binding

Output processing writes out the datapath and finite state machine resulting from all of the previous steps as RTL source code in the target language

Brett Cline gives two principal reasons why the use of higher level abstractions had not taken off before. First, there was no need, i.e. firms could produce designs without changing methodology- without moving up a level of abstraction. In last week's editorial on ESL I made the point of “No pain, no sale!” Today the challenge of meeting TTM pressures with increasing complex designs is generating a considerable amount of pain. Second, there was no path-to-implementation, no path-to-silicon from ESL. Brett believes the stating point for new designs is the algorithms, the
functional descriptions, typically written in C or C++. Since Forte's products are based upon SystemC, they provide
a natural progression to RTL. Brett sees Behavioral Synthesis potentially as a huge catalyst for ESL rather than as an alternative.

1 | 2 | 3  Next Page »

You can find the full EDACafe event calendar here.

To read more news, click here.

-- Jack Horgan, EDACafe.com Contributing Editor.

Review Article Be the first to review this article

Featured Video
Senior R&D Engineer...Timing Closure Specialist for EDA Careers at San Jose or Anywhere, CA
DDR 3-4-5 Developer with VIP for EDA Careers at San Jose, CA
Senior Front-End RTL Design AE for EDA Careers at San Jose, CA
Senior Methodology Automation Engineer for EDA Careers at San Jose, CA
Proposal Support Coordinator for Keystone Aerial Surveys at Philadelphia, PA
Upcoming Events
11th International Conference on Verification and Evaluation of Computer and Communication Systems at 1455 DeMaisonneuve W. EV05.139 Montreal Quebec Canada - Aug 24 - 25, 2017
The Rise of Mechatronics at Dassault Systèmes San Diego 5005 Wateridge Vista Drive San Diego CA - Sep 12, 2017
The Rise of Mechatronics at Buca di Beppo - Pasadena 80 West Green Street Pasadena CA - Sep 13, 2017
S2C: FPGA Base prototyping- Download white paper
TrueCircuits: UltraPLL

Internet Business Systems © 2017 Internet Business Systems, Inc.
25 North 14th Steet, Suite 710, San Jose, CA 95112
+1 (408) 882-6554 — Contact Us, or visit our other sites:
AECCafe - Architectural Design and Engineering TechJobsCafe - Technical Jobs and Resumes GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy