Operating in a Mixed-language Environment Using HDL, C/C++, SystemC and SystemVerilog

Transcription

1 Application Note Operating in a Mixed-language Environment Using HDL, C/C++, SystemC and SystemVerilog

2 Introduction C and C++ languages have an important role to play in ASIC design, and using these languages can significantly increase designer productivity. However, C and C++ cannot be used entirely alone; they must work together with conventional HDLs (VHDL and Verilog), to create a mixed HDL and C/C++ environment. The key to success when employing a mixed environment in ASIC design is to choose and use the language that offers the most effective abstraction level for the task at hand. Traditionally, Verilog and VHDL have proven to deliver the best solution for describing hardware, because they provide an efficient abstraction for level- and edge-sensitive registers and clock logic, arbitrary logic gates and larger elements of clocked logic arranged in parallel. C and C++, on the other hand have been used for years to describe higher-level system design, and to describe and implement new algorithms. System architects use C models to evaluate new architectures without regard for implementation details, such as timing and hardwaresoftware partitioning. Recently, SystemC was developed as a useful way to bridge the gap between what has been done traditionally with HDLs and what has been done in C. SystemC has all the architectural capabilities of C (because it is C), and adds class libraries that allow HDL concepts to be included, such as a time domain, event scheduling, clocks, concurrent processes, etc. Using C as the Design Specification One of the main advantages of describing a design in C is that the C language is very powerful and easy to implement complex objects. In addition, the designer can compile it into a standalone object and quickly run it and evaluate the results. Quick turnarounds can be made and reevaluated on the fly. More important, however, is the fact that the resulting C model can be used for equivalency checking between C and RTL. Once a golden C model is decided upon, HDL designers can begin the task of implementing it in RTL HDL. Viewing the C model as a specification is, in fact, becoming common. In practice, the C model can be used to generate tabular data files that can be compared to the output of the RTL design at any intermediate partition in the design. The strength of this method is its ability to automate the comparison of large numbers of pointed regressions or extended randomized tests. A simulation log can be maintained to show precisely which test failed and what conditions caused the error. An important limitation arises, however, due to the need for cycle accuracy in the C model a specific set of assignments in the C model must map directly to a single clock cycle in the RTL model. Since a clock cannot be readily generated in C, care must be taken to ensure that all appropriate dependencies are considered when ordering execution events. This need for cycle accuracy is especially apparent when modeling asynchronous boundary behaviors. Many designs prioritize transactions according to internal events that cross clock domain boundaries in the design. Unfortunately, this can cause perfectly valid outcomes from the RTL design to appear out of order according to the predictive C data. Interfacing C to VHDL Interfacing C code to Verilog and VHDL can take many forms some ad hoc and others operating under a standard. A standard interface for connecting C modules or functions to VHDL code is defined in the IEEE standard. The most commonly employed method under the standard is what are known as foreign architectures. These special VHDL architectures do not have any executable VHDL code in them. Instead, they contain a link to executable C code. At the beginning of the architecture, a foreign attribute declaration appears, such as: architecture foreign_arch of my_module is architecture foreign of foreign_arch: attribute is init_func file.so ; begin end; 2 Operating in a Mixed-language Environment Using HDL, C/C++, SystemC and SystemVerilog

