On April 17, 2018, Cadence announced three new VIPs, two of which are industry-firsts! Cadence revealed the first available VIP for CoaXPress for high-speed imaging and the first available VIP for HyperRAM high-speed memory. We also unveiled a new JEDEC Universal Flash Storage 3.0 (UFS) VIP. Together, these three new VIPs allow early-adopters to leap off the starting line in the race to create new, incredible SoCs and IPs incorporating these revolutionary new technologies.

CoaXPress is great for imaging technology needs. With the rise of automated driving technology, lightning-fast transfer and analysis of videos and images is more important than ever—and with speeds of up to 6.25 Gbit/s, CoaXPress is uniquely positioned to fill that need. Combine that with Cadence’s TripleCheck technology, and you’ve got a VIP worth integrating into your next project.

HyperRAM is a HyperBus-based read performance memory with speeds of up to 333 MB/s. Applications including automotive, industrial, and consumer applications that focus on a small footprint are a great fit for HyperRAM VIP.

The UFS 3.0 spec doubles the throughput bandwidth from 1.3 GB/s (in the old spec) to 2.6 GB/s. This’ll be a big help to the rapidly growing need for bandwidth and low-power SoCs—for both automotive and mobile designs. And don’t worry—this VIP still utilizes the Cadence TripleCheck  technology you know and love.

To read the full press release for all three of these new VIPs, check here.

Specman constraints solver process consists of a series of reductionsand assignments. It reducesthe range of the field value based on the constraints, and then assignsto it a random value from the reduced range. After assigning one field, the range of all connected fields is reduced accordingly, and the process continues until all fields are assigned.

A new feature added in Specman 18.03 – Range Generated Fields (RGF)- allows distinction between the reductionsand the assignments. With RGF, the constraint solver performs the reduction as usual but we have the option to do the assignment ourselves.

Let’s look at a simple example of the reduction and assignment process. The example defines three fields and some constraints.

   val_x  : uint;
  val_y  : uint;
  val_z  : uint;

  keep val_x in [5000..10000];
  keep val_z in [500..8000];
  keep val_y >= val_x;
  keep val_y <= val_z;

 The steps of generating one item are shown below (this information can be easily retrieved using the “trace gen” command):

reducing: val_x -> [5000..10000]       // applying constraint #1
reducing: val_z -> [500..8000]         // applying constraint #2
reducing: val_y -> [5000..8000]        // applying constraints #3 & #4
reducing: val_x -> [5000..8000]        // applying constraints #3 & #4
reducing: val_z -> [5000..8000]        // applying constraints #3 & #4
assigningval_z: [5000..8000] -> 6419  // picking randomly from range
reducing: val_y -> [5000..6419]        // applying constraints #4
assigningval_y: [5000..6419] -> 5693  // picking randomly from range
reducing: val_x -> [5000..5693]        // applying constraint #3
assigningval_x: [5000..5693] -> 5471  // picking randomly from range

As seen in the given example, we usually let the constraint solver to do all the work for us, including reducing all ranges and assigning values to all fields. However, in some cases we want to perform the last decision of assigning values ourselves by deciding which value from the reduced range to assign to the field.

In this blog post, we will look at some examples of flows in which the Range Generated Fields are helpful. In these examples, we will take the final decision of assigning a value from the reduced range to the field ourselves.

Rapid Creation of Altered Input

When testbench performance is crucial, for example in acceleration verification, we look for ways to boost the input generation. On one hand – we want to use the constraint solver, ensuring only legal data is created. On the other hand – using the constraint solver has a cost in performance.

Let’s change a bit the example shown above, and mark the val_x as an RGF field, by writing ~ before it:

  ~val_x  : uint;
   val_y  : uint;
   val_z  : uint;

Now the constraint solver will not only generate the struct, it will also maintain the information of the reduced range of val_x ([5000..5693], for example). After marking the field as RGF, we can generate the struct once and create many copies of it, in each of them picking one value from the reduced range and assigning it to val_x. This way we create many instances that are almost identical, differ in one essential field. We know all instances are legal - we ensure this by picking values only from the reduced range as it was calculated by the constraint solver.

For getting the reduced range we use a new method of any_struct– rgf_get_range(). This method returns the reduced range of the field. Note that this method is valid only for fields marked as RGF. To assign the field we use the new assignment operator rgf= and not a regular assignment (=). Using rgf= Specman checks that the assigned value is in the reduced range as it was calculated by the constraint solver.

   main_tcm() @clk is {
      var trans : trans;
      gen trans;
      // get the reduced range of val_x
      var reduced_range :=  rgf_get_range(trans.val_x);  

      var copied_trans : trans;
      var one_val_x : uint;
      
      // create many copies, in each of them give a different
      // value picked from the reduced range
      for i from 0 to 10000 {
         copied_trans = trans.copy();
         gen one_val_x keeping {
            it in reduced_range;
         };
         copied_trans.val_x rgf= one_val_x;
         send(copied_trans);
      };
   };  

 “Optional Assignment” - Does the user really want this value?

As described above, the constraint solver assigns values to all fields.  If there are no constraints on the field, the constraint solver would pick a random value from the type initial range. In some cases, you wish to know if the field got its value as a result of user constraints, and if no constraints were applied to this field, we will apply some predefined policy.  Until now, to implement this methodology you would add a designated field, e.g. “use _address”, and instruct the test writers to constrain this field to TRUE indicating “yes, I wrote constraints on address field”. If use_address is FALSE – it means that its value was assigned fully randomly by the constraint solver and in this case the testbench would apply some predefined policy.

Using RGF, we do not need such an auxiliary field. We mark the field as RGF and then we query whether the field range was reduced.

In the following example we use two new methods of any_struct– first is rgf_was_generated(), indicating whether the struct was evaluated by the constraint solver (and not created using ‘new’). After establishing that indeed it was generated – we call rgf_got_reduced(), returning TRUE if the struct’s final range differs from the original range (indicating that constrains were applied on it).  

   struct trans {
      ~address : address_t;
      // other fields …
   };

   unit agent {
      send(t : trans) is {
        if rgf_was_generated(t.address) {
          if rgf_was_reduced(t.address) {
             // reduced, meaning there were user constraints
             // on it, so send as is
          } else {
             // no user constraints were applied on the address field
             // so execute my default addressing policy
             t.address rgf= me.config.get_prefered_address();
          };
        };
       //// continue with sending this trans ….
     };
   };

Combining Power of Constraints with Other Algorithms

The last use model we will describe here, is the one in which we want to employ the power of the constraint solver with some complex algorithm. Some algorithms can be expressed with constraints, but this is not always the truth. Today, you have to decide whether a field is to be constrained or to be assigned procedurally applying some smart algorithm. Using RGF, we can mix both by letting the constraint solver reduce the range of the field and then calling some smart algorithm (even one implemented in another language) to pick one value from the reduced range.

In the following example, mem_block kind field is marked as RGF. After the mem_block is generated, we allocate it in the memory using a C routine named alloc_memory(). We pick random values from the kind reduced range until the memory allocator succeeds allocating a block of the requested kind. (To make the code example short, we skip the code that is required to ensure we do not get into an endless loop).

   routine alloc_memory(mem_block : mem_block): bool is C routine alloc_mem;

   struct mem_block {
      ~kind : mem_kind;
       size : uint;
      // additional fields and constraints …
   };

   extend agent {
      add_mem_block(block : mem_block) is {
         if rgf_was_generated(block.kind) {
            var a_kind : mem_kind;
            var assigned : bool = FALSE;
            while not assigned {
              gen a_kind keeping {it in rgf_get_range(block.kind)};
              if alloc_memory (a_kind, block) {
                assigned = TRUE;
              };
            };
            block.kind rgf= a_kind;
         };
      };
   };

As described in the above examples, Range Generated Fields (RGF) provide extra power to the generation process. When analyzing your environment and methodology to decide which fields should be marked as RGF, keep in mind that there are a few issues to be considered:

• Firstly, there cannot be more than one RGF field in a constraint.
• Secondly, if there is an unconditional == constraint between an RGF field and a generative field (i.e. constraints such as "keep sz == len/3", when 'sz' is an RGF), then RGF's range will always be a single value. Therefore, in these cases there is no advantage in marking such a field as RGF.

We are sure you will find great ways to employ this new powerful capability of RGF and continue to enjoy verification using Specman  J

Welcome back to a special multi-part edition of the App Note Spotlight, where we’ll continue highlighting an interesting app note that you may have overlooked—Simulation Performance Coding Guidelines for SystemVerilog. This app note overviews all sorts of coding guidelines and helpful tips to help optimize your SystemVerilog code’s performance. These strategies aren’t specific to just the Xcelium Parallel Simulator—in fact, they’ll help you no matter what simulator you’re using.

In this section, we’ll talk semantics—but these aren’t throwaway details, they’re SystemVerilog semantics. These are some small things that can show up here and there that can speed up your code without a whole lot of extra effort.

1)      Be Explicit with the Storage of Logic Types

SystemVerilog has a special data type called the logic data type. When a logic type is being used as a wire, you want to be explicit about it, otherwise SystemVerilog says you will get a variable. You don’t technically have to explicitly declare whether you’re using wire storage or variable storage, as the storage can be determined by context, but it’s much faster to choose one at the declaration. The biggest slowdowns caused by implicitly-declared logic types occur when a logic type is being used as a wire, without actually being declared as such. There’s a pretty simple solution here: make sure you declare it as a wire!

As a special note: when you’re profiling your design, (that’s with -profile, or -xmprof if you’re using Xcelium), places where this issue occurs will be flagged as Anonymous Continuous Assignments (ACAs).

2)      Avoid Bit-Blasting Vectors

Here’s another simple one: make sure your operations use the full vector instead of just operating on individual bits whenever possible. While SystemVerilog has constructs, such as generates, which make it easy to operate on individual bits of a vector, it’s often times just as easy to simply run your operations on the full vector instead, and it’s faster, too. The compiler generally won’t give you trouble if your use case is simple.

3)      Minimize String Formatting

SystemVerilog does provide string objects, but formatting these strings is a very expensive operation. String objects have a lot of useful features for writing messages in your verification environment—so using them occasionally isn’t the end of the world—but keep them to a minimum.

As an example: make sure your code only does whatever formatting is required in the event that the string object is actually used. And, when you are running regressions, where farm throughput is critical, make sure you are not wasting time formatting messages instead of doing real work.

4)      Pass Array Objects by Reference

SystemVerilog doesn’t specifically have “pointers” as they’re understood in other languages. That means you can’t create a reference to an object through syntax, but you can specify a function or a task argument as a reference. When the object is simple and small, like an integer or a class handle, it’s faster to pass it by value, but for larger objects, passing by reference is the less expensive operation.

That’s all we have for today—check back soon for a couple more helpful tips!

The wait is finally over—the Rapid Adoption Kit (RAK) for verifying the power intent of low-power mixed signal SoCs is here! The RAK is a tutorial designed to clearly show, through example, how to verify one of the most critical technology convergences in IoT devices. It’ll talk about the differences in verification of a processor-based design whether it’s powered internally or externally, how to verify SPICE, SystemVerilog Real Number Models, AMS, and Verilog models in the same environment, the new features in UPF 2.0 regarding power intent specification, and highlight issues you might face while verifying low-power SoCs.

Of course, all of this IP was developed by Cadence, and the testbench was created using UVM.  The source code is Apache-licensed to make it easier for you to use.

In the example provided by the RAK, the top level of the SoC is a processor-based design where an off-chip voltage regulator drives the power supplies on the chip. This design is referred to as the CORE.

                Figure 1: Block Diagram and Low Power Architecture

Off-chip, the voltage regulator provides 5V power to CORE. Inside CORE are two blocks—ANALOG_TOP and DIGITAL_TOP. ANALOG_TOP has the on-chip power supplies, while DIGITAL_TOP contains the processor (PROC) and its subsystem.

                Figure 2: Block Diagram of ANALOG_TOP

How is the power reduced? There are two main ways: through Power Shutoff (PSO), where the parts of a design that aren’t in use are shut down to conserve power, and through Multi-Supply Voltage (MSO), which lowers the supply voltage when the timing constraints allow that to be done without sacrificing performance.

The different power needs for different parts of the chip are called the “power intent”, which is specified using the Unified Power Format (UPF) 2.0.

Usually, in mixed-signal SoCs, the performance of on-chip power supplies isn’t all that important to the digital IP. In low-power simulations, however, those on-chip power supplies become a lot more relevant, as they’re being toggled on and off to save power regularly. This means that low-power mixed signal simulations can take advantage of the variable power intent modeled by UPF.

So—how does UPF model power intent? UPF does so through supply nets, which are modeled as SystemVerilog structs containing a state (of which there are four different ones) and an integer “voltage”, that holds the value of the voltage in microvolts.

There are four different states that can be mapped to the “state” field of the supply net: OFF, UNDETERMINED, PARTIAL_ON, and FULL_ON. In this screenshot of the RAK, you can see the state of the VDD_5V net transition from OFF to PARTIAL_ON, among other state transitions described in the “Power Up” power state.

                Figure 3: The “Power Up” power state

This RAK’s example SoC passes through six power states—Power Up, Load SRAM, Power Up PROC, Low Power Mode—Power Down, Low Power Mode—Power Up, and LDO Shutdown. Check out the RAK manual for pictures and additional information regarding each power state.

If you have questions about verifying power intent for low-power mixed-signal SoCs, this RAK is exactly what you’re looking for. Check it out here.

Microsemi has been evaluating a unique feature in Xcelium System Verilog UVM Dynamic Test Load for some time now, and they shared their thoughts on it in a paper presented at CDNLive San Jose April 2018.

One of the fields Microsemi operates in is the realm of optical networking. In optics, a given sensor’s input can vary wildly, but the way the input is processed is largely the same. Thus, a wide variety of tests are required to fully test a design for an optical sensor’s chip, and that implies the need for a lot of simulation.

To reach maximum coverage, though, they still need to be verified thoroughly. How did they solve this issue? Testing each input, and recompiling in between each test, takes a very long time.

In comes SystemVerilog / UVM Dynamic Test Load!

Before this update, SystemVerilog was very slow to debug: it requires you to recompile after each test. Plus, it only has simple peek, poke, and force options. SystemVerilog still has these limitations, but now Xcelium doesn’t! Dynamic Test Load is a solution within Xcelium that solves those issues making SystemVerilog UVM easier to use.

What was added that makes this new update so cool, then?

SystemVerilog UVM Dynamic Test Load allows you to load new UVM sequences via SystemVerilog packages into a saved snapshot (saved simulation state), and call testbench functions when that snapshot is reloaded.

