Re: [casper] Re: Red Pitaya Tutorial 2 Reg

[Aravind Venkitasubramony]

Hi Adam

I still get the same error message when I run the python script after
updating the mlib_devel. I had compiled the slx file once again after
updating mlib_devel to create a new .fpg file.

Connecting to Red Pitaya: rp-F07516.local
Uploading:
/home/cet/RP_work/models/rp_tut3/tut_spec_adam/outputs/tut_spec_adam_2020-04-14_1158.fpg
Traceback (most recent call last):
  File "tut_spec.py", line 23, in 
fpga.upload_to_ram_and_program(file_fpg)
  File "build/bdist.linux-x86_64/egg/casperfpga/casperfpga.py", line 319,
in upload_to_ram_and_program
  File "build/bdist.linux-x86_64/egg/casperfpga/casperfpga.py", line 747,
in get_system_information
  File "build/bdist.linux-x86_64/egg/casperfpga/casperfpga.py", line 588,
in _create_memory_devices
  File "build/bdist.linux-x86_64/egg/casperfpga/snap.py", line 59, in
from_device_info
RuntimeError: accum0_snap_ss has mask length_bytes 32768 bytes, but mem map
length_bytes 16384 bytes


I updated the mlib_devel from casper-astro and I get the following githash
upon rev-parse "a9e87d994cf5f512fa0ea555ec7495d8dedc0855". It also says
"Already up-to-date." if I run git pull once again while inside mlib_devel

On Wed, Apr 15, 2020 at 1:46 PM Adam Isaacson  wrote:

> Hi Aravind,
>
> If you have already checked out from casper-astro/mlib_devel then all you
> need to do is do a "git pull" and then run the "pip3 install -r
> requirements.txt" to install the new xm2vhdl.
>
> If you have installed the ska-sa/mlib_devel repo then I suggest you rename
> it and do a new git clone of the casper-astro/mlib_devel. Please see
> https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html
> 
>  and
> follow instructions.
>
> Kind regards,
>
> Adam Isaacson
> South African Radio Astronomy Observatory (SARAO)
> Hardware Manager
> Cell: (+27) 825639602
> Tel:  (+27) 215067300
> email: aisaac...@ska.ac.za
>
>
>
> On Wed, Apr 15, 2020 at 9:41 PM Aravind Venkitasubramony <
> aravind.venkitasubram...@colorado.edu> wrote:
>
>> Thanks Adam!
>>
>> I have one question. Do I overwrite the mlib_devel I already have? or
>> install it elsewhere?
>>
>> On Wed, Apr 15, 2020 at 1:40 PM Adam Isaacson 
>> wrote:
>>
>>> Hi Aravind,
>>>
>>> The pull request in casper-astro/mlib_devel was just approved - try that
>>> and let me know, thanks. This should sort your issue out.
>>>
>>> https://github.com/casper-astro/mlib_devel
>>>
>>> Kind regards,
>>>
>>> Adam Isaacson
>>> South African Radio Astronomy Observatory (SARAO)
>>> Hardware Manager
>>> Cell: (+27) 825639602
>>> Tel:  (+27) 215067300
>>> email: aisaac...@ska.ac.za
>>>
>>>
>>>
>>> On Wed, Apr 15, 2020 at 8:41 AM Adam Isaacson 
>>> wrote:
>>>
 Hi Aravind,

 I suspect the issue lies with your snap shot (accum0_snap_ss) - it is
 64 bits wide now and the others are 32 bit. You are probably using a
 version of the toolflow and xml2vhdl repo that does not support asymmetric
 bram usage - I just confirmed that. I would suggest you verify this, by
 installing the following mlib_devel:

 https://github.com/ska-sa/mlib_devel
  (devel branch)

 You will need to do the following:

 1) git clone https://github.com/ska-sa/mlib_devel.git
 2) git checkout devel
 3) cd /mlib_devel
 4) follow install in
 https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html

 You will notice there is a pull request on casper-astro/mlib_devel
 awaiting a review. I will discuss with Jack this evening during our CASPER
 meeting. Once that is approved then you will be able to use your slx file
 as is - https://github.com/casper-astro/mlib_devel/pull/123. We were
 unable to support any BRAM size other than 32 bits originally. I am now
 pleased to report we can support all sizes again.

 Kind regards,

 Adam Isaacson
 South African Radio Astronomy Observatory (SARAO)
 Hardware Manager
 Cell: (+27) 825639602
 Tel:  (+27) 215067300
 email: aisaac...@ska.ac.za



 On Tue, Apr 14, 2020 at 8:56 PM Aravind Venkitasubramony <
 aravind.venkitasubram...@colorado.edu> wrote:

