Cover Story

Standards are frequently viewed as hindrances to quick design. Actually, they make automated design easier. The current trend in ASIC design toward complete systems on a single chip is no exception. System-on-a-chip design often involves the use of multiple blocks of intellectual property (IP), or cores, with at least one block written in a different hardware description language from the others. A similar challenge faces IP suppliers who want to offer their products in both standard HDLs, VHDL and Verilog.

The existence of two standard HDLs isn't necessarily a problem for companies with their own reuseable IP doing their own system-on-a-chip designs, because they can choose the HDL they prefer and don't need to mix VHDL and Verilog. But it does have a serious impact on companies providing IP and those who integrate IP modules from several sources. As designs become more and more complex, all companies will likely face such integration issues and be forced to find a cure for the two-language headache.

Seizing an opportunity to increase market share by finding an efficient means of converting VHDL designs into Verilog, a design team at SICAN, one of Europe's largest IP providers, decided to use VHDL2Verilog by Alternative System Concepts (ASC) to develop a new design flow that automates language translation. Developing the new design flow required integrating the tool into the project setup, translating and verifying the code, cosimulating the VHDL and Verilog modules to detect bugs related to language differences, and then translating the VHDL test bench into Verilog. It also called for creating internal standards for coding style--a relatively simple task--to facilitate quick translation.

By automating the translation process, the new design flow cuts design time and allows SICAN to develop IP that supports both VHDL and Verilog.

The dual-language difficulty

In Europe and much of the East Coast, designers prefer VHDL, whereas engineers on the West Coast do most of their designs in Verilog. Many simulators support mixing two languages in one design, but this feature is probably not used very often, because of such traps and drawbacks as long simulation times and different simulation results. In addition, most design engineers have extensive knowledge of only their favorite language. Handling designs consisting of parts coded in VHDL and other modules in Verilog requires the designers to be proficient with both languages.

Instead of requiring mixed-language design and simulation, ASC saw advantages to a single language, and they set out to develop a tool that would automatically translate IP cores from one HDL into the other . Since some designers prefer VHDL and others prefer Verilog, two translators were needed. Although each user has a slightly different design flow, many of the steps are common to all users. However, since some of the constructs of language don't have equivalents in the other language, some translations can't be done automatically. In such a case, the user can either translate manually or change the input so that it will be translated automatically. As we learned, this requires a good deal of cooperation between the tool supplier and the designers using the tool.

Standards play an important role in translating HDLs. The semantics and syntax of the VHDL and Verilog standards allow designers to precisely define the structure of their design. When tool vendors adhere to these standards, designs can be run on multiple simulators. If vendors deviate from the full language and support only a subset of the language, problems can occur. As an IP supplier, SICAN has found that the lack of adherence to the standards can make later support for IP difficult because of simulator differences, even within the same language.

Figure 1	AC-3/MPEG-2 decoder core
The actual production design used in the translation is composed of numerous IP blocks.

The AC-3/MPEG-2 audio core

SICAN provides its IP, called Designobjects, mainly for the fields of multimedia, networking, and interfacing. As a European company, it usually develops IP using VHDL. With an increasing number of customers in the United States, the demand for IP coded in Verilog grew, and the company needed a way to transfer the VHDL building blocks into Verilog. As a result, it introduced a new design flow that was first used on a combined AC-3 and MPEG-2 multichannel audio decoder.

The AC-3/MPEG-2 core is a highly modular adaptable audio decoding engine (see Figure 1) serving applications ranging from high-end 5.1-channel Dolby Class A DVD players to low-cost set-top boxes. It can be tailored to support either or both audio compression algorithms. The number of channels can easily be switched from full 5.1-channel to basic stereo support, including the appropriate down mix. Parts required for both algorithms are implemented in the decoder core only once, whereas specific components are implemented separately as needed. This approach reduces the overhead for supporting both algorithms and makes it possible to easily modify the decoder's feature set. The VHDL source code base, including the test benches, consists of about 60,000 lines of code, not including comments. The overall design consists of some 65,000 to 70,000 gates for the high-end Dolby Class A AC-3 and MPEG-2 5.1-channel configuration. Test benches are available for top- and second-level modules.

Translation design flow

Translating a code base of this size can be split into three major tasks. First, the original sources have to be initially translated into the other HDL. Next, the results of the translation have to be verified to prove that the translated code is functionally equivalent to the original. And finally, as an ongoing process, the two source code bases have to be maintained and kept synchronized. SICAN wanted the new design flow to cover all three tasks and at the same time minimize the effort required to perform the translation.

The first step in setting up the new design flow was to select a translation tool. After evaluating several tools, SICAN chose VHDL2Verilog because it best supports the VHDL language subset used for coding Designobjects. The support even includes advanced VHDL constructs, like records used for modeling module interfaces in the AC-3/MPEG-2 Designobject. Also, the tool can easily be controlled from a command line and can therefore be called from scripts. Using scripts eases integrating the tool into an automatic translation and verification environment.

The second step was to integrate the tool into a typical project setup. The main goals here were to modify the general setup as little as possible and to seamlessly integrate the new translation and two-language simulation. The whole test bench therefore had to be translated and integrated into the overall verification flow (see Figure 2). An important advantage in this step was the ability to recognize entire processes, instead of attempting to translate line by line, as do some translators.