3 As you can see, there is no code between the begin and end statements. The standard also specifies that if there were code between the begin and end statements it would not be executed. The C code referenced by the foreign attribute declaration is called whenever this architecture needs to be evaluated such as when one of the ports is responding to input changes on the entity. Although most simulators require the same basic information to connect to the C code, the actual string for the foreign architecture specification is simulator dependent. ModelSim uses the form init_function object_file. The (init_function) is the name of the function in the C code that the simulator calls when the design is being loaded into memory (elaboration). The object_file referenced in the string is the name of the compiled and dynamically linked C code. An important note is that the IEEE standard does not define the actual procedural interface between the C and VHDL; only the definition of the foreign architecture is defined. Hence, C code is not portable between VHDL simulators. Interfacing C to Verilog The C interface for Verilog is quite different than VHDL and requires more of the designer, who must create an almost-empty module that has the single, simple task of calling a user-defined system task that is implemented in C. An example of Verilog interface code is: module my_module ( <my_ports> )... $my_task( <my_ports ); endmodule The C code that interfaces to Verilog is defined and standardized by the IEEE 1364 standard and is called Verilog PLI (Programming Language Interface). Using the code example above, the PLI defines a mechanism in the C code to specify which function to call when $my_task is evaluated. To enhance designer productivity, many simulators now include convenient shortcuts to simplify this mechanism. Unfortunately, these short cuts are not portable across all simulators. Verilog s interfacing method is clearly more complex than the interface between C and VHDL. As an example of this complexity, the code below is the C structure that must be implemented to interface C code to Verilog. typedef int (*p_tffn)(); typedef struct t_tfcell { short type;/* USERTASK, USERFUNCTION, or USERREALFUNCTION */ short data;/* passed as data argument of callback function */ p_tffn checktf; /* argument checking callback function */ p_tffn sizetf; /* function return size callback function */ p_tffn calltf; /* task or function call callback function */ p_tffn misctf; /* miscellaneous reason callback function */ char *tfname;/* name of system task or function */ int forwref; char *tfveritool; char *tferrmessage; int hash; struct t_tfcell *left_p; struct t_tfcell *right_p; char *namecell_p; int warning_printed; } s_tfcell, *p_tfcell; In addition to defining a mechanism to interface C and Verilog, the PLI also defines and standardizes function calls between C code and the simulator, something that the VHDL/C interface does not have. This means that the PLI function call interface is portable across simulators, which is a big advantage for users, and especially IP providers. Operating in a Mixed-language Environment Using HDL, C/C++, SystemC and SystemVerilog 3

4 The disadvantage of the standardized interface is impaired performance. The PLI has a set of documented parameters for all of the functions as well as the standardized data structures that hold information about the various design objects, and all simulators must use these conventions. Maintaining all of these data structures imposes a significant performance penalty. For example, the simulator must copy pieces of design data requested by the PLI from the internal simulator s data structures into the standard structures required by the PLI. This happens for every PLI access to the design and can be very expensive in terms of simulation time. Interfacing SystemC to VHDL and Verilog SystemC has a powerful set of features that allow it to be used for design models done in C, and design models done in VHDL or Verilog. However, it does not fully replace the need for VHDL and Verilog. Most design work done with SystemC still requires a mix of SystemC and HDLs. A common usage model is to do the top-level design in SystemC, and as the design implementation progresses, lower-level blocks of the SystemC model are replaced by VHDL or Verilog RTL implementations. Thus, to simulate the entire design throughout the development process, it is necessary to simulate the SystemC and HDL code together. The interface between SystemC and HDL is done in one of two ways: 1) the user codes his or her own interface using the FLI or PLI to connect the SystemC model and the HDL model together, or 2) the simulator vendor (or a third party) provides an integrated interface to do this. The first option of using the PLI/FLI to do the interfacing is painful at best. Not only do the design s signals and their types need to be converted across the interface, but also the events scheduled on the SystemC side must be synchronized with the events on the HDL side. The best option is to use an integrated interface provided by the simulator. Ideally, the SystemC language is native to the simulator, so the interface is not needed at all. The ModelSim 5.8 release supports SystemC natively, just as it does with VHDL and Verilog. This allows a mixed hierarchy of SystemC blocks and HDL blocks with no restrictions and no performance penalties. Full debug capabilities across all languages are available, as well. For more information about ModelSim s native SystemC integration, please refer to the application note entitled SystemC Verification with ModelSim. Interfacing C to SystemVerilog SystemVerilog has arrived, and has many powerful features to improve hardware design. One of the new features is the definition of a new API to interface C to the SystemVerilog language. This new interface is called the DPI (Direct Programming Interface). The DPI solves many of the C-to-HDL interface problems that occur today with VHDL and Verilog. In addition, SystemVerilog provides a consistent method for loading user s C code, unlike PLI/FLI, so the C code (and how it gets linked and loaded) is the same for all simulators. One of the problems of FLI and PLI is that they are complex and not easy to use. To do even simple tasks requires detailed knowledge of the interface, and requires a lot of C code to be written. Also, Verilog is able to call C code via user-defined system tasks, but the C code can t call the Verilog code. The DPI was designed to be a natural inter-language function call interface between C and SystemVerilog. In other words, the interface is such that C functions can be called directly by SystemVerilog, and SystemVerilog can directly call C functions, with no interface code between them. Even the datatypes of the parameters are converted automatically across a function call. The C calling conventions and semantics are used by the DPI. The example below shows the SystemVerilog code that calls a C function, and also exports a SystemVerilog function that can be directly called by the C code. Note all that is needed is an import and export function declaration. The imported HandleOutputPacket C function call is called directly at the bottom of the always block. 4 Operating in a Mixed-language Environment Using HDL, C/C++, SystemC and SystemVerilog

