https://community.cadence.com/search?q=*%3A*&category=blog&users=76788&sort=date%20desc&Redirected=trueen-USTelligent Community 12https://community.cadence.com/cadence_blogs_8/b/fv/posts/update-to-the-ovm-register-packageTue, 29 Nov 2011 11:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1305627Team genIES/cadence_blogs_8/b/fv/posts/update-to-the-ovm-register-package3OVM users have something new to give thanks for this holiday season -- an update to the OVM Register Package (new link!!). This package is used by novice and advanced users and embodies years of experience gathered through hundreds of SystemVerilog projects. The Cadence genIES team has been remiss since the demise of the OVM World, which left the OVM community to use OVM_RGM 2.5. We did try to post to UVM World , but that is really dedicated to the UVM. Therefore, we will be picking up the contribution thread and maintaining the Cadence contributions to the OVM here. By far the most popular is the register package so we are posting the latest version 2.7.1 here. We've included the release notes from 2.6, 2.7, and 2.7.1 to bring you all up to date. Of course, the complete release note history is in the tarball. Release Notes for OVM_RGM2.7.1 Nov 18, 2011 ** Bug Fixed: ¯¯¯¯¯¯¯¯¯ ¤ Fixed issue with backdoor read for special read fields ¤ Fixed issue with sync for special read fields Release Notes for OVM_RGM2.7 Sept 21, 2011 ** Bug Fixed: ¯¯¯¯¯¯¯¯¯ ¤ Walking one sequence did not create the regOp when writing ¤ Mode based register enum field macro having wrong case statement ¤ Typo in DPI file (vhpiHandleT changed to vpiHandle) ¤ Check for address overlap for indirect / shared and mode-based corrected ** Enhancements: ¯¯¯¯¯¯¯¯¯¯¯¯ ¤ Added support for mode based registers having separate storage Release Notes for OVM_RGM2.6.1 Aug 18, 2011 ** Bug Fixed: ¯¯¯¯¯¯¯¯¯ ¤ Fixed issue with syncing to VHDL ¤ Register overlap check error with end address ¤ Backdoor read of register fields was not properly masked ¤ Filtering of registers having unknown value is now only for rd_all regs seq ** Enhancements: ¯¯¯¯¯¯¯¯¯¯¯¯ ¤ Allowed backdoor write to read-only fields ¤ Allowed register's reset value over-ride using plusArgs ¤ Added register array delete at the end of built-in-seq ¤ Added support field-level backdoor access for shared register ¤ Modified shared_reg_backdoor example and added ipxact file ¤ Removed all uvm deprication warnings from examples ¤ Added more support for VHDL backdoor std_ulogic_[ports|signals|vector_signals] ¤ Modified all headers of XML files to get schema from http ¤ Added objection to built-in-sequences ¤ Added a global field to mask-out comparison of all non-read-write fields ¤ Added a global field to enable warning when accessed address is outside container =Incisive genIES Teamhttps://community.cadence.com/cadence_blogs_8/b/fv/posts/infinite-playbook-for-the-verification-superbowlMon, 10 Jan 2011 14:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1249149Team genIES/cadence_blogs_8/b/fv/posts/infinite-playbook-for-the-verification-superbowl0Its 4th and long, you're down by six, the clock is running out, and you are wary of a bug-blitz. What play do you call? With new approach defined by Silicon Realization, the updated Incisive Enterprise Simulator provides the new capabilities to finsh your drive, route the bugs, and win the verification Superbowl. Even before the snap you need to check the environment statically to eliminate bugs. The 700+ rules in the HAL lint support were expanded with new coding and structual checks, as well as the integration of the e Analyzer capabilities. Once the ball is snapped, you need to get the simulation up and running fast. New in the Incisive release is multi-core code generation, which speeds compilation times of designs that use gate libraries with many unique cells up to 1.2 times. Elaboration has also been tuned, tapping specific user test cases in both gate and RTL abstractions. Now that the simulation is running, you can really apply the new features regardless of the abstraction of the verification. Roughly 2/3 of you are running the OVM using transactions in your testbench to abstract the signals in your design. Cadence has over a dozen large user environments in-house that we are using to tune performance. In the simulator, the result is an average 1.3 times gain for no code change. However, this effort has also uncovered a series of best practices that we have applied with users to improve performance up to 10 times. All of this helps you achieve silicon realization convergence faster. With the emerging UVM 1.0 based on OVM, the best OVM solution provided by Incisive is now the best UVM solution. As a result, the performance improvements for the OVM also apply to the UVM. UVM 1.0 will build on the UVM 1.0 EA from May with several new features, and all of that code is running in the Incisive simulator now so you can move to the new release confident that it is ready for the UVM. You can learn more about this best UVM solution from one of our genIES, Kathleen Meade, in this webinar . If you are running a pre-tapeout gate simulation, this Incisive update will help you as well. You'll find gains up to 4 times depending on your configuration and foundry library. With the results pouring in during simulation or in post processing, you'll need a debugger -- the best debugger -- to sort through the data to find the bugs. SimVision is that debugger and has an array of new features that our colleague, Jim Kjellsen, will detail in a separate blog. So you run your play, win the game, and get some time with raw silicon as you lounge on a sandy Hawaiian beach. As you reflect on the last play that enabled verification convergence, you think "that was too close." Another key part of the 10.2 release is an expanded and updated Incisive Verification Kit. This clear source design includes a verification environment updated for low-power, UVM reference flow , e RM, TLM, and more. As you pour through the manuals, you'll gain new insights into new plays you can run. What's in your verification playbook for 2011? =Team genIEShttps://community.cadence.com/cadence_blogs_8/b/fv/posts/an-editor-for-ovm-field-registration-macrosMon, 22 Feb 2010 20:20:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:26144Team genIES/cadence_blogs_8/b/fv/posts/an-editor-for-ovm-field-registration-macros0The OVM SystemVerilog Class Library has built-in automation for many service routines that classes need for printing, copying, comparing and so on. OVM allows you to specify the automation needed for each field and to use a built-in, mature and consistent implementation of these routines. For each field you must use OVM field registration macros as in the example below: ... rand bit [15:0] addr; rand xbus_read_write_enum read_write; rand int unsigned size; rand bit [7:0] data[]; rand bit [3:0] wait_state[]; ... `ovm_object_utils_begin (xbus_transfer) `ovm_field_int (addr, OVM_ALL_ON) `ovm_field_enum (xbus_read_write_enum, read_write, OVM_ALL_ON) `ovm_field_int (size, OVM_ALL_ON) `ovm_field_array_int (data, OVM_ALL_ON) `ovm_field_array_int (wait_state, OVM_ALL_ON) ... Inside a single dedicated `ovm_*_utils_begin...end block, you must use dedicated macros for each field type. For example `ovm_field_int for a simple int or `ovm_field_aa_int_byte_unsigned for an associative array of integral types indexed by the byte unsigned. If you are hesitant and your head aches when matching the right macro with the right type, the OVM Field Editor of the already well known DVT (Design and Verification Tools) Eclipse Plug-in IDE comes to rescue: You can quickly check whether you have unregistered fields or registration errors. The DVT OVM Field Editor allows you to click on a field and register it with the right macro or customize it's printing, copying, packing and other controls. Based on the enclosing class type (object, component or sequence), the right `ovm_*_utils_begin...end< enclosing block for the registration macros is also created. From now on, just declare your fields, then open the OVM Field Editor, select all fields and click Register . That's it! Just don't forget to read more about the DVT Eclipse Plug-in and get your free trial license from www.dvteclipse.com . =genIEShttps://community.cadence.com/cadence_blogs_8/b/fv/posts/low-power-verification-with-systemc-the-great-unknownThu, 28 Jan 2010 11:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:25099Team genIES/cadence_blogs_8/b/fv/posts/low-power-verification-with-systemc-the-great-unknown0Design teams have used C/C++/SystemC reference models for many years and the trend is growing with SystemC synthesis. At the same time, many teams are adding power-aware structures to their designs and trying to simulate. So what happens when the models encounter unknowns propagated from shutdown blocks? For the unprepared, the simulation fails. In most cases. the models were written before low-power simulations were conceived. They do not take into account the fact that their inputs can go to X at any time during the simulation run (as opposed to just a short while after time 0). We have seen many C-models crash when one or more of the inputs goes to X (this simulates the driving block being shut-down). If you have this configuration in your chip, you must isolate all inputs going to the C-model before shutting down any driving blocks that are connected to the model’s inputs. Another thing to avoid is shutting down the C-model. You must put it in an always-on domain. The Incisive simulator (IES-XL) often does not have access to the internals of the model so it cannot properly handle the low-power operations that are necessary to power down the model. All power-down functions must be done natively in the model if you need it to work properly in shut-down. A third thing to look for is any driving or receiving net that is connected to the model. Proper drive/load analysis cannot be done when originating or terminating in the model. For instance, for all model inputs, the CPF command to specify isolation must be of the form: create_isolation_rule -name xxx -from ... When written in this form, only the driver must be located, not the receiver, so isolation will be placed properly. Likewise, for all model outputs that need to be isolated, use the following form: create_isolation_rule -name xxx -to ... This will remove the need to find drivers inside of the model. Finally, we are introducing a new capability that will allow users to have a SystemC module in their Verilog or VHDL testbench and still use the automatically generated low-power assertions. If you have a need for this capability, contact us at genIES@cadence.com today for an early look. =Team genIEShttps://community.cadence.com/cadence_blogs_8/b/fv/posts/changing-the-quot-f-quot-in-rtfm-to-quot-fantastic-quotTue, 12 Jan 2010 11:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:24589Team genIES/cadence_blogs_8/b/fv/posts/changing-the-quot-f-quot-in-rtfm-to-quot-fantastic-quot0Talk about unsung -- tech writers just don't get the credit they deserve. They sit between R&D, customers, and support trying to capture the capabilities and intent of the software and present it accurately and succintly. They record the " tribal knowledge " of the team so that new and existing users can function at their best, but then they hear that no one has read the f****** manual. Well one of our tech writers sought to change that and to do so not just for Cadence, but to influence her fellow writers across the industry. Faced with tens of thousands of pages of documentation organized by the whims of marketing, her team was burdened with a huge management task complete with redundantant information and huge monolithinc manuals. Claudia Landell led a team inside Cadence verification R&D to find better ways to organize the information, to create consistancy across multiple teams, and to ulitmately make the Cadence verification documentation easier to maintain, read, navigate, and search. She tested those ideas with you, our customers, to validate the improvements the team was making. For sure this was a team effort, but Claudia led the way. You can read more about this work (since this is, after all, a blog on documentation :-) ) in Claudia's article published in the Center for Information-Development Management's January newsletter. While documentation improvements are a work in progress, our customers are enjoying the fruits of this labor today with our current Incisive Enterprise Solutions. One of the big tasks for the genIES is to find opportunities to improve usability and enhance your productivity wherever we can. Claudia and the whole Incisive tech writing team have started by changing the "F" in RTFM to " fantastic ". If you have usability and productivity suggestions, make those via Cadence support or by emailing your genIES@cadence.com team. =Team genIEShttps://community.cadence.com/cadence_blogs_8/b/fv/posts/amiq-dvt-maximizes-ovm-reuse-via-methodology-complianceFri, 08 Jan 2010 18:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:24392Team genIES/cadence_blogs_8/b/fv/posts/amiq-dvt-maximizes-ovm-reuse-via-methodology-compliance2The Open Verification Component (OVC) defined by the official OVM User Guide in the OVM downloads enables the highest levels of reuse. While the OVM class libraries have the supporting classes for the OVC built-in, writing OVCs properly sits on the shoulders of the verification engineer. With Amiq's DVT, the verification engineer has the means to check their OVC for OVM compliance . To help you learn more about DVT compliance checking, the good folks at Amiq put together a short video . DVT also supports e and you can see OVM e compliance video at /blogs/fv/archive/2009/10/28/4-minute-demo-ovm-e-compliance-checks-added-to-amiq-s-dvt.aspx If you have any questions about OVM compliance in general feel free to contact the genIES@cadence.com or our direct line to OVM experts ovm_contributions@cadence.com . For more on DVT, you can go to the Amiq DVT website or contact etools@amiq.ro . =Team genIEShttps://community.cadence.com/cadence_blogs_8/b/fv/posts/are-you-playing-with-a-full-deckTue, 15 Dec 2009 12:50:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:23938Team genIES/cadence_blogs_8/b/fv/posts/are-you-playing-with-a-full-deck0A professional gambler confidently place bets because she know the odds, but she would be crazy to play at a table that didn’t use a full deck because the odds change in an unknown way. If you use a simulator that doesn’t enable low-power verification in every test run, you are just as crazy. Why? Let’s take a look at what gives the verification engineer confidence – finding bugs. If we have a power-aware structure like Figure 1 , we certainly need to verify two aspects – the power management circuitry itself plus the reaction of the power domain to those control signals. If we find and fix some errors we grab an extra donut knowing that, we’ve got the bugs beat. Right? Not if we ignore the bluff. What if the structure in Figure 1 is a peripheral in the SoC of Figure 2 ? How do we know that it will function properly in the rest of the circuit? Certainly, we simulated the directed test that ramps the supply voltage due to an external stimulus. However, if that stimulus can originate in both hardware and software then we need to validate both sources. Furthermore, the voltage ramp in this block may occur asynchronously to other functions in the SoC but those functions must be able to handle the appearance and disappearance of the resources associated with this block. If you are running 1000s of system regressions, but only a handful of directed “low-power tests” how can you be sure the directed tests possibly cover all of the situations in which the random tests might encounter a power mode? This is just like a poker player who thinks he knows his opponents tell thinking "I only have to worry about his hand when he stacks his chips." Unfortunately for that player, fate will always call that bluff and there will be cases where he didn't expect a good hand but one is played. For low-power designs, the engineer may know the cases that should cause power transitions, but what happens if there is a bug that causes an unexpected transition. If you don't run with low power enabled, this bug will go undetected. The trouble is that some verification engineers are willingly not playing with a full deck! Their simulators use a PLI application to validate power-aware structures, slowing their test runs so much that they choose to only run power-aware on a limited number of directed tests. Only the Incisive Enterprise Simulator validates power-aware structures natively which can actually result in faster test runs when blocks of the design are shutdown. In poker, it’s okay to lose a hand or two, but in chip design can you afford to lose a bug or two? =Team genIEShttps://community.cadence.com/cadence_blogs_8/b/fv/posts/ovm-tricks-and-treatsFri, 30 Oct 2009 18:30:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:22447Team genIES/cadence_blogs_8/b/fv/posts/ovm-tricks-and-treats0Your kids may be going house to house for treats, but you can get a big OVM sugar rush from Cadence's OVM World contributions. Each delectible nugget is wrapped in documentation that helps you savor all the goodness. So reach into the bowl and indulge in these methodology sweets! Callback Mechanism From day 1 the OVM has employed a factory mechanism for both simple reuse and multi-language consistancy. While factories are the generally accepted practice for object oriented languages, users migrating to the OVM from other methodologies may be more comfortable with extending procedural and structural elements using callbacks. This donation adds callbacks to the OVM SV (SystemVerilog) library. Compliance Checklist With it's roots in e RM, users of the OVM can access to the collective experience of 5000+ tapeouts over nearly a decade using the contributed OVC (OVM Verification Component) Compliance Checklist. Since each donation is open, it is easy for the ecosystem to take them and create value-added products. Amiq has done this by automating the checklist in an OVM DVE . A demo of the OVM e version was recently blogged and one demoing the OVM SV (SystemVerilog) version will be up shortly. Objection Mechanism When everything works perfectly, life is just so easy. Unfortunately (or fortunately for those of us who need the work!!), it rarely works that way. The Objection Mechanism package adds a number of capabilities to help coordinate and manage complex testbenches. It includes hierarchical status coordination, objection handling, simplified end-of-test coordination, heartbeat detection of malfunctioning objects, and more. Register and Memory Package Fourth in alphabetical order, this most downloaded contribution on the entire OVM World website with 1500+ at the time this blog was written. In its second release now, this register package contains significant improvements recommended by our customers and the OVM Advisory Group (OAG). Among these include greatly improved capacity/performance, multi-bus system-level control, alignment with IP_XACT 1.5, and much more. We do recommend upgrading from our 1.1 version and there is documentation on how to do so. The most-often asked question is "when will there be a joint package" and we are continuing to work with Mentor on that so say stuned to the OVM World and this blog! Regression Speed-Up OVM messages are critical to understanding both nominal and error conditions in your testbench. However, when you scale up the environment those innocent string manipulations can become very expensive regardless of the verbosity settings. This contribution show you how to optimize your messaging to improve OVM testbench performance. Like all of our contributions, this should improve your life regardless of the simulator you choose. Of course, this blogger would prefer y'all use Incisive Enterprise Simulator!! Christmas / Hanukkah / Kwanzaa is coming next. Will there be more treats? Yes! The genIES are hard at work conjuring up more magical treats for you so visit the OVM World contributions area and this blog frequently or sign-up for the RSS feed. =Team genIEShttps://community.cadence.com/cadence_blogs_8/b/fv/posts/ies-low-power-verification-at-warp-speedWed, 09 Sep 2009 11:53:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:20507Team genIES/cadence_blogs_8/b/fv/posts/ies-low-power-verification-at-warp-speed0Since your circuit always runs at low-power, your verification should too. To get that "always-on" low-power verification, Incisive Enterprise Simulator (IES) uniquely verifies low-power behaviors natively. In some cases that can result in tests that run faster with power analysis on than with power analysis off - engage the warp engine! IES introduced the most comprehensive native-compiled, low-power analysis features in 2007. Using the CPF power intent information, IES can verify behaviors such as shutdown, standby (sleep), isolation, state retention, voltage corruption, and power modes. In addition, it can also automatically generate assertions (SVA or PSL) to check for these behaviors. When IES simulates these behaviors it does so through its unique native-compiled engine so that no PLI calls are needed. This enables the warp speed in two ways - it provides less drag on the RTL engine and enables unique optimizations not available through PLI. Since PLI is a generic simulator API, applications that attach through it are subject to additional run-time checking that slows the engine while the native application is trusted by the simulator so that it can run faster. That trust goes on to enable warp speed because the low-power application can instruct IES to not simulate the shutdown parts of the circuit, during the time that they are shutdown, resulting in less circuit to run and higher simulator speeds. For circuits with major blocks shutdown, the result is a simulation that runs faster with power verification turned on than turned-off. PLI-based applications just can't compete. While all this speed is nice, pin-pointing your low-power bugs is even better. IES is also unique here with low-power debug capabilities in SimVision. Looking at figure 1 you can see how SimVision Figure 1 marks signals in isolation and power down modes. It also automatically maps power related signals into the waveform window and collects all of the power domain information into a handy sidebar window as shown in figure 2. Figure 2 SimVision also provides a power mode window that shows all of the power modes in the chip and shows the effect of voltage ramping when domains change voltage. Figure 3 You can see a demo of these capabilities in this related blog . With warp speed, you make every test in your regression both a functional _and_ and low-power test. Lower power, higher quality. Isn't that what it's all about? =Your genIEShttps://community.cadence.com/cadence_blogs_8/b/fv/posts/fsm-mnemonics-maps-enums-in-simvision-using-verilog-1364Thu, 23 Jul 2009 11:05:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:18456Team genIES/cadence_blogs_8/b/fv/posts/fsm-mnemonics-maps-enums-in-simvision-using-verilog-13643The mighty FSM – you first learned it when you were a young pup at University (some of you still are!) and you use it day in and day out today. Such a simple concept – I’m in a known state and I will either remain here or move to a new state based on inputs – but a difficult one to debug when we scale the number of states, number of inputs, and consider asynchronous events. While we have lots of tools in our belt to verify the FSM including formal analysis and code/functional coverage, tracing the changing states through time in debug is the most commonly used. Luckily for us, SimVision has the ability to map mnemonics to values in the waveform window to make it easier to visualize the states of the FSM. The process to do so starts within your IEEE 1364 Verilog code where you’ll need to code parameter or localparam objects that enumerate the state. Once you have that, you can run the TCL script created and documented by one of our genIES ( SimVision and Create FSM Mnemonic maps in SimVision ). An example of how to code the FSM using localparam is shown below: reg [1:0] curr_state, next_state; localparam EMPTY = 2'b00, INUSE = 2'b01, FULL = 2'b10, ILLEGAL = 2'b11; If you code your FSM using SystemVerilog enumerations, then SimVision will automatically show the correct mnemonics in the waveforms and source annotations: typedef enum bit [1:0] { EMPTY, INUSE, FULL, ILLEGAL } mystate; mystate curr_state, next_state; This handy script is provided "as is" for your use and we have other similar "plug-ins" that we will blog on in the future. If you are thinking "it would be great to automate..." comment on this blog or send us an email at genIES@cadence.com . Of course, if you do use this tip please comment. Positive feedback is a magical motivator. :-) =Team genIEShttps://community.cadence.com/cadence_blogs_8/b/fv/posts/enabling-ovm-transaction-debug-in-simvision-without-code-changesThu, 11 Jun 2009 11:05:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:18338Team genIES/cadence_blogs_8/b/fv/posts/enabling-ovm-transaction-debug-in-simvision-without-code-changes2Are you tired of putting print statements in your code to do debug? Do you work with designers who just want to use waveforms to debug testbench and design problems? There is a cool feature in the OVM library and Incisive Enterprise Simulator that comes to the rescue. It is the built-in OVM transaction recording. Modern metric driven testbenches generate a lot of dynamic data on the fly during a simulation run. The test and testbench combination is usually simulated with multiple random seeds to produce different sequences of transactions to maximize stimulus variation to the design. When the checker catches an error, there is always the question. Is it the design or the testbench? The answer usually is, let's look at the waveforms to figure out if the testbench is doing the right thing. Here you need a way to visualize and interact with the transaction stream without modifying your verification environment. We want to get away from doing vector decodes to figure out that this packet is going to port 5 or this transaction is a read request over a serial interface. Using OVM with the Incisive Enterprise Simulator gives you a built-in way to visualize sequences and transactions generated by OVM sequencer without writing any code! Consider the following class called xbus_transfer representing a CPU transaction. The steps in the illustration highlight how transaction recording is automated via base class functionality and macros that implement virtual functions. This xbus_transfer class is used to create sequences of transaction in a verification environment using ovm_sequencer base class. Typical environments have a handful of random sequences that the user defines to capture interesting scenarios using constraints on transactions. The user can use ovm_random_sequence to perform random selection of user defined sequences or specify their own weighting or specific sequence selection for a test. The following example shows how transactions are automatically recorded during the simulation and their visualization by using SimVision waveform window; these transactions are from the bus master and use the ovm_random_sequence. From the above graphic, let's figure out what happened. On the left you see the sequence hierarchy. It shows that the top most sequence, also called the default_sequence is set as ovm_random_sequence for this test. Upon expanding this stream (clicking on the plus sign in the left frame next to ovm_random_sequence), you can see what the ovm_random_sequence did during the simulation run. In debug, it's helpful to correlate the sequence tree that ultimately creates the transaction so you can review the sequence code and adjust constraints if required. For example, to see how the first random write occur, I can put the cursor in SimVision anywhere on the transaction and immediately understand that the WRITE of size 1 to address ‘hE539 was caused by the following sequence chain: ovm_random_sequence --> incr_read_write_seq --> write0 --> write_byte_seq0 --> request WRITE, size=1, addr='hE539 Using the GUI, you can easily correlate the abstract transaction chain with transaction details, all by leveraging automation in the Incisive Enterprise Simulator and the OVM library. How To Control Transaction Dumping in a Simulation Transaction recording is controlled by setting "recording_detail" variable at the component level using the standard OVM configuration API. You can control transaction dumping for any ovm_component or the derived class, through SystemVerilog test or IES TCL command. Remember the ovm_sequencer is a child of ovm_component. Controlling recording_detail from IES TCL Command The two above examples show different ways to enable the transaction recording: The first one turns on transaction recording for the specific component hierarchy "ovm_test_top.xbus_demo_tb0.xbus0.masters[0].*" This includes all subcomponents under masters[0] instance. The second command uses the wildcard "*" to enable transaction recording for ALL components in the testbench. Wildcarding is very convenient to affect large portions of the design with a single command. However, care should be taken when using it in a large verification environment because it may create a lot of waveform data affecting simulation performance. To turn transaction recording off using TCL, use OVM_NONE in place of OVM_FULL as value of recording_detail. This command can also be used during the run to capture transactions in a time-window desirable for bug analysis. Controlling recording_detail from SystemVerilog Test You can use standard OVM configuration mechanism from your test's build method to control transaction recording dumping as follows: Once transaction recording is enabled in a simulation, transactions can be viewed by loading the waves.shm database in SimVision interactively or in post-processing mode by selecting the appropriate component from the testbench hierarchy and sending it to the waveform viewer as shown below. Some Practical Considerations Incisive Enterprise Simulator and the OVM library ensure that changing "recording_detail" of a component doesn't affect random values. This way a failing random simulation from a regression run can be rerun with the same random seed value with transaction recording, signal probes and high message verbosity to speed up failure analysis. TCL api provides a better alternate to control transaction recording vs. the SystemVerilog build() function because: TCL doesn't require recompilation, any change to SystemVerilog test does. TCL can be used to enable recording in a time window to speed up debug simulations You need to use the OVM library distributed with Incisive Enterprise Simulator to take advantage of automatic transaction recording and TCL API. Simply use "-ovm" switch with the irun script to pick up the OVM library with transaction recording hooks into SimVision and OVM TCLcommands. Transaction recording can be used in more applications such as displaying transactions collected by monitor, showing cause and effect by linking transactions traversing the design, and more. For more information, see: xbus example distributed with the OVM library OVM Class Reference Manual, Component Hierarchy, Transaction Recording under /doc/ovm_ref OVM User Guide, XBUS OVC example under /doc/ovm_guide OVM User Guide, OVM TCL Commands under /doc/ovm_guide NOTE: You can download KITSOCV and IES tools from downloads.cadence.com If you have any questions, feel free to post a comment or email genIES@cadence.com . =Team genIEShttps://community.cadence.com/cadence_blogs_8/b/fv/posts/team-genies-bloggers-create-simulation-magicThu, 11 Jun 2009 11:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:18342Team genIES/cadence_blogs_8/b/fv/posts/team-genies-bloggers-create-simulation-magic0Simulation is a huge topic. Performance, debug, mixed-signal, low-power, assertions, coverage, IEEE languages, lint checking, interfaces, and much more. Many of us started using simulation when it was gates and waveforms while others joined in the era of complex, multi-language, testbench-driven simulation. Regardless, the pace of design and verification is accellerating for all of us. So how can we get those pearls of simulator wisdom that let us work our verification magic? Team genIES is the answer. We have assembled the greatest set of simulation minds in EDA ready to provide technical tips, insights, suggestions, and recommendations that you can use to work your verification magic. Our first topic -- Enabling OVM Transaction Debug in SimVision without Code Changes -- is now up in this blog. We have a long list of additional topics throughout the simulation space. So what's on you mind? How can I show a new test matches a golden test at the transaction level? How do I know my simulation is running as fast as it can? Under what conditions should I use DPI, VPI, PLI, VHPI, etc.? Just email us at genIES@cadence.com and we'll provide the tricks that will make you the magician! =Team genIES