Urgent help needed

mano · May 10, 2010, 10:27am

hello everyone,
I have written the code for verifying an i2c master. But due to some error the output is not coming as expected…
the code is in the attachment and the error is as follws
[manoranjan@node5 ~]$ qverilog /home/NIS/BTECH_06-10/manoranjan/Desktop/ibus_t.sv +define+CVC -R +OVM_TESTNAME=ibus_demo_tb
QuestaSim-64 qverilog 6.5b Compiler 2009.05 May 21 2009
/cad/Mentor2009/modeltech/bin/…/linux_x86_64/qverilog /home/NIS/BTECH_06-10/manoranjan/Desktop/ibus_t.sv +define -R +OVM_TESTNAME=ibus_demo_tb
– Compiling interface ibus_if
– Compiling package ibus_t_sv_unit
– Compiling module top
** Warning: /home/NIS/BTECH_06-10/manoranjan/Desktop/ibus_t.sv(211): (qverilog-2223) In-line constraints for hierarchical call to class::randomize() will be resolved with respect to the current scope
** Warning: /home/NIS/BTECH_06-10/manoranjan/Desktop/ibus_t.sv(249): (qverilog-2223) In-line constraints for hierarchical call to class::randomize() will be resolved with respect to the current scope
– Compiling module i2c_master_top
– Compiling module i2c_master_byte_ctrl
– Compiling module i2c_master_bit_ctrl
– Compiling module i2c_slave_model

Top level modules:
top

/cad/Mentor2009/questasim/v6.5b/linux_x86_64/vsim -lib work +OVM_TESTNAME=ibus_demo_tb top -c -do run -all; quit -f -appendlog -l qverilog.log -vopt
Reading /cad/Mentor2009/questasim/v6.5b/tcl/vsim/pref.tcl

6.5b

vsim +OVM_TESTNAME=ibus_demo_tb -appendlog -do {run -all; quit -f} -l qverilog.log -lib work -c -vopt top

** Note: (vsim-3813) Design is being optimized due to module recompilation…

** Warning: /home/NIS/BTECH_06-10/manoranjan/Desktop/ibus_t.sv(211): (vopt-2223) In-line constraints for hierarchical call to class::randomize() will be resolved with respect to the current scope

** Warning: /home/NIS/BTECH_06-10/manoranjan/Desktop/ibus_t.sv(249): (vopt-2223) In-line constraints for hierarchical call to class::randomize() will be resolved with respect to the current scope

// QuestaSim-64 6.5b May 21 2009 Linux 2.6.9-55.0.2.ELsmp

//

// Copyright 1991-2009 Mentor Graphics Corporation

// All Rights Reserved.

//

// THIS WORK CONTAINS TRADE SECRET AND

// PROPRIETARY INFORMATION WHICH IS THE PROPERTY

// OF MENTOR GRAPHICS CORPORATION OR ITS LICENSORS

// AND IS SUBJECT TO LICENSE TERMS.

//

Loading sv_std.std

Loading work.ibus_t_sv_unit(fast)

Loading work.top(fast)

Loading work.ibus_if(fast)

Loading work.i2c_master_top(fast)

Loading work.i2c_master_byte_ctrl(fast)

Loading work.i2c_master_bit_ctrl(fast)

Loading work.i2c_slave_model(fast)

run -all

Attempting stack trace sig 11

Signal caught: signo [11]

vsim_stacktrace.vstf written

Current time Mon May 10 15:26:05 2010

QuestaSim Stack Trace

Program = vsim

Id = “6.5b”

Version = “2009.05”

Date = “May 21 2009”

Platform = linux_x86_64

0 0x000000000093e95c: ‘<unknown (@0x93e95c)>’

1 0x00000000004b2631: ‘<unknown (@0x4b2631)>’

2 0x000000000050a075: ‘<unknown (@0x50a075)>’

3 0x000000000050a1d1: ‘<unknown (@0x50a1d1)>’

4 0x000000000045cd13: ‘<unknown (@0x45cd13)>’

5 0x000000000051f5c2: ‘<unknown (@0x51f5c2)>’

6 0x000000000076c5aa: ‘<unknown (@0x76c5aa)>’

7 0x000000000076d9e3: ‘<unknown (@0x76d9e3)>’

8 0x0000000000aa1400: ‘<unknown (@0xaa1400)>’

