Archive for category Verification

Welcome to Trusster 3.0

We have finally updated the Content Management System running our website. The old site became unmanageable for two over-worked engineers. With this new system we will have better control over spam together with better more integrated discussion forums. We also like the layout better. Please help us improve our site by reporting any issues you find.

To our registered users: While we where able to propagate all current users we couldn’t propagate the passwords so please keep an eye out for an e-mail with information on your new temporary password.

It is out intent to bring our site back to life and hopefully over time bring our forums back alive. Both Mike and I are still heavily if quietly involved with Teal and Truss. We use it in our daily professional lives. Mike currently use our C++ (and SystemC) libraries and I use our System Verilog version. Both incarnations are rather stable at this point and provide a great starting point for powerful but simple to use DV environment.

Regards

Robert

Webinar – Verification Code Longevity: Learn Expert Techniques

I’ll be doing a webinar on how to make code last! It is based on the “Thinking OOP” chapter of our book.

——————– North America —————————————-
Date : August 27, 2009
Time : 11:00 am – 12:00 pm Pacific Daylight Time (USA)

——————— Europe ———————————————-
Date : August 27, 2009
Time : 3:00 pm – 4:00 pm Central European Summer Time


Abstract :
It seems that we always have to rewrite verification code that we did on
a previous project. Why? What can we do to minimize code changes? In
this webinar, international author Mike Mintz shares Expert Techniques,
based on OOP (Object Oriented Programming) that he uses to make code
last. We’ll take a look at how to write adaptable monitors and checkers.
Mike will show how to maximize the probability that your code can be
adapted to other projects.

Agenda :

* Introduction
* What is bit rot?
* Adaptable versus Reusable code
* Minimizing your assumptions to Maximize Adaptability
* Canonical Monitors and Checkers
* Aldec RTL Simulators & Design Rule Checking
* Question and Answer Session

View All Aldec Events: http://www.aldec.com/Events

Regarding Code coverage running in Modelsim 6.3f..

Hi,

Can any one tell me which version of modelsim supports codecoverage option.
Actually i am using modelsim 6.3f[Special Edition] version. I face problems when trying do a codecoverage.

I would like to know the version number and edition number for both verilog and System verilog.

Regards,
Aathi

Verilog Testbench with VHDL DUT

I wasn’t quite sure where to post this in the forum so here it goes.

My question has to do with interfacing a Verilog testbench to a VHDL DUT. This is easy to do when the VHDL entity has normal port signals such as bit_vector, std_logic_vector, and std_logic. However to keep my design clean I make extensive use of records in VHDL. This has caused considerable headache when I try to instantiate the VHDL entity in the verilog testbench, which I still haven’t figured out how to do. I’m by no means a verilog expert but I did find out that verilog does not have an equivalent to records, just a way of faking them. I was wondering if the designers of Teal had run into the same problem and what solutions they ended up using?

Thanks,
Brian

C++ or SystemVerilog??

I’m not quite sure if this question has been asked before but I’d like to hear what the opinion of the user group is. For verification of a SoC design, what are the pros and cons of using a C++/SystemC based method as opposed to SystemVerilog? I have about equal experience in C programming and VHDL so it’s going to require a certain amount of learning to get either approach up and running. But what I’m looking for is some opinions as to what people have found to work for them, what industry seems to be gravitating to, and perhaps additional resources that would give me a better defined reasons to pick one over the other.

Thanks,

Brian

Mentor Graphics New England User Group Meeting Presentation

Mike and I attended Mentor Graphics New England Users Group Meeting yesterday and mike did a small presentation about Teal and Truss. For reference these were the slides Mike presented. It’s always interesting to give a presentation and I think we’re getting better each time we try. This presentation I think better highlighted the thinking behind teal and truss while also giving a decent overview.

Regards,

/Robert

Use of OOP to eliminate need to compile C++ simulation

I would appreciate your comments on a different approach to hardware simulation.

My examples are coded in C# (an OOP that is like a fraternal twin to C++). C# Express 2005 is a free download from Microsoft and is easy to learn. I also have a C++ version, but have not used as much OOP.

I think the interesting notion here is that the simulator/hardware can run on a thread with verification on another — everything in OOP C++.