> Thanks for that fix,Adam.
>
> I understand what I did wrong on 2,3 and 4. I am still unclear on 1. I
> will dig deeper to see what I did there to break it.
>
> The compilation went through and I generated the fpg file, but when I
> run the python code, I get an error in the line where it is uploading the
> fpg file to the ram and programming. I am not sure what error this is
> corresponding to. I ran the python file line by line as well in the
> terminal and also see the same error. I downloaded the py file from 
> github.
> From what I can understand, there is no need to change anything in here.
>
> Connecting to Red Pitaya: rp-F07516.local

Re: [casper] Re: Red Pitaya Tutorial 2 Reg

[Adam Isaacson]

Hi Aravind,

If you have already checked out from casper-astro/mlib_devel then all you
need to do is do a "git pull" and then run the "pip3 install -r
requirements.txt" to install the new xm2vhdl.

If you have installed the ska-sa/mlib_devel repo then I suggest you rename
it and do a new git clone of the casper-astro/mlib_devel. Please see
https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html

and
follow instructions.

Kind regards,

Adam Isaacson
South African Radio Astronomy Observatory (SARAO)
Hardware Manager
Cell: (+27) 825639602
Tel:  (+27) 215067300
email: aisaac...@ska.ac.za



On Wed, Apr 15, 2020 at 9:41 PM Aravind Venkitasubramony <
aravind.venkitasubram...@colorado.edu> wrote:

