ARCHITECTURAL SYNTHESIS AND DESIGN RE-USE

by

Marc Van Canneyt (marc_vancanneyt@frontierd.com)

Vice President of Business Development, Frontier Design, Inc.

ASIC gate counts have grown so phenomenally in the last decade that designers cannot keep up with their complexity. The issue is no longer whether a single IC has sufficient resources to accommodate a system-level design. Rather it is how are designers going to keep up with the increased complexity.

The answer to this question is re-usable intellectual property. The only way designers will be able to fill up the available silicon is to use previously developed blocks of functionality that can be modified and re-used to meet the design requirements. As a result the roles of system and ASIC designers are converging.

While most SOC and ASIC designers are now using an HDL-based design methodology, they encounter great difficulties when they interact with the system designers in their companies. System designers typically deliver a specification in the C-language, which has been simulated extensively with internal system level simulators or commercial products like SPW (Cadence), Cossap (Synopsys) or HP-ADS (HP EESOF). The hardware designer must rewrite the spec at least once in VHDL or Verilog, assuming the spec already was delivered in fixed point. If the spec did not support fixed point math, the designer will be forced to rewrite the code twice: a first time in fixed point c, so that he can verify the correctness of the fixed point behavior in the original simulation environment and then in VHDL or Verilog for the final implementation.

After all this trouble, the design is not truly "re-usable". HDL-based designs can be re-used as-is, but they are very difficult to modify because they are typically architecture dependent. The system resources (RAM, ROM, adders, multipliers, registers, etc.) have already been decided upon at the time the HDL description was created. They are explicit to the design. Even a minor modification of an HDL-based design is likely to result in an architecture change. It may need more registers or adders or it may need fewer registers and less RAM. In any case, it will be different than the original architecture and since the HDL is an architectural specification, it will have to be substantially re-written.

The problem of design re-use is particularly troublesome with designs that are highly parameterized. For example, a particular type of channel decoder may be appropriate for a wide variety of applications, but different applications may pose different throughput requirements.

Changing coding parameters of a Reed-Solomon or Viterbi coder, requires that the design be pretty much re-done from scratch, even though the overall algorithm does not change at all. In reality, the original code is only about 1/3 re-usable. The inability to easily modify an existing design plagues all HDL-based designs.

The solution to design re-usability is to keep the designs at the behavioral C-language level. Changes are very easy to make and validate, because C-language simulation is several orders of magnitude faster than HDL simulation. Since the source remains in C-code, design modifications can be shared with system level designers to ensure that the design's behavior conforms to the original specification.

However, very few hardware designers use this approach because the problem is that neither C-code nor behavioral modeling is well supported in hardware design-flows. Hardware design is typically performed at the RT-level, using VHDL and Verilog languages. Today’s ASIC designers have gotten so good at writing designs from scratch in Verilog or VHDL that they rarely even bother with the C-language. Unfortunately, this approach leaves them with questionable design re-usability and allows them little room to use their creative engineering skills to try various architectural approaches.

At first glance, using C provides so many advantages that one wonders why it hasn’t been used all along. The answer is that, until now, converting a C-language design to a synthesizable HDL description has been a time-consuming process that has had to be done entirely by hand.

For starters, the C-language does not really support fixed-point math, which is required for HDL descriptions. Designers must generally handle fixed-point math using an ad hoc, trial and error process that is time-consuming and error prone. Test benches have to be generated to ensure that the HDL design performs the same way as the C-level design. Until recently, there have been no EDA tools that support this type of C-based design flow. However, new EDA tools that convert C-language designs to Verilog of VHDL, such as those from C Level Design and Frontier Design, have addressed these issues.

For example, Frontier Design's A|RT Library tool allows designers to write bit-accurate, fixed-point descriptions using standard ANSI C - a language that virtually every designer already knows. A|RT Library is the only fixed-point design tool that lets designers accurately model the quantization and overflow effects that invariably occur when fixed-point math is used. Since these types of errors can adversely affect system behavior or even cause a catastrophic failure, accurately modeling them is required to maintain system behavior. A|RT Library also provides analysis tools that allow designers to optimize the fixed-point design at the C-level.

