Taking Advantage of SystemVerilog for Design with ModelSim

Transcription

1 D IGITAL S IMULATION A PPLICATION N OTE Taking Advantage of SystemVerilog for Design with ModelSim

2 Introduction SystemVerilog (SV) is the next generation of the popular Verilog language. As an extension to the IEEE Verilog standard (referred to hereafter as Verilog) SV has been carefully designed to be 100 percent backward compatible. Under Accellera (the standards body responsible for defining SystemVerilog ), SV has evolved in recent years. Version 3.0 was approved by the Accellera board at the Design Automation Conference (DAC) in June of This version concentrated on synthesizable design enhancements. Version 3.1 was approved by the Accellera board in June 2003 and added many enhancements aimed at the verification arena. At DAC 2004, an even more enhanced version of SystemVerilog (v3.1a) was officially handed over to the IEEE for standardization. The P1800 committee was formed and is working to release the new SV standard soon. ModelSim fully supports the SV design constructs, enabling design modeling and debug at higher levels of abstraction. Some of the SV features supported by ModelSim are discussed in this paper. Interfaces ModelSim supports SV interfaces. Larger interfaces can be problematic due to the sheer number of internal variables to which a connecting module may bind. Consider, for example, a simple Master/Slave system, such as shown in Figure 1. Figure 1. The connect interface abstractly defines communication between two modules, host and client. Since there may be a large number of signals defined within an interface, it can be difficult for a designer to know which signals they should (or are permitted to) use and whether the signals may be driven, read, or both. What is needed is a formal way to group signals and identify their direction. SystemVerilog with ModelSim 1

3 ModelSim can group sets of variables together into modports, which simplify the job of connecting to the interface. (Figure 2) Figure 2. The word modport is an abbreviation of module port. As the name implies, a modport describes signals from the point of view of the connecting module, so that an interface signal driven by the module is termed an output in the modport declaration and a signal read by the module is termed an input. The simulator will issue warnings if the connecting module tries to write an input variable or read an output. Another SV interface enhancement supported in ModelSim is the ability to define methods (tasks or functions), within the interface, that may be called from within a connecting module to perform interface transfers. Modports can be used to control access to these on-board methods within an interface. Consider the example below of an interface, called simple_bus, with on-board tasks. These tasks are designed to perform some operation within the interface (e.g. slaveread). This is a handy way of abstractly defining the communication details within the interface. The modports may be used to identify which tasks a connecting module has access to. In this example, any module that connects to the simple_bus interface slave modport will automatically be able to call the slaveread task. Notice the module memmod, which connects to the slave modport of the simple_bus interface. 2 SystemVerilog with ModelSim

4 From the point of view of memmod, the slaveread task encapsulates all the details of read transfers over the simple_bus. Simply by instantiating the simple_bus interfaces written at different levels of abstraction, the same memmod code could be made to perform slaveread operations across the simple_bus at behavioral, RTL, or other levels of abstraction with no changes to memmod code. This is a major advantage of SV interfaces with embedded methods (tasks or functions) and modports to control them. (Figures 3a, 3b, 3c). Figures 3a, 3b, 3c. SystemVerilog with ModelSim 3

5 Logic Datatype and Relaxed Driving Rules Verilog users have long been confused by the difference between the two basic datatypes: register and net. Basically, in Verilog, registers are storage elements that remember their state between assignments. The name register is unfortunate in that it implies flip-flop behavior, but in fact can be used to describe sequential or combinational logic. Nets are simple types that do not retain a state, but continuously reflect the value driven onto them. Verilog syntax requires that registers be driven by procedural assignment and nets by continuous assignment or the output of a module or primitive. Consider the interface example just discussed. What may not be obvious at first glance is that the addr signal can be driven from multiple modules (any that connect over the ctrl modport) and read by any number of other modules that connect to the mem modport. If addr is declared as type wire, only continuous assignments can be used to drive addr, and multiple, simultaneously driven values will be resolved by the net-type resolution functions of Verilog. Alternatively, by declaring addr as type reg, all drivers must use procedural assignments and only the last driven value will hold. Thus, the designer of a module is limited by the type declaration for addr used in the interface. Enter SV (and ModelSim) with a new concept: non-net datatypes can be treated as register or wire. By declaring addr as type logic, as in the example, connecting modules can drive this interface signal by procedural assignment or continuous assignment; thereby placing fewer restrictions on the designers of those modules. Specifically, SV allows any non-net variable to be driven from one (and only one) of the following: Arbitrary number of procedural assignments (like reg in Verilog) Single continuous assignment Single primitive/module output The simulator flags any violation of this rule with a warning. While logic is the SV datatype used in the example, it is important to remember that all non-net SV datatypes behave similarly, even including the venerable Verilog reg datatype. In fact, under SV v3.1a, there is no difference between reg and logic datatypes: they behave identically. Type Casting The limited number of datatypes in Verilog 2001 means there is little need for inter-type conversions. SV continues to support the conversion tasks/functions that were specified: $itor, $rtoi, $bitstoreal, $realtobits, $signed, $unsigned 4 SystemVerilog with ModelSim

