Add Synopsys VCS simulator support

[cmarqu]

I have taken a quick look into supporting the Synopsys VCS simulator.
It looks like similar to Cadence's cds.lib, VCS needs a file .synopsys_vss.setup for the library name-to-path mapping. http://salinasv.blogspot.de/2011/05/simulating-mixed-language-hdl-using-vcs.html has some info about it.
It would be nice if there was a class for reading and writing such a file, like the CDSFile class in cds_file.py for Incisive.

[kraigher]

I would like to help to create this support. But I want to remove the need for observing internal signals in the VHDL/SystemVerilog runner first. That way it is easier to port VUnit to new simulators.

[cmarqu]

FWIW, I had started this at https://github.com/cmarqu/vunit/blob/master/vunit/vcs_interface.py

[cmarqu]

If somebody reading this has experience with VCS, please contact me, or speak up here.

[cmarqu]

https://github.com/cmarqu/vunit now has VCS support that is able to successfully run the example vhdl/user_guide.

[svenka3]

A minor comment - in Synopsys terminology it's better if you call it VCSMX than plain VCS as seasoned VCS users get confused a bit.

On internal signal monitoring - there is hdl_xmr if needed

[cmarqu]

Thanks, I'll make that naming change soon. Internal signal monitoring is not necessary anymore I learned (just after I made the Tcl approach work :)).
@svenka3 Is there a way to set usage of 64-bit executables via an environment variable, like $CDS_AUTO_64BIT in Cadence Incisive? Right now, I have hardcoded the -full64 option (because it's required for my installation), but if we would not need to care about this at all, it would be even nicer.

[svenka3]

Can you try this:

“setenv VCS_TARGET_ARCH linux64

(Thanks to Vijay Kishore my ex-colleague)

[cmarqu]

Thanks Vijay and Srini, that variable works fine.

[cmarqu]

VCS MX either uses an environment variable SYNOPSYS_SIM_SETUP to find
the file containing library mappings and other settings
(synopsys_sim.settings or .synopsys_vss.setup it seems); or it
searches the CWD, $HOME or in the tool installation for this file.
There doesn't seem to be a corresponding command line switch in VCS MX.

What should the behavior be? Options:

If the SYNOPSYS_SIM_SETUP environment variable is defined:

• just expect everything to be defined in the file pointed to by it; or
• copy the file under vunit_out and set up the library part in it ourselves

If the SYNOPSYS_SIM_SETUP environment variable is NOT defined, and

• if a VUnit command line option (--vcsmxsetup) is given:

• just expect everything to be defined in the file pointed to by it; or

• copy the file under vunit_out and set up the library part in it ourselves

• if a VUnit command line option (--vcsmxsetup) is also NOT given:

• just handle everything ourselves

[kraigher]

@cmarqu Some valuable principles to keep in mind.

1. VUnit should depend as little as possible on the environment. It should ideally just need a fresh install of the simulator. That way people can ensure consistent simulations on different machines.
2. Command line flags should only be added for things that change often from one invocation of run.py to another. The sim setup file you mention does not sound like something that should be changed with different invocations of run.py.

Thus I would recommend just copying the sim setup file from the tool installation folder to the vunit output directory just like we do with modelsim.

[svenka3]

Agree with @kraigher - usually this setup file is done once per design.

Thanks
Srini

[kraigher]

@cmarqu Planning on finishing the VCS support?

[cmarqu]

I'd have to do some paperwork first, so probably not in the near term, sorry.

[kraigher]

@cmarqu Ok I understand. Just let me know if you need any support and I will try to help you

[benreynwar]

I've just started using VCS at work so can justify spending some time on this.
@cmarqu Can I use your repo as a starting point or is there a 'paperwork' issue with that?

[cmarqu]

@benreynwar The existing repo is is free from any paperwork issues, so feel free. Nice to see this progressing!

[benreynwar]

@cmarqu Looks like you've updated your master branch since it contained the vcs_interface.py file. Do you still have it anywhere?

[cmarqu]

@benreynwar I think this is the latest version I had: https://gist.github.com/cmarqu/60b4ea8517769faad412cb63b198c265

[benreynwar]

@cmarqu Thanks! Do you also have the vcsmx_setup_file.py that it uses?

[cmarqu]

Oh, right. Actually, I guess the right set of files is at https://gist.github.com/cmarqu/b7c8d5470d51204b3e66bab289ed548d

[benreynwar]

Alright. I've made extremely minor changes to get it installing. Branch is at:
https://github.com/benreynwar/vunit/tree/vcsmx_interface

I'm getting the following error when I run vunit/examples/vhdl/check/run.py:

=== Command used: ===
/data/tools/vcsmx/vcs-mx/N-2017.12-SP2-7/bin/vhdlan -f /home/ben/Code/vunit/examples/vhdl/check/vunit_out/vcsmx/vcsmx_compile_vhdl_file$
lib.args

=== Command output: ===

Error-[ANL_CTXREF_INVALID] Invalid context declaration
/home/ben/Code/vunit/examples/vhdl/check/vunit_out/preprocessed/lib/tb_example.vhd, 11
TB_EXAMPLE
  
  context vunit_lib.vunit_context;
  ^
  In the context reference, the selected name isn't a valid context 
  declaration.

Any tips on what's likely going wrong?

[cmarqu]

Ah yes - try running https://github.com/VUnit/vunit/blob/master/tools/incisive_vhdl_fixup.py on this file (or all sources).

[benreynwar]

I'm currently stuck because for some reason the object file for the logger_pkg package is not getting generated, and so I get error messages when linking. No error message is getting generated before the linking message so debugging is a little tricky. I've put a support request in with synopys so I'll see whether they're able to help.

[LarsAsplund]

@benreynwar is that support request open so that anyone can see?

[benreynwar]

@LarsAsplund No, I don't think it's possible to make it public. My next step is to produce a minimal testcase that reproduces the issue independently of VUnit so that I have a better chance of getting help from them.

[benreynwar]

Synopsys support has reproduced the issue and are looking into it.

[benreynwar]

Synopsys has identified the bug and fixed it in O-2018.09. I'm not sure which official build release it will be a part of. I'm including a snippet where they describe what part of the VUnit code was triggering the bug:

There was a code generation optimization bug for handling up-level references to unconstrained parameters from a nested impure function.

Source code "src/logger_pkg-body.vhd" which is causing issue.

---

……
……
impure function source_to_color (logger_name : string) return string is // issue
variable l : line;

impure function create_string return string is      // issue
  variable lines : lines_t;
  variable num_items : natural;
begin
  lines := split(logger_name, ":");   // issue
  num_items := integer'(lines.all'length);

…….
…….

---

[sbhutada]

Hello,

I have integrated VCSMX as well - but I am not getting proper exit status.

I have updated
o sim_if/vcsmx.py
o sim_if/factory.py
o vcsmx_setup_file.py
I have also added some print diagnostics to
o suites.py
o ostools.py

When I run the failing testcase from verilog/user_guide, VCS simulator exits with proper exit status, but vunit infrastructure is marking it as pass – Any suggestions?

python run.py -v "lib.tb_example.Test that a failing test case actually fails"
…
EXIT STATUS= 2
Raising NonZeroExitCode= 2
Command Failed
test starts = ['Test that a failing test case actually fails']
test_suite_done = True
done = True
test_name= Test that a failing test case actually fails
result= TestStatus('passed')
results= {'Test that a failing test case actually fails': TestStatus('passed')}
results file = /global/gtsnaw_rwest4/bhutada/vunit-master/examples/verilog/user_guide/vunit_out/test_output/lib.tb_example.Test_that_a_failing_test_case_actually_fails_e0b95858e14bbfb897b8d111a43505ca7f742d28/vunit_results {'Test that a failing test case actually fails': TestStatus('passed')}
sim_ok = False {'Test that a failing test case actually fails': TestStatus('passed')} False