> Thanks Adam!
>
> I have one question. Do I overwrite the mlib_devel I already have? or
> install it elsewhere?
>
> On Wed, Apr 15, 2020 at 1:40 PM Adam Isaacson  wrote:
>
>> Hi Aravind,
>>
>> The pull request in casper-astro/mlib_devel was just approved - try that
>> and let me know, thanks. This should sort your issue out.
>>
>> https://github.com/casper-astro/mlib_devel
>>
>> Kind regards,
>>
>> Adam Isaacson
>> South African Radio Astronomy Observatory (SARAO)
>> Hardware Manager
>> Cell: (+27) 825639602
>> Tel:  (+27) 215067300
>> email: aisaac...@ska.ac.za
>>
>>
>>
>> On Wed, Apr 15, 2020 at 8:41 AM Adam Isaacson 
>> wrote:
>>
>>> Hi Aravind,
>>>
>>> I suspect the issue lies with your snap shot (accum0_snap_ss) - it is
>>> 64 bits wide now and the others are 32 bit. You are probably using a
>>> version of the toolflow and xml2vhdl repo that does not support asymmetric
>>> bram usage - I just confirmed that. I would suggest you verify this, by
>>> installing the following mlib_devel:
>>>
>>> https://github.com/ska-sa/mlib_devel
>>>  (devel branch)
>>>
>>> You will need to do the following:
>>>
>>> 1) git clone https://github.com/ska-sa/mlib_devel.git
>>> 2) git checkout devel
>>> 3) cd /mlib_devel
>>> 4) follow install in
>>> https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html
>>>
>>> You will notice there is a pull request on casper-astro/mlib_devel
>>> awaiting a review. I will discuss with Jack this evening during our CASPER
>>> meeting. Once that is approved then you will be able to use your slx file
>>> as is - https://github.com/casper-astro/mlib_devel/pull/123. We were
>>> unable to support any BRAM size other than 32 bits originally. I am now
>>> pleased to report we can support all sizes again.
>>>
>>> Kind regards,
>>>
>>> Adam Isaacson
>>> South African Radio Astronomy Observatory (SARAO)
>>> Hardware Manager
>>> Cell: (+27) 825639602
>>> Tel:  (+27) 215067300
>>> email: aisaac...@ska.ac.za
>>>
>>>
>>>
>>> On Tue, Apr 14, 2020 at 8:56 PM Aravind Venkitasubramony <
>>> aravind.venkitasubram...@colorado.edu> wrote:
>>>
 Thanks for that fix,Adam.

 I understand what I did wrong on 2,3 and 4. I am still unclear on 1. I
 will dig deeper to see what I did there to break it.

 The compilation went through and I generated the fpg file, but when I
 run the python code, I get an error in the line where it is uploading the
 fpg file to the ram and programming. I am not sure what error this is
 corresponding to. I ran the python file line by line as well in the
 terminal and also see the same error. I downloaded the py file from github.
 From what I can understand, there is no need to change anything in here.

 Connecting to Red Pitaya: rp-F07516.local
 Uploading:
 /home/cet/RP_work/models/rp_tut3/tut_spec_adam/outputs/tut_spec_adam_2020-04-14_1158.fpg
 Traceback (most recent call last):
   File "tut_spec.py", line 23, in 
 fpga.upload_to_ram_and_program(file_fpg)
   File "build/bdist.linux-x86_64/egg/casperfpga/casperfpga.py", line
 319, in upload_to_ram_and_program
   File "build/bdist.linux-x86_64/egg/casperfpga/casperfpga.py", line
 747, in get_system_information
   File "build/bdist.linux-x86_64/egg/casperfpga/casperfpga.py", line
 588, in _create_memory_devices
   File "build/bdist.linux-x86_64/egg/casperfpga/snap.py", line 59, in
 from_device_info
 RuntimeError: accum0_snap_ss has mask length_bytes 32768 bytes, but mem
 map length_bytes 16384 bytes

 On Tue, Apr 14, 2020 at 3:12 AM Adam Isaacson 
 wrote:

> Hi Aravind,
>
> I have found the following issues:
>
> 1) The ADC yellow block was modified and the link to the library was
> broken. This meant that the number of bits parameter did not propagate 
> down
> to the cast blocks and so they were still set at 10 bits. I see you added
> some simulation blocks, but probably broke the links in the process.
>
> 2) The constant xilinx blocks for the imaginary inputs to the FFT were
> set at 10 bits and not 14 

Re: [casper] Re: Red Pitaya Tutorial 2 Reg

[Aravind Venkitasubramony]

Thanks Adam!

I have one question. Do I overwrite the mlib_devel I already have? or
install it elsewhere?

On Wed, Apr 15, 2020 at 1:40 PM Adam Isaacson  wrote:

