On our list of “to do’s” have always been to put Teal/Truss under web based revision control. We have been putting it off as we have been able to track the changes ourselves. With the amount of code we now “support” that is now hard to do, so we will over the next few weeks put Teal/Truss under on-line revision control. This should also enable us to better track bugs as well as integrate changes from other people.

We are currently leaning towards using subversion but an alternative would be mercurial. We have no direct experience with either so comments would be welcomed. My personal feeling us that subversion is the more common one.

Once we have Teal/Truss code under public revision control we should be able to also have a better bug tracking system. The most common one we have used is bugzilla but if you know of other good ones please let us know.

Hopefully we can get this done shortly as a new release of Teal/Truss for C++ is needed.

Hi, Dear author:
I’m using your Teal lib under Win32 system(WinXP).
You’d better modify the “teal_hdl_connect.cpp” file like below:

teal_hdl_connect.cpp: line 64
...
#ifdef _MSC_VER
extern "C" __declspec(dllexport) s_tfcell veriusertfs[] =
#else
s_tfcell veriusertfs[] =
#endif
...

So the “eriusertfs” will be expoted automatically. No other works should be done by the coders.

About the pthread lib:
I found the “pthreads for win32″ library is necessary for teal under Win32 OS.
Is it possible to use MS windows’ default “CreateThread” APIs instead?

Richard has a good blog about the beginnings of top-down design (in the hardware domain). He talks here about an early experience with VHDL.

I mentioned that top-down design is pretty much what we call ends-in design in our book. It’s just the way most people work. You iterate to a solution that works.

powered by performancing firefox

Hi,

below is a small improvement to the truss script. It will first test for PROJECT_HOME being set. If not set, it will set it to the current path.

That allows to switch projects by just cd into the directory, which might be benfitial for beginners like me with small projects.

This has nothing to do with this subject, but I was wondering whether it would benefit to simplify the forum. There are so many groups, I always have to look where a subject would fit in. I don’t know how other users feel about this?

Cheers,

Guenter

I am looking at Teal/Truss as a solution to a C++ constraint solver. I could not find any documentation on Truss so I am not sure if Truss would be the right way to go. Any pointers will be appreciated. Thanks.

Ok,

Just shot myself in the foot with this one. As you know truss has a randomize() phase that should be used to set-up anything that needs to be randomized. I decided not to use this method/phase for my current test and instead randomized as part of the tests constructor.
Turns out that in truss_verification_top.cpp we don’t set the SEED until after the test has been constructed. So if you call something like RAND_8 or RAND_IN_RANGE in the tests constructor you get random data but it always stays the same even with different SEEDs (at least on my build, it could maybe end up being non-repeatable as well).

Mike and I had a reason for why we don’t set the SEED until after the test is constructed. We wanted the test to be allowed to set the SEED of a simulation. The thinking being that you could create a directed test (from maybe a failing random test) by hard coding the seed (in the test constructor). I guess we didn’t realize the downside of this feature is that you can no longer randomize in the test’s constructor, and I like to use the constructor as initializer.

I’m not sure if this is a “feature” or a bug in truss yet. What do you think?

For now stay away from randomizing in the tests constructor and use the randomize (or any other) phase instead

/Robert

First problem I had was with make. I alias make to make -r, because in my env, I never use built-in rules. For Teal, you definitely need to use the built-in make rules, so unalias make.

The next problem I get is:

Parsing design file 'mutex_test.v'
Error-[UST] Undefined system task
Undefined System Task call to '$teal_memory_note'
"mutex_test.v", 29
1 error


I figured best thing to look at the pli tab:

$ cat pli.tab
$teal_memory_note_call call=teal_memory_note_call
$teal_top call=teal_top_call


To which the solution is to change the pli.tab to the following:

$teal_memory_note call=teal_memory_note_call
$teal_top call=teal_top_call


Then you can run the test using ./run -c -vcs -t mutex_test

However, the test hangs after saying

Thread simple thread 249 on transactor 2 created. ID is 0x1f416bb0 result 0x0


Hitting Ctrl-C seems to unlock the test, but it hangs further along at


[37801 ps][Teal::synch][simple thread 82 on transactor 0][FILE: ./teal_synch.cpp][line: 274][INFO]thread_completed: Thread simple thread 82 on transactor 0


At this point, Ctrl-C Ctrl-D appears to be the only way out. I ran it a second time, and it only went as far as the message:

Thread simple thread 249 on transactor 2 created. ID is 0x1f416bb0 result 0x0


Only ^C ^D could end the sim.

I was able to run the following tests without problems: reg_test, vreg_test, vrandom_test, synch_test, dictionary_test.

Hi Does this work with free Verilog simulator (like GPL Cver)?

Thanks

Yaw

Is it possible to use Teal without a verilog simulator?

I’d like to share my impressions of the book, and a few sparks it lit up in my brain as I was reading it. First I think this book is very important. I’ve always wanted to learn how to get rid of proprietary languages for asic verification, and this book shows me how. IMHO, this book has the potential to change the landscape in asic verification from crippled proprietary languages to the flexibility and power of C++.

The book introduces not only the foundation for building a verification infrastructure using C++ (e.g. random stability, cooperative threading) but also the nuts and bolts of it (e.g. register data types, logging).

I really liked the first 2 chapters, but the real deal for me started in chapter 3 with the first example. I write code for a living, so examples are very important to me. I knew after chapter 3 that I would read the book from cover to cover.

I knew quite a bit of the stuff in chapter 4, so it was a quick read for me.

Chapters 5, 6, 7 and 8 are about teal and truss. I have read them with attention. These chapters confirm that C++ is suited for the kind of work we do in asic verification: environment structure, environment flows, run scripts, etc. The authors show a small example where Perl and make are used to implement run scripts. I have become a big fan of GNU Make after seeing Janick use it. Then I realized I could not only build environments with it, but run test cases as well. For me, it was bye bye duct-tape Perl. I think C++ and Make is a winning combination for asic verification infrastructure.

There is a bit of advocacy for OOP in the book. Since the proprietary solutions converted me to OOP years ago, I read those sections quickly.

I’m at chapter 13 now, so I can’t comment on the rest, but I see lots of code in the coming pages…

I really like when the authors apply common sense to solve annoying coding problems. The example on how to get rid of deeply nested if statements on page 238, although simple, is a very effective technique which I only recently discovered on my own. They do that a couple of times in the book, they’re little pearls of knowledge, and you don’t need to know OOP to smile as you read them!

My greatest hesitation with C++ used to be the lack of few “minor” things like a constraints solver, functional coverage, and data packing/unpacking. After many years of using a proprietary constraint solver, I think it is entirely possible to live without a constraint solver at all. For example, a recent posting on the verification guild web site explains how to select a value based on a weighted range:

http://verificationguild.com/modules.php?name=Forums&file=viewtopic&t=1368&postdays=0&postorder=asc&highlight=verilog+dist&start=15

I am convinced that I can use a similar technique to execute code based on a weigthed range of values in C++. This way I could write my own solutions instead of using a constraint solver. I have also solved other types of constraints using procedural code.

As for functional coverage, I never understood why the underlying database could not be MySQL. One only has to figure out the methodology and show it to the world. Nothing C++ cannot do.

Lastly, I don’t see why packing and unpacking could not be solved in C++ either, since many times I could not use the proprietary languages built-in and had to write my own pack and unpack routines.

But I digress, I still have a few chapters to read.

So far, this book really got me thinking about what language I should use for asic verification. Because of that, it’s a great book. I am pretty sure I will read it a second time, after I follow the authors’ advice and learn a bit of C++.

Thank you for writing this book!