5 module EthPort( input [7:0] MiiOutData, input MiiOutEnable, input MiiOutError, input clk, reset, output bit [7:0] MiiInData, output bit MiiInEnable, output bit MiiInError); import DPI context void HandleOutputPacket( input integer portid, input bit [1439:0] payload); export DPI void PutPacket; function void PutPacket(input bit [1499:0] packet) // called BY C inputpacketdata = packet; inputpacketreceivedflag = 1; endfunction clk) begin // output packet FSM if (outstate == READY) begin If (MiiOutEnable) outstate <= PROCESS_OUTPUT_PACKET; end else if (outstate == PROCESS_OUTPUT_PACKET) begin HandleOutputPacket(myPortID, outpacketvector); // call TO C end end endmodule This direct call interface can save the user a lot of time debugging the interface between the C and the HDL code. In addition, the call is very fast, since there are no intermediate data structures created and destroyed, as is the case with the PLI. Operating in a Mixed-language Environment Using HDL, C/C++, SystemC and SystemVerilog 5

6 Summary With the complexity of ASIC and SoC designs spiraling out of control, the utilization of C and C++ for specific aspects of the design flow (such as creating a golden model for the design) is becoming imperative. Mixedlanguage environments are, however, relatively new to many designers and can cause problems for the uninitiated. Interfacing C-class languages to Verilog and VHDL, for example, requires a much different procedure and can be cumbersome, particularly when the design team wants to maintain portability between simulators. New technologies and tools have arrived which addresses many of the problems of interfacing C to HDL. SystemC has the capabilities to cross the boundary of the two design languages, and together with ModelSim s native integration, SystemC can be used seamlessly with VHDL and Verilog. SystemVerilog also solves many of the HDL/C shortcomings with its new DPI interface. No longer do designers need to concern themselves with the interface details of the two languages; now they can focus on their design implementation in both languages equally. Mentor Graphics Model Technology group is committed to supporting the SystemVerilog language and the DPI. Understanding all of the issues involved in using C and HDL together, along with using the latest tools, gives the designer an edge in development of complex designs. ModelSim leads the industry in providing a state of the art simulation environment that supports the latest C, C++, SystemC and SystemVerilog integration. For more information, call us or visit: Copyright 2003 Mentor Graphics Corporation. This document contains information that is proprietary to Mentor Graphics Corporation and may be duplicated in whole or in part by the original recipient for internal business purposed only, provided that this entire notice appears in all copies. In accepting this document, the recipient agrees to make every reasonable effort to prevent the unauthorized use of this information. Model Technology is a trademark and ModelSim and Mentor Graphics are registered trademarks of Mentor Graphics Corporation. All other trademarks are the property of their respective owners. Corporate Headquarters Mentor Graphics Corporation 8005 S.W. Boeckman Road Wilsonville, Oregon USA Phone: