Re: [casper] Jasper freezing on compile

[Ken Semanov]

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 
> 
>  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  
> 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 a

Re: [casper] Jasper freezing on compile

[Morag Brown]

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

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 
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
> runn ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
>
> 

Re: [casper] Jasper freezing on compile

[Mitchell Burnett]

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  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? 
>>> 
>>> 
>>> 
>>> 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 
> "casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to casper+unsubscr...@lists.berkeley.edu 
> .
> 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
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
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.

[casper] Jasper freezing on compile

[Ken Semanov]

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 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/cd2d3965-b283-45ee-a87b-4a29c7c0f1cbn%40lists.berkeley.edu.

Re: [casper] Jasper error while compiling

[Guillermo Gancio]

Hi Jonathon,

Thanks for the ideas, I installed the KDE desktop, and I has available
to compile the tut_intro and tut_spec doing a
update_casper_blocks(bdroot), but they run only once, the second time
as before they seems to never end

I guess I have some bad environment config.I'll keep trying to
find the issue

Thanks again!



El lun., 19 oct. 2020 a las 20:52, Jonathon Kocz () escribió:
>
>
>> I'm working on Ubuntu 18, matlab 2019a and vivado 2019.1.3
>>
> So I hadn't tried these tutorials in 2019a, only 2018a. (See recommended 
> versions here: 
> https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html
>  Vivado/Matlab are extraordinarily picky about which combinations will work)
>
> Just quickly testing:
>
> tut_intro ran, and took about 10 minutes.
>
> spec/corr would not compile without updating the blocks in 2019a. Did you run 
> update_casper_blocks / regen the fft with a new one from the library before 
> running jasper?
>
> So these ones not working *might* be a matlab version issue, but they should 
> work once you update the blocks.
>
>> I also tried tut_intro and I didnt get any error but it reaches
>> Skipping diagram update
>> Running system generator ...
>> and never finishes.
>
>
> This seems like something else.
>
> I'm wondering if this is an Ubuntu 18 issue - do you have kde installed? (See 
> this post by Jack in the mail archive: 
> https://www.mail-archive.com/casper@lists.berkeley.edu/msg07886.html). Even 
> though it's not quite the same, the timeout makes me wonder.
>
> Cheers,
> Jonathon
>
> --
> You received this message because you are subscribed to the Google Groups 
> "casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit 
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAPU71P_OcNnwtyZMWpUWaAqca5sAS%2B-9u28ZRDyQaaO7GPx-qw%40mail.gmail.com.



-- 
Instituto Argentino de Radioastronomia
[Argentine Institute of Radioastronomy]

Guillermo M. Gancio
Responsable Área Observatorio
[Head of Observatory]

Tel: (0054-0221) 482-4903 Int: 106
Mail laboralggan...@iar.unlp.edu.ar

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CA%2BEePfTfyUJFYbJCWfUQXxyPfHbr4AJJ6wYkJsv1bzhHjTKv0g%40mail.gmail.com.

Re: [casper] Jasper error while compiling

[Jonathon Kocz]

> I'm working on Ubuntu 18, matlab 2019a and vivado 2019.1.3
>
> So I hadn't tried these tutorials in 2019a, only 2018a. (See recommended
versions here:
https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html
Vivado/Matlab are extraordinarily picky about which combinations will work)

Just quickly testing:

tut_intro ran, and took about 10 minutes.

spec/corr would not compile without updating the blocks in 2019a. Did you
run update_casper_blocks / regen the fft with a new one from the library
before running jasper?

So these ones not working *might* be a matlab version issue, but they
should work once you update the blocks.

I also tried tut_intro and I didnt get any error but it reaches
> Skipping diagram update
> Running system generator ...
> and never finishes.
>

This seems like something else.

