How to access internal signals without disturbing in verific

Guest
HI,

I want to access internal signal values of design, in verification
environment. How it is possible.
Assume in some design whenever message x comes, the internal registers
will be updated and interrupt1 will be generated. In same way whenever
message y comes some other internal register will be generated and
interrupt2 will be generated. Once interrupt is generated i will
access internal registers through i2c interface and i will get details
of registers. But because of this i2c interface access it will slow
verification for some time. Because i have only one i2c interface for
the design. I want to change the verification environment like when
interrupt comes without going actual i2c interface(i.e it wont slow
down verification), through some technique i has to read those
registers from back door. How i can implement it in verilog? i dont
know for this one PLI will be useful or not? Can anyone provide what
are techinques i can use to get rid of this situation
 
Your problem statement is a bit confusing.

Here is what I understand. You have a DUT. You monitor a register or memory
for messages X and Y. When either of those messages appear you cuase an
interupt flag/flags. You have an extenal controller that see the interupt
flag/flags, the controller caused the runtime to DUT execution to freeze and
cycles out the appropriate register values over the I2C bus.

Becuase the verification is paused and the transfer is slow you want a speed
up.

What I don't understand is where the PLI routines would come into it or a
back door? It sounds like you have a very firm verification environment.
From your description it sounds like your dut is an fpga environment and you
are pin limited? Is this correct?
If so, how did you plan to synthesize the PLI, plus with the pin
limitations how do you expect a speed up? If you are not using an fpga
based verification environment. You don't have a problem. You could read
the variables directly.

The best I can suggest withou knowing more about your verification
environment is: Can the register values be auto checked?
Meaning if Message X or Y occurs will the registers have predictable values,
or does it take some human intuition to understand the register values?

If you can predict the values you can create a synthesizable checker.
Every time the message is received use the checker. if fail then stop and
transfer the registers over i2c.

<vishnuprasanth@gmail.com> wrote in message
news:e9ab0cc5-7e05-4cd6-964c-53d71f356849@e23g2000prf.googlegroups.com...
HI,

I want to access internal signal values of design, in verification
environment. How it is possible.
Assume in some design whenever message x comes, the internal registers
will be updated and interrupt1 will be generated. In same way whenever
message y comes some other internal register will be generated and
interrupt2 will be generated. Once interrupt is generated i will
access internal registers through i2c interface and i will get details
of registers. But because of this i2c interface access it will slow
verification for some time. Because i have only one i2c interface for
the design. I want to change the verification environment like when
interrupt comes without going actual i2c interface(i.e it wont slow
down verification), through some technique i has to read those
registers from back door. How i can implement it in verilog? i dont
know for this one PLI will be useful or not? Can anyone provide what
are techinques i can use to get rid of this situation
Click to expand...
 
