Add support for Vivado XSIM

[LarsAsplund]

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 ***@***.***> 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 <#209 (comment)>, 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 1f91ea0 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

[fcaruso-PL]

@qarlosalberto what version of vivado does it require? When I run 2020.2 the verilog tests in verbose mode but the summary does not report any failed tests. Do I need any specific settings beside xport VUNIT_XSIM_PATH=<...>/Vivado/2020.2/bin/ ?
Thanks!

[qarlosalberto]

Sorry, I haven't test it with Verilog. Only with VHDL.

[fcaruso-PL]

I am having problems with the mif files. When I run vunit/xsim it doesn't find the Memory Initialization Files of the external IPs.
Is there a workaround beside patching up the verilog files with the absolute address of the mif?

[LudvigVidlid]

@qarlosalberto , I've created a pull request to your fork, adding an xelab_flags simulation option for xsim.

I realize that the fork is a year behind, so I could make the effort to bring it up-to-date if anyone would benefit from it :)

[qarlosalberto]

Cool, thanks!

I'm working with an internal branch, I need to merge my changes and later I could add the xelab_flags. It would nice to bring it up-to-date the branch, I know some developers use it a lot.

[qarlosalberto]

I have updated the branch, it includes:

xsim:
  Xsim specific flags

  --xsim-vcd-path XSIM_VCD_PATH
                        VCD waveform output path.
  --xsim-vcd-enable     Enable VCD waveform generation.
  --xsim-xelab-limit    Limit the xelab current processes to 1 thread.

And xsim.xelab_flags added by @LudvigVidlid

[LudvigVidlid]

Thanks for merging, @qarlosalberto :)

I've attempted to bring xsim_support up-to-date with vunit, pr here. It works with my tests, which are only using xsim and SystemVerilog. Do you have a chance to try it with your use cases?

[LarsAsplund]

@LudvigVidlid @qarlosalberto Do you have a list of missing VHDL support in latest XSIM (2022.1). Have there been any relevant improvements? I have a person within Xilinx that I hope can bring our issues to the right people so I'd like current status from those having some experiences in this area.

[kmtaylor]

I've been working on getting 2022.1 working. Adding to qarlosalberto's work, I've been able to get the com library going as well as the axi stream modules. Generally it's been a process of swapping the linked lists in com to fixed size arrays. Ugly but works. If you want to take a look, my fork is here:
https://github.com/kmtaylor/vunit/tree/kimt/xsim_support

[antho24]

I have created a fork from the master branch here: https://github.com/antho24/vunit

I have pull in changes from qarlosalberto and kmtaylor latest work and merged with the master branch on VUnit/vunit. I also added support for running sim with verilog/systemverilog testbenches, including UVM (I have mainly tested with UVM testbench on Windows platform).

Outstanding issue for my fork is all related to VHDL testbench. I couldn't run a successful VHDL testbench yet due to xsim elaboration failure on this specific error: [VRFC 10-932] initial value for constant declaration is not constant. Seem related to using impure function to set value for constant.

Another problem is with using multiple generic value. I couldn't get subprocess to correctly parse testbench that have multiple generic parameters being set. If someone can help me fix that, it would be much appreciated.

[qarlosalberto]

@antho24 I think that I know your problem with the generics. I have solved it creating a SV testbench wrapper.

[kmtaylor]

Hi @antho24 - I had that error (initial value for constant declaration is not constant) a lot. It appears to be a bug in xsim. In many cases I could fix it by swapping constants for integer literals like this:

https://github.com/kmtaylor/vunit/blob/kimt/xsim_support/vunit/vhdl/xsim/data_types/src/queue_pkg-body.vhd#L21

I also noticed on your branch that you've altered builins.py to use the full libraries. I'm afraid you won't have much luck with this, as 2022.1 is still missing many features and is quite buggy.

[LudvigVidlid]

Outstanding issue for my fork is all related to VHDL testbench. I couldn't run a successful VHDL testbench yet due to xsim elaboration failure on this specific error: [VRFC 10-932] initial value for constant declaration is not constant. Seem related to using impure function to set value for constant.

@antho24 I think we had a similar problem with another simulator. We solved it by making a deferred constant (i.e. declaring the constant in the package header, and defining it in the package body). I'm not sure if that is applicable to your case?

[LudvigVidlid]

Another problem is with using multiple generic value. I couldn't get subprocess to correctly parse testbench that have multiple generic parameters being set. If someone can help me fix that, it would be much appreciated.

@antho24 This sounds familiar as well. We had issues getting xsim to work on command line on windows, and now do it differently between linux and windows. Maybe this would work for you?

[LarsAsplund]

Vivado 2022.2 claim VHDL 2008 support in the release notes. Have anyone tested if that makes a difference?

[kmtaylor]