I'm wondering if this is an Ubuntu 18 issue - do you have kde installed?
(See this post by Jack in the mail archive:
https://www.mail-archive.com/casper@lists.berkeley.edu/msg07886.html). Even
though it's not quite the same, the timeout makes me wonder.

Cheers,
Jonathon

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAPU71P_OcNnwtyZMWpUWaAqca5sAS%2B-9u28ZRDyQaaO7GPx-qw%40mail.gmail.com.

Re: [casper] Jasper error while compiling

[Guillermo Gancio]

Hi Jonathon,

Thanks for your quick answer, I'm using the designs from
tutorial_devel directly, I have the same issue with tut_spec and
tut_corr
I also tried tut_intro and I didnt get any error but it reaches
Skipping diagram update
Running system generator ...
and never finishes.

I'm working on Ubuntu 18, matlab 2019a and vivado 2019.1.3

I just got the mlib again and I have the same issue, I have the
feeling that is not a problem with the library itself but with some
other thing that I'm missing...

Thanks again.



El lun., 19 oct. 2020 a las 19:19, Jonathon Kocz () escribió:
>
> Hi Guillermo,
>
> I'm not sure what is causing that specific error - normally it's that there's 
> something like an invalid input (somewhere) in the signal chain leading up to 
> the block it is complaining about (though it looks like it's complaining 
> about the register block yellow block itself).
>
> Did you put the design together following the instructions, or are you just 
> trying to compile the example design provided? Have you been able to compile 
> any of the other SNAP designs?
>
> To confirm, you're using matlab 2018a and vivado 2019.1?
>
> As an aside, there was some work done on the toolflow last week, and as part 
> of that there is now an update on the main branch (as of this morning). I 
> tested those libraries against the SNAP tutorial designs as part of the 
> verification, so they should work, if you want to try using them instead. 
> (They have not yet been propagated into the tutorials_devel branch 
> submodules, this will probably happen in the next week or so).
>
> Cheers,
> Jonathon
>
> On Mon, 19 Oct 2020 at 15:04, Guillermo Gancio  wrote:
>>
>> Hi all,
>>
>> I'm having trouble compiling the SNAP tutorial designs, I guess that
>> I'm missing some (silly) variable config but after a week of looking
>> around I couldn't find it, I did a fresh tool-flow installation and
>> I'm using virtual env for python 3...If any one has any idea.
>>
>> the error that I got is this:
>>
>> Error using jasper_frontend (line 33)
>> The S-function 'sysgen' in 'snap_tut_corr/fft_shift/io_delay' has
>> specified the option SS_OPTION_PORT_SAMPLE_TIMES_ASSIGNED and
>> specified inherited for sample time number 0. Inheriting a sample time
>> is not supported when specifying
>> SS_OPTION_PORT_SAMPLE_TIMES_ASSIGNED
>>
>> Error in jasper (line 6)
>> build_cmd = jasper_frontend; - Show complete stack trace
>>
>> Thanks!
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To view this discussion on the web visit 
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CA%2BEePfTLub5_pF%3DoqNN_az5iD9VdjqW3e%3DmRDVKwpkV5eu2wJw%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit 
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAPU71P_-E7Gx-UeHuoC3_nEGKD0AMxFqCL1wU1y7v_9Zx6bZ%3DQ%40mail.gmail.com.



-- 
Instituto Argentino de Radioastronomia
[Argentine Institute of Radioastronomy]

Guillermo M. Gancio
Responsable Área Observatorio
[Head of Observatory]

Tel: (0054-0221) 482-4903 Int: 106
Mail laboralggan...@iar.unlp.edu.ar

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CA%2BEePfT46s5VAyPVtDPnO3ssRipQBGt%2BEJDrKRZ86Yz1L1xCyQ%40mail.gmail.com.

Re: [casper] Jasper error while compiling

[Jonathon Kocz]

Hi Guillermo,

I'm not sure what is causing that specific error - normally it's that
there's something like an invalid input (somewhere) in the signal chain
leading up to the block it is complaining about (though it looks like it's
complaining about the register block yellow block itself).

Did you put the design together following the instructions, or are you just
trying to compile the example design provided? Have you been able to
compile any of the other SNAP designs?

To confirm, you're using matlab 2018a and vivado 2019.1?

As an aside, there was some work done on the toolflow last week, and as
part of that there is now an update
on the main branch (as of this
morning). I tested those libraries against the SNAP tutorial designs as
part of the verification, so they should work, if you want to try using
them instead. (They have not yet been propagated into the tutorials_devel
branch submodules, this will probably happen in the next week or so).

Cheers,
Jonathon

On Mon, 19 Oct 2020 at 15:04, Guillermo Gancio  wrote:

> Hi all,
>
> I'm having trouble compiling the SNAP tutorial designs, I guess that
> I'm missing some (silly) variable config but after a week of looking
> around I couldn't find it, I did a fresh tool-flow installation and
> I'm using virtual env for python 3...If any one has any idea.
>
> the error that I got is this:
>
> Error using jasper_frontend (line 33)
> The S-function 'sysgen' in 'snap_tut_corr/fft_shift/io_delay' has
> specified the option SS_OPTION_PORT_SAMPLE_TIMES_ASSIGNED and
> specified inherited for sample time number 0. Inheriting a sample time
> is not supported when specifying
> SS_OPTION_PORT_SAMPLE_TIMES_ASSIGNED
>
> Error in jasper (line 6)
> build_cmd = jasper_frontend; - Show complete stack trace
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CA%2BEePfTLub5_pF%3DoqNN_az5iD9VdjqW3e%3DmRDVKwpkV5eu2wJw%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAPU71P_-E7Gx-UeHuoC3_nEGKD0AMxFqCL1wU1y7v_9Zx6bZ%3DQ%40mail.gmail.com.

[casper] Jasper error while compiling

[Guillermo Gancio]

Hi all,

I'm having trouble compiling the SNAP tutorial designs, I guess that
I'm missing some (silly) variable config but after a week of looking
around I couldn't find it, I did a fresh tool-flow installation and
I'm using virtual env for python 3...If any one has any idea.

the error that I got is this:

Error using jasper_frontend (line 33)
The S-function 'sysgen' in 'snap_tut_corr/fft_shift/io_delay' has
specified the option SS_OPTION_PORT_SAMPLE_TIMES_ASSIGNED and
specified inherited for sample time number 0. Inheriting a sample time
is not supported when specifying
SS_OPTION_PORT_SAMPLE_TIMES_ASSIGNED

Error in jasper (line 6)
build_cmd = jasper_frontend; - Show complete stack trace

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CA%2BEePfTLub5_pF%3DoqNN_az5iD9VdjqW3e%3DmRDVKwpkV5eu2wJw%40mail.gmail.com.

Re: [casper] jasper not working properly after upgrade

[Nitish Ragoomundun]

Hi,

Got the toolflow working again. :) Thank you very much for your help.
Yes, the old jasper_library/platform.pyc file was the cause. Removed it and
everything compiles correctly now.

Many thanks.
Best regards,
Nitish


