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.
#1 by mike on November 17th, 2006
Hi Ptk,
Doh! I could have sworn I ran all those tests under vcs. Yes, I changed the note to note_call. I’ll correct the pli tab.
Ahh the mutex_test. That one is always a pain. Can you try droping the number of threads and iterations to, say, 10 each? Those numbers I came up with are arbitrary. You may get some errors from the rather silly distribution checks the test is running. So, um what Linux are you on?
I really do need to get my act together and get pth installed.
Sorry about the issues.
Are you game for running the Truss examples? That’s when the real fun starts.
Take care,
Mike
#2 by ptk on November 19th, 2006
Lowering the threads to 10 and iterations to 20 works. I have not tried any other value. I am on CentOS 4, 2.6.9-22.0.1.ELsmp, dual pentium 4 (quite a machine). I don’t mind debuging this problem a bit because I want to understand the limitation, so how do you suggest I go about it?
I really do need to get my act together and get pth installed.
Do you mean GNU Pth (GNU Portable Threads) or POSIX Threads aka pthreads? Previously, you had mentionned qt, which I assume means QuickThreads (on top of which a C++ package has been built called RT++).
I haven’t tried truss yet, but when I untar it, there are three directories, and no readme file, so I’m a bit lost (and I don’t have the book handy right now – I left it at work for others to read it). The teal user manual talks about an example_1.cpp file which I don’t seem to be able to find in the downloads.
Thanks.
#3 by ptk on November 21st, 2006
I am getting a spurious error in the mutex_test:
Sometimes it’s like this:
[81 ps][top][simple thread 7 on transactor 1][FILE: ./mutex_test.cpp][line: 175][ERROR] of 20 bins 17 were within two standard deviations. Expected at least: 19
But it seems the number of bins varies:
[81 ps][top][simple thread 5 on transactor 1][FILE: ./mutex_test.cpp][line: 175][ERROR] of 33 bins 30 were within two standard deviations. Expected at least: 31.35
And sometimes there is no error. So there are two problems to debug here, the spurious error message, and the lock up. Is this a real error, or just a “did not get the bus in time” error (but nevertheless, got the bus eventually)?
#4 by mike on November 20th, 2006
Hi Ptk,
Whew, great. I would really appreciate you debuging this because it is quite likely a bug in Teal. It’s possible that the dual cpus are better at showing the bug.
Sorry, I did mean QuickThreads. I have not heard of RT++; I will google it.
Doh, the README was at the level above Truss in the Book CD. It’s now in the downloads it area.
I never got around to making the example_1.cpp. Hopefully the simple tests give you a flavor of Teal.
Take care,
Mike
#5 by robert on November 20th, 2006
PTK,
That is quite a machine. I’ve never tried teal/truss on dual pentium set-ups. Shouldn’t be a problem and actually kinda cool
I apologize for the problems you have run into. Regarding the make alias, we should def fix that.
It seems like you’re up and running?
Out of curiosity, what simulator and what version do you use? I’m currently running on a quite old VCS, and we haven’t been paying attention to versions of verilog simulators
#6 by ptk on November 20th, 2006
Robert,
For now I use vcs/2005.06-SP2.
ptk
#7 by mike on November 21st, 2006
Hi Ptk,
Those are not real errors. I was being an idiot and trying to make sure each thread got a “fair” amount of time. This is silly because (1) that’s not easly under Teal’s control, and (2) my understanding of fair was that the times to get the bus was a gaussian distribution.
Take care,
Mike
#8 by ptk on November 21st, 2006
Hi again,
After trying different number of threads and iterations, I see this message in the log:
[1 ps][Teal::synch][verification_top][FILE: ./teal_synch.cpp][line: 165][INFO]Thread : Teal Control Thread (0x489fbb0) is waiting.
I guess it can’t be good that the control thread is waiting… as it would not be able to dispatch the other threads.
I don’t quite understand why some messages are printed sometimes, and some other times they are not printed. I seem to get this changing behavior simply by changing the number of iterations or number of threads.
PS: I don’t know which “reply” button to hit anymore on this forum… sorry if I hit the wrong one. I find phpbb forums easier to read than drupal’s, but this is just personal preference.
#9 by mike on November 21st, 2006
Hi Ptk,
Humm, does it then hang? It’s not necessarily a bad thing as the control thread is really just there to observe when all threads have paused on a condition.
The reason there is different behavior on different iterations and number of threads is because both variables interact to allow different threads to run at diffent times. In the real world this is not an issue as you generally have one driver for each interface.
Take care,
Mike
#10 by ptk on November 21st, 2006
The minimum values causing the mutex test to hang are: 299 threads, 1 iteration (one iteration!!). VCS simulation time is at 1ps when I C-c C-d out of it. The CPU shows a blip of activity at the begining, then remains at 0% utlilization.
With 298 threads and 100 iterations, it completes by itself in 9 seconds. I tried with 298 threads and 700 iterations, it completes by itself in 62 seconds. The CPU show 100% utilization in these cases throughout the simulation.
I’ll uncommented out debug messages and see where I can get.