DesignCon Modeling Data and Transactions in SystemVerilog. Janick Bergeron, Synopsys

Transcription

1 DesignCon 2005 Modeling Data and Transactions in SystemVerilog Janick Bergeron, Synopsys

2 Abstract This paper describes how to properly use the object-oriented features of SystemVerilog to model data and transactions at a high-level of abstraction. Designers, used to a procedural programming model, will learn how to approach a modeling problem using the object-oriented approach. Software engineers, used to a traditional object-oriented programming model, will learn how to adapt their methods to the special requirements of constrained-random verification. This paper will present clear and concise guidelines that can be followed to create effective, easy-to-use and reusable data and transaction models and the transactors that operator on them. Author Biography Since April 2003, he is a Scientist within Synopsys's Verification Group where he helps define the stateof-the-art in functional verification methodology and the tools that support it. He is also the author of the best-selling book "Writing testbenches: functional verification of HDL models" and the moderator of the Verification Guild ( He is also a coauthor of the upcoming "SystemVerilog Verification Methodology Manual". Prior to joining Synopsys, Janick was the CTO of Qualis Inc, where he designed the architecture of their Domain Verification Component technology - which was acquired by Synopsys in April In the eight years he has worked at Qualis, he defined the methodology used by their service consultants and helped create industry-leading training introductory and advanced classes.

3 Introduction SystemVerilog is a language with a rich set of data types. Struct, union, tagged union and class can be used to model data at a high-level of abstraction. But which one is best to use? The Verification Methodology Manual [1] provides a set of clear guidelines for making the right decisions. This paper is based on the section of the manual that focuses on modeling data and transactions. Modeling Data A data item is any atomic amount of data eventually or directly processed by the DUT. Packets, instructions, pixels, picture frames, SDH frames and ATM cells are all examples of data items. A data item can be composed of smaller data items. For example, a data model of a picture frame would be composed of thousands of instances of a data models for individual pixels. When creating a data model, a class should be used instead of a struct or union, as shown in Example 1 Example 1. Ethernet MAC frame data model rand logic [47:0] da; rand logic [47:0] sa; rand logic [15:0] len; rand logic [ 7:0] data[]; rand logic [31:0] fcs; Using the class construct has advantages over using struct or union constructs. The latter would only be able to model the values contained in the data item whereas classes can also model operations and transformations such as calculating a CRC value or comparing two instances on these data items using methods. Class instances are more efficient to process and move around as only a reference to the instance is assigned or copied. Struct and union instances are scalar variables and their entire content is always assigned or copied. A class can also contain constraint declarations to control the randomization of data item values, whereas a struct and union cannot. Finally, it will be possible to modify the default behavior and constraints of a class through inheritance, without actually modifying the original base model. Struct and union do not support inheritance. Data Protection As also shown in Example 1, all class properties corresponding to a protocol element or data field shall have the rand attribute. The rand attribute of a class property can be turned off using the rand_mode() method to make it non-random. However, it cannot be made rand after the fact. As also shown in Example 1, all class properties with a rand attribute shall be public. This approach will make it possible to turn off their rand attribute, constrain them in a derived class, when instantiated in higher-level classes or via the randomize-with statement. This rule breaks one of the most basic rules of object-oriented programming. But, these software rules were designed for a

4 programming language where randomization and constraint solving does not exist. If the class properties are local, it will not be possible to constrain them. All class properties without a rand attribute should be local. Object state information should be accessed via public methods. This approach will ensure that the implementation can be modified while preserving the interface. Also, if class properties are interrelated, using methods to set their value will ensure they remain consistent. However, if you up with a set of indepent properties, each with a pair of set() and get() methods, you might as well make the class property public and do away with the methods. There should not be any need for protected class properties. Protocol-level data protection class properties shall model their validity, not their value. The information in CRC, HEC or parity properties is not in the actual value of the class property but in its correctness. These properties are modeled using a mask, indicating which bit of the class property value is to be valid or corrupted (on transmission) or was valid or not (on reception). A value of 0 indicates that the corresponding bit was valid. A constraint block should keep the value of data protection properties equal to 0 by default. Protection errors can be injected by overriding or turning the constraint block off. The actual value of these data protection properties is computed using methods and inserted or compared in the data object only upon packing and unpacking or physical transmission or reception. Example 2. Frame Check Sequence (FCS) validity class property rand bit [31:0] fcs; constraint fcs_errors { fcs == 0; } extern virtual function bit [31:0] compute_fcs(); virtual function int unsigned byte_pack(); bit [31:0] fcs_val; fcs_val = this.compute_fcs() ^ this.fcs; bytes.push_back(fcs_val); function: byte_pack Methods All methods shall be functions. Methods in data and transaction descriptors should be concerned only with their immediate state. There should not be any need for the simulation time to advance or for the execution thread to be susped within these methods. Data and transaction processing requiring time to advance or the execution thread to be susped should be located in transactors.