> Hi Aravind,
>
> The pull request in casper-astro/mlib_devel was just approved - try that
> and let me know, thanks. This should sort your issue out.
>
> https://github.com/casper-astro/mlib_devel
>
> Kind regards,
>
> Adam Isaacson
> South African Radio Astronomy Observatory (SARAO)
> Hardware Manager
> Cell: (+27) 825639602
> Tel:  (+27) 215067300
> email: aisaac...@ska.ac.za
>
>
>
> On Wed, Apr 15, 2020 at 8:41 AM Adam Isaacson  wrote:
>
>> Hi Aravind,
>>
>> I suspect the issue lies with your snap shot (accum0_snap_ss) - it is 64
>> bits wide now and the others are 32 bit. You are probably using a version
>> of the toolflow and xml2vhdl repo that does not support asymmetric bram
>> usage - I just confirmed that. I would suggest you verify this, by
>> installing the following mlib_devel:
>>
>> https://github.com/ska-sa/mlib_devel
>>  (devel branch)
>>
>> You will need to do the following:
>>
>> 1) git clone https://github.com/ska-sa/mlib_devel.git
>> 2) git checkout devel
>> 3) cd /mlib_devel
>> 4) follow install in
>> https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html
>>
>> You will notice there is a pull request on casper-astro/mlib_devel
>> awaiting a review. I will discuss with Jack this evening during our CASPER
>> meeting. Once that is approved then you will be able to use your slx file
>> as is - https://github.com/casper-astro/mlib_devel/pull/123. We were
>> unable to support any BRAM size other than 32 bits originally. I am now
>> pleased to report we can support all sizes again.
>>
>> Kind regards,
>>
>> Adam Isaacson
>> South African Radio Astronomy Observatory (SARAO)
>> Hardware Manager
>> Cell: (+27) 825639602
>> Tel:  (+27) 215067300
>> email: aisaac...@ska.ac.za
>>
>>
>>
>> On Tue, Apr 14, 2020 at 8:56 PM Aravind Venkitasubramony <
>> aravind.venkitasubram...@colorado.edu> wrote:
>>
>>> Thanks for that fix,Adam.
>>>
>>> I understand what I did wrong on 2,3 and 4. I am still unclear on 1. I
>>> will dig deeper to see what I did there to break it.
>>>
>>> The compilation went through and I generated the fpg file, but when I
>>> run the python code, I get an error in the line where it is uploading the
>>> fpg file to the ram and programming. I am not sure what error this is
>>> corresponding to. I ran the python file line by line as well in the
>>> terminal and also see the same error. I downloaded the py file from github.
>>> From what I can understand, there is no need to change anything in here.
>>>
>>> Connecting to Red Pitaya: rp-F07516.local
>>> Uploading:
>>> /home/cet/RP_work/models/rp_tut3/tut_spec_adam/outputs/tut_spec_adam_2020-04-14_1158.fpg
>>> Traceback (most recent call last):
>>>   File "tut_spec.py", line 23, in 
>>> fpga.upload_to_ram_and_program(file_fpg)
>>>   File "build/bdist.linux-x86_64/egg/casperfpga/casperfpga.py", line
>>> 319, in upload_to_ram_and_program
>>>   File "build/bdist.linux-x86_64/egg/casperfpga/casperfpga.py", line
>>> 747, in get_system_information
>>>   File "build/bdist.linux-x86_64/egg/casperfpga/casperfpga.py", line
>>> 588, in _create_memory_devices
>>>   File "build/bdist.linux-x86_64/egg/casperfpga/snap.py", line 59, in
>>> from_device_info
>>> RuntimeError: accum0_snap_ss has mask length_bytes 32768 bytes, but mem
>>> map length_bytes 16384 bytes
>>>
>>> On Tue, Apr 14, 2020 at 3:12 AM Adam Isaacson 
>>> wrote:
>>>
 Hi Aravind,

 I have found the following issues:

 1) The ADC yellow block was modified and the link to the library was
 broken. This meant that the number of bits parameter did not propagate down
 to the cast blocks and so they were still set at 10 bits. I see you added
 some simulation blocks, but probably broke the links in the process.

 2) The constant xilinx blocks for the imaginary inputs to the FFT were
 set at 10 bits and not 14 bits.

 3) The accumdat_snap snapshot had the incorrect number of bits for the
 "in_Ch_acc". This should not have been modified, as it is not influenced by
 the ADC number of bits.

 4) I fixed the bit growth through your system - hopefully this is
 correct now.

 Please see attached modified version. It should compile now.

 Kind regards,

 Adam Isaacson
 South African Radio Astronomy Observatory (SARAO)
 Hardware Manager
 Cell: (+27) 825639602
 Tel:  (+27) 215067300
 email: aisaac...@ska.ac.za



 On Mon, Apr 13, 2020 at 10:49 PM Aravind Venkitasubramony <
 aravind.venkitasubram...@colorado.edu> wrote:

> Hi Adam
>
> I revisited the spectrometer tutorial after finishing the second
> tutorial. I have attached the slx file along with. I have modified
> everything I could understand but I still get the 

Re: [casper] Re: Red Pitaya Tutorial 2 Reg

[Adam Isaacson]

Hi Aravind,

The pull request in casper-astro/mlib_devel was just approved - try that
and let me know, thanks. This should sort your issue out.

