|
A friend of mine once recommended me a book. It was The Tipping Point by Malcolm Gladwell. It sounded interesting, so I decided to put it on my reading list. Somehow the existence of my reading list came to the knowledge of a family member, I swear I don't know how. One thing led to another and by weird coincidence, on my next birthday I got this book as a present. I haven't yet found the time to read it from cover to cover, though I think I've read the first chapter a few times. I guess I'll just have to take it with on my next vacation.
|
|
|
Things are changing. The EDA industry is undergoing a paradigm shift. John Bruggerman’s visionary document talks about the application-driven market and how EDA should become its enabler and Janick Bergeron's inspiring talk at SNUG San Jose gives us a glimpse of the future of verification. One of the major challenges we’re already facing today is an increasing number of IP blocks in a single system. Designs are getting bigger and bigger, and the focus is shifting towards system level integration rather than “design creation”.
|
|
Is Assertion-Based Verification (ABV) becoming mainstream? This question popped up today at Mentor’s ABV seminar. Assertions in general and ABV in particular make another approach that you can use to verify your design. Usually ABV alone is not sufficient, and is used alongside other verification approaches such as Coverage-Driven Verification, Directed Testing, Formal Verification, and Code Coverage. What’s good about ABV though, is that it’s the fastest tool around in terms of failure-to-root-cause time (also in your testbench!)
|
|
|
This is a cool little utility that will make your SystemVerilog look much more professional. It simply adds an end-of-method identifier (label) to every task or function so that every endfunction turns into endfunction : function_name (with the appropriate function_name of course.. Duh!) and endtask turns into endtask : task_name. This really makes your code more readable and consistent.
|
|
Coverage driven verification has a big advantage – you can write a single test, and let run it several times with random seeds. Each run will generate a slightly different scenario – depending on the nature of the constraints you provided. I’ve talked about the pros and cons of excessive use of coverage driven methods here and here. Anyway, sometimes you just want to take an existing test and quickly create a number of variants off of it to make a small regression suite (that you might even throw away later on). For example – you could have a basic test that does some CPU writes and then drives random frames. During configuration you write to a register that sets the FIFO level and you want to have 10 different tests, each writes a different value to this register.
|
|
|
|
|
|
|
Page 1 of 8 |
Articles