5 All methods should be virtual. This structure will allow the functionality of methods to be exted in class derivatives. If a method is not virtual, it will not be possible to modify the behavior of existing code to perform a slightly different task for example, injecting error without modifying the original code. As shown in Example 2, a virtual method shall be provided to compute but not set the correct value of each data protection class property. Because the data protection class property is encoded simply as being valid or not, it must be possible to derive its actual value by other means when necessary. The method must be virtual to allow for the corruption of the protection class property value if necessary. The packing method is responsible for corrupting the value of a data protection class property if it is modeled as invalid, not the computation method. Modeling Transactions The natural tency is to model transactions as illustrated in Example 3. Transactions are implemented using procedure calls, such as read() and write(). Example 3. Transaction procedures typedef enum {OK, ABORT, RETRY} status_e; task read(input logic [31:0] addr, input logic [ 4:0] sel, output logic [31:0] data, output status_e status); task write(input logic [31:0] addr, input logic [ 4:0] sel, input logic [31:0] data, output status_e status) This approach, although suitable for a directed test, makes it more difficult to generate random streams of transactions, constraining transactions and registering transactions with a scoreboard. Transactions are better modeled using a transaction descriptor. A class property is used to define the kind of transaction being described. As shown in Example 4, a transaction descriptor contains all of the necessary input information and result variables to ultimately call the appropriate procedure that implements it. Example 4. Transaction descriptor class cpu_transaction; typedef enum {READ, WRITE} kind_e; typedef enum {OK, ABORT, RETRY} status_e; rand kind_e kind; rand logic [31:0] addr; rand logic [ 4:0] sel; rand logic [31:0] data; statue_e status; class: cpu_transaction

6 Tests never actually call the procedure that implements the transaction. Instead, tests submit a transaction descriptor to a transactor for execution. This approach offers the several advantages: 1. It is easy to create a series of random transactions. Generating random transactions becomes a process identical to generating random data. Notice how all properties in Example 5 have the rand attribute. Example 5. Generating random transactions repeat (1000) begin cpu_transaction tr = new; void'(tr.randomize()); cpu.do(tr); 2. Random transactions can be constrained. Constraints can be defined between class properties. Because the constraints are built on the object-oriented framework, they can be added to, modified or removed later on, without actually modifying the original transaction descriptor. Example 6. Transaction constraints class cpu_transaction; constraint address_space { sel < 2; if (sel == 0) addr < 32'h100; if (sel == 1) addr < 32'h1C0F; } class: cpu_transaction 3. Directed stimulus only need to specify the parameters that need to be directed. Directed stimulus often overconstrain a test by providing hardcoded stimulus for all elements of a transaction. If only a subset of these elements are required to be directed, better verification is achieved by letting the other elements remain random. Example 7. Directed-Random Stimulus for (s = 0; s < 2; s++) begin cpu_transaction rd, wr; rd = new; void'(rd.randomize() with {sel == s; kind == READ}); cpu.do(rd); wr = new; void'(wr.randomize() with {sel == rd.sel; kind == WRITE; addr == rd.addr}); cpu.do(tr); 4. New transactions can be added without modifying interfaces. A new transaction can be added by simply creating a new variant of the transaction object. No new class is created, no class interface is modified and no testcase is changed.