https://github.com/casper-astro/mlib_devel

Kind regards,

Adam Isaacson
South African Radio Astronomy Observatory (SARAO)
Hardware Manager
Cell: (+27) 825639602
Tel:  (+27) 215067300
email: aisaac...@ska.ac.za



On Wed, Apr 15, 2020 at 8:41 AM Adam Isaacson  wrote:

> Hi Aravind,
>
> I suspect the issue lies with your snap shot (accum0_snap_ss) - it is 64
> bits wide now and the others are 32 bit. You are probably using a version
> of the toolflow and xml2vhdl repo that does not support asymmetric bram
> usage - I just confirmed that. I would suggest you verify this, by
> installing the following mlib_devel:
>
> https://github.com/ska-sa/mlib_devel
>  (devel branch)
>
> You will need to do the following:
>
> 1) git clone https://github.com/ska-sa/mlib_devel.git
> 2) git checkout devel
> 3) cd /mlib_devel
> 4) follow install in
> https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html
>
> You will notice there is a pull request on casper-astro/mlib_devel
> awaiting a review. I will discuss with Jack this evening during our CASPER
> meeting. Once that is approved then you will be able to use your slx file
> as is - https://github.com/casper-astro/mlib_devel/pull/123. We were
> unable to support any BRAM size other than 32 bits originally. I am now
> pleased to report we can support all sizes again.
>
> Kind regards,
>
> Adam Isaacson
> South African Radio Astronomy Observatory (SARAO)
> Hardware Manager
> Cell: (+27) 825639602
> Tel:  (+27) 215067300
> email: aisaac...@ska.ac.za
>
>
>
> On Tue, Apr 14, 2020 at 8:56 PM Aravind Venkitasubramony <
> aravind.venkitasubram...@colorado.edu> wrote:
>
>> Thanks for that fix,Adam.
>>
>> I understand what I did wrong on 2,3 and 4. I am still unclear on 1. I
>> will dig deeper to see what I did there to break it.
>>
>> The compilation went through and I generated the fpg file, but when I run
>> the python code, I get an error in the line where it is uploading the fpg
>> file to the ram and programming. I am not sure what error this is
>> corresponding to. I ran the python file line by line as well in the
>> terminal and also see the same error. I downloaded the py file from github.
>> From what I can understand, there is no need to change anything in here.
>>
>> Connecting to Red Pitaya: rp-F07516.local
>> Uploading:
>> /home/cet/RP_work/models/rp_tut3/tut_spec_adam/outputs/tut_spec_adam_2020-04-14_1158.fpg
>> Traceback (most recent call last):
>>   File "tut_spec.py", line 23, in 
>> fpga.upload_to_ram_and_program(file_fpg)
>>   File "build/bdist.linux-x86_64/egg/casperfpga/casperfpga.py", line 319,
>> in upload_to_ram_and_program
>>   File "build/bdist.linux-x86_64/egg/casperfpga/casperfpga.py", line 747,
>> in get_system_information
>>   File "build/bdist.linux-x86_64/egg/casperfpga/casperfpga.py", line 588,
>> in _create_memory_devices
>>   File "build/bdist.linux-x86_64/egg/casperfpga/snap.py", line 59, in
>> from_device_info
>> RuntimeError: accum0_snap_ss has mask length_bytes 32768 bytes, but mem
>> map length_bytes 16384 bytes
>>
>> On Tue, Apr 14, 2020 at 3:12 AM Adam Isaacson 
>> wrote:
>>
>>> Hi Aravind,
>>>
>>> I have found the following issues:
>>>
>>> 1) The ADC yellow block was modified and the link to the library was
>>> broken. This meant that the number of bits parameter did not propagate down
>>> to the cast blocks and so they were still set at 10 bits. I see you added
>>> some simulation blocks, but probably broke the links in the process.
>>>
>>> 2) The constant xilinx blocks for the imaginary inputs to the FFT were
>>> set at 10 bits and not 14 bits.
>>>
>>> 3) The accumdat_snap snapshot had the incorrect number of bits for the
>>> "in_Ch_acc". This should not have been modified, as it is not influenced by
>>> the ADC number of bits.
>>>
>>> 4) I fixed the bit growth through your system - hopefully this is
>>> correct now.
>>>
>>> Please see attached modified version. It should compile now.
>>>
>>> Kind regards,
>>>
>>> Adam Isaacson
>>> South African Radio Astronomy Observatory (SARAO)
>>> Hardware Manager
>>> Cell: (+27) 825639602
>>> Tel:  (+27) 215067300
>>> email: aisaac...@ska.ac.za
>>>
>>>
>>>
>>> On Mon, Apr 13, 2020 at 10:49 PM Aravind Venkitasubramony <
>>> aravind.venkitasubram...@colorado.edu> wrote:
>>>
 Hi Adam

 I revisited the spectrometer tutorial after finishing the second
 tutorial. I have attached the slx file along with. I have modified
 everything I could understand but I still get the following error while
 compiling

 The input type propagated to this block did not match the specified
 type.
   Expected Type: Fix_14_0
   Actual Type: Fix_10_0

 It would be great if you could take a look and tell me what I am doing
 wrong.

 On Tue, Apr 7, 2020 at 

