I am leaving a few things here, not as a working solution, but as ongoing
diary of investigating this problem. I have two computers now,
side-by-side.
Computer "W"
- Ubuntu *22.04.1* kernel 6.5-0-28
- MATLAB R2021a
- Vivado 2021.1
Computer "GTX"
- Ubuntu 20.04.1 kernel 5.15.0-122
- MATLAB R20*22a*
- Vivado *2023.1*
Differences are already interesting. For example, Vivado 2023.1 no longer
has this file
/tools/Xilinx/Vivado/2021.1/bin/unwrapped/lnx64.o/sysgensockgui
It has been replaced by a new methodology, and this has an effect on the
processes that appear in ps aux.
The other reason why sysgensockgui is important is because of this blog ,
https://strath-sdr.github.io/tools/matlab/sysgen/vivado/linux/2021/01/28/sysgen-on-20-04.html
Following in Craig Ramsay's footprints, the following logs are from the
"W" computer.
https://bpa.st/H43UEICDV7OVWKJQPSXE7F3FEM
So all the dynamically linked libraries are in order. Just to make sure, I
added the following line to /etc/environment , sudo ldconfig, and logged
out of the desktop,
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu/:/usr/local/MATLAB/R2021a/bin/glnxa64/:/tools/Xilinx/Vivado/2021.1/lib/lnx64.o/
These directories *must *be in this order ( ldconfig simply uses the first
version of a library that occurs in left-to-right order. It is not smart
enough to compare various versions of libstdc++.so.6 and select the
correct one. Also, using the wrong order can lock you out of your desktop.)
To make sure this works, I added these lines to startsg (not startsg.local
!)
(below) echo "Using HDL_ROOT=${HDL_ROOT}"
echo "Using LD_LIBRARY_PATH=${LD_LIBRARY_PATH}"
sudo ldconfig
Other tidbits. There are several sysgen related processes loaded and
running during a frozen compile, including sysgensockgui, and other vivado
load scripts. These were incrementally sudo kill'd , but had no effect on
un-freezing the displayed window.
The current situation with computer "W" is that there are some models that
compile and others not. This means I can strip certain blocks, or
incrementally add some in, until the freeze bug is observed.
Investigations of this type have turned up *Mult (Xilinx Multiplier)* as a
problematic block. If you want to follow along, you can try adding or
removing a Mult block to observe the same effect I am seeing.
I will have some results from the "GTX" computer soon. Stay tuned.
On Wednesday, October 9, 2024 at 3:38:58 AM UTC-4 Morag Brown wrote:
> Jumping in on this rather late, but I've just been reminded that there's
> also an issue with clashing MATLAB/Simulink toolboxes that can cause issues
> with sysgen. The third comment from the bottom of this
> <https://adaptivesupport.amd.com/s/question/0D52E00006vF6FOSA0/model-composer-v20212-matlab-r2021a-gets-stuck-at-initialization-stage-on-ubuntu-20041?language=en_US>
> support
> post has a list of known compatible toolboxes.
>
> From what I've seen, clashes tend to be from anything involving some
> library's Simulink toolbox. I imagine that under the hood these things
> don't necessarily all play nicely, and it's worse with sysgen given that it
> also has to interact with Vivado in the background. Not sure that's
> necessarily the case here, considering you've managed to compile the design
> previously. But it may be worth mentioning in case you've recently found
> yourself with a new set of toolboxes.
>
> Even with compatible toolboxes, I've faced this issue quite a bit myself.
> I have an slx file that just flat out doesn't making it past sysgen
> generation at all anymore. Others will hang when just updating the design
> in Simulink - I've noticed this happens when I add in new sysgen library
> blocks, and it's really hit or miss as to whether it works after restarting
> things.
>
> As with Mitch, sorry I don't have a better answer either. But if anyone
> ever does manage to get to the bottom of this, please let us know.
>
> Morag
>
> On Sat, Sep 28, 2024 at 12:24 AM Mitchell Burnett <[email protected]>
> wrote:
>
>> Hi Ken,
>>
>> I am not sure anyone understands this problem. Once upon a time, I
>> thought it was a race condition between System Generator and Simulink. I
>> tried to debug it by changing some of the MATLAB Java Runtime parameters
>> and hooking into the JRE to watch what processes it was running, and see if
>> anything stood out. I didn’t have much luck then. It did look like Simulink
>> was waiting for a return value. I have since chalked it up to a race
>> condition and that Simulink just misses the return value. You could be
>> right that it never makes it back because it silently crashes. I am not
>> sure either how to look at System Generator as a process.
>>
>> Every time I have tried, I can hit the “cancel” button on the bottom of
>> the Simulink canvas and then repeatedly spam an interrupt to in the
>> terminal used to launch MATLAB and the interrupt is caught and returns
>> back. Although, I have more luck at that point restarting MATLAB/Simulink
>> entirely rather than starting a fresh compile. It just seems to happen
>> again too often without the restart. Wish I had a better answer for you.
>>
>> Mitch
>>
>> On Sep 27, 2024, at 2:49 PM, Ken Semanov <[email protected]> wrote:
>>
>> This problem is not resolved by the cache cleaning. A rumor is that this
>> is caused by System Generator silently crashing, which results in the
>> Compilation status popup waiting eternally for it. Does anyone know how to
>> see System Generator as a process (e.g. in ps aux? )
>> On Wednesday, September 18, 2024 at 7:38:52 PM UTC-4 Ken Semanov wrote:
>>
>>> This is an issue of the System Generator. Removing the cache relieves
>>> the problem.
>>>
>>> On Wednesday, September 18, 2024 at 7:01:04 PM UTC-4 Ken Semanov wrote:
>>>
>>>> Anyone have troubleshooting tips for when Jasper compiles hangs at this
>>>> stage?
>>>>
>>>> [image: Screenshot-20240918-180618.png]
>>>>
>>>> I have already tried the following continuously for 90 minutes on
>>>> several different slx models. While these "fixes" used to work in the
>>>> past,
>>>> they no longer work now.
>>>>
>>>> - Restart MATLAB, reload model, compile.
>>>> - Simulate the model first, save, then compile.
>>>> - Reboot the computer.
>>>> - Simulate the model for 1000 steps. Save slx. Close MATLAB, Open
>>>> MATLAB. Reopen the model. Compile
>>>> - Close model. Delete proj/proj/sysgen/ip_catalog/proj.cache/*
>>>> Reopen model. Compile.
>>>>
>>>> I have compiled this SLX model many times in the past. I have moved
>>>> the slx file into a fresh new directory before generating the following
>>>> logs.
>>>>
>>>> jasper.log at https://bpa.st/KBYAA
>>>>
>>>> vivado.log at https://bpa.st/ICB52
>>>>
>>>> The files generated before system generator begins to hang , at
>>>> https://bpa.st/5ZT7A
>>>>
>>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "[email protected]" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/ecc53875-558a-4e89-a6de-7fd45e063950n%40lists.berkeley.edu
>>
>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/ecc53875-558a-4e89-a6de-7fd45e063950n%40lists.berkeley.edu?utm_medium=email&utm_source=footer>
>> .
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "[email protected]" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>>
> To view this discussion on the web visit
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/6D7AC189-3F38-4B94-9D35-0AB8DF06CD65%40gmail.com
>>
>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/6D7AC189-3F38-4B94-9D35-0AB8DF06CD65%40gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> *Disclaimer*
>
> The information contained in this communication from the sender is
> confidential. It is intended solely for use by the recipient and others
> authorized to receive it. If you are not the recipient, you are hereby
> notified that any disclosure, copying, distribution or taking action in
> relation of the contents of this information is strictly prohibited and may
> be unlawful.
>
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/63d67967-fab1-41d5-a0e0-f8586935a93an%40lists.berkeley.edu.