Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > EDA/IP
?
?
EDA/IP??

Back to the language roots

Posted: 31 Jan 2005 ?? ?Print Version ?Bookmark and Share

Keywords:hardware-description language? hdl? c language?

Before we look forward into the debate over the best hardware-design methoda traditional hardware-description language (HDL) or the C languagelet's look back into the origins of HDLs. To understand which language is better for a specific design task, it's helpful to look at why we use HDLs in the first place and why each particular language was created. The three primary reasons to use an HDL are:

??? Documentation

??? Simulation

??? Synthesis

I bring this up because it will help us understand the languages. All aspects of design are some combination of these root reasons; for example, design reuse is a combination of all three, but primarily documentation.

Both Verilog and VHDL were created in the mid 1980s to fill gaps in the hardware-design process. At the time Verilog and VHDL were created, the main languages for logic synthesis were PALASM and ABEL.

Verilog was created for simulation; VHDL was created for documentation. These simple facts begin to explain why the languages may sometimes present difficulties to synthesis-tool users.

A brief history of time

Neither language is static. They weren't created perfectly with all the features needed. Throughout the last 20 years, both languages have improved. Most notably, VHDL was updated with the IEEE Standard 1164 and VITAL libraries to facilitate simulation while Verilog was updated with the nonblocking assignment for synthesis and the specify block for accurate ASIC timing. Both languages continue to evolve to better serve the needs of designers. Examples of this evolution are the VHDL 93 standard and the Verilog 2001 update, which reduces needless typing with ANSI-style declarations for ports and tasks.

Since logic synthesis went mainstream in the 1990s, the impact on synthesis is carefully considered as features were added to the languages. Advances in best practices, user knowledge, language features, and synthesis tools enable both Verilog and VHDL to generate high-quality practical designs.

Later in the 1990s design complexity increased to the point where Verilog and VHDL weren't sufficient to keep up with design and verification techniques. Techniques like assertion-based verification, transaction-based verification, and constrained random verification became essential for verifying complex systems. With these new techniques came new languages. Several tool vendors came up with proprietary methods for expressing assertions with Property Specification Language (PSL) emerging as a standard. Other vendors working on the simulation stimulus and checking problem developed proprietary languages for stimulus and verification, with "e" from Verisity and Vera from Synopsys emerging as the top two contenders.

VHDL had some advantages over Verilog because of its ability to declare types and to pass more complex types than just a bunch of bits through ports. The Verilog standards bodies within the IEEE and Accellera (the industry consortium behind Verilog standardization) were not standing still after the adoption of the 2001 Verilog Standard; a new standard, SystemVerilog, is on the horizon. SystemVerilog will incorporate many new features likely to accelerate design verification and synthesis. Some of the notable highlights include "interfaces" that allow ports to pass entire complex buses as a single item, assertions, and many of the capabilities available in "e" and Vera. Likewise, the VHDL committees aren't standing still and are adding many new features into that language.

Choosing a design language

Choosing a design language is much more than just a simple choice of languageit's also a choice about an entire design tool flow. You need to consider many related tools:

??? Design-entry tools

??? Syntax-checking and linting tools

??? Automatic and user formal assertion-checking tools

??? Simulators

??? Stimulus generation and response-checking tools

??? Visualization and debug tools

??? Synthesis tools

??? Static and dynamic timing-analysis tools

??? Place-and-route tools

While all designers might not use all of these tools, it's worth noting that the EDA industry has done a great job of providing all of these tools for Verilog, VHDL, and mixed Verilog/VHDL designs. Designers considering using C or C-like languages as a design tool should look at tool support for their language of choice. If their chosen flow starts with C and is then translated or synthesized into Verilog or VHDL, they should realize this multilingual flow might add some additional complication.

Which came first?

In the late 1990s there was a perceived shortage of hardware engineers. Simultaneously, many colleges merged their electrical engineering and computer science departments into electrical and computer engineering departments, fueling the myth that hardware design and programming are equivalent skills. Consequently, a number of EDA vendors and industry pundits proffered the idea of hardware design in C, C++, or Java as a way to use new college graduates to fill the perceived "hardware-design gap."

