Website Technology Profiler

{
  "PageContent": "Lateral Sands - Verification and UVMThe most important factor in writing a good testplan is… writing it!Write a test plan!Even if your manager doesn’t want you to spend the time, at least spend a few hours to develop bullet points to cover all the features of the device, all the interfaces (and their features) and all the use modes. Some argue that you can only learn a design, system, specification etc by doing.  The answer to that statement is that writing a test plan is doing! It will help you to avoid bad decisions at the start of the project if you have a better idea of the whole problem.The randomization trapDon’t fall into the trap of “letting the randomization catch it”. It’s a common problem these days as test plans in the past often just defined the directed test and what it would do (that doesn’t translate so well to a fully random testbench). A well written plan will outline the situations, sequences, corner cases that need attention, not just the knobs to be randomized.Things to watch forPay particular attention to inter-connects, be they physical interfaces or more functional “interfaces” (ie protocols that are implemented over multiple blocks). When one part of a feature is implemented in one place, by one person, and another part of the feature is implemented in another place by another person (or even another team), the chances of mistakes are very high! Document those high risk areas.Don’t forget to test error cases. We want to make sure that the design does the right thing, but we also want to make sure that it can handle a situation or can be easily recovered when something else does the wrong thing.Identify when error testing is crucial. Sometimes error testing is left to the end “in case we don’t get time”. But there are times when you will identify that errors will happen in the normal use of the design, these cases are crucial (and often difficult) to get right.Keep it up to dateA test plan is a dynamic document, it helps you to see what needs to be done and how to do it, but it will always need to be updated as new things are learned, or the design is changed, or the schedule is changed. Try to keep it up to date as best possible.How to write itEvery company, manager, engineer has their own requirements on what should be in a testplan. Its less important to get bogged down in what is right and what is best. The right and best thing to do is to write a testplan, so you are already most of the way there.A full product testplan and schedule (for pre-silicion verification) should cover who, what, where, when & how.who: Which engineer(s) is doing the workwhat: The definition of what needs to be testedwhere: The environment in which they will be doing it: block level, sub-system level, SOC level, emulation.when: the schedulehow: a description of how they plan on testing itIn most cases you will be writing a sub-part of this entire plan, and we are not going to cover the schedule, so that leaves your testplan to include the what, where and how.Where is the testbench description.  Usually your testplan will only cover one testbench, so a good starting point for your testplan is a brief description of your testbench.  Its (usually) doesn’t need to be a complete documentation of the entire testbench down to each function call etc. Just provide enough for someone new to get an introduction that they can then find things on their own. A diagram, a list of files (or location of files) and a description of what each part of the testbench does.What are the features of the device.  I like to break the device down. In some cases these things will overlap, that’s fine, you can refer to another section for the how. Its always good to list out everything in each category to help make sure you have covered everything. And I can’t stress how important it is to identify and concentrate on interfaces or functional boundaries that are shared with other modules. When two people/devices/modules/concepts need to be in sync, its the most likely place to result in bugs.Large Features / Product Requirementssub-featuresInterfaces to other modulesincluding shared protocols (ie a functional interface, not just a physical interface)sub-features within the interfacesUse CasesProgrammable Registers (CSRs)Programmable Descriptors (memory based descriptors)How the end product will use the systemHow will you test that feature?  This section will depend a lot on the device. Some important things to remember:Write the scope of what needs to be tested in this featureWrite the assumptionsWrite the pass/fail criteriaNote the high risk areas.",
  "Url": "http://verification.lateralsands.com",
  "IpAddress": "173.236.253.36",
  "ReverseDns": "apache2-linus.iad1-shared-b8-46.dreamhost.com",
  "Asn": null,
  "Http2": false,
  "Http3": false,
  "ResponseTimeMs": 511,
  "StatusCode": 200,
  "ServerHeaders": [
    "Apache"
  ],
  "Ssl": {
    "Issuer": null,
    "Subject": null,
    "NotBefore": null,
    "NotAfter": null,
    "SubjectAltNames": [],
    "Hsts": false,
    "Ciphers": [],
    "Protocol": null,
    "DaysUntilExpiry": 0
  },
  "Cdns": [],
  "HostingHints": [],
  "Cms": [
    "WordPress",
    "WordPress (robots.txt)"
  ],
  "Frameworks": [],
  "JsLibraries": [],
  "Analytics": [
    "Google Analytics UA"
  ],
  "AdsAndMarketing": [],
  "PaymentGateways": [],
  "EcommerceHints": [
    "PrestaShop"
  ],
  "SocialSignals": [],
  "MediaProviders": [],
  "SeoTags": [
    "keywords: asic,verification,uvm,contracting,recruiting,systemverilog",
    "content-type: text/html; charset=UTF-8"
  ],
  "HtmlLanguage": "en-US",
  "HasRobots": true,
  "HasSitemap": true,
  "SecurityHeaders": [],
  "CookiesObserved": [],
  "XhrApiHints": [],
  "SitemapCounts": {
    "total_urls": 6
  },
  "ChatWidgets": [],
  "ABTesting": [],
  "PrivacyConsent": [],
  "EmailMarketing": [],
  "WebFonts": [
    "Google Fonts"
  ],
  "DynamicJs": [
    "jQuery (script Resource)",
    "Bootstrap (CSS Classes)",
    "Web Server: Apache",
    "ES6+ JavaScript Features",
    "jQuery (CDN Detection)"
  ],
  "ResourceHosts": [
    "verification.lateralsands.com",
    "s0.wp.com",
    "stats.wp.com",
    "gmpg.org",
    "fonts.googleapis.com",
    "s.w.org",
    "wp.me",
    "v0.wordpress.com",
    "i0.wp.com",
    "i1.wp.com",
    "i2.wp.com",
    "0.gravatar.com"
  ],
  "CssFrameworks": [],
  "BuildTools": [],
  "ServerTech": [
    "PHP (inferred from WordPress)"
  ],
  "DatabaseHints": [],
  "PageTitle": "Lateral Sands - Verification and UVM | Discussing coding styles. Cheatsheets for refreshing verification skills. Verification News etc.",
  "MetaDescription": "The most important factor in writing a good testplan is... writing it! Write a test plan! Even if your manager doesn’t want you to spend the time, at least",
  "ImageCount": 4,
  "ScriptCount": 15,
  "LinkCount": 18,
  "Errors": [],
  "UiFrameworks": [
    "Slate",
    "Bootstrap (Class Names)",
    "Angular Material (Class Names)"
  ]
}