Add Cadence Xcelium support

[rodrigomelo9]

My attempt to provide support to Xcelium, based on previous Incisive support.

[cmarqu]

I added two suggestions, apply them to the other options of the same name.

[rodrigomelo9]

Which one @cmarqu ? both of them? (I have no access to incisive).

[rodrigomelo9]

I broke something. In master, pytest tests/unit is ok, but in my branch, there are a lot of complaints about:

>       raise ArgumentError(action, message % conflict_string)
E       argparse.ArgumentError: argument --cdslib: conflicting option string: --cdslib

[rodrigomelo9]

To be able to launch a test, I removed Incisive from my local copy. I have complaints about vunit/tests/acceptance/artificial_out/xunit.xml (and effectively, artificial_out is not created).

[cmarqu]

Which one @cmarqu ? both of them? (I have no access to incisive).

Ah, the GitHub GUI is not really good here; I commented specifically on the line if simulator_is("activehdl", "xcelium"): in tests/acceptance/test_artificial.py.

[cmarqu]

I broke something. In master, pytest tests/unit is ok, but in my branch, there are a lot of complaints about:

>       raise ArgumentError(action, message % conflict_string)
E       argparse.ArgumentError: argument --cdslib: conflicting option string: --cdslib

You are adding the --cdslib option to the argument parser that it already knows about, from the Incisive support I think. Sounds like vunit assumes that all supported simulators have unique arguments (without collisions), which is not true here?
You could rename the argument to e.g. --cdslib-xcelium as a workaround for now.

[rodrigomelo9]

@cmarqu taking into account that Xcelium is the newest, and Incisive could be deprecated sometime in the future, I defined the CLI arguments for both at xcelium.py. I put a note into incisive.py. What do you think?

[rodrigomelo9]

Which one @cmarqu ? both of them? (I have no access to incisive).

Ah, the GitHub GUI is not really good here; I commented specifically on the line if simulator_is("activehdl", "xcelium"): in tests/acceptance/test_artificial.py.

Solved.

[eine]

Looks good, however, I am unsure about duplicating the sim_if source. I think that the strategy from #684 about using some private fields (executable_name, option_prefix) might be applied here. As @LarsAsplund commented in #684 (comment), we want to support both simulators explicitly, meaning that users should be able to select incisive or xcelium. However, from an implementation point of view we should be able to use a single class or, at least, have a common class and two inheriting from it. Say:

from .cadence import IncisiveInterface, XceliumInterface

[rodrigomelo9]

