Add support for Vivado XSIM

[LarsAsplund]

trafficstars

We have started to do some work but we didn't have an issue for it so I'm creating one.

[schluta]

Any update on this? Any help needed?

[LarsAsplund]

@flamebut57 This issue has been dormant awaiting more interest. Maybe we're seeing that now? There were also some tool issues the last time we made some prototyping:

• XSIM didn't support custom resolved types which VUnit uses. This can be worked around but it would be easier if we didn't have to
• XSIM didn't support setting the severity level at which the simulation stops

We can surely use some help. Interested? Finding out if these two issues remains would be a starting point.

[drizzd]

I just tested both issues with Vivado 2013.1, 2016.2 and 2017.2.

• I didn't manage to compile run_types.vhd directly due to the large number of dependencies, but I could compile my own user defined resolved type just fine.
• I could find no option to set the severity level at which the simulation stops. Xsim will continue on severity warning or severity error. It will stop on severity failure. At that point the user can continue the simulation by writing run -all to standard input. Do we need to stop on warning or error?

[LarsAsplund]

@flamebut57 Is this true with all the tested versions? I can't remember what version I used to test user defined resolved types but 2013.1 should have been available at the time. What did your type look like? Was it based on std_logic?

[aodling]

Hi!

Any updates to this issue?

[kraigher]

There is no active work to add support for xsim. There have been some preliminary tests which shows it lacks enough VHDL support of even 93 standard to accept the VUnit code. Also it has a very sluggish startup time which would hinder fast feedback when running multiple small tests. The first issue can be worked arround in VUnit at least but takes effort which I am currently not willing to spend. If anyone in the community wants to give it a go fine by me.

[pedronevestopic]

I am not very experienced in Python, but I am in VHDL. I have some time and I would like to look into this to see if I can make it work with XSIM. Where should I start from? Is there a branch of previous attempts?

[kraigher]

@pedronevestopic I pushed a branch with a work in progress implementation of Python-level support. I do not know how well it works any more. The major blocker is the lack of VHDL support in particular user defined resolved types. Those limitations could be worked around though.

[jklapel]

@pedronevestopic Were you able to make any progress on making the VHDL work in XSIM?

[schluta]

I apologize as I have been very busy in the last year. I did throw together a template to use Vivado Simulator for both Verilog and VHDL. I was attempting to run the instance of Vivado in a VM and I am unsure if I was running into memory issues but if I remember correctly it just hung forever.

To clarify I believe the VHDL test stated that there was an unsupported feature ( it was a compile order issue where it stated one file changed after another compiled this may have changed in newer versions I tested on 2015.4 and 2016.4), while the Verilog test just hung forever.

I would be happy to share these templates and test cases that I added if they are of interest or use to the community.

Let me know if there is any interest.

Thanks,

On Tue, Feb 13, 2018 at 11:00 AM, jklapel [email protected] wrote:

@pedronevestopic https://github.com/pedronevestopic Were you able to make any progress on making the VHDL work in XSIM?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/VUnit/vunit/issues/209#issuecomment-365368695, or mute the thread https://github.com/notifications/unsubscribe-auth/AM4_JHx1VF6YLxy6zRws-9ijp9-PR_3Pks5tUdvHgaJpZM4K066i .

[PetterssonMagnus]

I am interested in xsim support, although from a purely (system)verilog perspective. Would https://github.com/VUnit/vunit/commit/1f91ea08f7f8e56b334116374d6676544b737858 be a good starting point should I have some spare time over?

[pedronevestopic]

I’m sorry. I couldn’t do anything . I got a problem on my back and going to need a surgery. I haven’t been able to sit on a computer. If no one has spend any time when I’m recovered in some months , I’ll pick it up.

[kraigher]

@PetterssonMagnus The xsim branch contains a work in progress that you can experiment with

[jklapel]

@PetterssonMagnus I was able to take the xsim branch and get it working for VHDL testbenches at a very basic level with only a day or so of tinkering with it. Getting Verilog to work with xsim shouldn't be too much different I don't believe, though I haven't tried it. I ran into bigger issues with the custom resolved types in VHDL. (Take a look at the conversation I had with kraigher on February 13th on the Gitter chat.) I don't know how the Verilog side of VUnit works, but my understanding is that Xilinx doesn't have a lot of support SystemVerilog.