7 5. It allows easier integration with the scoreboard. Since a transaction is fully described as an object, a simple reference to that object instance, passed to the scoreboard, is enough to completely define the stimulus and derive the expected response. Example 8. Scoreboard Integration repeat (1000) begin cpu_transaction tr = new; void'(tr.randomize()); cpu.do(tr); scoreboard.check(tr); Variant Data Data units and transactions often contain information that is optional or is unique to a particular kind of data or transaction. For example, Ethernet frames may or may not have virtual LAN (VLAN), link-layer control (LLC), sub-network access protocol (SNAP) or control information in any combination. Another example is the instruction set of a processor where different types of instructions use different numbers and modes of operands. Transaction descriptors are also variant forms of data: different transactions may usually require a different set or subset of protocol elements. Using traditional object-oriented design practices, inheritance looks like an obvious implementation: As illustrated in Example 9, a base class is used for the common properties then extensions are used for the various differences in format. This approach also seems the natural choice as the SystemVerilog equivalent 1 to Specman s when inheritance. Using inheritance to model data formats creates four problems, two of which are related to randomization and constraints concerns that do not exist in traditional object-oriented languages. Example 9. Using Inheritance to Model Variant Data rand logic [47:0] da; rand logic [47:0] sa; rand logic [15:0] len_typ; rand logic [ 7:0] data[]; rand bit [31:0] fcs; class eth_vlan_frame exts eth_frame; rand logic cfi; rand logic [ 2:0] pri; rand logic [11:0] vlan_id; class: eth_vlan_frame 1 SystemVerilog inheritance is corresponds to Specman's like inheritance. Specman's when inheritance corresponds to SystemVerilog tagged union.

8 The first problem is the difficulty of generating a stream containing a random mix of different data and transactions formats. Because an Ethernet device must be able to accept any mix of various Ethernet frame types on any given port, just like a processor must be able to execute any mix of instructions, it is often necessary to generate a random mix of data items with different formats on a single stream. Using a common base class gets around the type-checking problem. However, in SystemVerilog, objects must first be instantiated before they can be randomized. And because instances must be created based on their ultimate type, not their base type, the particular format of a data item or transaction would be determined before randomization of its content. Thus, it would be impossible to use constraints to control the distribution of the various data and transaction formats or to express constraints on a format as a function of the content of some other class property (e.g., if the destination address is equal to this, then the Ethernet frame must have VLAN but no control information). Example 10. Random Stream of Data Variants Using Inheritance repeat (1000) begin eth_frame fr; eth_vlan_frame vfr; randcase 1: fr = new; 1: begin vfr = new; fr = vfr; case void'(fr.randomize()); mii.tx(fr); The second problem is the difficulty of adding constraints to be applied to all formats of a data item or transaction descriptor. To add constraints to a data model, the most flexible mechanism is to create a derived class. To add a constraint that must apply to all formats of a data model cannot be done by simply exting the base class common to all formats as it simply creates yet another class unrelated to the other derivatives. It would require exting each one of the ultimate class extensions. Example 11. Constraining all Data Variances when Using Inheritance class min_eth_frame exts eth_frame; constraint len == 46; class: min_eth_frame class min_eth_vlan_frame exts eth_vlan_frame; constraint len == 46; class: min_eth_vlan_frame The third problem is that you will not be able to recombine different but orthogonal format variations. For example, the optional VLAN, LLC and control format variations on an Ethernet frame are orthogonal. This aspect creates eight possible variations of the Ethernet frame. Because SystemVerilog does not support multiple inheritance, using inheritance to model this simple case will require eight different classes: one for each combination of the presence or absence of the optional information. This approach creates an exponential number of classes. This problem could be solved if the language supported multiple inheritance an oft-mentioned grievance against the language but it would not help

9 in solving the significantly more serious previous two problems. This problem is better solved using proper modeling methodology than a new language capability. Example 12. Combining Data Variances when Using Inheritance class eth_llc_frame exts eth_frame; class: eth_llc_frame class eth_snap_frame exts eth_llc_frame; class: eth_snap_frame class eth_llc_vlan_frame exts eth_vlan_frame class: eth_llc_vlan_frame class eth_snap_vlan_frame exts eth_llc_vlan_frame; class: eth_snap_vlan_frame The final problem is that additional class properties are apped to the class properties already defined in the base class. The additional properties may be physically located or related to other properties in the middle of the data or transaction. It will be difficult to leverage the existing method to embed the additional properties at the proper or most logical location. It will be only possible to prep or app them. Composition is the use of class instances inside another class to form a more complex data model or transaction descriptor. Optional information from different formats could be modeled by instantiating or not a class containing that optional information in the data model. If the information is not present, the reference would be set to null. If the information is present, the reference would point to an instance containing that information. This technique also suffers from two severe problems with randomization and one minor problem. Example 13. Using Composition to Model Variant Data class eth_vlan; rand logic cfi; rand logic [ 2:0] pri; rand logic [11:0] id; class: eth_vlan rand logic [47:0] da; rand logic [47:0] sa; rand eth_vlan vlan; rand logic [15:0] len_typ; rand logic [ 7:0] data[]; rand bit [31:0] fcs;