On Wed, Nov 20, 2019 at 9:33 PM Jack Hickish  wrote:

> Hi Nitish,
>
> I think this is related to
> https://github.com/casper-astro/mlib_devel/commit/6e02a6ff98a9394c6b0acac570547d7841630dc9
>
> Could you check if you have a lingering "platform.pyc" file in
> mlib_devel/jasper_library and if so, delete it. Can you also check whether
> this pyc file is in your python installation directory and if so delete
> that too.
>
> I think the problem is that pyc files are not tracked by the repo, so if
> you have a version of mlib_devel from before the above commit you have
> installed from, there will be a platform.pyc file knocking around which
> will get erroneously installed after an upgrade.
>
> Let me know if that doesn't fix things.
>
> Cheers
> Jack
>
> On Wed, 20 Nov 2019 at 08:24, Jack Hickish  wrote:
>
>> Thanks for the detailed report Nitish. I have a vague recollection that
>> this is something simple which might have to do with a previous install of
>> the title not being overwritten properly.
>>
>> I'll dig through my notes and get back to you asap
>>
>> Jack
>>
>> On Wed, 20 Nov 2019, 12:02 am Nitish Ragoomundun, <
>> nitish.ragoomun...@gmail.com> wrote:
>>
>>>
>>> Thank you very much for your replies. I misunderstood the importance of
>>> the virtual environment. So I set it up like described in
>>> https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html
>>> and
>>> https://casper-toolflow.readthedocs.io/en/latest/src/Configuring-the-Toolflow.html.
>>> Yes, I am using the latest version of mlib_devel. Found out that we
>>> absolutely needed the LD_PRELOAD variable set or else jasper made an error
>>> looking for symbols for XML...
>>>
>>> Yes, I think changing the shabang line to point to python3 might cause
>>> other issues. There might be other scripts down the pipeline with the same
>>> call to "python".
>>>
>>> Anyway, got the virtual env running and I thought we were good to go but
>>> got another error:
>>>
>>> XSG generation complete.
>>> 
>>> *Front End compile complete*
>>> 
>>> To complete your compile, run the following command in a terminal.
>>> Remember to source your startsg.local environment first!
>>> /home/aragorn/Documents/SNAP/casper_venv/bin/python
>>> /home/aragorn/Documents/CASPER/mlib_devel/jasper_library/exec_flow.py -m
>>> /home/aragorn/Documents/SNAP/Spectrum_Analyser/spectrum_480mhz_2048pts_3c.slx
>>> --middleware --backend --software
>>> 
>>> *  Frontend complete!  *
>>> *  Running Backend generation  *
>>> 
>>> Starting compile
>>> Starting Toolflow!
>>> Frontend is simulink
>>> Setting compile directory:
>>> /home/aragorn/Documents/SNAP/Spectrum_Analyser/spectrum_480mhz_2048pts_3c
>>> /home/aragorn/Documents/CASPER/mlib_devel/jasper_library/toolflow.py:236:
>>> YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as
>>> the default Loader is unsafe. Please read https://msg.pyyaml.org/load
>>> for full details.
>>>   yaml_dict = yaml.load(fh)
>>>
>>> /home/aragorn/Documents/CASPER/mlib_devel/jasper_library/platforms/snap.yaml
>>> /home/aragorn/Documents/CASPER/mlib_devel/jasper_library/casper_platform.py:24:
>>> YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as
>>> the default Loader is unsafe. Please read https://msg.pyyaml.org/load
>>> for full details.
>>>   self.conf = yaml.load(fh.read())
>>> {'manufacturer': 'Xilinx', 'backend_target': 'vivado', 'sources': [],
>>> 'name': 'snap', 'invert_sfp_disable': True, 'pins': {'sync_out': {'iostd':
>>> 'LVCMOS25', 'loc': 'H9'}, 'lmx2581_muxout': {'iostd': 'LVCMOS33', 'loc':
>>> 'J19'}, 'mgt_tx_p': {'loc': ['P2', 'K2']}, 'usb_tx': {'iostd': 'LVCMOS25',
>>> 'loc': 'J8'}, 'sync_in_p': {'iostd': 'LVDS_25', 'loc': 'AD25'}, 'zdok0':
>>> {'iostd': 'LVCMOS25', 'loc': ['AA23', 'AB24', 'Y25', 'Y26', 'U24', 'U25',
>>> 'U19', 'U20', 'T24', 'T25', 'M21', 'M22', 'M24', 'L24', 'L22', 'K22',
>>> 'J24', 'J25', 'G25', 'G26', 'Y22', 'AA22', 'Y23', 'AA24', 'V23', 'V24',
>>> 'R22', 'R23', 'R21', 'P21', 'P23', 'N23', 'K25', 'K26', 'K23', 'J23',
>>> 'H21', 'G21', 'G22', 'F23', 'AE23', 'AF23', 'AC23', 'AC24', 'W23', 'W24',
>>> 'T22', 'T23', 'R18', 'P18', 'N18', 'M19', 'N19', 'M20', 'J21', 'H22',
>>> 'G24', 'F24', 'D23', 'D24', 'AE22', 'AF22', 'AB26', 'AC26', 'V21', 'W21',
>>> 'U17', 'T17', 'R16', 'R17', 'P19', 'P20', 'P16', 'N17', 'J26', 'H26',
>>> 'E25', 'D25', 'F22', 'E23']}, 'adc_sdata': {'iostd': 'LVCMOS18', 'loc':
>>> ['AF2', 'AF9', 'W14']}, 'lmx2581_be': {'iostd': 'LVCMOS33', 'loc': 'F15'},
>>> 'adc_sclk': {'iostd': 'LVCMOS33', 'loc': ['M17', 'L18', 'K16']},
>>> 'clk_sel_a': {'

Re: [casper] jasper not working properly after upgrade

[Jack Hickish]

Hi Nitish,

I think this is related to
https://github.com/casper-astro/mlib_devel/commit/6e02a6ff98a9394c6b0acac570547d7841630dc9

Could you check if you have a lingering "platform.pyc" file in
mlib_devel/jasper_library and if so, delete it. Can you also check whether
this pyc file is in your python installation directory and if so delete
that too.

I think the problem is that pyc files are not tracked by the repo, so if
you have a version of mlib_devel from before the above commit you have
installed from, there will be a platform.pyc file knocking around which
will get erroneously installed after an upgrade.

Let me know if that doesn't fix things.

Cheers
Jack

On Wed, 20 Nov 2019 at 08:24, Jack Hickish  wrote:

> Thanks for the detailed report Nitish. I have a vague recollection that
> this is something simple which might have to do with a previous install of
> the title not being overwritten properly.
>
> I'll dig through my notes and get back to you asap
>
> Jack
>
> On Wed, 20 Nov 2019, 12:02 am Nitish Ragoomundun, <
> nitish.ragoomun...@gmail.com> wrote:
>
>>
>> Thank you very much for your replies. I misunderstood the importance of
>> the virtual environment. So I set it up like described in
>> https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html
>> and
>> https://casper-toolflow.readthedocs.io/en/latest/src/Configuring-the-Toolflow.html.
>> Yes, I am using the latest version of mlib_devel. Found out that we
>> absolutely needed the LD_PRELOAD variable set or else jasper made an error
>> looking for symbols for XML...
>>
>> Yes, I think changing the shabang line to point to python3 might cause
>> other issues. There might be other scripts down the pipeline with the same
>> call to "python".
>>
>> Anyway, got the virtual env running and I thought we were good to go but
>> got another error:
>>
>> XSG generation complete.
>> 
>> *Front End compile complete*
>> 
>> To complete your compile, run the following command in a terminal.
>> Remember to source your startsg.local environment first!
>> /home/aragorn/Documents/SNAP/casper_venv/bin/python
>> /home/aragorn/Documents/CASPER/mlib_devel/jasper_library/exec_flow.py -m
>> /home/aragorn/Documents/SNAP/Spectrum_Analyser/spectrum_480mhz_2048pts_3c.slx
>> --middleware --backend --software
>> 
>> *  Frontend complete!  *
>> *  Running Backend generation  *
>> 
>> Starting compile
>> Starting Toolflow!
>> Frontend is simulink
>> Setting compile directory:
>> /home/aragorn/Documents/SNAP/Spectrum_Analyser/spectrum_480mhz_2048pts_3c
>> /home/aragorn/Documents/CASPER/mlib_devel/jasper_library/toolflow.py:236:
>> YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as
>> the default Loader is unsafe. Please read https://msg.pyyaml.org/load
>> for full details.
>>   yaml_dict = yaml.load(fh)
>>
>> /home/aragorn/Documents/CASPER/mlib_devel/jasper_library/platforms/snap.yaml
>> /home/aragorn/Documents/CASPER/mlib_devel/jasper_library/casper_platform.py:24:
>> YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as
>> the default Loader is unsafe. Please read https://msg.pyyaml.org/load
>> for full details.
>>   self.conf = yaml.load(fh.read())
>> {'manufacturer': 'Xilinx', 'backend_target': 'vivado', 'sources': [],
>> 'name': 'snap', 'invert_sfp_disable': True, 'pins': {'sync_out': {'iostd':
>> 'LVCMOS25', 'loc': 'H9'}, 'lmx2581_muxout': {'iostd': 'LVCMOS33', 'loc':
>> 'J19'}, 'mgt_tx_p': {'loc': ['P2', 'K2']}, 'usb_tx': {'iostd': 'LVCMOS25',
>> 'loc': 'J8'}, 'sync_in_p': {'iostd': 'LVDS_25', 'loc': 'AD25'}, 'zdok0':
>> {'iostd': 'LVCMOS25', 'loc': ['AA23', 'AB24', 'Y25', 'Y26', 'U24', 'U25',
>> 'U19', 'U20', 'T24', 'T25', 'M21', 'M22', 'M24', 'L24', 'L22', 'K22',
>> 'J24', 'J25', 'G25', 'G26', 'Y22', 'AA22', 'Y23', 'AA24', 'V23', 'V24',
>> 'R22', 'R23', 'R21', 'P21', 'P23', 'N23', 'K25', 'K26', 'K23', 'J23',
>> 'H21', 'G21', 'G22', 'F23', 'AE23', 'AF23', 'AC23', 'AC24', 'W23', 'W24',
>> 'T22', 'T23', 'R18', 'P18', 'N18', 'M19', 'N19', 'M20', 'J21', 'H22',
>> 'G24', 'F24', 'D23', 'D24', 'AE22', 'AF22', 'AB26', 'AC26', 'V21', 'W21',
>> 'U17', 'T17', 'R16', 'R17', 'P19', 'P20', 'P16', 'N17', 'J26', 'H26',
>> 'E25', 'D25', 'F22', 'E23']}, 'adc_sdata': {'iostd': 'LVCMOS18', 'loc':
>> ['AF2', 'AF9', 'W14']}, 'lmx2581_be': {'iostd': 'LVCMOS33', 'loc': 'F15'},
>> 'adc_sclk': {'iostd': 'LVCMOS33', 'loc': ['M17', 'L18', 'K16']},
>> 'clk_sel_a': {'iostd': 'LVCMOS33', 'loc': ['A18']}, 'i2c': {'iostd': 'I2C',
>> 'loc': ['', '', '', '', '', '', 'E18', 'B16', '', 'C16', '', '', '', '',
>> '', '', '', '', 'J20', '', 'K20', '', 'E17', 'G19', '', '', '', '', 'C17',
>> '', 'C18', 'C19', 'B19', '', 'A17', 'B17', 'D20', 'H18', '', 'H17']},
>> 'sync_in_n': {'iostd': 'LVDS_25', 'loc': 'AE25'}, 'adc_lclkp': {'iostd':
>> 'LVDS', 'loc': ['AA3']}

Re: [casper] jasper not working properly after upgrade

[Jack Hickish]

Thanks for the detailed report Nitish. I have a vague recollection that
this is something simple which might have to do with a previous install of
the title not being overwritten properly.

I'll dig through my notes and get back to you asap

Jack

On Wed, 20 Nov 2019, 12:02 am Nitish Ragoomundun, <
nitish.ragoomun...@gmail.com> wrote:

>
> Thank you very much for your replies. I misunderstood the importance of
> the virtual environment. So I set it up like described in
> https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html
> and
> https://casper-toolflow.readthedocs.io/en/latest/src/Configuring-the-Toolflow.html.
> Yes, I am using the latest version of mlib_devel. Found out that we
> absolutely needed the LD_PRELOAD variable set or else jasper made an error
> looking for symbols for XML...
>
> Yes, I think changing the shabang line to point to python3 might cause
> other issues. There might be other scripts down the pipeline with the same
> call to "python".
>
> Anyway, got the virtual env running and I thought we were good to go but
> got another error:
>
> XSG generation complete.
> 
> *Front End compile complete*
> 
> To complete your compile, run the following command in a terminal.
> Remember to source your startsg.local environment first!
> /home/aragorn/Documents/SNAP/casper_venv/bin/python
> /home/aragorn/Documents/CASPER/mlib_devel/jasper_library/exec_flow.py -m
> /home/aragorn/Documents/SNAP/Spectrum_Analyser/spectrum_480mhz_2048pts_3c.slx
> --middleware --backend --software
> 
> *  Frontend complete!  *
> *  Running Backend generation  *
> 
> Starting compile
> Starting Toolflow!
> Frontend is simulink
> Setting compile directory:
> /home/aragorn/Documents/SNAP/Spectrum_Analyser/spectrum_480mhz_2048pts_3c
> /home/aragorn/Documents/CASPER/mlib_devel/jasper_library/toolflow.py:236:
> YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as
> the default Loader is unsafe. Please read https://msg.pyyaml.org/load for
> full details.
>   yaml_dict = yaml.load(fh)
>
> /home/aragorn/Documents/CASPER/mlib_devel/jasper_library/platforms/snap.yaml
> /home/aragorn/Documents/CASPER/mlib_devel/jasper_library/casper_platform.py:24:
> YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as
> the default Loader is unsafe. Please read https://msg.pyyaml.org/load for
> full details.
>   self.conf = yaml.load(fh.read())
> {'manufacturer': 'Xilinx', 'backend_target': 'vivado', 'sources': [],
> 'name': 'snap', 'invert_sfp_disable': True, 'pins': {'sync_out': {'iostd':
> 'LVCMOS25', 'loc': 'H9'}, 'lmx2581_muxout': {'iostd': 'LVCMOS33', 'loc':
> 'J19'}, 'mgt_tx_p': {'loc': ['P2', 'K2']}, 'usb_tx': {'iostd': 'LVCMOS25',
> 'loc': 'J8'}, 'sync_in_p': {'iostd': 'LVDS_25', 'loc': 'AD25'}, 'zdok0':
> {'iostd': 'LVCMOS25', 'loc': ['AA23', 'AB24', 'Y25', 'Y26', 'U24', 'U25',
> 'U19', 'U20', 'T24', 'T25', 'M21', 'M22', 'M24', 'L24', 'L22', 'K22',
> 'J24', 'J25', 'G25', 'G26', 'Y22', 'AA22', 'Y23', 'AA24', 'V23', 'V24',
> 'R22', 'R23', 'R21', 'P21', 'P23', 'N23', 'K25', 'K26', 'K23', 'J23',
> 'H21', 'G21', 'G22', 'F23', 'AE23', 'AF23', 'AC23', 'AC24', 'W23', 'W24',
> 'T22', 'T23', 'R18', 'P18', 'N18', 'M19', 'N19', 'M20', 'J21', 'H22',
> 'G24', 'F24', 'D23', 'D24', 'AE22', 'AF22', 'AB26', 'AC26', 'V21', 'W21',
> 'U17', 'T17', 'R16', 'R17', 'P19', 'P20', 'P16', 'N17', 'J26', 'H26',
> 'E25', 'D25', 'F22', 'E23']}, 'adc_sdata': {'iostd': 'LVCMOS18', 'loc':
> ['AF2', 'AF9', 'W14']}, 'lmx2581_be': {'iostd': 'LVCMOS33', 'loc': 'F15'},
> 'adc_sclk': {'iostd': 'LVCMOS33', 'loc': ['M17', 'L18', 'K16']},
> 'clk_sel_a': {'iostd': 'LVCMOS33', 'loc': ['A18']}, 'i2c': {'iostd': 'I2C',
> 'loc': ['', '', '', '', '', '', 'E18', 'B16', '', 'C16', '', '', '', '',
> '', '', '', '', 'J20', '', 'K20', '', 'E17', 'G19', '', '', '', '', 'C17',
> '', 'C18', 'C19', 'B19', '', 'A17', 'B17', 'D20', 'H18', '', 'H17']},
> 'sync_in_n': {'iostd': 'LVDS_25', 'loc': 'AE25'}, 'adc_lclkp': {'iostd':
> 'LVDS', 'loc': ['AA3']}, 'spi_flash_csn': {'iostd': 'LVCMOS25', 'loc':
> 'C23'}, 'gpio': {'iostd': 'LVCMOS25', 'loc': ['B21', 'C21', 'B20', 'A20',
> 'H24', 'H23', 'B26', 'R25', 'L17', 'K18']}, 'zdok0_p': {'iostd': 'LVDS_25',
> 'loc': ['AA23', 'Y25', 'U24', 'U19', 'T24', 'M21', 'M24', 'L22', 'J24',
> 'G25', 'Y22', 'Y23', 'V23', 'R22', 'R21', 'P23', 'K25', 'K23', 'H21',
> 'G22', 'AE23', 'AC23', 'W23', 'T22', 'R18', 'N18', 'N19', 'J21', 'G24',
> 'D23', 'AE22', 'AB26', 'V21', 'U17', 'R16', 'P19', 'P16', 'J26', 'E25',
> 'F22']}, 'led': {'iostd': 'LVCMOS25', 'loc': ['C13', 'C14', 'D13', 'D14',
> 'E12', 'E13']}, 'adc2_out': {'iostd': 'LVDS', 'loc': ['AF14', 'AF15',
> 'AD15', 'AE15', 'AE18', 'AF18', 'AF19', 'AF20', 'AA14', 'AA15', 'AC14',
> 'AD14', 'AB19', 'AB20', 'AA19', 'AA20']}, 'lmx2581_le': {'iostd':
> 'LVCMOS33', 'loc': 'J16'

Re: [casper] jasper not working properly after upgrade

[Jack Hickish]

Re virtual environments -- your simplest work around is probably to use the
`CASPER_PYTHON_VENV_ON_START` variable described at
https://casper-toolflow.readthedocs.io/en/latest/src/Configuring-the-Toolflow.html

Alternatively, if "just" changing the shebang line to point to "python3"
works, that seems like a reasonable thing to do. (Others may disagree).

Cheers
Jack

On Tue, 19 Nov 2019 at 10:08, Wesley New  wrote:

> Hi Nitish
>
> This is a python 2/3 issue. The toolflow has been upgraded to use python
> 3. Most people are running it in a virtual environment and install the
> requirements.txt in the root of mlib_devel. Assuming you are using the
> latest version of mlib_devel in casper-astro.
>
> Hope this helps.
>
> Regards
>
> Wesley
>
> On Tue, 19 Nov 2019, 7:03 PM Nitish Ragoomundun, <
> nitish.ragoomun...@gmail.com> wrote:
>
>> Hi,
>>
>> I was using Matlab R2017b and Vivado 2016.4 until recently. Most things
>> were working until I had issues with the complex fft block and decided to
>> get the latest mlib_devel to program our SNAP board. I followed
>> https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html
>> and installed Matlab R2018a and Vivado 2019.1.1 on Ubuntu 16.04. I tested
>> using a design which I know was working before. I noticed that new Matlab
>> could not save the Simulink design if I opened the old one itself. So, I
>> manually made a replica of the .slx design with the same blocks and same
>> parameters. Ctrl+D was successfull. Compilation should have worked but got
>> the following error at some stage after running jasper:
>>
>> .
>> ('wb_register_ppc2simulink_sync',
>> ['/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/hdl_sources/wb_register_ppc2simulink_sync'])
>> snap
>> ('infrastructure',
>> ['/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/hdl_sources/infrastructure'])
>> ('wbs_arbiter',
>> ['/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/hdl_sources/wbs_arbiter'])
>> sys_block
>>  doesn't have
>> an attribute 'fullpath'
>> ('sys_block',
>> ['/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/hdl_sources/sys_block'])
>> spi_wb_bridge
>> 
>> doesn't have an attribute 'fullpath'
>> ('spi_wb_bridge',
>> ['/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/hdl_sources/spi_wb_bridge'])
>> xadc
>>  doesn't have an
>> attribute 'fullpath'
>> ('xadc/xadc.v',
>> ['/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/hdl_sources/xadc/xadc.v'])
>> ('xadc/xadc_wiz_0.xci',
>> ['/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/hdl_sources/xadc/xadc_wiz_0.xci'])
>> instantiating user peripherals
>> top:
>> /home/aragorn/Documents/SNAP/new_Spectrum_Analyser/spectrum_480mhz_2048pts_3c/top.v
>> instantiating user_ip
>> regenerating top
>> Dumping pickle of top-level Verilog module
>> Extracting constraints from peripherals
>> Generating physical constraints
>> Traceback (most recent call last):
>>   File
>> "/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/cit2csl.py", line
>> 107, in 
>> sys.stdout.buffer.write(csl)
>> AttributeError: 'file' object has no attribute 'buffer'
>> Failed to generate binary file
>> /home/aragorn/Documents/SNAP/new_Spectrum_Analyser/spectrum_480mhz_2048pts_3c/core_info.jam.tab.bin,
>> error code 256.
>> Traceback (most recent call last):
>>   File
>> "/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/exec_flow.py",
>> line 202, in 
>> tf.write_core_jam_info()
>>   File
>> "/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/toolflow.py",
>> line 525, in write_core_jam_info
>> raise Exception(errmsg)
>> Exception: Failed to generate binary file
>> /home/aragorn/Documents/SNAP/new_Spectrum_Analyser/spectrum_480mhz_2048pts_3c/core_info.jam.tab.bin,
>> error code 256.
>> Error using jasper (line 23)
>> Backend build failed! Check log files for more information
>>
>>
>> If you wish to see the beginning of the messages, please see attached
>> log. The messages in the Matlab window following the jasper command are in
>> Matlab.log.
>> Since the error is a "Traceback" from Python, I am guessing something. I
>> did download the new mlib_devel (master branch) and installed the
>> requirements using pip3. I saw in
>> https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html
>> that for SNAP, we need Python3 and I checked dependencies. One thing I
>> noticed by looking into the scripts inside mlib_devel/jasper_library is the
>> line "#! /usr/bin/env python". On Ubuntu 16.04 the default Python is
>> version 2.7 and "python" is actually a symlink at /usr/bin/python which
>> links to /usr/bin/python2.7. So, for example, if exec_flow.py is run, I am
>> pretty sure it is running with python2.7 and not python3.
>>
>> So, what do you think?
>> Can you please advise?
>>
>> Thanks.
>> Regards,
>> Nitish
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe f

Re: [casper] jasper not working properly after upgrade

[Wesley New]

Hi Nitish

This is a python 2/3 issue. The toolflow has been upgraded to use python 3.
Most people are running it in a virtual environment and install the
requirements.txt in the root of mlib_devel. Assuming you are using the
latest version of mlib_devel in casper-astro.

Hope this helps.

Regards

Wesley

On Tue, 19 Nov 2019, 7:03 PM Nitish Ragoomundun, <
nitish.ragoomun...@gmail.com> wrote:

> Hi,
>
> I was using Matlab R2017b and Vivado 2016.4 until recently. Most things
> were working until I had issues with the complex fft block and decided to
> get the latest mlib_devel to program our SNAP board. I followed
> https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html
> and installed Matlab R2018a and Vivado 2019.1.1 on Ubuntu 16.04. I tested
> using a design which I know was working before. I noticed that new Matlab
> could not save the Simulink design if I opened the old one itself. So, I
> manually made a replica of the .slx design with the same blocks and same
> parameters. Ctrl+D was successfull. Compilation should have worked but got
> the following error at some stage after running jasper:
>
> .
> ('wb_register_ppc2simulink_sync',
> ['/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/hdl_sources/wb_register_ppc2simulink_sync'])
> snap
> ('infrastructure',
> ['/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/hdl_sources/infrastructure'])
> ('wbs_arbiter',
> ['/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/hdl_sources/wbs_arbiter'])
> sys_block
>  doesn't have
> an attribute 'fullpath'
> ('sys_block',
> ['/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/hdl_sources/sys_block'])
> spi_wb_bridge
> 
> doesn't have an attribute 'fullpath'
> ('spi_wb_bridge',
> ['/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/hdl_sources/spi_wb_bridge'])
> xadc
>  doesn't have an
> attribute 'fullpath'
> ('xadc/xadc.v',
> ['/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/hdl_sources/xadc/xadc.v'])
> ('xadc/xadc_wiz_0.xci',
> ['/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/hdl_sources/xadc/xadc_wiz_0.xci'])
> instantiating user peripherals
> top:
> /home/aragorn/Documents/SNAP/new_Spectrum_Analyser/spectrum_480mhz_2048pts_3c/top.v
> instantiating user_ip
> regenerating top
> Dumping pickle of top-level Verilog module
> Extracting constraints from peripherals
> Generating physical constraints
> Traceback (most recent call last):
>   File
> "/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/cit2csl.py", line
> 107, in 
> sys.stdout.buffer.write(csl)
> AttributeError: 'file' object has no attribute 'buffer'
> Failed to generate binary file
> /home/aragorn/Documents/SNAP/new_Spectrum_Analyser/spectrum_480mhz_2048pts_3c/core_info.jam.tab.bin,
> error code 256.
> Traceback (most recent call last):
>   File
> "/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/exec_flow.py",
> line 202, in 
> tf.write_core_jam_info()
>   File
> "/home/aragorn/Documents/CASPER/mlib_devel/jasper_library/toolflow.py",
> line 525, in write_core_jam_info
> raise Exception(errmsg)
> Exception: Failed to generate binary file
> /home/aragorn/Documents/SNAP/new_Spectrum_Analyser/spectrum_480mhz_2048pts_3c/core_info.jam.tab.bin,
> error code 256.
> Error using jasper (line 23)
> Backend build failed! Check log files for more information
>
>
> If you wish to see the beginning of the messages, please see attached log.
> The messages in the Matlab window following the jasper command are in
> Matlab.log.
> Since the error is a "Traceback" from Python, I am guessing something. I
> did download the new mlib_devel (master branch) and installed the
> requirements using pip3. I saw in
> https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html
> that for SNAP, we need Python3 and I checked dependencies. One thing I
> noticed by looking into the scripts inside mlib_devel/jasper_library is the
> line "#! /usr/bin/env python". On Ubuntu 16.04 the default Python is
> version 2.7 and "python" is actually a symlink at /usr/bin/python which
> links to /usr/bin/python2.7. So, for example, if exec_flow.py is run, I am
> pretty sure it is running with python2.7 and not python3.
>
> So, what do you think?
> Can you please advise?
>
> Thanks.
> Regards,
> Nitish
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAC6X4cP%3DkUfwym5YKZKxnZvjE%2BwxQNxSo_XcoAx95%2Ba1x5OF6A%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google 

Re: [casper] JASPER

[Adam Isaacson]

Hi Homin and Jack,

I am pleased to report that Wes and I managed to get the first SKARAB fpg
file generated with the microblaze and 40GbE core last week. We haven't
done extensive tests on this, but I was able to read registers. We still
have lots of optimisations to do and get the wishbone interface for the DSP
functional, but at least the first Milestone has been reached. Yes, we are
also using JASPER with the Vivado tool set. I have written a document on
how to use JASPER, which will eventually end up on the wiki - it is on my
to do list. For those that would like to get access to this document please
check out the following link - it has been recently updated:

https://docs.google.com/document/d/131VGftG8QoCVqnm5unFcj0pplnPoI17urIgvb-qymu4/edit?usp=sharing
(Running
Jasper Tool Flow How To)

Please feel free to review and send comments concerning this document.

Kind Regards,

Adam





On Tue, Aug 30, 2016 at 8:54 AM, Jack Hickish  wrote:

> Hi Homin,
>
> JASPER works for SNAP (https://casper.berkeley.edu/wiki/SNAP_Bringup --
> there are instructions to find the repo there, too) -- i.e., you can go
> from simulink to boffiles. Toolflow support includes all the SNAP-relevant
> yellow blocks -- tge, software registers, bram, gpio, on-board ADC. Support
> for external ZDOK ADCs (probably the iADC and ADC5g at first) and 1gbe is
> forthcoming. All the casper DSP libraries are still supported.
>
> I believe the SKA-SA folks have the flow ~working for SKARAB.  Perhaps
> Adam / Wes have an update.
>
> For new hardware, the tricky part is getting support for the software
> interface. For SNAP this is achieved with a raspberry pi talking to the
> FPGA over SPI. Replicating this setup on any arbitrary FPGA platform would
> be relatively straight-forward. For SKARAB, the comms are through the QSFP
> ports, using a microblaze controller - when integrated properly within the
> toolflow this should be a much more portable solution. There's probably a
> little bit of work also needed if you wish to use the flow with an FPGA
> that has different transceivers to SNAP (kintex 7) or SKARAB (virtex 7),
> since the existing tge cores might not be immediately compatible.
>
> Cheers
> Jack
>
> On Mon, 29 Aug 2016 at 19:01 Homin Jiang 
> wrote:
>
>> Hello:
>>
>> Could someone update me the status of Vivado based CASPER's
>> toolflow/libraries ? And where the link is if available ?
>>
>> regards
>> homin jiang
>>
>>
>>


-- 

Adam Isaacson

DBE: FPGA Engineer

SKA-SA

3rd Floor

The Park

Park Road

Pinelands

7405


Tel: +27215067300 (W)

Fax: +27215067375 (W)

Cell: +27825639602

Re: [casper] JASPER

[Jack Hickish]

Hi Homin,

JASPER works for SNAP (https://casper.berkeley.edu/wiki/SNAP_Bringup --
there are instructions to find the repo there, too) -- i.e., you can go
from simulink to boffiles. Toolflow support includes all the SNAP-relevant
yellow blocks -- tge, software registers, bram, gpio, on-board ADC. Support
for external ZDOK ADCs (probably the iADC and ADC5g at first) and 1gbe is
forthcoming. All the casper DSP libraries are still supported.

I believe the SKA-SA folks have the flow ~working for SKARAB.  Perhaps Adam
/ Wes have an update.

For new hardware, the tricky part is getting support for the software
interface. For SNAP this is achieved with a raspberry pi talking to the
FPGA over SPI. Replicating this setup on any arbitrary FPGA platform would
be relatively straight-forward. For SKARAB, the comms are through the QSFP
ports, using a microblaze controller - when integrated properly within the
toolflow this should be a much more portable solution. There's probably a
little bit of work also needed if you wish to use the flow with an FPGA
that has different transceivers to SNAP (kintex 7) or SKARAB (virtex 7),
since the existing tge cores might not be immediately compatible.

Cheers
Jack

On Mon, 29 Aug 2016 at 19:01 Homin Jiang  wrote:

> Hello:
>
> Could someone update me the status of Vivado based CASPER's
> toolflow/libraries ? And where the link is if available ?
>
> regards
> homin jiang
>
>
>

[casper] JASPER

[Homin Jiang]

Hello:

Could someone update me the status of Vivado based CASPER's
toolflow/libraries ? And where the link is if available ?

regards
homin jiang