Unfortunately no, if I try and run vanilla vunit first thing I hit is:
ERROR: [VRFC 10-932] initial value for constant declaration is not constant [/home/kmtaylor/.local/lib64/python3.9/site-packages/vunit_hdl-4.6.1rc0-py3.9.egg/vunit/vhdl/core/src/core_pkg.vhd:65
Which is very familiar!

[LarsAsplund]

@kmtaylor In this case the constant is initialized by a function call and there is a rather long chain of things happening behind the scene. Do you have any idea about what it is in that function it dislikes? Or is it the fact that it is a function rather than a value or a simple expression? Or maybe it is because it is an impure function. Can it handle constant start_time : time := now;?

[umarcor]

FTR:

• Vivado Design Suite User Guide: Synthesis > Supported VHDL-2008 Features: https://docs.xilinx.com/r/en-US/ug901-vivado-synthesis/Supported-VHDL-2008-Features
• Vivado Design Suite User Guide: Logic Simulation > VHDL 2008 Support in Vivado Simulator: https://docs.xilinx.com/r/en-US/ug900-vivado-logic-simulation/VHDL-2008-Support-in-Vivado-Simulator

[kmtaylor]

@LarsAsplund I think it's really just broken, I work around it by using an integer literal in the initialisation function:
constant state : integer_vector_ptr_t := new_integer_vector_ptr(3); -- (core_failure_mock_state_length);
(ie swap core_failure_mock_state_length for 3) Which implies that xsim has fairly broken propagation of constness.
I've got heaps of these workarounds on my xsim branch. Far too many to list here, but this particular example can be found here:
https://github.com/kmtaylor/vunit/blob/kimt/xsim_support/vunit/vhdl/xsim/core/src/core_pkg.vhd#L57

[kmtaylor]

Thanks for the link to the supported features list @umarcor, however I think there is a bit of disconnect between what Xilinx says is working, and what is really working. For example they say that protected types work in xsim, however I need to use a very ugly workaround here:
https://github.com/kmtaylor/vunit/blob/kimt/xsim_support/vunit/vhdl/xsim/verification_components/src/axi_stream_master.vhd#L65
You will see that I've moved probability_stall_axi_stream out from the axi_stream_private_pkg.vhd. This is because passing the rnd protected type reference to another design unit is broken. What's worse is that it is silently broken, there are no errors, however rnd always returns the same "random" result. I suspect that there is some internal pointer reference being lost, and it is just returning uninitialised memory. Keeping both the declaration and use of a protected type within a single design unit does work however.
So my conclusion is that there is enough VHDL2008 support to get vunit running, there are just many bugs in the simulator that all have workarounds.

[kmtaylor]

Update to previous message: I made that workaround for Vivado 2022.1. I tried reverting that commit:
kmtaylor@9a5aa67
And running a testbench using 2022.2. It is still broken. So I think we can conclude that there isn't much difference between 2022.1 and 2022.2

[umarcor]

@kmtaylor, there is an absolute disconnect (not a bit). Last time I checked, Xilinx would have issues with VHDL 1993 features, which are critical for VUnit to work. They can claim to support whatever they want, but they should prove it (there are plenty of public and open source tests that they can use). Meanwhile, it's marketing noise.

With regard to VHDL 2008 features, it will be 2023 in a couple of weeks. They are still using ieee_proposed.fixed_pkg.all because they wouldn't work on a fundamental feature from 15 years ago. That's the kind of implementation that is listed as "supported feature". As far as I am aware, they keep adding bits to the list, but not fixing any of the others.

My perception is that SV/UVM support is similar. Otherwise, I would expect Vivado to be listed in https://chipsalliance.github.io/sv-tests-results/.

Nevertheless, Xilinx is not a software company. They traditionally recommended third-party tools for synthesis and simulation. That's why they've always had good integration with e.g. Mentor's synth and sim tools. The companies that take simulation and synthesis seriously do have decent VHDL (and SV) support. What Xilinx is has been good at is building and distributing FPGAs, and PnR; because they have had access to critical data about the devices which they don't share with others.

Overall, VHDL and SV are advanced and complex verification and hardware description languages. They are significantly more difficult to support than Verilog 2005. It's not something that can be done without a non-negligible budget. It needs to be in the priorities of the company. The priorities of Xilinx are legitimally somewhere else.

Honestly, I believe we'd be better try get Xilinx to allow open source tools (GHDL, Verilator, Icarus Verilog, etc.) to use encrypted simulation models. It might sound crazy, because it might effectively invalidate the purpose of the encryption. Then, maybe the focus should be on them making the simulation models not encrypted. I find that more plausible in the next decade than them having acceptable VHDL support.

Still, I do find very enriching that for 6 years, lots of users did not stop trying each new release of ISE/Vivado/XSIM and seeking workarounds. That's what open source is about. Should XSIM be open source, probably many of the features would be properly supported already.

[nfrancque]

The 2022.2 release notes claim to add 08 support to the simulator, has anyone taken a look yet?

https://www.xilinx.com/products/design-tools/vivado/vivado-whats-new.html

[nselvara]

Hi guys, did someone try with the latest version Vivado 2023.2 to simulate stuff?
If not, I could give a try, however, do I need to modify the current VUnit repo to have a XSIM_PATH or something like that or is there already something around?

[LarsAsplund]

@nselvara No, there has been no efforts on this (that I'm aware of). Please give it a try and let us know if you managed to get something going.

[nselvara]

@LarsAsplund, ok I'll give it a shot in my free time and report back.

[kmtaylor]

I've been using 2023.2 for a few weeks now. Seems to be working fine for my purposes. 2023.1 had broken VCD export, so was unusable for me. So far I've not noticed any differences between 2022.2 and 2023.2.

[nselvara]

@kmtaylor, did you have to do any modifications and/or specify xsim path in order to work?

[kmtaylor]

Yep, I started with softwareradiosystems' branch above, and have since added workarounds to get the verification components to work. Since not everything is working, you need to make small changes to the test benches. You can get an idea of what works by running the axi_dma example. You'll first have to apply the attached patch, and then run:

VUNIT_SIMULATOR=xsim python run.py -p 8 --minimal axi_dma_lib.tb_axi_dma.*

My branch is here:
https://github.com/kmtaylor/vunit/tree/kimt/xsim_support

[nselvara]

@kmtaylor, thank you for your reply. I'll try to work from the softwareradiosystems and try to rebase the master on it as well. Let's see how far I can go.