UVM Connect needs wait() before first peek()

UVM
, ,
1

Hi,

using UVMC 2.3.0 I found out that in order to be able to call peek() on a sc_port tlm_get_peek_if which is onnected to a uvm_tlm_fifo, I need do call wait(1, SC_NS) at the beginning.

Instead of calling wait I could also do a get() on the same port before calling peek().

Calling peek() right away using neither wait(1, SC_NS) nor get() causes an error:
UVM_FATAL /usr/local/uvmc-2.3.0/src/connect/sv/uvmc_tlm1.sv(121) @ 0: reporter [UVMC] Internal error (uvmc_pkg::C2SV_peek): port at id 0 is null

Has this something to do with the call to wait_connected()
which is present in function get() in line 216 of file /usr/local/uvmc-2.3.0/src/connect/sc/uvmc_channels.h
but is not present in function peek() at line 263 of the same file ?

Can this be patched in UVMC source ?

Regards,
Elmar

2

In reply to elmar:

Hi,
my question was cut hort after the first line because I used the “minor” symbol in the text,
before and after the word “tlm_get_peek_if”, as is needed in SystemC code.
Regards,
Elmar

3

In reply to elmar:

Hi,

in function peek() at line 265 of file uvmc-2.3.0/src/connect/sc/uvmc_channels.h I inserted:

const_cast< this_type * >( this )->wait_connected();

Now I can use peek() on a sc_port’<‘tlm_get_peek_if’<’ without a previous wait or get.

Is this modification of UVMC o.k. or will it break anything ?

Regards,
Elmar

4

Elmar,

My understanding of peek() is that it is semantically required
to be a 0-time call as per TLM 1.0 specification.

Therefore any wait() calls within the call should be disallowed.

Is it possible you are peeking before the data actually
got placed in the fifo ?

Is it possible to send a test case ?

– johnS

5

In reply to jstickle:

Hi John,

I am not sure what you mean by “0-time call”, but I understand that peek() is a blocking call, just like get().
Yes, I am in fact peeking before the data actually got placed in the fifo and I want peek() to block until data got placed in the fifo.

Here is a test case.

Regards,
Elmar

6

In reply to elmar:

Elmar,

Sorry, sometimes in my Mentor division use “0-time function call” as
a synonym for a non-blocking, i.e. “instantaneous” call. But looking at
IEEE 1666 I realize that you are correct that peek() itself is blocking.
I had not looked at this for awhile and was thinking that peek()'ing is
just an instantaneous non-blocking call.

OK, so reviewing the meaning of peek() in the LRM it must wait until
the next transaction on the fifo, then return its value without removing
it (as get() does).

And indeed it looks like ::get() itself does already call wait_connected()
as your fix suggests. So it appears that we need to do the same in
peek().

I think the issue is that, although peek() itself is already blocking
on the m_sem member, the problem is that semaphore is not is not created
in the first place until it is connected. So it stands to reason that we
need to call wait_connect() as ::get() does and as you suggest.

We will file a bug report on this and put this fix in for
the 2.3.1 release.

Thanks very much for your feedback.
– johnS

7

In reply to jstickle:

Hi,

I did not have access to a Mentor license for quite a while.

File uvmc-2.3.1/src/connect/sc/uvmc_channels.h:264 reads

wait_connected(); // [Bugzilla 77644]

This leads to the following compilation error using native UVMC in Questa Ultrasim:

sccom -DSC_INCLUDE_DYNAMIC_PROCESSES -DQUESTA -I/usr/local/mentor/questa_sim-2019.3_2/questasim/verilog_src/uvmc-2.3.1/src/connect/sc srs.cpp 
Start time: 11:44:58 on Oct 28,2019

QuestaSim-64 sccom 2019.3_2 compiler 2019.09 Sep 24 2019

In file included from /usr/local/mentor/questa_sim-2019.3_2/questasim/verilog_src/uvmc-2.3.1/src/connect/sc/uvmc.h:41:0,
                 from srs.cpp:4:
/usr/local/mentor/questa_sim-2019.3_2/questasim/verilog_src/uvmc-2.3.1/src/connect/sc/uvmc_channels.h: In instantiation of 'void uvmc::uvmc_tlm1_channel_proxy<T1, T2, CVRT_T1, CVRT_T2>::peek(T2&) const [with T1 = a_tr; T2 = a_tr; CVRT_T1 = uvmc_converter<a_tr>; CVRT_T2 = uvmc_converter<a_tr>]':
srs.cpp:33:1:   required from here
/usr/local/mentor/questa_sim-2019.3_2/questasim/verilog_src/uvmc-2.3.1/src/connect/sc/uvmc_channels.h:264:5: error: passing 'const uvmc::uvmc_tlm1_channel_proxy<a_tr, a_tr, uvmc_converter<a_tr>, uvmc_converter<a_tr> >' as 'this' argument discards qualifiers [-fpermissive]
     wait_connected(); // [Bugzilla 77644]
     ^
In file included from /usr/local/mentor/questa_sim-2019.3_2/questasim/verilog_src/uvmc-2.3.1/src/connect/sc/uvmc.h:37:0,
                 from srs.cpp:4:
/usr/local/mentor/questa_sim-2019.3_2/questasim/verilog_src/uvmc-2.3.1/src/connect/sc/uvmc_common.h:189:8: note:   in call to 'void uvmc::uvmc_proxy_base::wait_connected()'
   void wait_connected();
        ^
** Error: (sccom-6142) Compilation failed.
End time: 11:45:00 on Oct 28,2019, Elapsed time: 0:00:02
Errors: 1, Warnings: 0

Making uvmc-2.3.1/src/connect/sc/uvmc_channels.h:264

const_cast< this_type * >( this )->wait_connected(); // [Bugzilla 77644]

as I suggested on May 05, 2015 corrects that error.

Regards,
Elmar

8

Elmar,

Yes, your solution has been incorporated into the source code for
the upcoming UVMC-2.3.2 release will be posted to the Verification Academy
as soon as we get it through the validation and legal process.

– johnS

In reply to elmar: