|
Time to talk about module-to-system reuse, a very important topic. If you plan your verification environment properly (using one of the common methodologies in the market today or your own) you’ll be able to easily build a system level verification environment that reuses most of your module level environments (i.e. sub-environments). However, even if all your sub-environments are well suited for plug and play reuse at the top level, there are still considerations to be made regarding the overall topology. In other words, how do you go about connecting the sub-environments to each other to make an effective top level environment? Here are 3 methods that you can use.
|
|
|
If you’re looking for an outsourcing solution for your verification problem then a quick look around will tell you that there are many alternatives out there. The number of verification contractors has grown rapidly over the recent years and today you can find anything from freelance contractors through big consulting companies with tens or sometimes hundreds of engineers offering various service models and packages, off-site and on-site, hourly-based , fixed price, turnkey, and so on. How do you know what’s good for you? Here are a few quick tips:
|
|
You’ve developed a verification environment, hooked up the DUT, written a bunch of tests and alas! Simulations start to fail So just before you dive in, Think Verification’s tips department recommends the following:
|
|
|
If you’re using Specman GUI to run simulations you must have encountered this rather annoying feature before - When running several simulations during the same session, specman doesn’t clear the log file by default so what you get in the end is a concatenation of all log files which makes it kind of - how to put it nicely - useless.
|
|
Here’s a cool (and free) application that can make your life a bit more organized if you tend to have many open windows.
|
|
|
|
|
|
|
Page 1 of 2 |
Tips