While many programmers can design simple hardware and hardware designers can write simple programs, being an expert in one does not generally make an engineer an expert in the other. Verilog may have C-like syntax and VHDL an Ada-like syntax, but there are significantly different concepts in HDLs and software programming languages. Most importantly, an HDL adds the notions of concurrency and time.

Many parallels occur between programming languages and hardware languages. Both use a hierarchy of functions, procedures, and tasks as a way to create complex data operations from smaller, more understandable operations. Hardware-design languages and object-oriented languages also share "hardware hierarchy" through the use of instances in the HDLs.

Fundamentally traditional HDLs such as Verilog and VHDL describe hardware, thus their categorization as hardware-description languages. Programming languages such as C and C++ describe programs or algorithms, thus their categorization.

HDLs provide many hardware-centric features not native to programming languages, such as the ability to directly manipulate bits or work with constants in binary, decimal, hexadecimal, and octal of any arbitrary length from a single bit to thousands of bits or more. Programming languages generally only allow limited usage of radixes other than decimal and generally only work with data in a few fixed sizes.

Higher-level modeling

One argument against traditional HDLs is the difficulty in expressing abstract behavioral models. HDLs can be used to express some abstract concepts and model abstract behaviors but may not be the best method to describe and test some algorithms. For more than a decade, system architects exploring alternative algorithms have employed Matlab models or C programs to experiment with their ideas.

Today it's common for architects to explore the design space with spreadsheets, Matlab models, and C programs and then hand off the concept and reference models to micro-architects and RTL (register-transfer level) designers for implementation. One of the key skills experts can employ in the manual algorithm-to-RTL transformation is refactoring of equations and repartitioning functions into more efficient hardware structures. The high-level models from the system architect may express the desired function but may not describe the optimal or desired implementation.

RTL designers and HDLs provide the detail of the desired implementation and can map directly into the hardware. The expert HDL implementer has a strong idea of the desired hardware in his mind as each line of RTL is written. The architect may not have been considering implementation details and may have used complex operations in C or Matlab. Floating-point operations and complex numbers may not synthesize into the desired area or power goal.

Higher-level design

Today some tools can synthesize directly from Matlab such as Simulink and some tools can synthesize from SystemC into RTL or gates such as Cynthesizer. Do these tools spell the end of HDLs or RTL design? If the design is intended for a field-programmable gate array (FPGA) tools such as Simulink can map Matlab to FPGAs. In the case of FPGA design, this is a great solution because if it fits in the FPGA and achieves the desired performance, the design can be done quickly and automatically. Updating the Matlab model and reprogramming the FPGA is all that's needed to implement minor changes in the algorithm.

In the case of ASIC design, the solution is not as simple and straightforward. It's costly to change a fixed hardware implementation such as an ASIC. An automated C-synthesis tool might create a less-than-ideal or inflexible implementation. Extra ASIC gates might translate into unwanted area or power, both of which drive up cost. The fixed hardware solution may incur costly redesign or foundry NRE changes when the algorithm needs updating because of evolving industry standards or new features.

When the design is done using HDLs and good RTL engineers, the engineers have the flexibility to add features and options into the algorithm to allow for some variation in the hardware's usage. If the engineers did a good job, they may have provided enough flexibility to allow the new features or workarounds for limitations in the original algorithms. Because the HDL designers are working closer to the hardware, they can spot little opportunities for enhancement. They might be able to exploit details in the implementation that high-level, algorithm-centered programmers might miss.

Another alternative to fixed-function hardware is to embed FPGAs inside ASICs or to include processors that allow field- or post-production updating of features. As an example, Tensilica promotes the idea of using multiple Xtensa processors to control the data flow through a complex ASIC as a way to simplify implementing complex algorithms in hardware.

Is RTL dying?

Proponents of SystemC, C++, Java, and other programming languages may give the impression that RTL designers are a dying breed. Not so, based on my impressions from talking with two providers of SystemC tools, CoWare, and Forte Systems. Both vendors offer tools to help designers work rapidly from algorithm to detailed design. Both also see their tools as complementary in solving different design problems.