I am an old retired hardware guy self taught in C++ so I’m not up to speed with some of your lingo.
Hardware design and simulation are still in my blood.

First, the simulator does not use a programming language that has to be learned and compiled. Instead it is a collection of facilities ( flip-flops, registers, arrays, etc) that have Boolean/arithmetic statements describing their controls and inputs. The input phase assigns an ID# to each, the statements are parsed and a stack is created so the statements can be interpretatively evaluated at runtime.

At runtime objects are created and put in arrays or lists that are accessed by index or iterators.

Clocking is a C1/C2 scheme where C1 time determines the facility state that will be assigned at C2 time. Multiple clocks are allowed so that asynchronous, edge triggered, latch operations are permitted.

Functional delays (delay lines, long cables, etc) can be used.

Circuit delays are not used. Instead static timing analysis would be used to identify long paths that would determine cycle time. After all, placement in physical design will have major timing effects anyway.

The porting and wiring is implicit in the input statements so that back tracing the input can produce a net list or whatever is needed for synthesis. (Hypothesis)

The level of abstraction is a matter of the operators used in the statements. +, -, *, /, etc can be used at the system level, then later reduced to and/or/not operations..

There are C++ (Express and MFC) and C# versions implemenmted so that a driver could be added to generate inputs and verify outputs.

I do have running programs and several testcases available. ( Think I can upload them to a Web page for download or else post them as file attachments) The program is small and quick. It does need a simple GUI front end to isolate the user from syntax details.

I hope not to have wasted too much of your time, and welcome questions.

Thankyou, Karl Stevens

Book excerpt on Teal and Truss available!

Hardware Verification with C++ Book Cover Hardware Verification with SystemVerilog Book CoverWe’re happy announce that the teal and truss section of both our C++ and SystemVerilog books are on the downloads page!

Apart from providing a preview of our style, they also provide documentation for our open-source libraries.

So to get a feel for what our books are like and to find out more details about our verification libraries teal and truss, and what “the dance” is all about, simply download either the C++ or SystemVerilog sections from our downloads page.

You can also access the chapters for teal and truss for C++ by following this link, or if you are interested in SystemVerilog follow this link.

So if these section are free, what else are in the books? Well, the section dealing with teal and truss is less then a 1/4 of the books. Most of the books could care less about our verification libraries but instead talk about how to best apply Object Oriented Programming (OOP) to Verification. We provide many code examples as well as lessons learned with the hope that you can avoid some of the pit-falls we encountered.

In fact, both our C++ and SystemVerilog verification books share the same format and are divided into four parts. The chapters provided for download are the second part of the book. In case you are curious, the four parts are:

  • Part one provides and overview of Object Oriented Programming (OOP) concepts and conceptually looks at how a high level white-board block-diagram drawing can be turned into classes and code, as well as a short history of how verification has developed.
  • Part two describes our open source verification libraries. We talk about our verification libraries in the books to show what a real, professional verification system looks like. Our hope is that people will find our libraries and ideas useful and adapt (parts of) them, or at least serve as inspiration or contrast too their actual environments. A lot of experience and industry best-practice ideas has gone into creating these libraries.
  • Part three shows how to use OOP for Verification. It’s full of lessons learned, tips-and-tricks from years of experience using OOP in both HW verification and SW development fields and multitude of projects.
  • Part four provides several complete verification environment examples too give the reader a sense for what an OOP verification environment looks like put together. As we provide the complete environment (including run scripts) we hope people can find useful code and ideas from them.

Happy reading!

Hardware Verification With SystemVerilog — An Object Oriented Framework

Hardware Verification with SystemVerilog Book Cover New! The two chapters describing teal and truss, our open-source verification libraries can be downloaded here

Verification is increasingly complex, and SystemVerilog is one of the languages that the verification community is turning to. However, no language by itself can guarantee success without proper techniques. Object-oriented programming (OOP), with its focus on managing complexity, is ideally suited to this task.

With this handbook — the first to focus on applying OOP to SystemVerilog—we’ll show how to manage complexity by using layers of abstraction and base classes. By adapting these techniques, you will write more “reasonable” code, and build efficient and reusable verification components.