9 0x0000000000aa2cd9: ‘<unknown (@0xaa2cd9)>’

10 0x0000000000acab54: ‘<unknown (@0xacab54)>’

11 0x0000000000acd0e4: ‘<unknown (@0xacd0e4)>’

12 0x0000000000aa3b3d: ‘<unknown (@0xaa3b3d)>’

13 0x0000000000aaac32: ‘<unknown (@0xaaac32)>’

14 0x0000000000aa2cd9: ‘<unknown (@0xaa2cd9)>’

15 0x0000000000acab54: ‘<unknown (@0xacab54)>’

16 0x0000000000ac6fa7: ‘<unknown (@0xac6fa7)>’

17 0x0000000000aa2523: ‘<unknown (@0xaa2523)>’

18 0x0000000000aae568: ‘<unknown (@0xaae568)>’

19 0x0000000000aa2cd9: ‘<unknown (@0xaa2cd9)>’

20 0x0000000000aa2f48: ‘<unknown (@0xaa2f48)>’

21 0x0000000000aa3335: ‘<unknown (@0xaa3335)>’

22 0x0000000000aa33c8: ‘<unknown (@0xaa33c8)>’

23 0x0000000000980685: ‘<unknown (@0x980685)>’

24 0x0000000000ad9b83: ‘<unknown (@0xad9b83)>’

25 0x0000000000b09d4c: ‘<unknown (@0xb09d4c)>’

26 0x0000000000aea1cd: ‘<unknown (@0xaea1cd)>’

27 0x0000000000aea4dd: ‘<unknown (@0xaea4dd)>’

28 0x0000000000a69ff6: ‘<unknown (@0xa69ff6)>’

29 0x000000000075a570: ‘<unknown (@0x75a570)>’

30 0x00000000006c0698: ‘<unknown (@0x6c0698)>’

End of Stack Trace

** Fatal: (SIGSEGV) Bad pointer access. Closing vsimk.
** Fatal: vsimk is exiting with code 211.
(Exit codes are defined in the QuestaSim messages appendix
of the QuestaSim User’s Manual.)

----------------------------------------------------------------

OVM-2.0.2

(C) 2007-2009 Mentor Graphics Corporation

(C) 2007-2009 Cadence Design Systems, Inc.

----------------------------------------------------------------

OVM_INFO @ 0: reporter [RNTST] Running test ibus_demo_tb…

OVM_INFO @ 0: ibus_demo_tb [ibus_demo_tb] START of build test

OVM_INFO @ 0: ibus_demo_tb [ibus_demo_tb] END of build test

OVM_INFO @ 0: ibus_demo_tb.ibus0 [ibus_demo_tb.ibus0] START of build env

OVM_INFO @ 0: ibus_demo_tb.ibus0 [ibus_demo_tb.ibus0] END of build env

OVM_INFO @ 0: ibus_demo_tb.ibus0.masters [ibus_demo_tb.ibus0.masters] START of build agent

OVM_INFO @ 0: ibus_demo_tb.ibus0.masters [ibus_demo_tb.ibus0.masters] END of build agent

OVM_INFO @ 0: ovm_test_top [ovm_test_top] START of build test

OVM_INFO @ 0: ovm_test_top [ovm_test_top] END of build test

OVM_INFO @ 0: ovm_test_top.ibus0 [ovm_test_top.ibus0] START of build env

OVM_INFO @ 0: ovm_test_top.ibus0 [ovm_test_top.ibus0] END of build env

OVM_INFO @ 0: ovm_test_top.ibus0.masters [ovm_test_top.ibus0.masters] START of build agent

OVM_INFO @ 0: ovm_test_top.ibus0.masters [ovm_test_top.ibus0.masters] END of build agent

OVM_INFO @ 0: ibus_demo_tb.ibus0.masters [ibus_demo_tb.ibus0.masters] START of connect agent

OVM_INFO @ 0: ibus_demo_tb.ibus0.masters [ibus_demo_tb.ibus0.masters] END of connect agent

OVM_INFO @ 0: ovm_test_top.ibus0.masters [ovm_test_top.ibus0.masters] START of connect agent

OVM_INFO @ 0: ovm_test_top.ibus0.masters [ovm_test_top.ibus0.masters] END of connect agent

OVM_INFO @ 0: ovm_test_top.ibus0 Called ibus_env::run

INSIDE RUN : DRIVER CLK1 = 0