Verilog and VHDL are both approaching their 20th birthdays and are still going strong. The new features going into both languages continue to improve productiveness and extend the life of the languages and their associated design techniques.

Is C out of the question?

C-based design isn't out of the question. There are many good ways to use C as part of the ASIC and SoC design flow. Automated tools from Critical Blue, Tensilica, and Synforia automate parts of the traditional C-to-ASIC/SoC design flow. Synthesis tools from Forte, Mentor, and Celoxica allow designs to be expressed in the SystemC language.

Most industry experts agree that the rising cost of SoC design implies that chips will need to have some programmability to allow field upgrades and other updates to improve the ROI of these chips. This programmability, whether through programmable logic or embedded processors, implies that programming languages will play an ever-increasing role in chip design.

The dead languages

While it would appear C is likely to play an increasing role in hardware design though SystemC, EDA tools, and programmable chips, there's also some road kill from the late 1990s. The Esterel language is also about 20 years old and although it's still occasionally presented at technical conferences, it hasn't ever managed to be more than the subject of occasional research. For serious hardware design, it can be easily dismissed.

Java is still widely in use for Web pages and graphical user interfaces. It wasn't widely supported as a design language by designers or EDA tool vendors and can also be overlooked as a hardware-design language.

Likewise, many proprietary languages have fallen by the wayside. Dable, Endot, Helix, Hilo, and Tegas are a few of the languages of the 1980s that are now long forgotten. Verilog and VHDL aren't likely to disappear anytime soon because of C or SystemC. Looking into the future it's more likely that "e" and Vera will fade away as their features are rolled into future Verilog/SystemVerilog and VHDL 200x versions.

The holistic approach

Going back to the list of tools needed in the EDA design flow before choosing a design language is key. If the language you chose isn't supported by tools in all categories you won't have an entire design flow and will need to finish the flow with a traditional HDL.

Assertions, lint tools, and formal verification (static assertion checking) are becoming a more-important part of the design and verification process since they find problems earlier in the design cycle. It's well known that finding problems earlier in the cycle reduces design time and cost. C/C++ and SystemC don't currently have wide support for these early-phase error-detection and debugging tools. At the ASIC Group, we run RTL code directly from the text editor into Real Intent's Verix to find syntax, lint, and formal errors before a line of code is ever compiled for simulation and synthesis. Using SystemC, we would find simple errors much later in the cycle.

Similarly, we can visualize Verilog and VHDL designs using Novas' Debussy and Verdi tools and quickly debug connections, functions, and assertions. All simulation vendors provide graphical interfaces to debug Verilog and VHDL with their simulators. Support for debugging SystemC and C models is spottier.

Logic synthesis for the majority of Verilog and VHDL constructs is supported by Cadence, Mentor, Synopsys, and Synplicity and widely known and understood by engineers. Synthesis of C/C++ or SystemC is much restricted in terms of language coverage and vendor support.

Once the design progresses to the gate-level and layout stages, you're restricted to the industry standards of Verilog and VHDL, with many VHDL designs migrating to Verilog at the gate level for its broader industry support. Although design is possible in C, it currently doesn't work with all the tools needed in the design flow so it's not likely to replace traditional HDLs. C/C++/SystemC are complimentary to and not a replacement of traditional HDLs.

The proper tool

Verilog and VHDL allow the engineer the detailed control they need to describe hardware. The languages have the broad tool support for all steps of the hardware-design process. Some algorithms may be difficult to express in the traditional HDLs and may be more directly expressed in an algorithm language such as Matlab or C/C++. In these cases the algorithm can be verified in Matlab or C, then the design team must decide if it's appropriate to use automated tools such as Simulink or Cynthesizer for implementation or if the end design will be better realized as embedded processors or custom hardware.

Even when automated implementation tools are used, traditional HDLs will still be employed in the design flow. It's not appropriate to describe the details of a counter in SystemC and it may be difficult to describe the function of MPEG 4 Codec in a traditional HDL, so you need to use the proper language for the design task at hand. Think about that the next time you reach into your toolbox for a hammer to bang in a loose screw.

James L. Lee

President

The ASIC Group Inc.

Courtesy of Embedded Systems Programming





Article Comments - Back to the language roots
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top