[casper] ZCU111 Fan

[Ross Martin]

Hi Casperites,

FYI:  On the ZCU111 board, Xilinx misdesigned the fan control.  Thus the fan is 
always running full speed, which is why the fan on these boards is so loud.   
It’s not really Xilinx’s fault.  It happened because the manufacturer’s 
documentation for the fan controller chip is especially poor, which resulted in 
a FULLSPD pin being high when it should be low — overriding normal fan control 
and forcing the fan to full speed permanently.

The good news: there are both hardware and software fixes.  There is a GPIO 
connected to the FULLSPD pin, for monitoring it.  This GPIO can be flipped from 
an input to an output in software to override the pullup resistor that’s 
pulling the FULLSPD pin high.  Alternately, the pin right next to the FULLSPD 
pin is ground, and a solder bridge can be put on the board to pull the pin 
permanently low for a hardware fix.

Either fix works to restore quiet operation to the board.  The only consequence 
would be that the fixes interfere with the monitoring of this pin, but as far 
as I know there is no software that actually monitors it.  I’ve fixed my board 
in hardware with no adverse consequences to either standalone or linux 
applications.

For further information you can search for “ZCU111 Fan” on google or the Xilinx 
forums, or follow this link:  

https://forums.xilinx.com/t5/Xilinx-Evaluation-Boards/ZCU111-Fan-Oddities/td-p/926050
 


Ross

Ross Martin
Bit by Bit Signal Processing LLC
r...@bitbybitsp.com 
+1-623-487-8011

-- 
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/15F557A3-037B-4A9B-9321-C9D90846E18F%40ieee.org.

Re: [casper] Re: Red Pitaya Tutorial 2 Reg

[Adam Isaacson]

Hi Aravind,

I suspect the issue lies with your snap shot (accum0_snap_ss) - it is 64
bits wide now and the others are 32 bit. You are probably using a version
of the toolflow and xml2vhdl repo that does not support asymmetric bram
usage - I just confirmed that. I would suggest you verify this, by
installing the following mlib_devel:

https://github.com/ska-sa/mlib_devel
 (devel
branch)

You will need to do the following:

1) git clone https://github.com/ska-sa/mlib_devel.git
2) git checkout devel
3) cd /mlib_devel
4) follow install in
https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html

You will notice there is a pull request on casper-astro/mlib_devel awaiting
a review. I will discuss with Jack this evening during our CASPER meeting.
Once that is approved then you will be able to use your slx file as is -
https://github.com/casper-astro/mlib_devel/pull/123. We were unable to
support any BRAM size other than 32 bits originally. I am now pleased to
report we can support all sizes again.

Kind regards,

Adam Isaacson
South African Radio Astronomy Observatory (SARAO)
Hardware Manager
Cell: (+27) 825639602
Tel:  (+27) 215067300
email: aisaac...@ska.ac.za



