Application Note
Operating in a Mixed-language Environment Using HDL, C/C++, SystemC and SystemVerilog
www.model.com Introduction Viewing the C model as a specification is, in fact, becoming common. C and C++ languages have an important role to play in ASIC design, and using these languages can significantly In practice, the C model can be used to generate tabular increase designer productivity. However, C and C++ cannot data files that can be compared to the output of the RTL be used entirely alone; they must work together with design at any intermediate partition in the design. The conventional HDLs (VHDL and Verilog), to create a mixed strength of this method is its ability to automate the HDL and C/C++ environment. The key to success when comparison of large numbers of pointed regressions employing a mixed environment in ASIC design is to or extended randomized tests. A simulation log can be choose and use the language that offers the most effective maintained to show precisely which test failed and what abstraction level for the task at hand. conditions caused the error. An important limitation arises, however, due to the need for cycle accuracy in the Traditionally, Verilog and VHDL have proven to deliver the C model—a specific set of assignments in the C model must best solution for describing hardware, because they provide map directly to a single clock cycle in the RTL model. Since an efficient abstraction for level- and edge-sensitive registers a clock cannot be readily generated in C, care must be taken and clock logic, arbitrary logic gates and larger elements of to ensure that all appropriate dependencies are considered clocked logic arranged in parallel. when ordering execution events.
C and C++, on the other hand have been used for years This need for cycle accuracy is especially apparent when to describe higher-level system design, and to describe modeling asynchronous boundary behaviors. Many and implement new algorithms. System architects use designs prioritize transactions according to internal C models to evaluate new architectures without regard events that cross clock domain boundaries in the design. for implementation details, such as timing and hardware- Unfortunately, this can cause perfectly valid outcomes software partitioning. from the RTL design to appear out of order according to the predictive C data. 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 Interfacing C to VHDL architectural capabilities of C (because it is C), and adds class libraries that allow HDL concepts to be included, such Interfacing C code to Verilog and VHDL can take as a time domain, event scheduling, clocks, concurrent many forms—some ad hoc and others operating under processes, etc. a standard. A standard interface for connecting C modules or functions Using C as the Design Specification to VHDL code is defined in the IEEE 1076-1993 standard. The most commonly employed method under the standard One of the main advantages of describing a design in is what are known as “foreign architectures.” These special C is that the C language is very powerful and easy to VHDL architectures do not have any executable VHDL implement complex objects. In addition, the designer can code in them. Instead, they contain a link to executable C compile it into a standalone object and quickly run it and code. At the beginning of the architecture, a foreign evaluate the results. Quick turnarounds can be made and re- attribute declaration appears, such as: evaluated on the fly. More important, however, is the fact architecture foreign_arch of my_module is that the resulting C model can be used for equivalency architecture foreign of foreign_arch: checking between C and RTL. Once a golden C model attribute is “init_func file.so”; is decided upon, HDL designers can begin the task of begin implementing it in RTL HDL. end;
2 Operating in a Mixed-language Environment Using HDL, C/C++, SystemC and SystemVerilog As you can see, there is no code between the begin and end The C code that interfaces to Verilog is defined and statements. The standard also specifies that if there were standardized by the IEEE 1364 standard and is called code between the begin and end statements it would not Verilog PLI (Programming Language Interface). Using the be executed. The C code referenced by the foreign attribute code example above, the PLI defines a mechanism in the declaration is called whenever this architecture needs to C code to specify which function to call when $my_task be evaluated—such as when one of the ports is responding is evaluated. To enhance designer productivity, many to input changes on the entity. simulators now include convenient shortcuts to simplify this mechanism. Unfortunately, these short cuts are not Although most simulators require the same basic portable across all simulators. Verilog’s interfacing method information to connect to the C code, the actual string is clearly more complex than the interface between C and for the foreign architecture specification is simulator VHDL. As an example of this complexity, the code below dependent. ModelSim uses the form init_function is the C structure that must be implemented to interface object_file. The (init_function) is the name of the function C code to Verilog. in the C code that the simulator calls when the design is typedef int (*p_tffn)(); being loaded into memory (elaboration). The object_file typedef struct t_tfcell { referenced in the string is the name of the compiled and short type;/* USERTASK, USERFUNCTION, dynamically linked C code. or USERREALFUNCTION */ An important note is that the IEEE standard does not short data;/* passed as data argument of define the actual procedural interface between the C and callback function */ VHDL; only the definition of the foreign architecture is p_tffn checktf; /* argument checking defined. Hence, C code is not portable between VHDL callback function */ simulators. p_tffn sizetf; /* function return size callback function */ p_tffn calltf; /* task or function call callback Interfacing C to Verilog function */ The C interface for Verilog is quite different than VHDL p_tffn misctf; /* miscellaneous reason and requires more of the designer, who must create an callback function */ almost-empty module that has the single, simple task of char *tfname;/* name of system task or function */ calling a “user-defined system task” that is implemented in int forwref; C. An example of Verilog interface code is: char *tfveritool; char *tferrmessage; module my_module ( 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 The disadvantage of the standardized interface is impaired mixed hierarchy of SystemC blocks and HDL blocks with performance. The PLI has a set of documented parameters no restrictions and no performance penalties. Full debug for all of the functions as well as the standardized data capabilities across all languages are available, as well. structures that hold information about the various design objects, and all simulators must use these conventions. For more information about ModelSim’s native SystemC Maintaining all of these data structures imposes a integration, please refer to the application note entitled significant performance penalty. For example, the simulator SystemC Verification with ModelSim. must copy pieces of design data requested by the PLI from the internal simulator’s data structures into the standard Interfacing C to SystemVerilog structures required by the PLI. This happens for every PLI access to the design and can be very expensive in SystemVerilog has arrived, and has many powerful terms of simulation time. 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 Interfacing SystemC to VHDL and Verilog the DPI (Direct Programming Interface). The DPI solves many of the C-to-HDL interface problems that occur SystemC has a powerful set of features that allow it to be today with VHDL and Verilog. In addition, SystemVerilog used for design models done in C, and design models done provides a consistent method for loading user’s C code, in VHDL or Verilog. However, it does not fully replace the unlike PLI/FLI, so the C code (and how it gets linked need for VHDL and Verilog. Most design work done with and loaded) is the same for all simulators. SystemC still requires a mix of SystemC and HDLs. A common usage model is to do the top-level design in One of the problems of FLI and PLI is that they are SystemC, and as the design implementation progresses, complex and not easy to use. To do even simple tasks lower-level blocks of the SystemC model are replaced by requires detailed knowledge of the interface, and requires VHDL or Verilog RTL implementations. Thus, to simulate a lot of C code to be written. Also, Verilog is able to call the entire design throughout the development process, it is C code via user-defined system tasks, but the C code can’t necessary to simulate the SystemC and HDL code together. call the Verilog code. The interface between SystemC and HDL is done in one The DPI was designed to be a natural inter-language of two ways: 1) the user codes his or her own interface function call interface between C and SystemVerilog. using the FLI or PLI to connect the SystemC model and In other words, the interface is such that C functions can the HDL model together, or 2) the simulator vendor (or be called directly by SystemVerilog, and SystemVerilog a third party) provides an integrated interface to do this. can directly call C functions, with no interface code between them. Even the datatypes of the parameters are The first option of using the PLI/FLI to do the interfacing converted automatically across a function call. The C is painful at best. Not only do the design’s signals and calling conventions and semantics are used by the DPI. their types need to be converted across the interface, but also the events scheduled on the SystemC side must be The example below shows the SystemVerilog code that synchronized with the events on the HDL side. calls a C function, and also exports a SystemVerilog function that can be directly called by the C code. The best option is to use an integrated interface provided Note all that is needed is an import and export function by the simulator. Ideally, the SystemC language is native declaration. The imported HandleOutputPacket C to the simulator, so the interface is not needed at all. function call is called directly at the bottom of the The ModelSim® 5.8 release supports SystemC natively, always block. just as it does with VHDL and Verilog. This allows a 4 Operating in a Mixed-language Environment Using HDL, C/C++, SystemC and SystemVerilog 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 always @(posedge 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 Summary SystemVerilog also solves many of the HDL/C shortcomings with its new DPI interface. No longer With the complexity of ASIC and SoC designs spiraling do designers need to concern themselves with the out of control, the utilization of C and C++ for specific interface details of the two languages; now they can aspects of the design flow (such as creating a golden focus on their design implementation in both languages model for the design) is becoming imperative. Mixed- equally. Mentor Graphics Model Technology group is language environments are, however, relatively new to committed to supporting the SystemVerilog language and many designers and can cause problems for the uninitiated. the DPI. Interfacing C-class languages to Verilog and VHDL, for example, requires a much different procedure and can be Understanding all of the issues involved in using C and cumbersome, particularly when the design team wants HDL together, along with using the latest tools, gives to maintain portability between simulators. the designer an edge in development of complex designs. ModelSim leads the industry in providing a state of New technologies and tools have arrived which addresses the art simulation environment that supports the latest many of the problems of interfacing C to HDL. SystemC C, C++, SystemC and SystemVerilog integration. 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. For more information, call us or visit: www.model.com 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 97070 USA Phone: 503-685-0824