vunit
vunit copied to clipboard
VUnit
Working Xcelium + Indago support with single command commpilation plus a basic rerun script for Xcelium
This work started from the work that @rodrigomelo9 presented in his PR: https://github.com/VUnit/vunit/pull/728.
Another quick thing I noticed is there is already https://github.com/VUnit/vunit/pull/728. Does anyone know how this differs?
@GlenNicholls As mentioned in the opening of this PR, this is based on #728 which was incomplete. If you look at the commit history for this PR, it has the full history from #728 included.
Hi. I started #728, but I'm not a VUnit user, so when it started to be complicated, I left it unfinished... Happy to see that somebody continues this work and hopefully, it will be part of VUnit finally! Thanks.
@GlenNicholls As mentioned in the opening of this PR, this is based on #728 which was incomplete. If you look at the commit history for this PR, it has the full history from #728 included.
I see, thanks for the clarification!
I did a first pass on cleaning up the review per the comments. I've addressed most issues so far locally, but I haven't had time to finish my changes and verify them against xcelium this week. I'll probably get a new commit up sometime next week, time permitted.
I did a first pass on cleaning up the review per the comments. I've addressed most issues so far locally, but I haven't had time to finish my changes and verify them against xcelium this week. I'll probably get a new commit up sometime next week, time permitted.
Any updates regarding this MR? I would like to use VUnit with Xcelium in an upcoming project. If you need any assistance, let me know. Maybe i can somehow contribute.
FYI I decided to try this branch with Xcelium 2303 using the Uart example run.py - Failed. Seemed like OSVVM wasn't even compiling correctly. Edit: "After making a few modifications to this branch and rebasing to the latest release, I was able to get simulations running with the latest 23.03 Xcelium"
@JFMarten Due to leaving the position where I worked on this, I won't be able to continue the work on this for contractual reasons. I wasn't able to get this into a good linted state before leaving the job. The branch does work for System Verilog and Verilog. For VHDL, we didn't have anything other than toy examples to try and those appeared to work.
@bryankerr1986 I believe that is likely an OSVVM + Cadence Xcelium issue not an issue with this branch if I'm remembering the communications with Cadence correctly. There were a lot of OSVVM issues in Cadence and they got fixed after this branch was created so we never got the fixes in the git submodule into this branch.
For anyone who is capable of picking this up, please feel free to do so.
@Hardolaf
Ok, well I forked your repo and rebased to the latest VUnit. I also added an option to pass compile arguments. Now I have a pretty large vhdl sim working.
One thing I noticed is that your compiling the source files a little differently than incisive was doing this right? I noticed run.py --compile and run.py -m we're not working for me. Does this sound familiar?
@bryankerr1986 We ran into a lot of issues around NFSv4 and file timestamps with Xcelium when we tried doing multi-library compiles. We also found that the per-file compilation was fundamentally broken both in terms of speed and in terms of maintaining a consistent database on NFSv4 drives (and we saw the same issue on a GlusterFS filesystem). We also tried several parallel build and simulation trials but didn't get good results using a common compilation directory with per-sim elaboration keys.
And yes, I did break a good number of things from what was being done for Incisive. Overall, VUnit is not designed to handle 3-step compilation or efficient compilation particularly well. And we didn't really fully test everything. We got it to a working state for us and pushed that. Additional changes were made but I never got approval to push them. But those are mostly around automation in Indago not around the compilation and simulation flow without a debugger attached.
Overall, we were in the process of moving away from VUnit as it was too inflexible for the number of simulations we were running in CI/CD and it was not scaling well.