Both a learning tool and a reference, this handbook contains hundreds of real-world code snippets and three professional verification-system examples. You can copy and paste from these examples, which are all based on an open-source, vendor neutral
framework (with code freely available at www.trusster.com).

Learn about Object-oriented techniques such as these:

  • Creating classes—code interfaces, factory functions, reuse
  • Connecting classes—pointers, inheritance, channels
  • Using “correct by construction”—strong typing, base classes
  • Packaging it up—singletons, static methods, packages


“This handbook guides the user in applying OOP techniques for verification. Mike and Robert have captured their years of experience in a clear and easy-to-read handbook. The examples are complete, and the code is available for you to get started right away. Highly recommended.”
– Thomas D. Tessier, President,
t2design, Inc.


“This handbook contains a lot of useful advice for any verification engineer wanting to create a class-based testbench, regardless of the framework/methodology used. I recommend Hardware Verification with SystemVerilog to anyone who wants a greater understanding of how best to use OOP with SystemVerilog.”

– Dr David Long, Senior Consultant,
Doulos


“This is a fantastic book that not only shows how to use SystemVerilog and Object-Oriented Programming for verification, but also provides practical examples that are open source!”

– Stephanie Waters, Field Applications Engineer,
Cadence Design Systems


“I have been using SystemVerilog for two years in my research, and this is by far the best book I have found about how to achieve professional grade verification. I will apply these techniques on my future projects.”

– Dr. Oswaldo Cadenas, Lecturer, Electronic Engineering,
University of Reading, U.K.

Pre-compiled static libraries for teal & truss

Hi, Mike/Robert:
I’m using your teal/truss under WinXP with ModelSim.
I have comp iled your teal library into a single static library file “teal.lib” with VC8 successfully. But I failed to compile the truss framework.
I think it will be very easy for coders to write a testbench if they can link to the pre-compiled static libraries.
OK, finally, the “truss.lib” born after a few days work.
Here is my TIPs about How to compile a “truss.lib” binary static library file:

  • 1. move the
    namespace {
    truss::shutdown* a_shutdown;
    };
    and
    the piece of code (from function “verification_top” to the end) from truss_verification_top.cpp file to the end of truss.h file and define it like:

    #define TEAL_EXPORT(TEST,TESTNAME) \
    truss::shutdown * a_shutdown; \
    void verification_top() \
    { \
    std::string test_name = #TEST_NAME;
    ...
    ...
    } \
    std::string truss::truss_version = "teal_1.40b"; \
    #include "teal_hdl_connect.cpp"

  • 2. Notice the last line in “1.” step, we just remove it and replace it with:

    void force_memory_reference () { \
    teal::memory::lookup ("top.a_sub_module"); \
    } \
    extern "C" __declspec(dllexport) s_tfcell veriusertfs[] = \
    { \
    { usertask, 0, 0, 0, (p_tffn)teal_top_call, 0, "$teal_top", 0, 0, 0 }, \
    { usertask, 0, 0, 0, (p_tffn)teal_memory_note_call, 0, "$teal_memory_note", 0, 0, 0 }, \
    {0} \
    };

    Hahaaaaa the file “teal_hdl_connect.cpp” in no useful anymore.

  • 3. Compile the modified truss into a static library file “truss.lib”.
  • 4. As to users: Just export their top most module like this:
    take alu_test for an example–Just put below line at the end of file alu_test.cpp:

    #include "teal.h"
    #include "truss.h"
    ...
    class alu_test .....
    .....
    TEAL_EXPORT(alu_test,alu_test)

    and compile the verilog file truss_watchdog.v when neccessary.

    That’s all.

    Wish you can intergrate this function into next release:). Then everything will go easy!

    BTW: About the “SEED” in teal_verification_top.cpp file
    Why not generating the SEED like below?

    #include "time.h"
    ...
    time_t seed; time( &seed);
    unsigned __int64 SEED = seed;
    ...

    As you see, the SEED will change once the simulation is starting to run. I think this can generate a REAL random value.

    OK, I post my whole VC80 project here for testing which contain the static library files in Debug and Release version.

    Please download the attachment and rename it back to “trusster_1_40.rar”

    I also fix some bugs in the truss_thread.h file!!

    Good Luck(^_^)