[PetterssonMagnus]

Ok, I have been able to successfully get the example user_guide through xvlog thus creating libraries vunit_lib and lib. Subsequently xelab seems to lock up, neither finish executing nor providing me with any error messages.

xelab -L vunit_lib -L lib --runall lib.tb_example --generic_top "runner_cfg=active python runner : true,enabled_test_cases : Test that a test case that takes too long time fails with a timeout,output path : C::/repo/vunit/examples/verilog/user_guide/vunit_out/test_output/lib.tb_example.f763c9dbbd826025101721b40758dfe8d596eff6/" -v 1 -O0 -mt off I get the following output: .... Starting static elaboration INFO: [VRFC 10-520] compiling module tb_example [C:/repo/vunit/examples/verilog/user_guide/tb_example.sv:12] Completed static elaboration Starting simulation data flow analysis Completed simulation data flow analysis SDG Object Count: 375, SDG Object Memory Usage: 46 KB. Time Resolution for simulation is 1ps Compiling module lib.tb_example

... and then the fun ends ... id est nothing more happens.

[LarsAsplund]

@PetterssonMagnus What happens if you setup the project from within XSIM? Does it fail? Does it give you more info? If not, I would start doing some divide an conquer

[PetterssonMagnus]

Eventually I got verilog examples "uart" and "user_guide" to work in non-gui mode. Have not verified, but I doubt xsim supports verilog-ams. Created a fork: https://github.com/PetterssonMagnus/vunit/tree/xsim .

[LarsAsplund]

@jklapel @kraigher @PetterssonMagnus I have pushed a VUnit version without custom types to a new branch. I'm keeping it on a branch because I need someone to test if Incisive still works. The runner signal which used to be of a custom resolved type is currently a two bit std_logic_vector but I may take that another step and make it a single std_logic. That work wouldn't affect the porting to XSIM much so you can go ahead with what I have now.

[LarsAsplund]

@jklapel @kraigher @PetterssonMagnus I've merged the aforementioned branch to master now such that it doesn't use any custom resolved types.

[haggaie]

Hi, I rebased the xsim support on master and tested the SystemVerilog examples. I had to modify the code a bit to make it work on Linux.

[LarsAsplund]

I'll test this. I think it's about time we get this going so any help is appreciated. @PetterssonMagnus Do you have any comments on the status of your work?

[PetterssonMagnus]

Hm, this was a while ago. Status, Been using vunit and xsim for sv testbenches. The only non pushed, functional, addition I have is a crude way of specifying Xsim initfile. Used to locate ips and other Xilinx libraries. At some point I had the vhdl examples compiling but ran into null pointer exceptions immediately at startup(elab). Think it was due to the order of objects (runner perhaps) being created / referenced. The vunit internal vhdl code required a few hours of transformations to get to that.

[ro-ca]

Hi! Is there any progress on this? What's the best way to test out what y'all have or help out? Still new to GitHub, but good at python / vhdl. Looks to my untrained eye that @haggaie and @PetterssonMagnus 's branches are identical, but both may have fallen somewhat behind the master. Is that accurate? Any thoughts on what needs to be done to get vhdl compiling?

[eine]

@ro-ca, I rebased their branch on top of master, so you can try it: https://github.com/1138-4EB/vunit/tree/petterssonmagnus-xsim

[imd1]

Hi

I've downloaded https://github.com/1138-4EB/vunit/tree/petterssonmagnus-xsim and tried to run one of my existing testsuites (OK under Questasim and GHDL) using Vivado 2018.3. and I get the following compile error for a VUnit library file:

ERROR: [VRFC 10-1261] prefix of LENGTH attribute should be an array or array (sub)type [/usr/lib/....../vunit/vhdl/data_types/src/string_ptr_pkg-body-2002p.vhd:93]

Is this expected, anticipated? Are there any workarounds?

Regards Ian

[eine]

It seems to be an unsupported feature in Vivado.