Another tool that supports a C-language design flow is A|RT Builder. A|RT Builder eliminates the problem of going from C to Verilog or VHDL by automatically translating RT-level C-language models to equivalent synthesizable VHDL or Verilog models. This allows designers to perform their detailed RT-level design at the C-level, generate a synthesizable, bit-accurate Verilog or VHDL description quickly - less than a couple of minutes in most cases — synthesize the design and analyze the results for die size, power consumption and performance. Since C-language simulations are several orders of magnitude faster than HDL simulations, the designer has the time and freedom to try multiple approaches until the best solution is found.

The tools described above do not yet allow the use of behavioral models. This is because most logic synthesis tools are HDL-based and don’t accept the more abstract and more flexible behavioral models. These logic synthesis tools only work with architecture-dependent RT-level VHDL or Verilog. This means that even using a C-to-HDL conversion tool, such as A|RT Builder or C-2-Verilog, designers must write RT-level C code in order to get an HDL model that can be used by today’s logic synthesis engines. The relatively greater architecture dependence of RT-level designs necessarily restricts their re-usability.

However, in spite of the fact that RT-style C-models are more architecture-dependent than behavioral C-models, even RT-level C greatly enhances design re-usability. The ability to create bit-true fixed-point C-language designs and quickly convert them to "what-you-write-is-what-you-get" Verilog or VHDL enables designers to at least keep their source designs in RT-level C-code. Although, not as flexible as behavioral C, RT-level C is substantially more practical to modify and re-use than an HDL. C-language cores developed with the A|RT tools, for example, are quickly customized to the specific design requirements, simulated at the C-level, converted to an HDL and then synthesized.

However, re-use could be raised to a much higher level if the source design could be made more architecture-neutral by keeping it at a behavioral level. To support this higher level of abstraction, additional tools must be provided that allow a designer to map behavioral source-models of his/her IP to a particular architectural implementation. This approach also significantly enhances the design creativity by the designer by making it easy to try a variety of architectural options to develop highly optimized silicon implementations of SoC designs. With this approach, the wealth of C-language models that already exist in systems groups and software houses, could be easily re-used and converted to silicon, as well.

New EDA tools support behavior-based design with architectural synthesis. Architectural synthesis is similar to behavioral synthesis in that it tries to help the designer to achieve an optimum architecture from a behavioral description of the design. However, the similarities end there.

Architectural synthesis was pioneered by Frontier Design. It is based on technology that was developed and matured over the last decade by Frontier and its predecessor entity, EDC (European Design Center). It is derived from the same technology used in Frontier’s Mistral EDA tools.

Frontier Design's architectural synthesis tools are interactive, allowing the designer to make decisions about resource allocation, resource assignment, scheduling of operations, and resource sharing. Behavioral synthesis typically has a more "black box" compiler-approach that tries to solve the entire design with only minimal input from the designer, such as clock speed, program steps and resource budget. This approach, although attractive at first sight, results in three types of problems: 1) the designer has limited control over the resulting design; 2) if the design becomes larger than 1,000 operations, the number of solutions is so large that the process can take hours or days; 3) the solution finally arrived at may be very far from the one the design had in mind.

Interactive architectural synthesis, on the other hand, gives the designer more direct control over the architectural parameters, and lets him/her drive important parameters, like resource allocation, resource assignment and scheduling, in a very detailed way — without touching the source-code. This also takes an enormous load off the architectural synthesis engine, so a result is achieved in a few minutes rather than hours or days. Because of the speed of the tool, the designer has the time and freedom to explore a variety of architectural options to achieve a design that is highly optimized for the application.

By using interactive architectural synthesis, various architectures for a given behavior can be explored quickly, so designers can achieve a solution that is highly optimized for silicon, performance or power. For example, using two ALUs instead of a single ALU might increase the system throughput without appreciably increasing the die size, so that the system could have higher performance. Or, the higher throughput could be exploited by slowing the clock to reduce power consumption, while maintaining the same performance. Optimizing the design at the architectural invariably results in substantially greater improvements in the silicon implementation than can be achieved by optimizing at the HDL-level, which is typically carried out during synthesis.

Over the years, the architectural synthesis technology and early versions of these tools have been used to develop systems-on-a-chip for National Semiconductor, Sony and Phonak. The power of this methodology is evident in the highly optimized nature of these SoC designs. The Phonak chip, for example, includes all of the signal processing functionality of a high-end digital hearing aid, performs 400 MOPS at 2 MHz and consumes only slightly more than 1 mW. These types of results validate the interactive architectural synthesis methodology.

		Click here to get your listing up.