Seg Fault when running RapidWright in WSL #552
-
|
Hello RW community, I am currently trying to use RapidWright in Ubuntu 20.04 LTS that is installed into a WSL 2 (Windows Sub-System for Linux) instance. The other RW tools have worked great but I am now trying to go through the PicoBlaze tutorial which requires usage of the RW performance explorer and Vivado Seg Faults every time with the following error:
Failed Job Count: 60 I guess I am willing to accept that this is just user error and the performance explorer cannot be run in a VM or VM like environment but I figured it was worth discussion before trying to move to a native Linux box. Things I have tried:
Other system info: Thanks for the help and discussion! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 5 replies
-
|
RapidWright and Vivado are supported on Windows, is there a particular constraint in your workflow that requires WSL? How did you install Vivado for WSL? Although we might be able to accommodate minor changes for RapidWright on WSL, it would be harder to make changes to Vivado for that platform if something wasn't working correctly. Your best bet might be to try it on a native Linux or Windows machine. |
Beta Was this translation helpful? Give feedback.
-
|
Chris, Thank you for the quick response. No I guess there isn't a reason that I needed to be running Vivado and RapidWright in WSL vs Windows. I didn't have an additional machine available to run Linux natively which is why I went to WSL. I guess I've always done dev in Linux and figured it was required for RW and Vivado. My assumption is that this isn't directly an issue with RapidWright and more of an issue with Vivado. Although maybe the way that you call Vivado instances in the Performance Explorer results in memory issues with Vivado in virtualized environments. I'll take a look at running in Windows or see if I can't find another machine to run native Linux and see how that goes. Thanks, |
Beta Was this translation helpful? Give feedback.
-
|
Hey Calvin, Well it seems like switching to a native Linux OS installation did not help as I still seg-faulted although the actual readout on the command line was slightly different. "
Failed Job Count: 60 Do you have any other suggestions to try out? I am sort of at a loss here for what to try next as this seems to be a seg-fault within Vivado and not specifically RapidWright. Colin |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for trouble you are seeing. Here are a few things you could try to diagnose.
This should only run 3 jobs in series and you can even go into the pblock file and remove two of them to get down to one. If you can get a successful run, try building up until it breaks. If you are still having trouble, can you please provide the version of Linux you are using and as much information as possible about your environment so we can try to reproduce on our side? |
Beta Was this translation helpful? Give feedback.
-
|
Hi Calvin, So initially, I think I found a user error... The performance explorer crashes out if you already have a pblock saved to your DCP file that matches any of the default names the explorer wants to use [pblock0, pblock1, etc.]. After deleting any pblocks that I had saved to my design I re-ran the modified script you provided <java com.xilinx.rapidwright.util.PerformanceExplorer -c clk -i picoblaze_synth.dcp -t 2.85 -b picoblaze_pblocks.txt -z 1 -p Default -r Default -u 0.0> and SUCCESS I moved up to 4 total jobs <java com.xilinx.rapidwright.util.PerformanceExplorer -c clk -i picoblaze_synth.dcp -t 2.85 -b picoblaze_pblocks.txt -z 1 -u 0.0> SUCCESS Then 15 total jobs <java com.xilinx.rapidwright.util.PerformanceExplorer -c clk -i picoblaze_synth.dcp -t 2.85 -b picoblaze_pblocks.txt -z 1 -p Default -r Default> SUCCESS Then 30 total jobs <java com.xilinx.rapidwright.util.PerformanceExplorer -c clk -i picoblaze_synth.dcp -t 2.85 -b picoblaze_pblocks.txt -z 1 -p Default> SUCCESS And then 60 total jobs <java com.xilinx.rapidwright.util.PerformanceExplorer -c clk -i picoblaze_synth.dcp -t 2.85 -b picoblaze_pblocks.txt -z 1> FAILED
Time (s): cpu = 00:00:00.01 ; elapsed = 00:00:00.40 . Memory (MB): peak = 3495.328 ; gain = 0.000 ; free physical = 412 ; free virtual = 4386 Phase 1.2 IO Placement/ Clock Placement/ Build Placer Device You were right about some jobs succeeding. I didn't click through all 60 but my feeling is that the majority of the jobs succeeded. One interesting thing to note is that even when passing the -z 1 flag, to limit the max number of concurrent jobs, I feel like it is being ignored. For example, Vivado still uses the max about of CPUs (in this case 8) and a thread for each RW Performance Explorer job gets created and is being executed concurrently; usually ~20 system tasks get created and ~400 new threads are created. I can verify the Vivado CPU usage in the cmd.log files that are created for each run and I look at HTOP to see the total amount of new threads and tasks.
Ultimately, this is still workable as I can limit the total jobs per run of the explorer to less than 30 and just iterate through some of the options on my own but I would be interested to understand if the -z flag is working as intended or if there was a way to limit Vivado CPU count from this application. I am happy to provide more information if you think there is something here worth digging into. Thanks, |
Beta Was this translation helpful? Give feedback.
-
|
Hi Colin, You were right in that Thanks for bringing it up! Chris |
Beta Was this translation helpful? Give feedback.
RapidWright and Vivado are supported on Windows, is there a particular constraint in your workflow that requires WSL? How did you install Vivado for WSL?
Although we might be able to accommodate minor changes for RapidWright on WSL, it would be harder to make changes to Vivado for that platform if something wasn't working correctly. Your best bet might be to try it on a native Linux or Windows machine.