There’s two types of dynamic snapshots: a dynamic base snapshot (DBS), which is the snapshot saved at time zero, and a dynamic test snapshot, which contains whatever new SystemVerilog packages you want to use. Use the $save("snapshot_name") system task in the testbench to create a snapshot and use the xsim tcl save command during runtime (xrun> save snapshot_name).

Dynamic Test Load is still pretty new, so new features are being added all the time. Right now, we’re working on support to save your snapshot into a different path than the default—that said, Dynamic Test Load does support saving into a different library at this time. Be wary of increases in the size of the CDS library caused by multiple jobs writing to the same library —in the future, there will be a bundled tool that can copy this library, minimizing the risk of the original library corrupting.

How do you use SystemVerilog UVM Dynamic Test Load? First, compile the DUT and the stable parts of your testbench with incremental elaboration (MSIE). Save a dynamic base snapshot at time zero. Make sure each test case and all sequences that may change are in their own packages. Now, you’re ready to save and load snapshots as you need.

Doing this the old way, where everything was re-elaborated every time, would take around five minutes. However, with Dynamic Test Load, you can drop that time done just one minute.

This can speed up your RTL debug turnaround time by around 90%, with an average time to failure in simulation at six hours. Overall, it can halve your development time!

If you’re ready to start cutting your development time in half, check out the presentation given at CDNLive by Microsemi here.

Are you aware of all the cool new features in Digital Mixed Signal 2.0 (DMS 2.0)? Provided with the Xcelium Parallel Simulator versions 17.10 and beyond, DMS 2.0 brings you all kinds of new and wonderful features to help you use Xcelium to verify your mixed-signal designs.

The level of interaction between analog structures and digital logic is a lot more complex than it used to be. Divide-and-conquer verification isn’t good enough anymore; analog and digital components are often too intertwined to properly test each individually. Thus, Cadence has put substantial time and effort into solving this problem—and DMS 2.0 is the fruit of our labor.

Cadence is leading the industry with the most comprehensive set of mixed-signal verification capabilities across logic, real number modeling, and electrical abstractions. You may have already used DMS 1.0 in earlier versions of our simulators—but with 2.0, we’re bringing so much more to the table.

DMS 2.0 is an extension of 1.0, so everything you know and love is still there. So, what’s new?

We’ve added advanced real-number modeling features like coercion, support for multiple drivers and resolutions, wreal arrays, support for `wrealXstate and `wrealZstate, real assertions (in both PSL and SVA), multilanguage connections, and amsd control block support for blocks without analog content. There are also new SystemVerilog real-number modeling features, like SystemVerilog real coverage, SystemVerilog compliant nettypes and interconnects, support for multiple drivers and resolutions, support for user-defined data types (UDTs), and user-defined resolution functions (UDRs) in both real and non-real cases, and scalar nets with UDTs and UDRs.

We’ve expanded port-binding capabilities, too.

With DMS 2.0, Xcelium now has the best bi-directional modeling tech for SystemVerilog real-number modeling, the smartest implementation of power intent and distribution (brought to you by UPF/1801 or CPF), as well as SystemVerilog and mixed-signal features like the first SystemVerilog AMS compiler for connect modules and automatic insertion.

And that’s not even covering the new reuse features like advanced test bench and IP reuse.

DMS 2.0 brings a lot of new tech to the table, and if you’re not using it already—in this bloggers’ opinion, you’re missing out.

Check out a video overview of what DMS 2.0 brings to the table here.

Welcome to the first installment of a three-part blog series examining the issues and opportunities for performing verification in the cloud.

For a while now, there’s been a growing interest in cloud-based EDA solutions, but the time wasn’t ripe for production deployment. People had concerns about security and the sustainability of the data centers. But nowadays, public clouds are highly secure, typically more secure than on-premise datacenters, which has reenergized thinking about moving design and verification to the cloud.

New chip designs are more complicated than ever, and cloud-based verification solutions can take some of the weight off local machines, allowing smaller companies to have more competitive times-to-market. Time-to-market is, and always will be, critical for a successful SoC development project. Designing and verifying a chip can cost upwards of a billion dollars, and if that chip isn’t ready when the market demands it, any dream of recuperating that cost goes right out the window.

In a survey conducted in 2016, it was found that, on average, 55% of ASIC development time is spent on verification. Past surveys show that this figure is consistent across previous years—but here’s the catch: the flow of fresh engineers into verification is three times that of design. So—even with three times as many engineers entering the field, verification time is only static. Clearly, increasing the engineer headcount can only do so much—a breakthrough is needed, and that breakthrough is coming in the cloud.

But why is the cloud the answer? Can’t companies just have more on-site computers to deal with the increasing machine cost of verification?

Well, no. Not every company can afford that—start-ups can’t, for one, and even for larger companies, replacing or expanding their existing farms can cost huge amounts of money. Even for the largest companies, for whom this sort of spending isn’t that much of an issue, constantly expanding and  upgrading your computer resources is inconvenient and cumbersome.

Consider the figure below:

Here, we see a picture of a company that upgrades their computer resources before they become out of date. They never have an issue where their computing power isn’t enough; however, they’re spending huge amounts of money on state-of-the-art equipment, and replacing it just as often as everyone else, since the time-cost of installing new computers all the time factors in too.

Now, consider this:

Here, we see what is likely a smaller company, who can’t afford to replace their computers all the time. They get the most out of what they have—but they have to completely stop everything when the demands become too great.

What happens if the company doesn’t have to keep track of their own computer resources, and lets a cloud-based service do it, instead?

In this situation, a company can simply increase the amount of resources they use as they need it. They still have their own resources, of course, but whenever needs become too great, they can use the cloud to keep things running smoothly, as some extra power. This way there’s no great waste in running state-of-the-art equipment all the time, and no downtime when equipment needs to be replaced mid-project.

Now that we’ve set the stage, check back next time to see what Cadence has in store for the future of cloud-based verification!

Welcome back to the third installment of a special multi-part edition of the App Note Spotlight, where we’ll continue highlighting an interesting app note that you may have overlooked—Simulation Performance Coding Guidelines for SystemVerilog. [link to app note here]. This app note overviews all sorts of coding guidelines and helpful tips to help optimize your SystemVerilog code’s performance. These strategies aren’t specific to just the Xcelium Parallel Simulator—in fact, they’ll help you no matter what simulator you’re using.

Today, we’ll talk about data structures, and how to make sure you’re using the best-optimized method for any use case.

1)      Use static arrays instead of dynamic arrays when the size is relatively constant.

SystemVerilog has a couple of dynamic data structures, and static counterparts for each. The dynamic structures have overhead in that they are heap-managed objects, so there’s a certain amount of overhead that comes with that. Static data structures don’t suffer from this issue so, for cases where it is reasonable, static arrays will perform better than their dynamic counterparts.

2)      Use associative arrays when you need to do lookup or random insertion/deletion

Associative arrays have more efficient lookup than other data structures. Often implemented using a tree, they have a complexity of O(log n). This is much, much faster than a queue or array, which has a linear lookup complexity, O(n).

It’s not all fun and games for associative arrays, though. Since they’re implemented as trees, adding or removing an element from the front or back isn’t as simple of a process; while queues and arrays have access to those areas in constant time, O(1), associative arrays are O(log n) to add or remove an element at any point.

So—if your use case requires a lot of random lookup, and you won’t be inserting or deleting things from the front or back specifically all that often, consider an associative array.