10 The first problem is that the randomization process in SystemVerilog does not allocate sub-instances, even if the reference class property has the rand attribute. The randomization process either randomizes a pre-existing instance or does nothing if the reference is null. This requires that all possible sub-instances be allocated before randomization. The second problem is that it complicates the expression of constraints that may involve a null reference. A null reference would cause a runtime error and constraint guards must be used to detect the absence of the optional properties. Furthermore, it is not possible to express constraints to determine the presence or absence or their respective ratio of the sub-instance. It would thus be impossible to define the data format based on some other (possibly random) properties. Example 14. Constraining Variant Data Using Composition class my_eth_frame exts eth_frame; constraint dst_as_vlan { if (da == 48'h && vlan!= null) vlan.pri == 3'b000; } class: my_eth_frame The last problem is the needless introduction of hierarchies of references to access properties that, in all respect, belong to the same data or transaction descriptor. One would have to remember whether a class property is optional or not and under which optional instance it is located to know where to access it. However, a runtime error while attempting to access non-existent information in the current data format would be a nice type-checking mechanism. But that benefit does not outweigh the other disavantages. Unions allow multiple data formats to coexist in the same bits. Tagged unions enforce strong typing in the interpretation of multiple orthogonal data format. This approach is the SystemVerilog almost-equivalent to Specman s when inheritance. Example 15. Using Tagged Unions to Model Variant Data typedef union tagged { void untagged; struct { logic cfi; logic [ 2:0] pri; logic [11:0] id; } valid; } eth_vlan; rand logic [47:0] da; rand logic [47:0] sa; rand eth_vlan vlan; rand logic [15:0] len_typ; rand logic [ 7:0] data[]; rand bit [31:0] fcs;

11 Unfortunately, tags cannot be randomized. It is not possible to have a tagged union randomly select one of the tags, much less constraints the tag based on other class properties. It is also not possible to constrain fields in randomly-tagged unions because the value of the tag is not yet defined until solved. Instead of using inheritance, composition or tagged unions to model different data and transaction formats, the proper approach is to use the value of a discriminant class property. This discriminant class property indicates which, if any, optional properties are present. All optional properties are in-lined. The discriminant class property also has the rand attribute to allow random data format selection. Orthogonal variations are modeled using different discriminant properties allowing all combinations of variations to occur within a single model. It is necessary for methods that deal with the ultimate format of the data or transaction such as byte_pack() and compare() to procedurally check the value of these discriminant properties to determine the format of the data or transaction and decide on a proper course of action. Example 16. Using a discriminant class property to model data format rand logic [47:0] da; rand logic [47:0] sa; rand bit has_vlan; rand logic cfi; rand logic [ 2:0] priority; rand logic [11:0] vlan_id; rand logic [15:0] len_typ; rand logic [ 7:0] data[]; rand bit [31:0] fcs; virtual function string psdisplay(string prefix = "") $sformat(psdisplay, "%sda=48'h%h, SA=48'h%h, len/typ=16'h%h\n", prefix, da, sa, len_typ); if (has_vlan) begin $sformat(psdisplay, "%s%svlan: cfi=%b pri=%0d, id=12'h%h\n", psdisplay, prefix, cfi, priority, vlan_id); $sformat(psdisplay, "%s%sdata=%h %h.. %h (length=%0d)\n", psdisplay, prefix, data[0], data[1], data[data.size()-1], data.size()); $sformat(psdisplay, "%s%sfcs = %s", psdisplay, prefix, (fcs)? "BAD" : "good")); function