I applied two fixes in VHDL packages (based on #325 (comment) and from #684) and now when I run under examples/vhdl/user_guide, I get:

<PATH>/vunit/examples/vhdl/user_guide$ python3 run.py
WARNING - /<PATH>/vunit/examples/vhdl/user_guide/tb_example_many.vhd: failed to find a primary design unit 'vunit_context' in library 'vunit_lib'
WARNING - /<PATH>/vunit/examples/vhdl/user_guide/tb_example.vhd: failed to find a primary design unit 'vunit_context' in library 'vunit_lib'
Compiling into vunit_lib: ../../../vunit/vhdl/string_ops/src/string_ops.vhd                        passed
Compiling into vunit_lib: ../../../vunit/vhdl/path/src/path.vhd                                    passed
Compiling into vunit_lib: ../../../vunit/vhdl/logging/src/print_pkg.vhd                            passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/types.vhd                             passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/codec_builder.vhd                     passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/codec_builder-2008p.vhd               passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/codec.vhd                             passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/codec-2008p.vhd                       passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/api/external_string_pkg.vhd           passed
  impure function read_char (
                          |
xmvhdl_p: *W,NORETN (/<PATH>/vunit/vunit/vhdl/data_types/src/api/external_string_pkg.vhd,35|26): No return statement in the body of function READ_CHAR.
  impure function get_ptr (
                        |
xmvhdl_p: *W,NORETN (/<PATH>/vunit/vunit/vhdl/data_types/src/api/external_string_pkg.vhd,42|24): No return statement in the body of function GET_PTR.
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/string_ptr_pkg.vhd                    passed
Compiling into vunit_lib: ../../../vunit/vhdl/logging/src/ansi_pkg.vhd                             passed
Compiling into vunit_lib: ../../../vunit/vhdl/logging/src/log_levels_pkg.vhd                       passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/string_ptr_pkg-body-2002p.vhd         passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/byte_vector_ptr_pkg.vhd               passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/api/external_integer_vector_pkg.vhd   passed
  impure function read_integer (
                             |
xmvhdl_p: *W,NORETN (/<PATH>/vunit/vunit/vhdl/data_types/src/api/external_integer_vector_pkg.vhd,35|29): No return statement in the body of function READ_INTEGER.
  impure function get_ptr (
                        |
xmvhdl_p: *W,NORETN (/<PATH>/vunit/vunit/vhdl/data_types/src/api/external_integer_vector_pkg.vhd,42|24): No return statement in the body of function GET_PTR.
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/integer_vector_ptr_pkg.vhd            passed
Compiling into vunit_lib: ../../../vunit/vhdl/logging/src/log_handler_pkg.vhd                      passed
Compiling into vunit_lib: ../../../vunit/vhdl/logging/src/print_pkg-body.vhd                       passed
Compiling into vunit_lib: ../../../vunit/vhdl/logging/src/logger_pkg.vhd                           passed
Compiling into vunit_lib: ../../../vunit/vhdl/dictionary/src/dictionary.vhd                        passed
Compiling into vunit_lib: ../../../vunit/vhdl/run/src/run_types.vhd                                passed
Compiling into vunit_lib: ../../../vunit/vhdl/logging/src/file_pkg.vhd                             passed
Compiling into vunit_lib: ../../../vunit/vhdl/logging/src/log_handler_pkg-body.vhd                 passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/integer_vector_ptr_pkg-body-2002p.vhd passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/integer_array_pkg.vhd                 passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/queue_pkg.vhd                         passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/string_ptr_pool_pkg.vhd               passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/queue_pkg-body.vhd                    passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/queue_pkg-2008p.vhd                   passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/integer_vector_ptr_pool_pkg.vhd       passed
Compiling into vunit_lib: ../../../vunit/vhdl/run/src/runner_pkg.vhd                               passed
Compiling into vunit_lib: ../../../vunit/vhdl/run/src/run_api.vhd                                  passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/queue_pool_pkg.vhd                    passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/integer_array_pkg-body.vhd            passed
Compiling into vunit_lib: ../../../vunit/vhdl/data_types/src/dict_pkg.vhd                          passed
Compiling into vunit_lib: ../../../vunit/vhdl/core/src/stop_pkg.vhd                                passed
Compiling into vunit_lib: ../../../vunit/vhdl/core/src/stop_body_2008p.vhd                         passed
Compiling into vunit_lib: ../../../vunit/vhdl/core/src/core_pkg.vhd                                passed
Compiling into vunit_lib: ../../../vunit/vhdl/run/src/run.vhd                                      passed
Compiling into vunit_lib: ../../../vunit/vhdl/logging/src/logger_pkg-body.vhd                      passed
Compiling into vunit_lib: ../../../vunit/vhdl/logging/src/log_levels_pkg-body.vhd                  passed
Compiling into vunit_lib: ../../../vunit/vhdl/logging/src/log_deprecated_pkg.vhd                   passed
Compiling into vunit_lib: ../../../vunit/vhdl/check/src/checker_pkg.vhd                            passed
Compiling into vunit_lib: ../../../vunit/vhdl/run/src/run_deprecated_pkg.vhd                       passed
Compiling into vunit_lib: ../../../vunit/vhdl/check/src/checker_pkg-body.vhd                       passed
Compiling into vunit_lib: ../../../vunit/vhdl/check/src/check_api.vhd                              passed
Compiling into vunit_lib: ../../../vunit/vhdl/check/src/check_deprecated_pkg.vhd                   passed
Compiling into vunit_lib: ../../../vunit/vhdl/check/src/check.vhd                                  passed
Compiling into lib:       tb_example_many.vhd                                                      failed
=== Command used: ===
/<TOOL>/19/19.09.002/tools.lnx86/bin/xrun -f /<PATH>/vunit/examples/vhdl/user_guide/vunit_out/xcelium/xrun_compile_vhdl_file_lib.args

=== Command output: ===
context vunit_lib.vunit_context;
                 |
xmvhdl_p: *E,SELLIB (/<PATH>/vunit/examples/vhdl/user_guide/tb_example_many.vhd,8|17): unit (VUNIT_CONTEXT) not found in library (VUNIT_LIB).
architecture tb of tb_example_many is
                                 |
xmvhdl_p: *E,ENNOFN (/<PATH>/vunit/examples/vhdl/user_guide/tb_example_many.vhd,14|33): Intermediate file for entity 'TB_EXAMPLE_MANY' could not be loaded, entity may require re-analysis.
xrun: *E,VHLERR: Error during parsing VHDL file (status 1), exiting.

Compile failed

Seems to be almost there :-D

[rodrigomelo9]

Well, we were testing with @eine and the context must be replaced by the use clauses, and it works. At least part of the fixup will be needed.

[rodrigomelo9]

I was wrong. It works without changes returning True in supports_vhdl_contexts. I saw it in #684. @powARman did a good job and must be added as a co-author if this PR reaches master.

[umarcor]

@rodrigomelo9 we picked one of the commits in #731. Can you please rebase?

[rodrigomelo9]

I rebased from master. Now, I am not sure about these changes taken from #684. Next, I will merge the support in only one cadence.py file, as suggested by @eine.

[rodrigomelo9]

I took it from #684 but I'm not sure it's necessary. If yes, must be also applied to VHDL.SDT_2002? Must be applied to Incisive?

[rodrigomelo9]

Ok, I found some answers...

To successfully compile the code with the VHDL protected types, a second option in addition to -v200x is needed. Please add -extv200x to your compiler command line. This switch is not documented.

To compile the latest VHDL 2008 constructs, a new command line option, -inc_v200x_pkg, must be used. This is in addition to the -v200x option.

So these additions seem ok.

[cmarqu]

They are okay for Xcelium, but I'm not so sure about a "true" Incisive installation - after all, the last Incisive release was 2015.
Thinking about it, I wouldn't be surprised if such an old Incisive cannot run a modern vunit at all anymore, so maybe we can and should remove Incisive support completely.
I'll try to check what the status there is.

[cmarqu]

Ok, so Incisive 15.20 doesn't accept -inc_v200x_pkg and without it doesn't compile vunit/vhdl/logging/src/ansi_pkg.vhd (which I'm sure is just the first file of many with problems).

[rodrigomelo9]

Ok. Taking this into account seems ok to maintain xcellium.py as parent class and incisive.py could heritage from it?

[umarcor]

Ok, so Incisive 15.20 doesn't accept -inc_v200x_pkg and without it doesn't compile vunit/vhdl/logging/src/ansi_pkg.vhd (which I'm sure is just the first file of many with problems).

@cmarqu, did you try running Incisive or did you find it in the documentation?

In case you can run it, would you please try the user_guide for 1993 I proposed in #737? It might be desirable to support running the subset of tests that is compatible with 1993, for those simulators which support VHDL 1993 properly, but don't support VHDL 2008 (yet).

Until now, I believe we had not run into that use case. All other simulators support both 1993 and 2008, or don't support either of them (XSIM cannot handle VUnit's 1993 codebase). However, strictly it should be possible to use VUnit as a "project builder and test runner", despite many utility libraries not being available without 2008 support.

[rodrigomelo9]

Trying the verilog user guide, I have this message:

xmelab: *W,DSEMEL: This SystemVerilog design will be simulated as per IEEE 1800-2009 SystemVerilog simulation semantics. Use -disable_sem2009 option for turning off SV 2009 simulation semantics.

Which disappears if I include the arg -disable_sem2009. I didn't found documentation about exactly what it means (which SV is using?). Seems ok to add this option? @cmarqu

[rodrigomelo9]

Hi @umarcor

I perform the change to inherit Incisive from Xcelium, but I have pytest issues where I need help. I open rodrigomelo9#1 to work on that.

[rodrigomelo9]

@LarsAsplund @cmarqu @umarcor here is an update, to define possible next steps. In the current state of this PR:

• pytest tests/lint/ pass
• pytest tests/unit/ pass (also the added test_xcelium_interface.py)
• pytest tests/acceptance presents a lot of fails (log here)
• examples/vhdl/user_guide pass
• examples/verilog/user_guide pass after run python3 tools/xcelium_verilog_fixup.py
• I have another branch to inherit incisive from xcelium as suggested by @umarcor (Modified to inherit Incisive from Xcelium rodrigomelo9/vunit#1 where I need help because I have doubts about Vunit's internals)

[cmarqu]

Sorry, I can't test it for the next three weeks or so.

[rodrigomelo9]

Ok @cmarqu let me know if you take a look. I will be working into a unified Cadence interface to be inherited by Incisive and Xcelium.

[Hardolaf]

@rodrigomelo9 I'm wondering if you've had a chance to get this further down the path of working? I've rebased your branch on the latest master and fixed one decode issue in commits over on my branch here: https://github.com/Hardolaf/vunit/tree/add/xcelium-support

[rodrigomelo9]

Sorry, I did not further development on that. I'm not a VUnit user. It would be great if it reaches main (working, of course) :-D and I can try in a machine with access with Xcelium, but no more than that currently.

[VinieBerry]

I made an attempt to run VUnit with Xcelium 21.09 but still some issues.

I did the acceptance test and the current status is 28 failed, 13 passes and 8 skipped. I'm also running the examples.

Two issues happens quite often:

• Compilation issue in AlertLogPkg.vhd :

xmvhdl_p: *E,ALTYMM (/work/sesa595203/vunit/vunit/vhdl/osvvm/AlertLogPkg.vhd,3260|17): subprogram call or operator argument type mismatch 87[4.3.3.2] 93[4.3.2.2].
    if MetaMatch(L, R) then

• Simulation issue in codec.vhd

xmsim: *E,TRINDXC: index constraint violation.
          File: /work/sesa595203/vunit/vunit/vhdl/data_types/src/codec.vhd, line = 521, pos = 39
         Scope: @vunit_lib.codec_pkg:decode(STRING:STRING)

There is also a problem when calling VUnit in batch mode : the test ends but Xcelium does not exit (simulation stops still). I had to add the '-exit' argument to xrun call to fix this.

I will try in the coming weeks to work on that.

[VinieBerry]

I did a bit of progress since yesterday, I'm focusing on making the uart example working.

The implicit conversion between std_logic_vector and std_ulogic_vector seems not to be well supported by Xcelium. For instance at many places there is this kind of construct:

data := pop_std_ulogic_vector(request_msg); where data is declared as std_logic_vector

And it triggers this error:

xmvhdl_p: *E,EXPTYP (...): expecting an expression of type STD_LOGIC_VECTOR 87[8.4] 93[8.5].

To fix this, we can add an explicit cast but it is a bit painful and I'm not sure it is the best way to proceed (even this is what I did as a quick fix). This affects many files in the OSVVM and verification components libraries.

Another issue is the unconstrained type inside record, when the record type is used as a subprogram parameter. It is for instance the case in axi_stream_pkg.vhd at line 313. Based on Cadence support it is a known limitation...

[Hardolaf]

@VinieBerry I believe we can fix the OSVVM issues for some versions of Xcelium by checking to see if there is a Cadence provided version of OSVVM located at $XCELIUM_INSTALL_DIR/tools/inca/files/OSVVM and then defaulting to using that at least until there is a version of Xcelium which fully supports OSVVM (assuming OSVVM is correct; I'm very rusty on my VHDL as I haven't used it since 2018).

[VinieBerry]

Concerning the xmsim: *E,TRINDXC: index constraint violation error, it seems to appear only when a logging call is done with a mocked logger. Here is an example in the tb_logging_example.vhd:

-- Loggers can also be mocked
mock(my_logger);
failure(my_logger, "message");
check_only_log(my_logger, "message", failure);
unmock(my_logger);

0 fs - default                   -   TRACE - Verbose format
0 fs - default                   -   DEBUG - Verbose format
0 fs - default                   -    INFO - Verbose format
0 fs - default                   - WARNING - Verbose format
0 fs - default                   -   ERROR - Verbose format
0 fs - default                   - FAILURE - Verbose format
REPORT/NOTE (time 0 FS) from procedure @vunit_lib.logger_pkg:mock_log
Got mocked log item 
   time = 0 fs
   logger = logging_example:my_logger
   log_level = failure
   msg = message
   file_name:line_num = :0

xmsim: *E,TRINDXC: index constraint violation.
          File: /work/sesa595203/vunit/vunit/vhdl/data_types/src/codec.vhd, line = 521, pos = 39
         Scope: @vunit_lib.codec_pkg:decode(STRING:STRING)
          Time: 0 FS + 1

/work/sesa595203/vunit/vunit/vhdl/data_types/src/codec.vhd:521     variable ret_val : string(ret_range'range) := (others => NUL);
xcelium> exit

While:

-- Loggers can also be mocked
-- mock(my_logger);
failure(my_logger, "message");
check_only_log(my_logger, "message", failure);
-- unmock(my_logger);

0 fs - default                   -   TRACE - Verbose format
0 fs - default                   -   DEBUG - Verbose format
0 fs - default                   -    INFO - Verbose format
0 fs - default                   - WARNING - Verbose format
0 fs - default                   -   ERROR - Verbose format
0 fs - default                   - FAILURE - Verbose format
0 fs - logging_example:my_logger - FAILURE - message
REPORT/FAILURE (time 0 FS) from procedure @vunit_lib.core_pkg:core_failure
Stop simulation on log level failure
Report at 0 FS + 1
/work/sesa595203/vunit/vunit/vhdl/core/src/core_pkg.vhd:84       report msg severity failure;
xcelium> exit

This error happens 294 times in the acceptance test. I'm wondering if it is actually related to Xcelium simulator ? Does someone have already deal with this kind of issue ?

[VinieBerry]

The root cause of the xmsim: *E,TRINDXC: index constraint violation error is actually the 'ascending attribute returned value for strings when the length is zero. This occurs in the encode_array_header subprogram.

REPORT/NOTE (time 0 FS) from function @vunit_lib.codec_pkg:encode
Length is greater than 0
REPORT/NOTE (time 0 FS) from function @vunit_lib.codec_pkg:encode
Right = 7
REPORT/NOTE (time 0 FS) from function @vunit_lib.codec_pkg:encode
Left = 1
REPORT/NOTE (time 0 FS) from function @vunit_lib.codec_pkg:encode
Ascending = true
REPORT/NOTE (time 0 FS) from function @vunit_lib.codec_pkg:encode
Length is 0
REPORT/NOTE (time 0 FS) from function @vunit_lib.codec_pkg:encode
Right = 0
REPORT/NOTE (time 0 FS) from function @vunit_lib.codec_pkg:encode
Left = 1
REPORT/NOTE (time 0 FS) from function @vunit_lib.codec_pkg:encode
Ascending = false

I don't know why it seems to only happen with mocked logger (to be confirmed). For now my fix is to force to True the attribute value. Would it be possible to condition this depending on the simulator ?

[VinieBerry]

Another issue is the unconstrained type inside record, when the record type is used as a subprogram parameter. It is for instance the case in axi_stream_pkg.vhd at line 313. Based on Cadence support it is a known limitation...

Good news, I reported the issue to Cadence support and the answer is that it has been fixed and will be supported in a next release. This will be a great improvment since as of today we cannot compile all the VIP components (and therefore the associated testbenches).

[Hardolaf]

Doing more testing, I'm running into two issues:

1. The build times are slower compared to another simulator due to the repeated invocation of xrun during the compilation stage instead of running as a two or three stage xrun invocation. This appears to be primarily related to the startup time of the tool and the license check that occurs at startup.

2. When reinvoking using the same built libraries, the implementation can occasionally load the wrong testbench resulting in a false failure. I'm still trying to find the root cause of this issue.

[umarcor]

The build times are slower compared to another simulator due to the repeated invocation of xrun during the compilation stage instead of running as a two or three stage xrun invocation. This appears to be primarily related to the startup time of the tool and the license check that occurs at startup.

This is partially unexpected... It is expected for multiple xrun invocations to be slow, precisely because of the startup time and the license check that you mentioned. However, in all other simulators, that is worked around by reducing the calls. For instance, in GHDL elab-run is used, instead of calling analyze, elaborate and run (https://github.com/VUnit/vunit/blob/master/vunit/sim_if/ghdl.py#L274). However, if sources are to be compiled to different libraries, first those need to be analyzed through independent calls (https://github.com/VUnit/vunit/blob/master/vunit/sim_if/ghdl.py#L235), because GHDL supports multiple lib syntax for synth but not for sim. In GHDL's case, startup and license checking are not problematic, but I hope you get the idea. Hence, the question is, does Xcelium allow to reduce the number of xrun calls? Does it have a CLI syntax that allows analyzing multiple sources into different libraries and then elaborating and running a primary unit, all at once?

[cmarqu]

Does it have a CLI syntax that allows analyzing multiple sources into different libraries and then elaborating and running a primary unit, all at once?

It does, via the -makelib ... -endlib options.

[Hardolaf]

I'll take a look at making that change. I've done it in the past but haven't had the bandwidth to do it yet due to other work obligations.

[Hardolaf]

I took a look at adding support for this and it appears to be a non-trivial change to VUnit due to Xcelium not supporting certain options within a -makelib ... -endlib area. For example, in my current environment, I receive the following three errors repeatedly while trying to make this work:

xrun: *E,COLOPT: Cannot have the option -64bit within an active -makelib area.  The option must be moved from this active area.
xrun: *E,COLOPT: Cannot have the option -sparsearray within an active -makelib area.  The option must be moved from this active area.
xrun: *E,OPTNOML: Multiple -sparsearray option specified, only 1 required.

Now, I say that this is a non-trivial change because VUnit currently tracks compilation options on a per-file basis rather than on a per-invocation basis (see vunit/ui/__init__.py:455). To resolve this problem, I would need to do one of two things:

1. Rewrite core parts of VUnit to store compilation options on a per-invocation basis instead of on a per-file basis. But I only have Xcelium currently setup as a simulator so I'd be blindly making changes for other simulators.
2. Collect the set of options for each file and then de-duplicate all options which are common for all files in the Cadence Xcelium runner. This may be potentially error prone but only for people doing weird things in their runner scripts such as removing a global option from a single file.

I personally believe that option 1 is the best option in terms of a resolution and adding proper support for this (and it is lower runtime compared to option 2 by a lot) but in terms of implementing the change, I don't know if I have the requisite knowledge of VUnit's internals to safely make this change for all simulators especially as I only have one simulator currently able to run on my development machine. If I did go ahead with it, I could get one of our Python devs to at least review the code before I try to push it up, but even that will only have limited utility as they would be completely unfamiliar with the code base.

So I'm really just looking for opinions as to what people think is the best path forward on adding this support. If it would help to see the code that I currently have, I can push it to my branch and link it here.

[cmarqu]

I can't help with your real question but the first error could be circumvented by setting the environment variable CDS_AUTO_64BIT to ALL and removing the -64bit option.

[Hardolaf]

I know that in theory that should work, but I have already opened an issue with Cadence about CDS_AUTO_64BIT not working properly. It doesn't open every program in 64-bit mode whereas explicitly calling -64bit does open every program in 64-bit mode.

[VinieBerry]

I’m digging on the communication library support after having many errors and/or crashes. After many attempts I figured out that an issue arises from the com_messenger_pkg. It seems that at some moments the name() procedure (line 312 of com_messenger.vhd) is called while the actors variable is null. Therefore, we have:

xmsim: *E,TRNULLID: NULL pointer dereference.
          File: /ecad/tools/misc/vunit/beta/4.6.0/vunit/vhdl/com/src/com_messenger.vhd, line = 314, pos = 13
          Time: 0 FS + 1

/ecad/tools/misc/vunit/beta/4.6.0/vunit/vhdl/com/src/com_messenger.vhd:314     if actors(actor.id).name /= null then

As a workaround I have added a condition to avoid this case:

impure function name (actor : actor_t) return string is
  begin
    if actors /= null then
      if actors(actor.id).name /= null then
        return actors(actor.id).name.all;
      else
        return "";
      end if;
    else
      report "actors is null (xmsim: *E,TRNULLID: NULL pointer dereference.)" severity warning;
      return "null";
    end if;
  end;

This solves the problem, but now I get the same kind of issues when calling the to_string(msg) function...

I'm not enough familiar with the internal cooking of the communication library to deeply understand the root cause. What I can say is that my actor is well created at startup (I suppose):

REPORT/NOTE (time 0 FS) from process :main (architecture amba_lib.apb_mem_bridge_tb:tb)
num_of_actors = 1
REPORT/NOTE (time 0 FS) from process :main (architecture amba_lib.apb_mem_bridge_tb:tb)
num_of_deferred_creations = 0

Any ideas ?

[VinieBerry]

I did a bit of progress since yesterday, I'm focusing on making the uart example working.

The implicit conversion between std_logic_vector and std_ulogic_vector seems not to be well supported by Xcelium. For instance at many places there is this kind of construct:

data := pop_std_ulogic_vector(request_msg); where data is declared as std_logic_vector

And it triggers this error:

xmvhdl_p: *E,EXPTYP (...): expecting an expression of type STD_LOGIC_VECTOR 87[8.4] 93[8.5].

To fix this, we can add an explicit cast but it is a bit painful and I'm not sure it is the best way to proceed (even this is what I did as a quick fix). This affects many files in the OSVVM and verification components libraries.

Another issue is the unconstrained type inside record, when the record type is used as a subprogram parameter. It is for instance the case in axi_stream_pkg.vhd at line 313. Based on Cadence support it is a known limitation...

On this side, I figured out that Xcelium is able to switch from std_logic/std_ulogic implicitely (procedures with std_logic or std_ulogic parameter have the same signature).

Hovewer it is not the case for std_logic_vector/std_ulogic_vector. Thus, I have added the same functions/procedures for std_logic_vector than for std_ulogic_vector in com_types_pkg and queue_pkg (and associated files). The explicit casting is then hidden from the user.

[bryankerr1986]

Hello! I have two simple questions:

1. Is it correct that if I want to use Vunit with Xcelium 2303 I have to use this branch?
2. Is there any documentation or example run.py scripts regarding Xcelium support? i.e. how to pass in xrun arguments / cds.lib