3)      Choose queues when insertions and deletions are mostly at the front or back

Like the above tip, if you only care about adding to the front or back of your structure, a queue is for you. Not only does it access the front or back of the queue in constant time—it can also access an element at any index in constant time, too. This makes it the absolute fastest option for that use case.

4)      Use built-in array functions when needed

This is a fairly simple one—don’t reinvent the wheel on your data structure’s functions. If you’re using a SystemVerilog standard data structure, there’s a good chance whatever operation you’re trying to perform can be done through a built-in function. This extends to querying functions, locator methods, ordering methods, and reduction methods.

5)      Don’t use the wildcard (*) index type for associative arrays

You’re allowed to use the wildcard (*) to make your key a generic integral type; however, this isn’t a good idea if you’re looking for maximum efficiency. Since the wildcard allows you to use any key type, whenever an item is stored in the associative array, the simulator uses a dynamic key type to account for the uncertainty. This has quite a bit of overhead versus a statically sized key. Likewise, the simulator must dereference the dynamic keys to check against the input when you’re doing a lookup or search, and this adds overhead as well.

That’s all we have for today—check back soon for the next installment!

Welcome back to our series on cloud verification solutions. This is part two of a three-part blog—you can read part one here.

The high-performance computing (HPC) market continues to grow. Analysts say that the HPC market will reach almost $11 billion by 2020—that’s an annual growth rate of almost 20%. Cloud providers and other related companies are putting more and more resources into building solutions for this rapidly growing HPC market, which is of great interest to the EDA community.

All of this talk is leading to action—cloud providers are increasing their attention to HPC, which in turn helps create an EDA-appropriate environment for users in the cloud. It’s also a nice confidence boost to the verification and semiconductor design team—it shows them that their needs are being addressed, and that there may be better options for them to do their future work in the cloud.

Now, if you’re in verification—as this is the functional verification blog—how can the cloud help you? There’s a couple of important things to keep in mind as you do your research.

Make sure you’re fully aware of your long-term needs as well as your immediate needs before you partner with an EDA vendor. Just because something works for you now doesn’t mean it’ll work for you in the future. Companies and goals evolve; make sure you’re not getting stuck with subpar tools because you had simple needs when you wrote up your contracts.

Another thing to be aware of is a given provider’s expertise with variable computing requirements. You don’t want to be a new company’s guinea pig with something this vital to your workflow. Keep an eye out for:

1.       Awareness of the best practices associated with creating a secure cloud environment

2.       Products that are validated as cloud-ready

3.       Experience selecting compute and storage instances in the cloud using EDA workload data

4.       The ability to facilitate cloud orchestration

Beyond those things, make sure that your prospective EDA partner has plans to improve their cloud solutions, and to create new cloud solutions, in the future. You want a partner who will take this as seriously as you take it—don’t settle for anything less.

Now, you may be wondering where this is all going.

Tune in next time for our thrilling finale!

Freedom of choice is a term we hear a lot, especially in the last 10 years. It is defined in wikipedia as “an individual's opportunity and autonomy to perform an action selected from at least two available options…”.

Is having many choices always a good thing? Well, usually it is- who would not want to live in a world where s/he has options and can make choices? However, there are also downsides to having multiple options. In the TED lecture, The paradox of choice, Barry Schwartz discusses the negative aspects of having too many choices.

For example, in the healthcare world- in some cases, your physician might present you with a few options and let you make the right medical choice for yourself.  Is it necessarily a good thing? Do you always feel you have the tools to make this choice?...

Freedom of Choice is discussed a lot in the context of many fields such as, law, economics, and well being. But, what does freedom of choice mean in the context of verification? Among other things, it is the freedom to choose the right verification language for your project.

The world today is much more complex than it used to be a few years ago.  Situations like acquisitions, mergers, remote-sites, and purchased third-party VIPs might create few challenging situations, especially for the managers who need to make choices.

Let’s talk about two common scenarios, integrating existing UVCs and choosing a language for new projects.

Integrating Existing UVCs

This is a very common scenario as a result of acquisitions. What would you do if you need to have an existing UVM-SV UVC interact with an existing UVM-e UVC? Will you rewrite one of them with the other language? Naturally, rewriting a UVC is a huge effort.

Fortunately, with UVM-ML you can reuse these existing UVCs and have them co-exist and communicate with the right topology) discussed in the following sections). As a manager, it saves you the effort of rewriting a UVC and if you want each team to continue working with the language it is used to, you can do this with UVM-ML.

Choosing a Language for New Projects  

You might find yourself in a similar situation (as described above) even for a new project. For example, if you have two teams, and each team is used to working with a different language. Here, you can either select the best language for all the teams or let each team continue working with the language it is used to. In principle, the former option is preferred. Firstly, regardless of the power of UVM-ML, it is always easier having everything written in the same language. Secondly, you would prefer having all your people working with the language providing the best quality and productivity.

So, what is the best verification language?

Anyone who has worked with both e and SV knows by experience that e is much superior because of several reasons, but this is a subject for a different blog.  It is true that Xcelium bypasses many limitations of the System Verilog LRM, however, still using e as the verification language is easier and more effective.

So, the best option would be to have everyone work with e, however, it is not always possible. In reality, there might be other factors and considerations. For example, you might have a team pressuring to continue with the language it is used to. In such a situation, as a manager you might decide to let each team select its preferred language. This is the flexibility you get with UVM-ML, this means you have a choice and you can have each team make its own choice.

So what is UVM-ML exactly?

UVM-ML library enables you to connect different UVCs written with UVM-e, UVM-SV, and UVM-SC. While we, as the R&D, are aware of its importance as the glue in several leading companies, it is always exciting to hear customers appreciate its capabilities.  In 2018 US DVCon, HP won the best poster called: “Is e still relevant?”. In addition to the fact that the answer in the poster is “yes”, in this poster (and its relating paper), HP describes UVM-ML as the enabler for both reuse of the existing projects written in different languages and selecting the right language for each project (frankly speaking, we could not say it better…).

Figure 1:HP poster that won best poster in 2018 US DVCon

 This poster and the paper include case studies and learnings from projects within the Silicon Design Lab (SDL) of HP. They are saying: “UVM-ML has a proven track record within SDL. It has been used for several years, spanning numerous projects… Through these projects, SDL has been able to take advantage of many of the advanced testing features available in Specman/e while utilizing a variety of UVMSV content from internally developed VCs to externally purchased Verification IPs.”.

UVM-ML was developed with AMD as an open source library provided in Accellera site. Since Incisive 15.2 it is provided also within incisive and Xcelium. We encourage our customers to use the version provided within Xcelium since it has an enhanced integration with Xcelium, however, there are some cases in which customers choose to use the open source version (you can always consult with the UVM-ML support team: support_uvm_ml@cadence.com).

UVM-ML supports multiple topologies according to the user environment. In a side-by-side hierarchy (parallel trees), the environment contains multiple tops, each top containing the components of a single language. In Unified hierarchy (single tree)- each component is instantiated in its logical location in the hierarchy. For simplicity, the two examples contain two languages, however can be extended to three.

Figure 2: Side by side example

Figure 3: unified hierarchy example

How does the magic work?

UVM-ML contains an inner backplane, services, etc. but the main part that is relevant to the user’s point of view is the adapter which has an API for connecting your UVC to the UVM-ML library. The API of each adapter is provided in the native language of the framework that is being connected, meaning there is a UVM-e adapter, a UVM-SV adapter, and a UVM-C adapter. This means that when you connect your UVC to the library, you do it with the language you are familiar with.

Figure 4: UVM-ML inner blocks

There is a lot of material out there about UVM-ML. You can read more about UVM-ML in the reference and user manuals in cdnshelp. If you want to quickly get started, it is recommended to read the following blogs:

• Multi-Language Verification Environment—Getting First Run in Few Minutes
• Multi-Language Verification Environment (#2) – Passing Items on TLM Ports, Using UVM ML
• Multi-Language Verification Environment (#3) – Connecting UVM Scoreboard to a Multi-Language Environment
• Multi-Language Verification Environment (#4)—Multi-Language Hierarchy

 To wrap up, enjoy our multi choices world of verification!!!

Orit Kirshenberg

Specman team

Welcome back to our series on cloud verification solutions. This is the final part of a three-part blog—you can read part one here and part two here.

Now, for the moment you’ve all been waiting for: what can Cadence do for you in the realm of cloud verification. Are you ready?

In case you saw that list of qualities one should look for in a cloud partner in the last part of this blog, and wondered who ticks all those boxes—Cadence does. Tapping into 20 years of hosting experience, Cadence has just announced Cadence Cloud, a portfolio of solutions that meet the needs of companies large and small.  The first of these is the Cloud-Hosted Design Solution—a fully-managed offering that provides access to the full suite of Cadence software products. This offering is an EDA-as-a-Service solution that can help you—no matter who you are—meet your variable compute, time-to-market, and cost requirements without the difficulty of managing the cloud environment yourself.

If you’re concerned about the security of doing all your verification work in the cloud, don’t worry: we were concerned about that, too. Our IaaS partners pass global security standards like:

·         FIPS 140-2 Level 2

·         DoD Security Requirements

·         ISO 27001, 27017, and 27018

·         …and more!

In addition, the Cloud-Hosted Design Solution takes your usual infrastructure-as-a-Service (IaaS) security to the next level, with additional security apps, practices, and testing.

The next solution in the portfolio is Palladium Cloud. This gives users access to the Cadence Palladium emulation platform. Seasoned Palladium users who already have on-site hardware can use it when they need a little extra emulation capacity for their projects. New users find it great for getting instant access to emulation tech. Palladium Cloud supports the full range of emulation use models.

If you don’t like the idea of Cadence managing your environment for you, then the third solution in the Cadence Cloud portfolio is for you—the Cloud Passport model. With Passport, you can choose from a list of cloud-ready tools and manage your own environment using any of the top IaaS vendors.

Now, when you combine the scalability, security, and flexibility of Cadence Cloud with Xcelium’s amazing simulation technology, you get a radical increase in verification productivity that was inconceivable before.

If you’re worried about time to market—and who isn’t, really—Cadence Cloud is here for you. Verification is the biggest time-sink in the development process, so shrinking that should be your first concern—and it’s exactly there that Cadence Cloud packs the most power. Bringing together Cadence’s twenty-plus years of environment managing experience and a wide range of cloud-read and optimized products, Cadence Cloud is ready to help you address your needs.

So, the question remains: are you ready?

Here’s something to chew on:

Syntiant is an AI startup involved in deep learning technology and semiconductor design. Their goal is to create exceptionally low-power designs for always-on devices, like those used in speech detection.

Syntiant went from empty air to tapeout in six months.

That sounds hard to believe, but it’s true. They got their first venture-capital funding in October of 2017, taped out initial test chips in December, hit first product chip tape-out in March, and formally announced their company in May. This kind of timeline is completely unheard of—but thanks to Cadence technology, Syntiant’s scintillating success story—told at the Cadence Theater at DAC 2018—may be soon be more common than you think.

What do you need to start a semiconductor company? Lots of things, obviously—tools, data center access, EDA experts—the whole nine yards. How does a fledgling company like Syntiant gain access to all of these things? Building your own data center is expensive, and finding qualified EDA experts isn’t exactly easy—never mind purchasing all those tool licenses.

Thanks to Cadence, though, Syntiant only needed one thing: the Cadence Cloud.

Syntiant wanted speed. They wanted instant ramp-up, fast releases, a quick transition to SoC development, and—above all—a fast tapeout to silicon. Cadence Cloud-Hosted Design Solution got them all of those things, and it can get you all of those things, too. Cadence Cloud-Hosted is ready to go right out of the box, and you can use it while VPN connected to your secure chamber. If you’re not sure what you need yet, there’s the DEMO chamber, where you can familiarize yourself with the design environment and any of the Cadence tools. Then there’s the POC (proof-of-concept) where you test out a chamber created to your unique design specifications and tool requirements to ensure you purchase what’s right for you.

Cadence Cloud-Hosted allowed Syntiant to easily produce their test chips with Virtuoso, and use SystemC for their system modeling needs. They ended up using SystemC to build their full system model, taking advantage of SystemC’s object-oriented source language in C++. On top of that, Cadence Cloud-Hosted also allowed for their source code to be co-compiled into Python for use with Tensorflow.

The Cadence Cloud-Hosted Design Solution changed everything for Syntiant. The Virtuoso and Stratus environment let them ramp up quickly, understand the technology, make sound decisions and build up to substantial models in record time. On top of that, using the Cadence Cloud-Hosted Design Solution gave them access to Cadence AEs for assistance.

Six months to tapeout is no laughing matter. If you’re done joking around with inefficient flows, read more on the Cadence Cloud here.

We’re going to take a wild guess and say you’ve been in a meeting before. Maybe it was a virtual meeting—but those never really feel the same in person, do they? Attending a virtual meeting can feel cold and impersonal, especially since you can barely see everyone else. Everyone is there except you—and even then, saying you’re “there” is a bit of a stretch.

Nowadays, though, there’s technology to remedy this problem. Panoramic video systems fill this need by providing 180 degrees of video field range—and the newest offering from Altia Systems has so much more than just that: it is the world’s first 4K Plug-and-Play USB camera system, the PanaCast 2.  It delivers ultra-fast video with a natural human perspective, and in two years, has grown to over 1400 customers in 41 countries.

This thing has some serious specs: 300 million pixels, more than eight processors, 30+ patents behind its creation, and three imaging sensors—all for under $1000 a unit. Each camera has an angle of overlap that allows it to cover a 180-degree range, and those views are stitched together with an image stitching algorithm that pieces together the final video in 5 milliseconds. It’s UVC compliant, works right after plug-in, and is compatible with cloud or on-premises conference services.

Figure 1: The specifications of the PanaCast 2

So: how do you build something like this? Well, the parts are certainly complicated enough. You need a built-in AI for anti-aliasing, minimal distortion and a natural perspective to ensure a comfortable image, and everyone needs to be in the conversation—you’ve got to be able to see everything, and that means 100% space utilization.

That’s a serious task for the verification engineers—but luckily for them, Altia Systems used Xcelium Parallel Simulator for this, and got it done fast.

The PanaCast 2 required an exceptionally complex test bench—with between 3-6 image sensor models, multiple MIPI interfaces, and DDR3/DDR4 models. On top of that, each frame of video is quite large, at between 2-8 megapixels each. The design also contained a complex mix of Verilog, SystemVerilog, and Netlists, alongside several gate-level macros within a Xilinx FPGA.

Those engineers had quite the job ahead of them.

With Incisive, it would take 5-6 hours to simulate each frame; 19 hours if we’re talking about the 3 – 4 frames needed for video verification. On top of that, exported waveform files were 50 GB, creating a real strain on data storage.

Altia Systems worked with Cadence AEs to help pare down their load; bringing those waveform files down to between 1 and 10 GB, and achieving a 1.25x speedup on their single-core simulation needs right out of the box using Xcelium.

So: what’s next for Altia Systems and their journey with Xcelium? They expect that their performance needs will vastly increase. Frame sizes are going to go from 2 megapixels to somewhere between 13 and 16; plus, there’ll be new features and DSP cores for the next generation of cameras.

To help, they plan to use some of the sweet new features Xcelium brings to the table: Save/restart functionality will give them checkpointing, to help speed up their debug turnaround. Multi-threading and multi-core waveform dumping will give them extra info to look at. Lastly, Xcelium’s famous multi-core speedup will be put to the test.

Altia Systems has only scratched the surface of what Xcelium can do for them with the PanaCast 2—as Altia Systems moves on to their next endeavors, the unmatched power and speed of Xcelium can only send them to new heights.

Let’s say that you got an invitation from the police station nearest your home to be there the next day at 14:00. Hmm…. What could it be about? You check the letter and envelope for more information, but it does not say which department sent it. Well, it makes a big difference if the invitation was from the “lost and found” department, which means you will probably get something back, or if it came from “investigations department” which might mean you are in trouble. Yes indeed, the context or the source could make a big difference. And that’s the point.  

To what is this similar in the Specman world? Well, if you were attempting to use a list of input TLM analysis ports (interface_port of tlm_analysis), before Specman 18.03 you had no way of knowing which exact port from the list got the data; the write method only provided you with the data received, without any context. As of Specman 18.03, you also get the context.

 But before we move on with the new syntax, let’s start first with some background. If you do not need this background, feel free to “jump” to the last paragraph.

TLM analysis ports are mainly used to connect monitors to other monitors, to checkers and to scoreboards. If the DUT has one input and one output, your scoreboard would have one Add port connected to the monitor (collecting the data sent to the DUT), and one Match port connected to the monitor (collecting the data received from the DUT). But if the DUT has more than one input and one output interface? Then you need to instantiate, for example, 3 Add ports and 3 Match ports and implement a different write method for each.

unit MySCBD{

add_port_0 : in interface_port of tlm_analysis of (packet) using suffix=_0 is instance;

add_port_1 : in interface_port of tlm_analysis of (packet) using suffix=_1 is instance;

//….add additional declaration for the rest of the ports

write_0(p:packet) is {

   // implementation for items coming from DUT output #0

};

write_1(p:packet) is {

   // implementation for items coming from DUT output #1

};

//…add additional write methods for the rest of the ports

Well, this is a lot of code and in the Specman world, we do not like a lot of code.  It is true that if you were using UVM-e Scoreboard, you could already use macros doing most of the work for you, but it is still an overhead. Moreover, what if the environment topology is configurable – in some tests the DUT has 3 outputs, and in some – 4. How would you write the code for this? Can you avoid writing additional code? In few seconds (or few lines to be more accurate…) you will see how easily it can be done. 

 You don’t have to instantiate each port, there is a way to make your life simpler- you could define a list of tlm_analysis ports even before Specman 18.03, however look at the following code and search for information which is missing:

unit MySCBD{

addPorts : list of in interface_port of tlm_analysis of (packet) using suffix=_Add is instance;

keep addPorts .size() == 3;

matchPorts : list of in interface_port of tlm_analysis of (packet) using suffix=_Match is instance;

keep matchPorts.size() == 3;

connect_ports() is also {

      //connect the ports to the monitors

    };

write_Add(p:packet) is {

       // implementation for item coming from an Add port

 };

write_Match(p:packet) is {

    // implementation for item coming from a Match port };

First, you can see that using lists of ports it is easy to add a port- you just need to change the constraint on the list size. However, back to my question of what is missing- you get the data in the write method, but you do not know from which port it was coming from (remember the first paragraph of getting an envelope without knowing the exact source?)…

 Starting from Specman 18.03, you do have a way of knowing the source, meaning from which port this was received. What you need to do is to add the using context option to the definition of the list of ports, and implement the new write method which, in addition to the data, provides the relevant port which received the data. Now you can respond differently according to the source of this data.

unit MySCBD{

addPorts : list of in interface_port of tlm_analysis of (packet) using suffix=_Add using context  is instance;

keep addPorts .size() == 3;

matchPorts : list of in interface_port of tlm_analysis of (packet) using suffix=_Match using context  is instance;

keep matchPorts.size() == 3;

connect_ports() is also {

      //connect the ports to the monitors

    };

 write_Add(p:packet, port: any_interface_port) is {

    // implementation for item coming from an Add port

        if (port == addPorts [0] ) {

            //….

        } else if (port == addPorts [1] ) {

           //…

        } else{

          //…

        }

 };

 write_Match(p:packet,port: any_interface_port) is {

    // implementation for item coming from an Match port

        if (port == matchPorts [0] ) {

            //….

        } else if (port == matchPorts [1] ) {

           //…

        } else{

          //…

        }

 };

 I strongly recommend you check out the What’s New? section to find out what else we have added in Specman 18.03.

Orit Kirshenberg

Specman team

You may have heard about the overhaul to the old save/restart mechanism that was in Incisive—but are you aware of what the new Xcelium Simulator version can do?

While the old version is still supported, there’s a lot of benefits to shifting to the new one. Now called “checkpointing,” this new system uses a process-based implementation and is overviewed in the app note, Using Save/Restart Checkpointing with Xcelium.

If you’re still using that old save/restart functionality, you’re probably already aware of some of the issues and shortcomings of that system. You could only save or restart at a “clean” point, which limited when you could actually save. It also didn’t save any states from any of your external code—so your C/C++/SystemC code needed to be re-run, and you’ll have to manually scrub your output files. There were also issues with certain basic system tasks that weren’t supported.

Xcelium’s checkpointing system solves these issues and others, creating a smoother, better-integrated solution that’s a good fit for any environment.

To enable the new checkpointing system just use the -checkpoint_enable run-time switch. Once you’ve done that, there are a couple of ways to invoke the new checkpointing system.

From tcl, just use the save command as before. You can also put the $save system task in your Verilog code. If that task is present at elaboration time, wherever the $save system task is called, checkpointing will be used to save the snapshot.

With checkpointing, the memory state of the entire model is saved—no more worrying about your external code! This includes the state of any files being read or written. That means the read/write pointers of any associated files are saved. in a warm restart, your output will pick up right where it left off at the save action. In a cold restart, you can choose to start with a fresh log file by specifying a different log file name from what was used at the time of save, or opt for a continuous log file from before the save through post-restart by using the same one.

There are two issues still in the works with Xcelium’s new checkpointing. One is that the new images created through this checkpointing system are much larger than the old ones. That said, you can use the -zlib option with xrun to compress the image. The images are still very large even when compressed, though, so be sure to watch your disk space usage if you’re saving multiple times. You can read more about -zlib in the Xcelium User Guide.

If you need multi-threading, stay tuned—it will be available in the next few weeks.

If you want to read more about Xcelium’s new save/restart functionality, check out the app note here.

Today, Cadence announced three new VIPs, two of which are industry-firsts! Cadence revealed the first available VIP for CoaXPress for high-speed imaging and the first available VIP for HyperRAM high-speed memory. We also unveiled a new JEDEC Universal Flash Storage 3.0 (UFS) VIP. Together, these three new VIPs allow early-adopters to leap off the starting line in the race to create new, incredible SoCs and IPs incorporating these revolutionary new technologies.

CoaXPress is great for imaging technology needs. With the rise of automated driving technology, lightning-fast transfer and analysis of videos and images is more important than ever—and with speeds of up to 6.25 Gbit/s, CoaXPress is uniquely positioned to fill that need. Combine that with Cadence’s TripleCheck technology, and you’ve got a VIP worth integrating into your next project.

HyperRAM is a HyperBus-based read performance memory with speeds of up to 333 MB/s. Applications including automotive, industrial, and consumer applications that focus on a small footprint are a great fit for HyperRAM VIP.

The UFS 3.0 spec doubles the throughput bandwidth from 1.3 GB/s (in the old spec) to 2.6 GB/s. This’ll be a big help to the rapidly growing need for bandwidth and low-power SoCs—for both automotive and mobile designs. And don’t worry—this VIP still utilizes the Cadence TripleCheck  technology you know and love.

To read the full press release for all three of these new VIPs, check here.

Specman constraints solver process consists of a series of reductionsand assignments. It reducesthe range of the field value based on the constraints, and then assignsto it a random value from the reduced range. After assigning one field, the range of all connected fields is reduced accordingly, and the process continues until all fields are assigned.

A new feature added in Specman 18.03 – Range Generated Fields (RGF)- allows distinction between the reductionsand the assignments. With RGF, the constraint solver performs the reduction as usual but we have the option to do the assignment ourselves.

Let’s look at a simple example of the reduction and assignment process. The example defines three fields and some constraints.

   val_x  : uint;
  val_y  : uint;
  val_z  : uint;

  keep val_x in [5000..10000];
  keep val_z in [500..8000];
  keep val_y >= val_x;
  keep val_y <= val_z;

 The steps of generating one item are shown below (this information can be easily retrieved using the “trace gen” command):

reducing: val_x -> [5000..10000]       // applying constraint #1
reducing: val_z -> [500..8000]         // applying constraint #2
reducing: val_y -> [5000..8000]        // applying constraints #3 & #4
reducing: val_x -> [5000..8000]        // applying constraints #3 & #4
reducing: val_z -> [5000..8000]        // applying constraints #3 & #4
assigningval_z: [5000..8000] -> 6419  // picking randomly from range
reducing: val_y -> [5000..6419]        // applying constraints #4
assigningval_y: [5000..6419] -> 5693  // picking randomly from range
reducing: val_x -> [5000..5693]        // applying constraint #3
assigningval_x: [5000..5693] -> 5471  // picking randomly from range

As seen in the given example, we usually let the constraint solver to do all the work for us, including reducing all ranges and assigning values to all fields. However, in some cases we want to perform the last decision of assigning values ourselves by deciding which value from the reduced range to assign to the field.

In this blog post, we will look at some examples of flows in which the Range Generated Fields are helpful. In these examples, we will take the final decision of assigning a value from the reduced range to the field ourselves.

Rapid Creation of Altered Input

When testbench performance is crucial, for example in acceleration verification, we look for ways to boost the input generation. On one hand – we want to use the constraint solver, ensuring only legal data is created. On the other hand – using the constraint solver has a cost in performance.

Let’s change a bit the example shown above, and mark the val_x as an RGF field, by writing ~ before it:

  ~val_x  : uint;
   val_y  : uint;
   val_z  : uint;

Now the constraint solver will not only generate the struct, it will also maintain the information of the reduced range of val_x ([5000..5693], for example). After marking the field as RGF, we can generate the struct once and create many copies of it, in each of them picking one value from the reduced range and assigning it to val_x. This way we create many instances that are almost identical, differ in one essential field. We know all instances are legal - we ensure this by picking values only from the reduced range as it was calculated by the constraint solver.

For getting the reduced range we use a new method of any_struct– rgf_get_range(). This method returns the reduced range of the field. Note that this method is valid only for fields marked as RGF. To assign the field we use the new assignment operator rgf= and not a regular assignment (=). Using rgf= Specman checks that the assigned value is in the reduced range as it was calculated by the constraint solver.

   main_tcm() @clk is {
      var trans : trans;
      gen trans;
      // get the reduced range of val_x
      var reduced_range :=  rgf_get_range(trans.val_x);  

      var copied_trans : trans;
      var one_val_x : uint;
      
      // create many copies, in each of them give a different
      // value picked from the reduced range
      for i from 0 to 10000 {
         copied_trans = trans.copy();
         gen one_val_x keeping {
            it in reduced_range;
         };
         copied_trans.val_x rgf= one_val_x;
         send(copied_trans);
      };
   };  

 “Optional Assignment” - Does the user really want this value?

As described above, the constraint solver assigns values to all fields.  If there are no constraints on the field, the constraint solver would pick a random value from the type initial range. In some cases, you wish to know if the field got its value as a result of user constraints, and if no constraints were applied to this field, we will apply some predefined policy.  Until now, to implement this methodology you would add a designated field, e.g. “use _address”, and instruct the test writers to constrain this field to TRUE indicating “yes, I wrote constraints on address field”. If use_address is FALSE – it means that its value was assigned fully randomly by the constraint solver and in this case the testbench would apply some predefined policy.

Using RGF, we do not need such an auxiliary field. We mark the field as RGF and then we query whether the field range was reduced.

In the following example we use two new methods of any_struct– first is rgf_was_generated(), indicating whether the struct was evaluated by the constraint solver (and not created using ‘new’). After establishing that indeed it was generated – we call rgf_got_reduced(), returning TRUE if the struct’s final range differs from the original range (indicating that constrains were applied on it).  

   struct trans {
      ~address : address_t;
      // other fields …
   };

   unit agent {
      send(t : trans) is {
        if rgf_was_generated(t.address) {
          if rgf_was_reduced(t.address) {
             // reduced, meaning there were user constraints
             // on it, so send as is
          } else {
             // no user constraints were applied on the address field
             // so execute my default addressing policy
             t.address rgf= me.config.get_prefered_address();
          };
        };
       //// continue with sending this trans ….
     };
   };

Combining Power of Constraints with Other Algorithms

The last use model we will describe here, is the one in which we want to employ the power of the constraint solver with some complex algorithm. Some algorithms can be expressed with constraints, but this is not always the truth. Today, you have to decide whether a field is to be constrained or to be assigned procedurally applying some smart algorithm. Using RGF, we can mix both by letting the constraint solver reduce the range of the field and then calling some smart algorithm (even one implemented in another language) to pick one value from the reduced range.

In the following example, mem_block kind field is marked as RGF. After the mem_block is generated, we allocate it in the memory using a C routine named alloc_memory(). We pick random values from the kind reduced range until the memory allocator succeeds allocating a block of the requested kind. (To make the code example short, we skip the code that is required to ensure we do not get into an endless loop).

   routine alloc_memory(mem_block : mem_block): bool is C routine alloc_mem;

   struct mem_block {
      ~kind : mem_kind;
       size : uint;
      // additional fields and constraints …
   };

   extend agent {
      add_mem_block(block : mem_block) is {
         if rgf_was_generated(block.kind) {
            var a_kind : mem_kind;
            var assigned : bool = FALSE;
            while not assigned {
              gen a_kind keeping {it in rgf_get_range(block.kind)};
              if alloc_memory (a_kind, block) {
                assigned = TRUE;
              };
            };
            block.kind rgf= a_kind;
         };
      };
   };

As described in the above examples, Range Generated Fields (RGF) provide extra power to the generation process. When analyzing your environment and methodology to decide which fields should be marked as RGF, keep in mind that there are a few issues to be considered:

• Firstly, there cannot be more than one RGF field in a constraint.
• Secondly, if there is an unconditional == constraint between an RGF field and a generative field (i.e. constraints such as "keep sz == len/3", when 'sz' is an RGF), then RGF's range will always be a single value. Therefore, in these cases there is no advantage in marking such a field as RGF.

We are sure you will find great ways to employ this new powerful capability of RGF and continue to enjoy verification using Specman  J

Welcome back to a special multi-part edition of the App Note Spotlight, where we’ll continue highlighting an interesting app note that you may have overlooked—Simulation Performance Coding Guidelines for SystemVerilog. This app note overviews all sorts of coding guidelines and helpful tips to help optimize your SystemVerilog code’s performance. These strategies aren’t specific to just the Xcelium Parallel Simulator—in fact, they’ll help you no matter what simulator you’re using.

In this section, we’ll talk semantics—but these aren’t throwaway details, they’re SystemVerilog semantics. These are some small things that can show up here and there that can speed up your code without a whole lot of extra effort.

1)      Be Explicit with the Storage of Logic Types

SystemVerilog has a special data type called the logic data type. When a logic type is being used as a wire, you want to be explicit about it, otherwise SystemVerilog says you will get a variable. You don’t technically have to explicitly declare whether you’re using wire storage or variable storage, as the storage can be determined by context, but it’s much faster to choose one at the declaration. The biggest slowdowns caused by implicitly-declared logic types occur when a logic type is being used as a wire, without actually being declared as such. There’s a pretty simple solution here: make sure you declare it as a wire!

As a special note: when you’re profiling your design, (that’s with -profile, or -xmprof if you’re using Xcelium), places where this issue occurs will be flagged as Anonymous Continuous Assignments (ACAs).

2)      Avoid Bit-Blasting Vectors

Here’s another simple one: make sure your operations use the full vector instead of just operating on individual bits whenever possible. While SystemVerilog has constructs, such as generates, which make it easy to operate on individual bits of a vector, it’s often times just as easy to simply run your operations on the full vector instead, and it’s faster, too. The compiler generally won’t give you trouble if your use case is simple.

3)      Minimize String Formatting

SystemVerilog does provide string objects, but formatting these strings is a very expensive operation. String objects have a lot of useful features for writing messages in your verification environment—so using them occasionally isn’t the end of the world—but keep them to a minimum.

As an example: make sure your code only does whatever formatting is required in the event that the string object is actually used. And, when you are running regressions, where farm throughput is critical, make sure you are not wasting time formatting messages instead of doing real work.

4)      Pass Array Objects by Reference

SystemVerilog doesn’t specifically have “pointers” as they’re understood in other languages. That means you can’t create a reference to an object through syntax, but you can specify a function or a task argument as a reference. When the object is simple and small, like an integer or a class handle, it’s faster to pass it by value, but for larger objects, passing by reference is the less expensive operation.

That’s all we have for today—check back soon for a couple more helpful tips!

Services like facial detection, efficient cloud server workload management, artificial intelligence, and image enhancement are all the rage these days; but creating a design to accommodate these needs can be incredibly taxing on your engineering resources. Luckily, Netspeed Systems is here to help.

The devices being designed nowadays are more complicated than ever, and the design requirements are more complex, too. Designers that want the highest performance, multi-core capabilities, mixed traffic requirements, and other features all delivered with either CPUs or GPUs need more. Designers today need a mix of both, for each of their strengths—they need heterogenous computing.

Services like facial detection, efficient cloud server workload management, and image enhancement all call upon heterogenous computing to meet their complex needs. Designers want to use GPUs for easily parallelized data and big data, while they also want CPUs for smaller data and highly-structured, non-parallelizable data. There’s also issues with efficient memory management and maintaining cache coherencies without compromising system-level quality-of-service.

This is where NetSpeed Gemini comes in.

Gemini is highly configurable—you can easily set your cache hierarchies and ensure caching and coherency participation. Its distributed architecture makes for lower latency and allows for floorplan-aware configurable cache hierarchies.

This is all pretty cool—but you still need software automation to help avoid deadlock in this complex computational platform. The burning question is: how do you know when you’re done with the verification? Netspeed’s architectural design approach seeks to answer exactly that question. You begin with a specification of your architectural requirements; then, Netspeed helps you weigh the different tradeoffs and explore the design space so you can find the best solution for your project. Then, you can get design feedback at any step of the process. This way, you can create and reach concrete goals.

The Netspeed platform has its own built-in simulator, called the Integrated Performance Simulator. This simulator—and its accompanying SystemC model—are great if you don’t have a solid grasp of your traffic requirements yet, and things are still a little more abstract. But, if you’re looking for something more precise, you want Verilog simulation—and the best way to get that is through the Cadence Interconnect Workbench (IWB). Cadence IWB gets you cycle accurate performance analysis, protocol checking via VIP, data consistency checking via IVD, and loads more—and it’s easy to execute on Xcelium or Palladium XP II or Z1. You can get great graphs showing your workload-base traffic simulations, alongside other data analytics to help you identify and fix your performance bottlenecks.

Next-generation applications are driving us to next generation architectures. Devices have caches everywhere, and they’re all snooping each other—how can you expect to keep coherency in that kind of chaos? With next-generation performance analysis—the kind brought to you by Cadence IWB and NetSpeed.

For more information on Netspeed Gemini, check here; for more information on the Cadence Interconnect Workbench, check here.

One animation video - Patch Like The Wind -  is worth a thousand words :)

If you don’t use Specman or don’t use Specman correctly, you spend most of your time waiting for compilation to finish.

One of the most frustrating (and common…) scenarios is when you know more or less what the fix should be (such as, “wait additional cycle before sending” or “the variable should be int and not uint”) and the fix can be done in a matter of minutes. However, you are forced to spend hours waiting for the compilation to end in order to analyze the results and decide if you are satisfied with the fix. While fixing the code, usually you do not write the exact right code the first time. So, you adjust your code – another matter of few minutes – and then you have few more hours to wait for compilation.

Horrifying.

But not if you use Specman.

With Specman, you can fix a file loaded on top of the compiled environment. Here, you don’t need to wait for hours of compilation. You can create a small ‘patch’ file, in which you implement the changes, and then you can load this patch file on top of the compiled environment. Once you are happy with the changes you made – you can move the fixed code to the relevant file/s and compile. Loading one or two files instead of compiling the whole environment can save you hours, if not days, for every fix of your code.

If you want to save some more time – don’t run the test from the start. Save the test before the interesting point (before sending the item, when calling the checker), and dynamic load the fixed file.

The capability to modify the testbench with code loaded on top is also very helpful when it comes to getting fixes from other teams/companies. Instead of waiting for the VIP or any other tool provider to create a fixed version – they send you one e file which you can load on top. Even Specman, as it is written in e, can be extended with patches. No need to wait for an official hot fix - you can get a patch file from the Support team with the required fix.  

Yes, this is no news to Specman users. In meetings with Specman users, asking them “What is your favorite feature?”, one of the top answers is “the Great Patching Capability”.

Next time you are asked “Are you still using Specman?”, you can reply “Sure, and are you still compiling?”