As the complexity of digital systems increases, so has the need for flexibility in hardware modeling and test environments to support system design. Register-transfer-level (RTL) models have become the overwhelming mainstream for describing IC hardware, thanks to their equivalence to schematic representations and support of a synthesis infrastructure that automates taking an RTL design to silicon. But engineers have also recognized the advantages of higher-level representations provided by behavioral modeling to improve the system-level analysis and concurrent engineering aspects of design.
Asynchronous transfer mode communications systems provide a good example of the trade-offs between behavioral and RTL modeling. This article sets the stage for the use of behavioral modeling as a design methodology in general and then details how behavioral models are applied to the complexity of ATM system design.
Unlike RTL modeling, which is practically de fined as hardware models that have a direct and uniform correspondence to gate-level functions that can be synthesized into silicon, behavioral modeling can be much slipperier to get a handle on. Behavioral models have been defined as:any hardware-description language (HDL) models that are not developed specifically or synthesized; models that describe a design's intent rather than its implementation; HDL models that are used to analyze or evaluate the performance of a system; and models that incorporate abstractions of functionality or coding style as compared with RTL coding to simplify the design representation.
In the ever-changing world of HDL design, even these definitions are elusive. Modeling types and features that are not considered RTL become synthesizable with each new generation of tools. Behavioral models can include a range of modeling types. These include, but are not limited to: Algorithmic functional behavior, where the functionality of the design is described algori thmically, focusing on the data structures and their manipulation, without any specific relation to a given implementation. Bus-functional behavior, where only the functionality and characteristics of the control and interface parts of a design are fully implemented and where data path aspects of the design are abstracted or ignored. HLL callable behavior, where the HDL model is primarily a wrapper for the high-level language (C or other external description) of a design. Performance models, where a model is developed to address only a specific aspect of the design characteristics. A widely used type of performance model is based on queues, which allow modeling and analysis of the statistical properties of a design such as data throughput, delay and latency over large and varying types of data for different levels of bus utilization .
The interrelationship of these model types in one design flow is shown in Fig. 1. The value of having different behavioral models can be seen in several plac es in the design process.
Behavioral models can provide an unambiguous method for communication between the system and hardware design teams in developing ICs. While the long-stated goals of using HDL models as a practical "executable specification" for a design can remain elusive, behavioral models can provide a common representation between the specifications and assumptions provided in system engineering and the requirements of the hardware design. By defining and maintaining key assertions and bounds on the design and maintaining a consistent nomenclature in the development of interfaces from the system down to the partitioned RTL models, behavioral models can be used to both drive and check a system against its original design parameters. (This methodology of course assumes a system community that is conversant in VHDL or Verilog, which is a subject for a different article.)
With the increasing presence of third-party intellectual property in many systems, behavioral models can play a key role, both in integration and determination of the appropriateness of the IP for a given requirement. The RTL of an IP block is often encrypted or mapped to hardware by a vendor to protect it or is too large or complex to be readily understood by the end users, who nevertheless still require functional models. Bus-functional and HLL-callable behavioral models are often used to provide a user with a functional representation that allows visibility into design operation. These models allow system integration and evaluation without revealing, or burdening the end user with, the internal complexity of the IP.
Behavioral models, which are perhaps the most widely used, complement RTL in verifying multiblock systems. In the testing and analysis of a design, having all the blocks integrated at an RTL can produce a logistical verification headache, especially in the typical cases when the blocks are still going through design iterations or when very large amounts of test vectors are being passed through a design. Test development and testing performance is improved when these nonsynthesizable aspects of a design are handled at a behavioral level.
Perhaps the most important consideration in developing a behavioral model is to determine what model parameters and aspects are left out. Is cycle accuracy important? Are the specific details of all the lower levels of functionality really required? Since the advantage of behavioral models lies in simplifying a design, it should be clear up front what areas in a design require simplification, and what simplifications are reasonable and appropriate for the analysis for which the behavioral models are being used.
Although in many cases behavioral modeling does not present the level of detailed complexity of an RTL model, behavioral modeling presents its own types of modeling challenges. Whereas an extensive infrastructure-including libraries, packages and utilities from both electronic design automation and silicon vendors-exists for RTL modeling to facilitate implementing a design in silicon, the support for behavioral modeling is more limited.
Some interesting efforts in behavioral modeling techniques have been developed at a number of universities . Every behavioral-modeling expert seems to have his own package of functions to streamline his work-a situation that may have the potential to lead to a tower of Babel during the integration phase of a project.
Asynchronous transfer mode provides a good example of the trade-offs between behavioral and RTL modeling. At a behavioral level, ATM is fairly straightforward: Bring a packet in; read the header; and use, modify, forward or store the packet based on the packet information and system requirements.
In practice, ATM processing can be extremely complex, both because of the complexities of the processing operations and-equally as critical-because of the coding considerations for efficient implementation to silicon.
ATM systems typically consist of a number of sizable and complex blocks, including ingress and egress logic, header segmentation and reassembly operations, arbitration and quality-of-service functions, and bus interfaces. The abstract block of one such system developed recently is given in Fig. 2.
Each block structurally consisted of one or more FPGAs with external memory. The decision was made to invest in behavioral-model development in order to be able to further explore key system considerations in close synchronization with, but outside of, the critical path of RTL development of the system.
Among the key goals were the following: the formal definition of the system, both functionally and in context of system requirements; analysis of system performance and trade-offs to performance parameters (including amount and types of memory and logic assigned to different functions); modeling of the bus characteristics and performa nce of both internal and external paths to the blocks, which may include a variety of bus interfaces; and functional verification of the system over the large and varying amounts of traffic typical in ATM application.
These diverse requirements are difficult to address purely at the register-transfer level. By leveraging specialization and abstraction of behavioral modeling approaches, different models in an ATM design were developed with specific requirements that were to a large extent plug-and-play, since they were created in a common HDL (in this case VHDL) with a common set of I/O ports.
Each block had its own C-model description, the output of which was integrated into the design environment by a file-I/O-intensive, but otherwise simplistic, model. This C-based VHDL description was used at both ends of the design, as part of the system engineering simulations and as a key part of the verification testbench, to quickly generate large amounts of customized data traffic. Performance models of the ingress/bus control/egress path, along with their associated memory parameters, simplified the process of tracking, modifying and manipulating packets: Each packet was treated as a token, with a corresponding set of associated parameters to the packet header and payload.
Bus-functional models were developed both for the proprietary internal busing structure as well as for the external interfaces and were used to cross-reference the bus functions as implemented in the RTL models. During verification stages, the bus-functional models were also used in conjunction with data from the C-level models to create drivers for the system testbench. The availability of several types of behavioral models had an unexpected impact on the system and hardware design, analysis and verification concurrently performed by different groups. By providing a choice of model types, this had the effect of minimizing the occasions that a single model view was in the uncomfortably visible position of being held up in the critica l path of the entire design.
The effort of creating a set of behavioral models for a complex system is not trivial. The potential advantages of having these models can compensate for the effort involved.
As critical as RTL design is and will remain for the near term, having supporting and corresponding behavioral models will augment the design flow by helping to improve both the performance and confidence level in the overall design process.
 Performance and Fault Modeling with VHDL, Joel Schoen ed. Prentice Hall. ISBN 0-13-658816-6.
Neal Stollon is principal engineer with system and hardware design consulting group HDL Dynamics (Dallas). A professional engineer, he holds a PhD in EE from Southern Methodist University. Stollon has worked at Texas Instruments, DSC Communications, Infinite Technology and LSI Logic.
Copyright © 2002 CMP Media LLC
4/1/02, Issue # 1 4154, page 26.