On Tue, Apr 14, 2020 at 8:56 PM Aravind Venkitasubramony <
aravind.venkitasubram...@colorado.edu> wrote:

> Thanks for that fix,Adam.
>
> I understand what I did wrong on 2,3 and 4. I am still unclear on 1. I
> will dig deeper to see what I did there to break it.
>
> The compilation went through and I generated the fpg file, but when I run
> the python code, I get an error in the line where it is uploading the fpg
> file to the ram and programming. I am not sure what error this is
> corresponding to. I ran the python file line by line as well in the
> terminal and also see the same error. I downloaded the py file from github.
> From what I can understand, there is no need to change anything in here.
>
> Connecting to Red Pitaya: rp-F07516.local
> Uploading:
> /home/cet/RP_work/models/rp_tut3/tut_spec_adam/outputs/tut_spec_adam_2020-04-14_1158.fpg
> Traceback (most recent call last):
>   File "tut_spec.py", line 23, in 
> fpga.upload_to_ram_and_program(file_fpg)
>   File "build/bdist.linux-x86_64/egg/casperfpga/casperfpga.py", line 319,
> in upload_to_ram_and_program
>   File "build/bdist.linux-x86_64/egg/casperfpga/casperfpga.py", line 747,
> in get_system_information
>   File "build/bdist.linux-x86_64/egg/casperfpga/casperfpga.py", line 588,
> in _create_memory_devices
>   File "build/bdist.linux-x86_64/egg/casperfpga/snap.py", line 59, in
> from_device_info
> RuntimeError: accum0_snap_ss has mask length_bytes 32768 bytes, but mem
> map length_bytes 16384 bytes
>
> On Tue, Apr 14, 2020 at 3:12 AM Adam Isaacson  wrote:
>
>> Hi Aravind,
>>
>> I have found the following issues:
>>
>> 1) The ADC yellow block was modified and the link to the library was
>> broken. This meant that the number of bits parameter did not propagate down
>> to the cast blocks and so they were still set at 10 bits. I see you added
>> some simulation blocks, but probably broke the links in the process.
>>
>> 2) The constant xilinx blocks for the imaginary inputs to the FFT were
>> set at 10 bits and not 14 bits.
>>
>> 3) The accumdat_snap snapshot had the incorrect number of bits for the
>> "in_Ch_acc". This should not have been modified, as it is not influenced by
>> the ADC number of bits.
>>
>> 4) I fixed the bit growth through your system - hopefully this is correct
>> now.
>>
>> Please see attached modified version. It should compile now.
>>
>> Kind regards,
>>
>> Adam Isaacson
>> South African Radio Astronomy Observatory (SARAO)
>> Hardware Manager
>> Cell: (+27) 825639602
>> Tel:  (+27) 215067300
>> email: aisaac...@ska.ac.za
>>
>>
>>
>> On Mon, Apr 13, 2020 at 10:49 PM Aravind Venkitasubramony <
>> aravind.venkitasubram...@colorado.edu> wrote:
>>
>>> Hi Adam
>>>
>>> I revisited the spectrometer tutorial after finishing the second
>>> tutorial. I have attached the slx file along with. I have modified
>>> everything I could understand but I still get the following error while
>>> compiling
>>>
>>> The input type propagated to this block did not match the specified type.
>>>   Expected Type: Fix_14_0
>>>   Actual Type: Fix_10_0
>>>
>>> It would be great if you could take a look and tell me what I am doing
>>> wrong.
>>>
>>> On Tue, Apr 7, 2020 at 2:22 AM Adam Isaacson 
>>> wrote:
>>>
 Dear Aravind,

 You can do any tutorial in any order, but as a beginner it is better to
 do it in order. The spectrometer tutorial should be able to work for a 14
 bit board, but if you go through the steps you will see that the
 spectrometer bit growth is based on an input of 10 bits. You would need to
 change that based on an input of 14 bits. The python script would also need
 to be updated to handle 14 bits or so I think. This could be why you are
 experiencing these issues reading back