• The prefix is ptrs(ref): https://github.com/1138-4EB/vunit/blob/petterssonmagnus-xsim/vunit/vhdl/data_types/src/string_ptr_pkg-body-2002p.vhd#L93).
• ptr is type vava_t: https://github.com/1138-4EB/vunit/blob/petterssonmagnus-xsim/vunit/vhdl/data_types/src/string_ptr_pkg-body-2002p.vhd#L58.
• vava_t is an alias of string_access_vector_access_t: https://github.com/1138-4EB/vunit/blob/petterssonmagnus-xsim/vunit/vhdl/data_types/src/string_ptr_pkg.vhd#L27.
• string_access_vector_access_t is type access string_access_vector_t: https://github.com/1138-4EB/vunit/blob/petterssonmagnus-xsim/vunit/vhdl/data_types/src/types.vhd#L12.
• string_access_vector_t is an array of string_access_t: https://github.com/1138-4EB/vunit/blob/petterssonmagnus-xsim/vunit/vhdl/data_types/src/types.vhd#L11.
• string_access_t is type access string: https://github.com/1138-4EB/vunit/blob/petterssonmagnus-xsim/vunit/vhdl/data_types/src/types.vhd#L10.

Therefore, ptrs(ref) is/returns an access to a string. It might be possible to work around the issue by rewriting function length:

    impure function length (
      ref : natural
    ) return integer is
    variable s : string_access_t := ptrs(ref);
    begin
      return s'length;
    end;

Further notes:

• This will probably need to be fixed in other places too. For example: https://github.com/1138-4EB/vunit/blob/petterssonmagnus-xsim/vunit/vhdl/data_types/src/integer_vector_ptr_pkg-body-2002p.vhd#L85
• https://github.com/1138-4EB/vunit/tree/petterssonmagnus-xsim has not been rebased after merging #507 into master. These sources were modified in #507: https://github.com/VUnit/vunit/blob/master/vunit/vhdl/data_types/src/string_ptr_pkg-body-2002p.vhd#L191-L200
  • Will you keep a working copy of the branch in your fork?
  • Are you ok with fixing the current status of https://github.com/1138-4EB/vunit/tree/petterssonmagnus-xsim or would you like to rebase it first?

[imd1]

I'm happy to make some progress on this, but I'm not too GitHub literate, so I might need some guidance on topics such as forking and rebase in this case. Should I fork 1138-4EB/vunit and work on the xsim branch? How should I rebase?

[eine]

I suggest to clone this repo first:

git clone --recurse-submodules https://github.com/VUnit/vunit
cd vunit

Then, add my fork as a remote:

git remote add 1138-4EB https://github.com/1138-4EB/vunit
git fetch 1138-4EB

Now, checkout the branch:

git checkout -b xsim 1138-4EB/petterssonmagnus-xsim

Last, you can either fix this version, or rebase:

git rebase origin/master

Rebasing will require you to fix possible conflicts between existing modifications in branch xsim and recent additions to master. Likely in Pythons sources, since no VHDL sources are modified in branch xsim: https://github.com/VUnit/vunit/compare/master...1138-4EB:petterssonmagnus-xsim

If you don't know how to fix conflicts, just git rebase --abort and you will be back in xsim (1138-4EB/petterssonmagnus-xsim).

[imd1]

I've applied the suggested patch to string_ptr_pkg-body-2002p.vhd and now I get an error in the file that is compiled immediately after...

ERROR: [VRFC 10-3782] `string_ptr_pkg` is not compiled into `vunit_lib` [/usr/lib/..../vhdl/logging/src/ansi_pkg.vhd:10]

The console output shows passes for string_ptr_pkg-body-2002p.vhs and string_ptr_pkg.vhd immediately before a fail for ansi_pkg.vhd

Any ideas?

[eine]

@imd1, on the one hand, it seems that you are trying to compile sources with vhdl_standard=08, which is likely to fail because VHDL 2008 support in Vivado is quite limited. I suggest to use vhdl_standard=93. On the other hand, bear https://github.com/VUnit/vunit/issues/209#issuecomment-335524828 in mind.