On Jan 17, 1:01 pm, vishnuprasa...@gmail.com wrote:
I want to change the verification environment like when
interrupt comes without going actual i2c interface(i.e it wont slow
down verification), through some technique i has to read those
registers from back door. How i can implement it in verilog? i dont
know for this one PLI will be useful or not? Can anyone provide what
are techinques i can use to get rid of this situation
Click to expand...
Back-door access is usually done through hierarchical references (also
known as cross-module references or XMR's). A quick description:

If your testbench is called tb, and your DUT is instantiated as dut,
and the DUT top-level instantiates a module as mod1, and it declares a
register called reg1, you can refer to it from anywhere in your
testbench as tb.dut.mod1.reg1.

You can read it:
foo = tb.dut.mod1.reg1;

Write it:
tb.dut.mod1.reg1 = foo;

Force/release it:
force tb.dut.mod1.reg1 = 1;
release tb.dut.mod1.reg1;

Trigger on it:
always @(posedge tb.dut.mod1.reg1)

and so on. Consult your favorite Verilog reference for more
information.

-cb
 
On Jan 18, 1:09 am, "Dwayne Dilbeck" <ddilb...@yahoo.com> wrote:
Your problem statement is a bit confusing.

Here is what I understand. You have a DUT. You monitor a register or memory
for messages X and Y. When either of those messages appear you cuase an
interupt flag/flags. You have an extenal controller that see the interupt
flag/flags, the controller caused the runtime to DUT execution to freeze and
cycles out the appropriate register values over the I2C bus.

Becuase the verification is paused and the transfer is slow you want a speed
up.

What I don't understand is where the PLI routines would come into it or a
back door? It sounds like you have a very firm verification environment.
From your description it sounds like your dut is an fpga environment and you
are pin limited? Is this correct?
If so, how did you plan to synthesize the PLI, plus with the pin
limitations how do you expect a speed up? If you are not using an fpga
based verification environment. You don't have a problem. You could read
the variables directly.

The best I can suggest withou knowing more about your verification
environment is: Can the register values be auto checked?
Meaning if Message X or Y occurs will the registers have predictable values,
or does it take some human intuition to understand the register values?

If you can predict the values you can create a synthesizable checker.
Every time the message is received use the checker. if fail then stop and
transfer the registers over i2c.

vishnuprasa...@gmail.com> wrote in message

news:e9ab0cc5-7e05-4cd6-964c-53d71f356849@e23g2000prf.googlegroups.com...

HI,
Click to expand...
I have mentioned PLI, because i do not know for this case it may be
useful.
The values updated by register are predictable values only.
Eventhough i need to access the registers throgh i2c interface to get
the results. Without going through i2c interface how i can access
these internal signal values.
 
On Jan 18, 11:47 pm, Chris Briggs <ch...@engim.com> wrote:
On Jan 17, 1:01 pm, vishnuprasa...@gmail.com wrote:

I want to change the verification environment like when
interrupt comes without going actual i2c interface(i.e it wont slow
down verification), through some technique i has to read those
registers from back door. How i can implement it in verilog? i dont
know for this one PLI will be useful or not? Can anyone provide what
are techinques i can use to get rid of this situation

Back-door access is usually done through hierarchical references (also
known as cross-module references or XMR's). A quick description:

If your testbench is called tb, and your DUT is instantiated as dut,
and the DUT top-level instantiates a module as mod1, and it declares a
register called reg1, you can refer to it from anywhere in your
testbench as tb.dut.mod1.reg1.

You can read it:
foo = tb.dut.mod1.reg1;

Write it:
tb.dut.mod1.reg1 = foo;

Force/release it:
force tb.dut.mod1.reg1 = 1;
release tb.dut.mod1.reg1;

Trigger on it:
always @(posedge tb.dut.mod1.reg1)

and so on. Consult your favorite Verilog reference for more
information.

-cb
Click to expand...
HI,

Thankyou, i got the answer
 
Still don't know what your verification environment is like, but based on
your responce to the other poster. I assume it is all in Software right
now. In that case use the OOMR(Out of Module Reference) appoach. I would
also suggest that since the data is predictable you make the testbench self
checking. That will save engineer time. That way the enginer only has to
look at the results when they fail.

<vishnuprasanth@gmail.com> wrote in message
news:d7458dff-ce40-492d-9710-5196754b24ac@d21g2000prf.googlegroups.com...
On Jan 18, 1:09 am, "Dwayne Dilbeck" <ddilb...@yahoo.com> wrote:
Your problem statement is a bit confusing.

Here is what I understand. You have a DUT. You monitor a register or
memory
for messages X and Y. When either of those messages appear you cuase an
interupt flag/flags. You have an extenal controller that see the
interupt
flag/flags, the controller caused the runtime to DUT execution to freeze
and
cycles out the appropriate register values over the I2C bus.

Becuase the verification is paused and the transfer is slow you want a
speed
up.

What I don't understand is where the PLI routines would come into it or a
back door? It sounds like you have a very firm verification environment.
From your description it sounds like your dut is an fpga environment and
you
are pin limited? Is this correct?
If so, how did you plan to synthesize the PLI, plus with the pin
limitations how do you expect a speed up? If you are not using an fpga
based verification environment. You don't have a problem. You could
read
the variables directly.

The best I can suggest withou knowing more about your verification
environment is: Can the register values be auto checked?
Meaning if Message X or Y occurs will the registers have predictable
values,
or does it take some human intuition to understand the register values?

If you can predict the values you can create a synthesizable checker.
Every time the message is received use the checker. if fail then stop and
transfer the registers over i2c.

vishnuprasa...@gmail.com> wrote in message

news:e9ab0cc5-7e05-4cd6-964c-53d71f356849@e23g2000prf.googlegroups.com...

HI,
I have mentioned PLI, because i do not know for this case it may be
useful.
The values updated by register are predictable values only.
Eventhough i need to access the registers throgh i2c interface to get
the results. Without going through i2c interface how i can access
these internal signal values.
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top