INSIDE RUN : DRIVER CLK2 = 0

INSIDE RUN : DRIVER CLK3 = 0

INSIDE RUN : DRIVER CLK4 = 0

OVM_INFO @ 0: ibus_demo_tb.ibus0 Called ibus_env::run

INSIDE RUN : DRIVER CLK1 = 0

INSIDE RUN : DRIVER CLK2 = 0

INSIDE RUN : DRIVER CLK3 = 0

INSIDE RUN : DRIVER CLK4 = 0

INSIDE RUN : DRIVER CLK5 = 1

INSIDE RUN : DRIVER CLK6 = 1

INSIDE RUN : DRIVER CLK5 = 1

[manoranjan@node5 ~]$

cgales · May 10, 2010, 12:29pm

Like I posted in response to your previous question, what do you expect the test to do? If you have a specific issue, such as “I expect to see ‘something’, but I see ‘something else’”, then it is a lot easier to assist you.

Your current environment is doing exactly what it is programmed to do. However, the way that you are using the testbench may be causing issues. You are specifying “+OVM_TESTNAME” on the qverilog command line as well as creating an instance of “ibus_demo_tb” in the top module itself. These co-existing instances will most likely cause errors since they are operating on the same interface/DUT. You should remove the instance created inside the top module and let OVM handle the creation using “+OVM_TESTNAME”.

As for functionality, you still haven’t created any meaningful test(s). You need to create some sequences which will program/test your DUT.

mano · May 10, 2010, 4:15pm

Thank you cgales for replying so soon.
Now i would like to answer few of your questions as requested by you…

Like I posted in response to your previous question, what do you expect the test to do? If you have a specific issue, such as “I expect to see ‘something’, but I see ‘something else’”, then it is a lot easier to assist you.

Actually my DUT is an I2C master core which i want to test. I want to see if it correctly initiates and responds to transfers on the SDA and SCL lines. I first want to test it for just a single data byte transfer thus such a simple sequence and i believe the sequence should work. I should be able to see the randomly generated address and corresponding transferred data byte since i have used the ovm_report_info in the sequence. I first want to see it. I would later add to these basic sequences and generate more complex cases to test the DUT.

Your current environment is doing exactly what it is programmed to do. However, the way that you are using the testbench may be causing issues. You are specifying “+OVM_TESTNAME” on the qverilog command line as well as creating an instance of “ibus_demo_tb” in the top module itself. These co-existing instances will most likely cause errors since they are operating on the same interface/DUT. You should remove the instance created inside the top module and let OVM handle the creation using “+OVM_TESTNAME”.

Regarding co-existing instances, i would like to say that i could never run my earlier project of verifying D - Flip/Flop without having them together.
Back then i had no issues. Now this attempting stack trace error has cropped up.

I would like to ask you a question how do we see waveforms using OVM in QuestaSim 6.5b in linux environment. Specifically what changes need to be made in the source .cshrc file to view the waveforms?

cgales · May 10, 2010, 4:36pm

To view waves using qverilog, you need to add ‘-gui -novopt’ to the qverilog command line. You can also use the integrated debugger as well to trace through your code and fix the issues you have.

mano · May 10, 2010, 5:42pm

Thank you again for a quick reply…

To view waves using qverilog, you need to add ‘-gui -novopt’ to the qverilog command line. You can also use the integrated debugger as well to trace through your code and fix the issues you have.

Actually my DUT is an I2C master core which i want to test. I want to see if it correctly initiates and responds to transfers on the SDA and SCL lines. I first want to test it for just a single data byte transfer thus such a simple sequence and i believe the sequence should work. I should be able to see the randomly generated address and corresponding transferred data byte since i have used the ovm_report_info in the sequence. I first want to see it. I would later add to these basic sequences and generate more complex cases to test the DUT.

Are my sequences correct to fulfill the criterion cited above???
You didn’t post any reply to the above and now could you say what’s causing stack trace…???

cgales · May 10, 2010, 5:57pm

When I run the code without +OVM_TESTNAME, I am not seeing a stack trace. My thought is that there is something conflicting when you have two instances at the top level. Try removing one and see if that makes a difference.

Your ibus_master_driver seems to have enough to get a I2C transfer going. While it isn’t the ideal way to organize your code, it seems sufficient. You have some other issues which will prevent things from working, but I’m sure you can debug them using waveforms and the Questa debugger.