SICAN's designers performed the translation and verification in several steps. Starting from a VHDL module and test bench, they first translated the module using the automatic translator. Then they patched the translated Verilog module with some information that isn't available to the translator. The patches consisted mainly of appending some include directives with perl and shell scripts, based on the design's hierarchy.

If the translator's reported error messages were caused by unsupported VHDL constructs, the designers modified the VHDL source until it was translatable. The modifications applied to the VHDL were more or less mechanical replacements of unsupported syntax by supported constructs in a very local scope. They had no influence on the modules' architecture or on intermodule communications. In addition, while performing the first translation, they developed a coding style guide that incorporated what they had learned in making the modifications, to provide helpful rules for new designs to make them translatable.

Figure 2	Verification flow
It is insufficient to translate only the design. Instead, verification must include test bench translation and verification in the second HDL.

The designers then cosimulated the translated Verilog module in the VHDL test bench environment to detect bugs related to general differences between the two languages and the behavior of VHDL and Verilog simulators. The two main problems found during the cosimulation phase were translating VHDL signal assignments into Verilog's blocking or nonblocking assignments and handling the VHDL signals and variables in a local scope. Those problems can easily be avoided in the future by following a few simple coding style rules.

When cosimulation produced the same results as the pure VHDL simulations, the next step was to translate the test bench. This step is similar to translating the module itself. However, because in general VHDL is a more robust language, the test bench architecture should also follow some basic guidelines to avoid using advanced VHDL constructs for which no Verilog equivalent is available.

In the general test bench structure, the module under test is surrounded by two different types of stub modules (see Figure 3). The first type is responsible for feeding the input interfaces of the module under test, and the second type checks the output signals of the design during simulation. The generated log file is automatically analyzed, providing an instant indication of whether or not the design has passed the test. Both types of stub modules are fed by file I/O. The input stimuli files and the output reference data are generated by C models.

This approach has several advantages when translating a design into another HDL. For example, the test bench is a simple structural connection of the design and the surrounding stub modules. No test information is coded in the test bench itself; instead, it's implemented in the bit-accurate C reference model, which is HDL-independent. The test bench can also be translated as easily as the structural connection of separate modules belonging to the standard repertoire of each translator.

Whereas VHDL supports advanced file I/O features, Verilog's means for handling files are basic and far simpler. Verilog simulators can be extended by a standardized PLI. Encapsulating the file I/O handling tasks into VHDL functions, the Verilog simulator can be extended by analogous PLI routines. Since all stimuli and reference data files are built using the same patterns, only a very small set of functions is required for handling the data input, and this set has to be coded using the PLI. When the designers had translated all the test bench elements, they could execute the final pure Verilog simulations.

Results and lessons learned

SICAN's designers fully integrated all the translation steps into the project environment, which consists of a common directory structure for all second-level and top-level modules; a set of makefiles for handling dependencies between the different files; two C models for generating stimuli and reference data for both the AC-3 and the MPEG-2 decoder part; test streams; and a set of perl and shell scripts for translation, data generation, and simulator invocation.

They modified the VHDL code following a few simple coding style rules so that about 99 percent of the Verilog code could be generated automatically. Keeping the two code bases consistent requires simply applying changes to the VHDL and starting the retranslation of the modified code. Using makefiles for controlling the translation guarantees that all modifications to the VHDL are also applied to the Verilog code.

Verifying the Verilog version requires the same verification strategy and project setup. Switching between VHDL and Verilog is done by setting one environment variable and running the same simulations as for the VHDL code.

The designers checked the correctness of the translated Verilog code by running gate-level simulations with gate-level netlists produced from both VHDL and Verilog RTL code by Synopsys Design Compiler. The gate count that resulted from synthesizing the VHDL and Verilog versions varied less than 0.5 percent.

Figure 3	Test bench architecture
A generic approach to the test bench makes it useful for other designs. Only the test data stream needs to be tailored to each module or design being tested.

Thanks to a great deal of cooperation between the design team and the vendor, ASC was able to extend the functionality of the tool based on the SICAN's application and thereby speed setup time. Using the new design flow, SICAN's designers are able to retranslate the AC-3/MPEG-2 audio decoder in less than a day. What's more, they can adopt existing designs to the new design flow by checking against the coding style guide, and they can make them new designs easily translatable without any significant overhead by following the coding style rules from the very beginning of the coding phase. The new design flow reduces the tasks of applying changes and keeping both language versions consistent to using a simple push-button retranslation and running the appropriate simulations with both versions.

Jake Karrfalt is the founder, president, and CEO of Alternative System Concepts, Inc. in Windham, N.H. He has 30 years' experience developing computer architectures.

Thomas Oberthür joined SICAN GmbH (Hanover, Germany) in 1993 and works as project manager for digital audio applications. He is responsible for turnkey ASIC designs and concentrates on IP development, design reuse, and design flow issues.

To voice an opinion on this or any Integrated System Design article, please email your message to miker@isdmag.com.

integrated system design  April 1998