6 However, SV adds so many new types (including user-defined ones) that it is useful to have C-style casting capability in the language. (Figure 4) Casting may be performed between predefined types as well as userdefined types. Even where a cast is not required (between two packed structures for example) it may be used to enforce a stronger type-checking style. Figure 4. Do-While Loops ModelSim supports the do-while loop SV construct. This is similar to the while-loop in Verilog but offers some advantages. Consider the equivalent examples shown in Figure 5. Figure 5. The while-loop has an entry condition (variable i must be less than 10 for the loop to start), which also acts as the loop terminating condition, as it is checked at the start of each pass through the loop. Notice, the designer must allow for the fact that the loop may not execute at all (if i is greater than 9). The do-while loop on the other hand is guaranteed to execute at least once since it has no entry condition, only a loop terminating condition checked at the end of each pass. This more definite coding style is designed to prevent unforeseen loop-logic errors. SystemVerilog with ModelSim 5

7 Jump Statements One of the constructs that is not seen as favorable by non-verilog users is the disable statement. This is seen by most programmers as an antiquated construct closely akin to a goto statement and is often referred to as a hack because it usually indicates poor coding style. Thankfully, SV borrows several more modern alternatives from C. Two of these are called continue and break. Their function is best described by an example, as shown in Figure 6. Figure 6. While both constructs are used in this example to terminate the flow of a loop, notice how the continue statement simply terminates the current iteration and jumps to the next iteration of the loop. Conversely, the break statement terminates the loop completely. NOTE: break and continue may only be used inside a loop. Another improvement over disable offered by SV (and ModelSim) is the return() statement. In Verilog 2001 functions, the returned value was specified by an assignment to the name of the function. To avoid the use of a disable statement, this return assignment was usually made in the last line of the function code. SV s more modern approach is to use a return() statement, which not only specifies the return value but has an implied break to end the function call. Compare the similar functions shown in Figure 7. Figure 7. 6 SystemVerilog with ModelSim

8 Tasks may also contain a return statement, but without passing a return value. Here, return is used purely for the implied break it provides. Void Type Another feature of SV supported in ModelSim is the void type, which is useful to declare functions with no return value, as shown in Figure 8. Figure 8. RTL Procedural Blocks One major complaint of Verilog RTL designers is the potential ambiguity between simulation and synthesis of procedural blocks. The loose coding style of Verilog procedural blocks has always left open the possibility of problems, such as accidentally inferred latches or sequential elements in what was meant to be combinational code. SV (and ModelSim) greatly reduces this ambiguity by providing specific procedural block types for combinational, latch-based, and synchronous blocks. Notice that both combinational and latch forms of the always block have implicit sensitivity lists. Notice too how both forms are clearly visible to any SV-compatible tool. This means, for example, that the simulator can warn of latch inference, a great efficiency for the designer writing the code. Both forms allow other SV tools to enforce another synthesis rule: variables may be written by only one such block in the module. Figure 9. Finally, SV helps remove another type of simulator ambiguity by assuring that these new block types will execute at least once at the start of simulation and then only after all other procedural blocks have started execution. This can reduce race conditions and other problems that have plagued Verilog users. SystemVerilog with ModelSim 7

9 Notice how the synchronous form of the always block is clearly visible to all SV tools, and that it enforces another synthesis rule: there can be only a single timing control (@ edge clk) in the block. Summary Figure 10. With ModelSim, designers can take advantage of many constructs provided by SystemVerilog. These features allow more abstract levels of modeling and reduce the ambiguity present in RTL Verilog descriptions. Consult the release notes for the ModelSim version you plan to use for the latest information on these and other available SV features. For more information, call us or visit: Copyright 2005 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. 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: North American Support Center Phone: Fax: Silicon Valley Mentor Graphics Corporation 1001 Ridder Park Drive San Jose, California USA Phone: Fax: Europe Mentor Graphics Deutschland GmbH Arnulfstrasse Munich Germany Phone: Fax: Pacific Rim Mentor Graphics Taiwan Room 1603, 16F, International Trade Building No. 333, Section 1, Keelung Road Taipei, Taiwan, ROC Phone: Fax: Japan Mentor Graphics Japan Co., Ltd. Gotenyama Hills 7-35, Kita-Shinagawa 4-chome Shinagawa-Ku, Tokyo 140 Japan Phone: Fax: MGC 3-05 TECH6630-w