12 Because a single class is used to model all formats, constraints can be specified to apply to all variants of a data type. Also, because the format is determined by an explicit class property, constraints can be used to express relationships between the format of the data and the content of other properties. Example 17. Constraining Data Variances when Using Discrimant Property class min_eth_frame exts eth_frame; constraint len == 46; if (da == 48'h) begin has_vlan == 1; pri == 3'b000; class: min_eth_frame This technique may appear verbose but does not require any more lines of code or statements to fully implement. Inheritance provides for better localization of the various differences in formats, but does not reduce the amount of code and may even increase it. Furthermore, this technique does not require that the optional properties be modeled in specific locations amongst the other properties to enable some built-in functionality to operate properly. The data and transaction models are implemented to facilitate usage, not match some obscure language or simulator requirement. This approach has only one disadvantage: There is no type checking to prevent the access of a class property that is not currently valid given the current value of a discriminant class property. If absolute usage safety is required, using a discriminant property to identify the data format and using composition to include only those optional class properties that are valid for that format can be used. This would require that all sub-instances be allocated in pre_randomize() then pruned in post_randomize(). Example 18. Combining Composition and Discriminant Property to Model Variant Data class eth_vlan; rand logic cfi; rand logic [ 2:0] pri; rand logic [11:0] id; class: eth_vlan rand logic [47:0] da; rand logic [47:0] sa; rand bit has_vlan; rand eth_vlan vlan; rand logic [15:0] len_typ; rand logic [ 7:0] data[]; rand bit [31:0] fcs; function void pre_randomize() if (vlan == null) vlan = new; function function void post_randomize() if (!has_vlan) vlan = null;

13 function Constraints The declarative nature of constraints and their implementation as part of the object-oriented framework requires careful considerations. It will be easy to create a model that can be used to generate random stimulus. It will be also simple to add constraints to target a particular corner case. But injecting errors, which requires the controlled relaxation of constraints design to ensure that the generated data is valid, requires careful consideration for the granularity of constraint blocks and the modeling approach used for data protection fields. A constraint block shall be provided to ensure the validity of randomized class property values. Some properties may be modeled using a type that can yield invalid values. For example, a length class property may need to be equal to the number of bytes in a payload array. This constraint would ensure that the value of the class property and the size of the array are consistent. Note that "valid" is not the same thing as "error-free". Validity is a requirement of the descriptor implementation, not of the data or transaction being described. This constraint block must never be turned off nor overridden; hence, it is a good idea to use a unique name, such as class_name_valid. Example 19. Necessary Constraints Based on Implementation class some_packet; typedef enum {DATA, CONTROL} kind_typ; rand kind_typ kind; rand int unsigned length; rand byte data[]; constraint some_packet_valid { data.size() == length; } class: some_packet All array properties with a rand attribute should have a constraint to limit their size. Left unconstrained, an implementation of the solver using a 32-bit unsigned integer to represent the random array size will allocate, on average, over 2 billion elements in the array. A constraint should ensure that the size of any array is reasonable at all times. Should it be necessary to allow the randomization of larger arrays, the constraint can be turned off or replaced. Example 20. Constraining Random Array Properties rand logic [7:0] data[]; constraint reasonable { data.size() <= 1500; }

14 Constraint blocks should be provided to produce better distributions on size or duration properties. Size and duration properties do not have equally interesting values. For example, short or back-to-back and long or drawn-out transactions are more interesting than average transactions. Randomized properties modeling size, length, duration or intervals should have a constraint block that distributes their value equally between limit and average values. A distribution constraint block shall constrain a single class property. Use one constraint block per class property to make it easy to turn off or override without affecting the distribution of other properties. Example 21. Distribution Properties constraint interesting lengths { data.size() dist {0 } :/ 1, // Min [1:45] :/ 1, // Padded 46 :/ 1, // Min no pad [47:1499] :/ 1, // Ordinary 1500 :/ 1}; // Max Discriminant properties should be solved before depent properties. A conditional constraint block does not imply that the properties used in the expression are solved before the properties in the body of the condition. If a class property in the body of the condition is solved with a value that implies that the condition cannot be true, this will further constrain the value of the properties in the condition. If there is a greater probability of falsifying the condition, this makes it less likely to get an even distribution over all discriminant values. In Example 22, if the length class property is solved before the kind class property, it is unlikely to produce CONTROL packets because there is a low probability of the length class property to be solved as 1. Example 22. Poor distribution caused by conditional constraints class some_packet; typedef enum {DATA, CONTROL} kind_typ; rand kind_typ kind; rand int unsigned length; rand byte data[]; constraint control_packet_length { if (kind == CONTROL) length == 1; } class: some_packet This problem can be avoided and a better distribution of discriminant properties can be obtained by forcing the solving of the discriminant class property before any depent class property using the solve before constraint. Example 23. Improving distribution in conditional constraints

15 class some_packet; typedef enum {DATA, CONTROL} kind_typ; rand kind_typ kind; rand int unsigned length; rand byte data[]; constraint control_packet_length { if (kind == CONTROL) length == 1; solve kind before length; } class: some_packet Constraint blocks shall be provided to avoid errors in randomized values. Error can be randomly injected by selecting an invalid value for error protection properties. A constraint block should keep the value of such properties valid by default. See Example 2 for an example. An error-prevention constraint block shall constrain a single class property. Use one constraint block per error injection class property to make it easy to turn off or override without affecting the correctness of other properties. Example 24. Error-Prevention Constraints constraint valid_len { if (len < 16'h0600) len == data.size(); } Transactors Data and transactions models are not useful by themselves. They have to be generated, transmitted, executed, observed or analyzed. Data and transaction processing must be kept separate from their descriptors. Data and transaction descriptors are used to model data items and transactions regardless of the flow of data or their physical implementation. Transactors will be used to process data and transactions. For example, as illustrated in Example 25, three different transactors can exist that deal with Ethernet frames on a MII interface. All three use the same data model, but process them differently. Different sets of transactors processing Ethernet frames for different physical protocols (e.g. RMII, GMII, XGMII, XAUI) would also use the same data model. Example 25. Transactors Using the Same Data Model class mii_mac; protected extern virtual task tx(eth_frame fr); protected extern virtual task rx(ref eth_frame fr); class: mii_mac class mii_phy;

16 protected extern virtual task tx(eth_frame fr); protected extern virtual task rx(ref eth_frame fr); class: mii_phy class mii_mon; protected extern virtual task to_mac(ref eth_frame fr); protected extern virtual task to_phy(ref eth_frame fr); class: mii_mon Generators are also transactor: their processing consists of generating a stream of random or directed transaction or data descriptors. Generators must thus be connected to transactors that will execute the generated transactions. This is typically done by having the generator call the appropriate method in the other transactor, as shown in Example 26. Example 26. Generator Calling Transactor class cpu_tr_gen; cpu_transaction cpu_tr; local cpu_xactor cpu; function new(cpu_xactor cpu); this.cpu_tr = new; this.cpu = cpu; function task main(); while () begin cpu_transaction tr; void'(this.cpu_tr.randomize()); tr = new this.cpu_tr; cpu.execute(tr); task: main But this approach makes the generator specific to the transactor it is connected to. Several different transactors share the data or transaction descriptors. All of them could be connected to the same generator if a generic connection mechanism is used. The fact that transactions and data are described as objects offers an opportunity to create a generic transaction interface. A mailbox can be used to exchange transactions from an upstream transactor (e.g. a generator) and a downstream transactor (e.g. a bus-functional model). By making the mailbox bounded, the flow of data and transactions between the two transactors is automatically regulated by the slowest of the two transactors. Example 27. Connecting Transactors Using a Mailbox typedef mailbox #(cpu_transaction) cpu_tr_mbox; class cpu_tr_gen; cpu_transaction cpu_tr;

17 local cpu_tr_mbox mbox; function new(cpu_tr_mbox mbox); this.cpu_tr = new; this.mbox = mbox; function task main(); while () begin cpu_transaction tr; void'(this.cpu_tr.randomize()); tr = new this.cpu_tr; mbox.put(tr); task: main class cpu_xactor; local cpu_tr_mbox mbox; function new(cpu_tr_mbox mbox); this.mbox = mbox; function task main(); while () begin cpu_transaction tr; mbox.get(tr); task: main class: cpu_xactor class verify_env; cpu_tr_mbox mbox = new(1); cpu_tr_gen gen = new(mbox); cpu_xactor cpu = new(mbox); class: verify_env With an object-based interface, transactors can thus be easily partitioned into sub-transactors according to the layering of the protocol they implement. They can also more easily be reconfigured according to the need of the verification environment. There are more aspects and techniques to writing powerful, useful and reusable transactors that are outside the scope of this paper. For further information, the reader is invited to consult [1] and [2]. Conclusions This paper has presented an approach for modeling data and transactions using SystemVerilog. The various elements and trade-offs of the approach have been justified compared to similar guidelines when

18 using a pure object-oriented programming language such as C++. Constrainability and concurrent connectivity creates requirements not found in traditional programming languages. Data and transaction modeling is but a small part of creating as successful functional verification strategy. Readers interested in more details on that topic or a more comprehensive approach covering the entire functional verification process are invited to consult [2]. References [1] J. Bergeron, E. Cerny, A. Hunter & A. Nightingale, "SystemVerilog Verification Methodology Manual", Kluwer Academic Publishers, 2005 [2] Janick Bergeron, "Modeling Usable & Reusable Transactors in SystemVerilog", 18 th International Conference on VLSI Design, Jan 3-7, 2005