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 ( <my_ports>…) int hash; . struct t_tfcell *left_p; $my_task( <my_ports…); struct t_tfcell *right_p; endmodule 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 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.