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

[Adam Isaacson]

Hi Aravind,

No worries. It applies equally to existing designs. The hardware porting
workshops are an annual event, so you will at some point get a chance to
participate if you want to.

Good luck!

Kind regards,

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



On Fri, Apr 17, 2020 at 9:02 PM Aravind Venkitasubramony <
aravind.venkitasubram...@colorado.edu> wrote:

> Thanks Adam
>
> I am not building a custom FPGA board. I will be using the Red Pitaya and
> ZCU 111 to build custom projects and applications I can do with these
> boards. I am sorry if I didn't make that clear.
>
> I was just checking how to proceed further since I got all the tutorials
> to work and have a basic idea now. I was not aware of the last year's
> workshop. It would have been amazing to attend that.
>
> I would look at the yellow block tutorials as you mentioned in the
> meanwhile.
>
> On Fri, Apr 17, 2020, 12:52 PM Adam Isaacson  wrote:
>
>> Hi Aravind,
>>
>> I am assuming you are referring to custom boards other than the Red
>> Pitaya and that you are using the Red Pitaya as a learning platform?
>>
>> If so our annual Hardware Porting Workshop is a great way to learn how to
>> port to custom hardware - alas, that has been postponed this year.
>>
>> In the meantime, you could look at the yellow block tutorial under the
>> SNAP tutorials. This can easily be adjusted for the Red Pitaya. It explains
>> how to create a yellow block (consisting of ADC, DAC, memory, Ethernet,
>> platforms and I/O drivers) and save it to the XPS library. The
>> casper_library just uses existing DSP blocks, but you can always create
>> your own and save to the casper_library as well.
>>
>> Please note that your custom board needs an FPGA and ethernet interface
>> in order to be successfully CASPERised i.e ported to work with the
>> toolflow. I think creating the yellow blocks is a good start. I would
>> create a type of model like the introduction tutorials of the Red Pitaya
>> i.e. platform yellow block, software register yellow blocks, ethernet
>> yellow block and using gpio yellow blocks only. First establish comms with
>> your custom board using these registers and the python package casperfpga.
>> From there I would get the custom ADC, DAC and other I/O working. Once that
>> is working then I would add the DSP. I think that you may find
>> understanding casperfpga a bit tricky as the documentation and comments are
>> not as complete as they should be **ahem**. However, we do have members
>> who have a decent understanding of casperfpga and they can support.
>>
>> I hope this helps. We are currently CASPERsing the Xilinx Alveo Data
>> Accelerator Card U280, so are going through a similar exercise. I am happy
>> to move this conversation to slack.
>>
>> Good luck!
>>
>> Kind regards,
>>
>> Adam Isaacson
>> South African Radio Astronomy Observatory (SARAO)
>> Hardware Manager
>> Cell: (+27) 825639602
>> Tel:  (+27) 215067300
>> email: aisaac...@ska.ac.za
>>
>>
>>
>> On Fri, Apr 17, 2020 at 7:42 PM Aravind Venkitasubramony <
>> aravind.venkitasubram...@colorado.edu> wrote:
>>
>>> Thank you Adam, I will send the email out to learn more about the ZCU111
>>> work going on. I did join the Slack channel. I will check that out as well.
>>>
>>> What would be a good way to build on these red pitaya tutorials to
>>> develop custom applications?
>>>
>>> On Thu, Apr 16, 2020 at 1:18 PM Adam Isaacson 
>>> wrote:
>>>
 Hi Aravind,

 Great, I am glad you are sorted.

 I am not really involved with the ZCU111 anymore, but can say that
 there are no existing tutorials for that yet. The people to speak to are
 Brian Bradford and Mitch Burnett. I suggest you send out another email to
 the CASPER email list with "ZCU111 tutorials" in the title and they should
 get back to you whether they have something. There is also a slack channel
 for the ZCU111. I did invite you to the CASPER slack group. I suggest you
 accept and post your questions there as well. You will also see all the
 posts concerning the ZCU111.

 I hope this helps!

 Kind regards,

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



 On Thu, Apr 16, 2020 at 9:08 PM Aravind Venkitasubramony <
 aravind.venkitasubram...@colorado.edu> wrote:

> Oh. That was it. Even though I recompiled the slx file, I kept using
> the old fpg data file in the script. That was the issue. Now it works from
> any location.
>
> Sorry for the confusion Adam. I just didn't pay attention to that
> part.
>
> Is there any tutorial planned with the ZCU111 board? My interest lies
> mainly in the ZCU111 board and I was using the redpitaya as a learning
> platform to get 

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

[Aravind Venkitasubramony]

Thanks Adam

I am not building a custom FPGA board. I will be using the Red Pitaya and
ZCU 111 to build custom projects and applications I can do with these
boards. I am sorry if I didn't make that clear.

I was just checking how to proceed further since I got all the tutorials to
work and have a basic idea now. I was not aware of the last year's
workshop. It would have been amazing to attend that.

I would look at the yellow block tutorials as you mentioned in the
meanwhile.

On Fri, Apr 17, 2020, 12:52 PM Adam Isaacson  wrote:

> Hi Aravind,
>
> I am assuming you are referring to custom boards other than the Red Pitaya
> and that you are using the Red Pitaya as a learning platform?
>
> If so our annual Hardware Porting Workshop is a great way to learn how to
> port to custom hardware - alas, that has been postponed this year.
>
> In the meantime, you could look at the yellow block tutorial under the
> SNAP tutorials. This can easily be adjusted for the Red Pitaya. It explains
> how to create a yellow block (consisting of ADC, DAC, memory, Ethernet,
> platforms and I/O drivers) and save it to the XPS library. The
> casper_library just uses existing DSP blocks, but you can always create
> your own and save to the casper_library as well.
>
> Please note that your custom board needs an FPGA and ethernet interface in
> order to be successfully CASPERised i.e ported to work with the toolflow. I
> think creating the yellow blocks is a good start. I would create a type of
> model like the introduction tutorials of the Red Pitaya i.e. platform
> yellow block, software register yellow blocks, ethernet yellow block and
> using gpio yellow blocks only. First establish comms with your custom board
> using these registers and the python package casperfpga. From there I would
> get the custom ADC, DAC and other I/O working. Once that is working then I
> would add the DSP. I think that you may find understanding casperfpga a bit
> tricky as the documentation and comments are not as complete as they should
> be **ahem**. However, we do have members who have a decent understanding
> of casperfpga and they can support.
>
> I hope this helps. We are currently CASPERsing the Xilinx Alveo Data
> Accelerator Card U280, so are going through a similar exercise. I am happy
> to move this conversation to slack.
>
> Good luck!
>
> Kind regards,
>
> Adam Isaacson
> South African Radio Astronomy Observatory (SARAO)
> Hardware Manager
> Cell: (+27) 825639602
> Tel:  (+27) 215067300
> email: aisaac...@ska.ac.za
>
>
>
> On Fri, Apr 17, 2020 at 7:42 PM Aravind Venkitasubramony <
> aravind.venkitasubram...@colorado.edu> wrote:
>
>> Thank you Adam, I will send the email out to learn more about the ZCU111
>> work going on. I did join the Slack channel. I will check that out as well.
>>
>> What would be a good way to build on these red pitaya tutorials to
>> develop custom applications?
>>
>> On Thu, Apr 16, 2020 at 1:18 PM Adam Isaacson 
>> wrote:
>>
>>> Hi Aravind,
>>>
>>> Great, I am glad you are sorted.
>>>
>>> I am not really involved with the ZCU111 anymore, but can say that there
>>> are no existing tutorials for that yet. The people to speak to are Brian
>>> Bradford and Mitch Burnett. I suggest you send out another email to the
>>> CASPER email list with "ZCU111 tutorials" in the title and they should get
>>> back to you whether they have something. There is also a slack channel for
>>> the ZCU111. I did invite you to the CASPER slack group. I suggest you
>>> accept and post your questions there as well. You will also see all the
>>> posts concerning the ZCU111.
>>>
>>> I hope this helps!
>>>
>>> Kind regards,
>>>
>>> Adam Isaacson
>>> South African Radio Astronomy Observatory (SARAO)
>>> Hardware Manager
>>> Cell: (+27) 825639602
>>> Tel:  (+27) 215067300
>>> email: aisaac...@ska.ac.za
>>>
>>>
>>>
>>> On Thu, Apr 16, 2020 at 9:08 PM Aravind Venkitasubramony <
>>> aravind.venkitasubram...@colorado.edu> wrote:
>>>
 Oh. That was it. Even though I recompiled the slx file, I kept using
 the old fpg data file in the script. That was the issue. Now it works from
 any location.

 Sorry for the confusion Adam. I just didn't pay attention to that part.

 Is there any tutorial planned with the ZCU111 board? My interest lies
 mainly in the ZCU111 board and I was using the redpitaya as a learning
 platform to get familiar with the casper tools and environment. I get a
 flavor of the toolflow now.

 On Thu, Apr 16, 2020 at 12:51 PM Adam Isaacson 
 wrote:

> Hi Aravind,
>
> That is strange. It shouldn't matter where your slx file and script
> file is located. I am sure I have compiled my slx file in a different
> folder to the jasper_library/test_models.
>
> Are you sure you were not using an old version of your fpg file by
> mistake i.e. before you git pulled the new commit? Just confirm that.
>
> Please can you send me the fpg file of the working 

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

[Adam Isaacson]

Hi Aravind,

I am assuming you are referring to custom boards other than the Red Pitaya
and that you are using the Red Pitaya as a learning platform?

If so our annual Hardware Porting Workshop is a great way to learn how to
port to custom hardware - alas, that has been postponed this year.

In the meantime, you could look at the yellow block tutorial under the SNAP
tutorials. This can easily be adjusted for the Red Pitaya. It explains how
to create a yellow block (consisting of ADC, DAC, memory, Ethernet,
platforms and I/O drivers) and save it to the XPS library. The
casper_library just uses existing DSP blocks, but you can always create
your own and save to the casper_library as well.

Please note that your custom board needs an FPGA and ethernet interface in
order to be successfully CASPERised i.e ported to work with the toolflow. I
think creating the yellow blocks is a good start. I would create a type of
model like the introduction tutorials of the Red Pitaya i.e. platform
yellow block, software register yellow blocks, ethernet yellow block and
using gpio yellow blocks only. First establish comms with your custom board
using these registers and the python package casperfpga. From there I would
get the custom ADC, DAC and other I/O working. Once that is working then I
would add the DSP. I think that you may find understanding casperfpga a bit
tricky as the documentation and comments are not as complete as they should
be **ahem**. However, we do have members who have a decent understanding of
casperfpga and they can support.

I hope this helps. We are currently CASPERsing the Xilinx Alveo Data
Accelerator Card U280, so are going through a similar exercise. I am happy
to move this conversation to slack.

Good luck!

Kind regards,

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



On Fri, Apr 17, 2020 at 7:42 PM Aravind Venkitasubramony <
aravind.venkitasubram...@colorado.edu> wrote:

> Thank you Adam, I will send the email out to learn more about the ZCU111
> work going on. I did join the Slack channel. I will check that out as well.
>
> What would be a good way to build on these red pitaya tutorials to develop
> custom applications?
>
> On Thu, Apr 16, 2020 at 1:18 PM Adam Isaacson  wrote:
>
>> Hi Aravind,
>>
>> Great, I am glad you are sorted.
>>
>> I am not really involved with the ZCU111 anymore, but can say that there
>> are no existing tutorials for that yet. The people to speak to are Brian
>> Bradford and Mitch Burnett. I suggest you send out another email to the
>> CASPER email list with "ZCU111 tutorials" in the title and they should get
>> back to you whether they have something. There is also a slack channel for
>> the ZCU111. I did invite you to the CASPER slack group. I suggest you
>> accept and post your questions there as well. You will also see all the
>> posts concerning the ZCU111.
>>
>> I hope this helps!
>>
>> Kind regards,
>>
>> Adam Isaacson
>> South African Radio Astronomy Observatory (SARAO)
>> Hardware Manager
>> Cell: (+27) 825639602
>> Tel:  (+27) 215067300
>> email: aisaac...@ska.ac.za
>>
>>
>>
>> On Thu, Apr 16, 2020 at 9:08 PM Aravind Venkitasubramony <
>> aravind.venkitasubram...@colorado.edu> wrote:
>>
>>> Oh. That was it. Even though I recompiled the slx file, I kept using the
>>> old fpg data file in the script. That was the issue. Now it works from any
>>> location.
>>>
>>> Sorry for the confusion Adam. I just didn't pay attention to that part.
>>>
>>> Is there any tutorial planned with the ZCU111 board? My interest lies
>>> mainly in the ZCU111 board and I was using the redpitaya as a learning
>>> platform to get familiar with the casper tools and environment. I get a
>>> flavor of the toolflow now.
>>>
>>> On Thu, Apr 16, 2020 at 12:51 PM Adam Isaacson 
>>> wrote:
>>>
 Hi Aravind,

 That is strange. It shouldn't matter where your slx file and script
 file is located. I am sure I have compiled my slx file in a different
 folder to the jasper_library/test_models.

 Are you sure you were not using an old version of your fpg file by
 mistake i.e. before you git pulled the new commit? Just confirm that.

 Please can you send me the fpg file of the working one and the non
 working one, thanks. I want to check the fpg metadata.

 Kind regards,

 Adam

 On Thu, 16 Apr 2020, 8:13 PM Aravind Venkitasubramony, <
 aravind.venkitasubram...@colorado.edu> wrote:

> Hi Adam
>
> 1 and 2 are as expected. I do not find any change there
>
> But upon reading your email, I realized  I might be  supposed to have
> saved the model file inside the mlib_devel/jasper_library/test_models
> folder. I saved the slx file inside jasper_library/test_models, saved the
> python file inside scripts folder, compiled it again and then I see that
> there is no error and I get the plots. 

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

[Aravind Venkitasubramony]

Thank you Adam, I will send the email out to learn more about the ZCU111
work going on. I did join the Slack channel. I will check that out as well.

What would be a good way to build on these red pitaya tutorials to develop
custom applications?

On Thu, Apr 16, 2020 at 1:18 PM Adam Isaacson  wrote:

> Hi Aravind,
>
> Great, I am glad you are sorted.
>
> I am not really involved with the ZCU111 anymore, but can say that there
> are no existing tutorials for that yet. The people to speak to are Brian
> Bradford and Mitch Burnett. I suggest you send out another email to the
> CASPER email list with "ZCU111 tutorials" in the title and they should get
> back to you whether they have something. There is also a slack channel for
> the ZCU111. I did invite you to the CASPER slack group. I suggest you
> accept and post your questions there as well. You will also see all the
> posts concerning the ZCU111.
>
> I hope this helps!
>
> Kind regards,
>
> Adam Isaacson
> South African Radio Astronomy Observatory (SARAO)
> Hardware Manager
> Cell: (+27) 825639602
> Tel:  (+27) 215067300
> email: aisaac...@ska.ac.za
>
>
>
> On Thu, Apr 16, 2020 at 9:08 PM Aravind Venkitasubramony <
> aravind.venkitasubram...@colorado.edu> wrote:
>
>> Oh. That was it. Even though I recompiled the slx file, I kept using the
>> old fpg data file in the script. That was the issue. Now it works from any
>> location.
>>
>> Sorry for the confusion Adam. I just didn't pay attention to that part.
>>
>> Is there any tutorial planned with the ZCU111 board? My interest lies
>> mainly in the ZCU111 board and I was using the redpitaya as a learning
>> platform to get familiar with the casper tools and environment. I get a
>> flavor of the toolflow now.
>>
>> On Thu, Apr 16, 2020 at 12:51 PM Adam Isaacson 
>> wrote:
>>
>>> Hi Aravind,
>>>
>>> That is strange. It shouldn't matter where your slx file and script file
>>> is located. I am sure I have compiled my slx file in a different folder to
>>> the jasper_library/test_models.
>>>
>>> Are you sure you were not using an old version of your fpg file by
>>> mistake i.e. before you git pulled the new commit? Just confirm that.
>>>
>>> Please can you send me the fpg file of the working one and the non
>>> working one, thanks. I want to check the fpg metadata.
>>>
>>> Kind regards,
>>>
>>> Adam
>>>
>>> On Thu, 16 Apr 2020, 8:13 PM Aravind Venkitasubramony, <
>>> aravind.venkitasubram...@colorado.edu> wrote:
>>>
 Hi Adam

 1 and 2 are as expected. I do not find any change there

 But upon reading your email, I realized  I might be  supposed to have
 saved the model file inside the mlib_devel/jasper_library/test_models
 folder. I saved the slx file inside jasper_library/test_models, saved the
 python file inside scripts folder, compiled it again and then I see that
 there is no error and I get the plots. Earlier I had saved the .slx files
 outside mlib_devel.

 Just to confirm - I should always have the .slx files inside
 /mlib_devel/jasper_library/test_models and scripts under
 /mlib_devel/jasper_library/scripts - Is this correct?

 Also, I had saved the first two tutorial files also outside mlib-devel
 and I did not face any issues there. Is this expected?


 On Thu, Apr 16, 2020 at 12:38 AM Adam Isaacson 
 wrote:

> Hi Aravind,
>
> It is definitely the right commit githash. Please can you check the
> following (1 and 2 below) to confirm that all the required files are in
> place - if not then do a fresh git clone again:
>
> 1) Please check that your file is identical to this file
> https://github.com/casper-astro/mlib_devel/blob/master/jasper_library/yellow_blocks/bram.py.
> Ensure that line 35 has this "nbytes=self.depth*self.data_width//8"
> and not "nbytes=4".hould always
>
> 2) Go to where your xml2vhdl repo was installed. Mine was installed in
> my python virtual environment under
> "~/venv/src/xml2vhdl-ox-0.2.2-py3.5.egg". Do a "git log" and you should 
> see
> "commit 690ef929a8dd32aef...".
>
> If no luck, then tar your generated project folder under
> "jasper_library/test_models" and send it to me via a google drive link for
> investigation with the slx file, thanks. I am sure your core_info.tab,
> which is in the project folder is not being generated with the correct
> number of bytes.
>
> 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 10:45 PM Aravind Venkitasubramony <
> aravind.venkitasubram...@colorado.edu> wrote:
>
>> 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
>> 

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

[Adam Isaacson]

Hi Aravind,

Great, I am glad you are sorted.

I am not really involved with the ZCU111 anymore, but can say that there
are no existing tutorials for that yet. The people to speak to are Brian
Bradford and Mitch Burnett. I suggest you send out another email to the
CASPER email list with "ZCU111 tutorials" in the title and they should get
back to you whether they have something. There is also a slack channel for
the ZCU111. I did invite you to the CASPER slack group. I suggest you
accept and post your questions there as well. You will also see all the
posts concerning the ZCU111.

I hope this helps!

Kind regards,

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



On Thu, Apr 16, 2020 at 9:08 PM Aravind Venkitasubramony <
aravind.venkitasubram...@colorado.edu> wrote:

> Oh. That was it. Even though I recompiled the slx file, I kept using the
> old fpg data file in the script. That was the issue. Now it works from any
> location.
>
> Sorry for the confusion Adam. I just didn't pay attention to that part.
>
> Is there any tutorial planned with the ZCU111 board? My interest lies
> mainly in the ZCU111 board and I was using the redpitaya as a learning
> platform to get familiar with the casper tools and environment. I get a
> flavor of the toolflow now.
>
> On Thu, Apr 16, 2020 at 12:51 PM Adam Isaacson 
> wrote:
>
>> Hi Aravind,
>>
>> That is strange. It shouldn't matter where your slx file and script file
>> is located. I am sure I have compiled my slx file in a different folder to
>> the jasper_library/test_models.
>>
>> Are you sure you were not using an old version of your fpg file by
>> mistake i.e. before you git pulled the new commit? Just confirm that.
>>
>> Please can you send me the fpg file of the working one and the non
>> working one, thanks. I want to check the fpg metadata.
>>
>> Kind regards,
>>
>> Adam
>>
>> On Thu, 16 Apr 2020, 8:13 PM Aravind Venkitasubramony, <
>> aravind.venkitasubram...@colorado.edu> wrote:
>>
>>> Hi Adam
>>>
>>> 1 and 2 are as expected. I do not find any change there
>>>
>>> But upon reading your email, I realized  I might be  supposed to have
>>> saved the model file inside the mlib_devel/jasper_library/test_models
>>> folder. I saved the slx file inside jasper_library/test_models, saved the
>>> python file inside scripts folder, compiled it again and then I see that
>>> there is no error and I get the plots. Earlier I had saved the .slx files
>>> outside mlib_devel.
>>>
>>> Just to confirm - I should always have the .slx files inside
>>> /mlib_devel/jasper_library/test_models and scripts under
>>> /mlib_devel/jasper_library/scripts - Is this correct?
>>>
>>> Also, I had saved the first two tutorial files also outside mlib-devel
>>> and I did not face any issues there. Is this expected?
>>>
>>>
>>> On Thu, Apr 16, 2020 at 12:38 AM Adam Isaacson 
>>> wrote:
>>>
 Hi Aravind,

 It is definitely the right commit githash. Please can you check the
 following (1 and 2 below) to confirm that all the required files are in
 place - if not then do a fresh git clone again:

 1) Please check that your file is identical to this file
 https://github.com/casper-astro/mlib_devel/blob/master/jasper_library/yellow_blocks/bram.py.
 Ensure that line 35 has this "nbytes=self.depth*self.data_width//8"
 and not "nbytes=4".hould always

 2) Go to where your xml2vhdl repo was installed. Mine was installed in
 my python virtual environment under
 "~/venv/src/xml2vhdl-ox-0.2.2-py3.5.egg". Do a "git log" and you should see
 "commit 690ef929a8dd32aef...".

 If no luck, then tar your generated project folder under
 "jasper_library/test_models" and send it to me via a google drive link for
 investigation with the slx file, thanks. I am sure your core_info.tab,
 which is in the project folder is not being generated with the correct
 number of bytes.

 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 10:45 PM Aravind Venkitasubramony <
 aravind.venkitasubram...@colorado.edu> wrote:

> 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

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

[Aravind Venkitasubramony]

Oh. That was it. Even though I recompiled the slx file, I kept using the
old fpg data file in the script. That was the issue. Now it works from any
location.

Sorry for the confusion Adam. I just didn't pay attention to that part.

Is there any tutorial planned with the ZCU111 board? My interest lies
mainly in the ZCU111 board and I was using the redpitaya as a learning
platform to get familiar with the casper tools and environment. I get a
flavor of the toolflow now.

On Thu, Apr 16, 2020 at 12:51 PM Adam Isaacson  wrote:

> Hi Aravind,
>
> That is strange. It shouldn't matter where your slx file and script file
> is located. I am sure I have compiled my slx file in a different folder to
> the jasper_library/test_models.
>
> Are you sure you were not using an old version of your fpg file by mistake
> i.e. before you git pulled the new commit? Just confirm that.
>
> Please can you send me the fpg file of the working one and the non working
> one, thanks. I want to check the fpg metadata.
>
> Kind regards,
>
> Adam
>
> On Thu, 16 Apr 2020, 8:13 PM Aravind Venkitasubramony, <
> aravind.venkitasubram...@colorado.edu> wrote:
>
>> Hi Adam
>>
>> 1 and 2 are as expected. I do not find any change there
>>
>> But upon reading your email, I realized  I might be  supposed to have
>> saved the model file inside the mlib_devel/jasper_library/test_models
>> folder. I saved the slx file inside jasper_library/test_models, saved the
>> python file inside scripts folder, compiled it again and then I see that
>> there is no error and I get the plots. Earlier I had saved the .slx files
>> outside mlib_devel.
>>
>> Just to confirm - I should always have the .slx files inside
>> /mlib_devel/jasper_library/test_models and scripts under
>> /mlib_devel/jasper_library/scripts - Is this correct?
>>
>> Also, I had saved the first two tutorial files also outside mlib-devel
>> and I did not face any issues there. Is this expected?
>>
>>
>> On Thu, Apr 16, 2020 at 12:38 AM Adam Isaacson 
>> wrote:
>>
>>> Hi Aravind,
>>>
>>> It is definitely the right commit githash. Please can you check the
>>> following (1 and 2 below) to confirm that all the required files are in
>>> place - if not then do a fresh git clone again:
>>>
>>> 1) Please check that your file is identical to this file
>>> https://github.com/casper-astro/mlib_devel/blob/master/jasper_library/yellow_blocks/bram.py.
>>> Ensure that line 35 has this "nbytes=self.depth*self.data_width//8" and
>>> not "nbytes=4".hould always
>>>
>>> 2) Go to where your xml2vhdl repo was installed. Mine was installed in
>>> my python virtual environment under
>>> "~/venv/src/xml2vhdl-ox-0.2.2-py3.5.egg". Do a "git log" and you should see
>>> "commit 690ef929a8dd32aef...".
>>>
>>> If no luck, then tar your generated project folder under
>>> "jasper_library/test_models" and send it to me via a google drive link for
>>> investigation with the slx file, thanks. I am sure your core_info.tab,
>>> which is in the project folder is not being generated with the correct
>>> number of bytes.
>>>
>>> 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 10:45 PM Aravind Venkitasubramony <
>>> aravind.venkitasubram...@colorado.edu> wrote:
>>>
 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 

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

[Adam Isaacson]

Hi Aravind,

That is strange. It shouldn't matter where your slx file and script file is
located. I am sure I have compiled my slx file in a different folder to the
jasper_library/test_models.

Are you sure you were not using an old version of your fpg file by mistake
i.e. before you git pulled the new commit? Just confirm that.

Please can you send me the fpg file of the working one and the non working
one, thanks. I want to check the fpg metadata.

Kind regards,

Adam

On Thu, 16 Apr 2020, 8:13 PM Aravind Venkitasubramony, <
aravind.venkitasubram...@colorado.edu> wrote:

> Hi Adam
>
> 1 and 2 are as expected. I do not find any change there
>
> But upon reading your email, I realized  I might be  supposed to have
> saved the model file inside the mlib_devel/jasper_library/test_models
> folder. I saved the slx file inside jasper_library/test_models, saved the
> python file inside scripts folder, compiled it again and then I see that
> there is no error and I get the plots. Earlier I had saved the .slx files
> outside mlib_devel.
>
> Just to confirm - I should always have the .slx files inside
> /mlib_devel/jasper_library/test_models and scripts under
> /mlib_devel/jasper_library/scripts - Is this correct?
>
> Also, I had saved the first two tutorial files also outside mlib-devel and
> I did not face any issues there. Is this expected?
>
>
> On Thu, Apr 16, 2020 at 12:38 AM Adam Isaacson 
> wrote:
>
>> Hi Aravind,
>>
>> It is definitely the right commit githash. Please can you check the
>> following (1 and 2 below) to confirm that all the required files are in
>> place - if not then do a fresh git clone again:
>>
>> 1) Please check that your file is identical to this file
>> https://github.com/casper-astro/mlib_devel/blob/master/jasper_library/yellow_blocks/bram.py.
>> Ensure that line 35 has this "nbytes=self.depth*self.data_width//8" and
>> not "nbytes=4".hould always
>>
>> 2) Go to where your xml2vhdl repo was installed. Mine was installed in my
>> python virtual environment under "~/venv/src/xml2vhdl-ox-0.2.2-py3.5.egg".
>> Do a "git log" and you should see "commit 690ef929a8dd32aef...".
>>
>> If no luck, then tar your generated project folder under
>> "jasper_library/test_models" and send it to me via a google drive link for
>> investigation with the slx file, thanks. I am sure your core_info.tab,
>> which is in the project folder is not being generated with the correct
>> number of bytes.
>>
>> 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 10:45 PM Aravind Venkitasubramony <
>> aravind.venkitasubram...@colorado.edu> wrote:
>>
>>> 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 <
 

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

[Aravind Venkitasubramony]

Hi Adam

1 and 2 are as expected. I do not find any change there

But upon reading your email, I realized  I might be  supposed to have saved
the model file inside the mlib_devel/jasper_library/test_models folder. I
saved the slx file inside jasper_library/test_models, saved the python file
inside scripts folder, compiled it again and then I see that there is no
error and I get the plots. Earlier I had saved the .slx files outside
mlib_devel.

Just to confirm - I should always have the .slx files inside
/mlib_devel/jasper_library/test_models and scripts under
/mlib_devel/jasper_library/scripts - Is this correct?

Also, I had saved the first two tutorial files also outside mlib-devel and
I did not face any issues there. Is this expected?


On Thu, Apr 16, 2020 at 12:38 AM Adam Isaacson  wrote:

> Hi Aravind,
>
> It is definitely the right commit githash. Please can you check the
> following (1 and 2 below) to confirm that all the required files are in
> place - if not then do a fresh git clone again:
>
> 1) Please check that your file is identical to this file
> https://github.com/casper-astro/mlib_devel/blob/master/jasper_library/yellow_blocks/bram.py.
> Ensure that line 35 has this "nbytes=self.depth*self.data_width//8" and
> not "nbytes=4".hould always
>
> 2) Go to where your xml2vhdl repo was installed. Mine was installed in my
> python virtual environment under "~/venv/src/xml2vhdl-ox-0.2.2-py3.5.egg".
> Do a "git log" and you should see "commit 690ef929a8dd32aef...".
>
> If no luck, then tar your generated project folder under
> "jasper_library/test_models" and send it to me via a google drive link for
> investigation with the slx file, thanks. I am sure your core_info.tab,
> which is in the project folder is not being generated with the correct
> number of bytes.
>
> 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 10:45 PM Aravind Venkitasubramony <
> aravind.venkitasubram...@colorado.edu> wrote:
>
>> 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 

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

[Adam Isaacson]

Hi Aravind,

It is definitely the right commit githash. Please can you check the
following (1 and 2 below) to confirm that all the required files are in
place - if not then do a fresh git clone again:

1) Please check that your file is identical to this file
https://github.com/casper-astro/mlib_devel/blob/master/jasper_library/yellow_blocks/bram.py.
Ensure that line 35 has this "nbytes=self.depth*self.data_width//8" and not
"nbytes=4".

2) Go to where your xml2vhdl repo was installed. Mine was installed in my
python virtual environment under "~/venv/src/xml2vhdl-ox-0.2.2-py3.5.egg".
Do a "git log" and you should see "commit 690ef929a8dd32aef...".

If no luck, then tar your generated project folder under
"jasper_library/test_models" and send it to me via a google drive link for
investigation with the slx file, thanks. I am sure your core_info.tab,
which is in the project folder is not being generated with the correct
number of bytes.

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 10:45 PM Aravind Venkitasubramony <
aravind.venkitasubram...@colorado.edu> wrote:

> 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 

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 

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 

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

[Aravind Venkitasubramony]

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 from the snapshots.
>>>
>>> I would have to see your script and your slx file that you have updated
>>> in order to see if they are correct. Send that to me and I will glance over
>>> it.
>>>
>>> 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 7, 2020 at 1:04 AM Aravind Venkitasubramony <
>>> arve9...@colorado.edu> wrote:
>>>
 I guess I have to complete the tutorial 2 first before jumping on the
 third one to get an answer why. I will see if that helps.

 On Monday, April 6, 2020 at 4:35:34 PM UTC-6, Aravind Venkitasubramony
 wrote:
>
> Sorry for the confusion. I meant the wide(ish) spectrometer tutorial 3
>
> On Monday, April 6, 2020 at 3:58:50 PM UTC-6, Aravind Venkitasubramony
> wrote:
>>
>> Does the spectrometer tutorial work with the 14 bit Red Pitaya board
>> as well? The tutorial mentions the 10 bit board, but I am using the 14 
>> bit
>> board version.
>>
>> Also, going through the spectrometer tutorial with the 14 bit board,
>> I get the following message at the terminal when executing the python
>> command. Can someone help me with what might be the issue here?
>>
>> Connecting to Red Pitaya: rp-F07516.local
>> Uploading: tut_spec.fpg
>> These are the devices in your design 

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

[Adam Isaacson]

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 from the snapshots.

I would have to see your script and your slx file that you have updated in
order to see if they are correct. Send that to me and I will glance over it.

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 7, 2020 at 1:04 AM Aravind Venkitasubramony <
arve9...@colorado.edu> wrote:

> I guess I have to complete the tutorial 2 first before jumping on the
> third one to get an answer why. I will see if that helps.
>
> On Monday, April 6, 2020 at 4:35:34 PM UTC-6, Aravind Venkitasubramony
> wrote:
>>
>> Sorry for the confusion. I meant the wide(ish) spectrometer tutorial 3
>>
>> On Monday, April 6, 2020 at 3:58:50 PM UTC-6, Aravind Venkitasubramony
>> wrote:
>>>
>>> Does the spectrometer tutorial work with the 14 bit Red Pitaya board as
>>> well? The tutorial mentions the 10 bit board, but I am using the 14 bit
>>> board version.
>>>
>>> Also, going through the spectrometer tutorial with the 14 bit board, I
>>> get the following message at the terminal when executing the python
>>> command. Can someone help me with what might be the issue here?
>>>
>>> Connecting to Red Pitaya: rp-F07516.local
>>> Uploading: tut_spec.fpg
>>> These are the devices in your design ...
>>> ['acc_cnt', 'acc_len', 'accum0_snap_ss_bram', 'accum0_snap_ss_ctrl',
>>> 'accum0_snap_ss_status', 'accum1_snap_ss_bram', 'accum1_snap_ss_ctrl',
>>> 'accum1_snap_ss_status', 'accumdat_snap_ss_bram', 'accumdat_snap_ss_ctrl',
>>> 'accumdat_snap_ss_status', 'adc_dv', 'adc_sample_cnt',
>>> 'adc_voltage_snap_ss_bram', 'adc_voltage_snap_ss_ctrl',
>>> 'adc_voltage_snap_ss_status', 'fft_sync_inc0', 'fft_sync_inc1',
>>> 'reg_cntrl', 'snap_gap', 'sync_cnt', 'sync_reg', 'sys_block',
>>> 'sys_board_id', 'sys_clkcounter', 'sys_rev', 'sys_rev_rcs',
>>> 'sys_scratchpad']
>>> Traceback (most recent call last):
>>>   File "tut_spec.py", line 38, in 
>>> spec0=fpga.snapshots.accum0_snap_ss.read(arm=False)['data']
>>>   File "/usr/local/lib/python2.7/dist-packages/casperfpga/snap.py", line
>>> 227, in read
>>> rawdata, rawtime = self.read_raw(**kwargs)
>>>   File "/usr/local/lib/python2.7/dist-packages/casperfpga/snap.py", line
>>> 333, in read_raw
>>> bram_dmp['length'] / (self.width_bits / 8)))
>>> RuntimeError: accum0_snap_ss.read_uint() - expected 16384 bytes, got 32
>>>
>>> --
> 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/77f027f3-c878-43c1-ab28-b77f3582d4f8%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/CADTJ%3DnF22fvRt-WuwViLJ1qmAwEE4nPkKaieMXX7-HXKpXoaMQ%40mail.gmail.com.

[casper] Re: Red Pitaya Tutorial 2 Reg

[Aravind Venkitasubramony]

I guess I have to complete the tutorial 2 first before jumping on the third 
one to get an answer why. I will see if that helps. 

On Monday, April 6, 2020 at 4:35:34 PM UTC-6, Aravind Venkitasubramony 
wrote:
>
> Sorry for the confusion. I meant the wide(ish) spectrometer tutorial 3
>
> On Monday, April 6, 2020 at 3:58:50 PM UTC-6, Aravind Venkitasubramony 
> wrote:
>>
>> Does the spectrometer tutorial work with the 14 bit Red Pitaya board as 
>> well? The tutorial mentions the 10 bit board, but I am using the 14 bit 
>> board version. 
>>
>> Also, going through the spectrometer tutorial with the 14 bit board, I 
>> get the following message at the terminal when executing the python 
>> command. Can someone help me with what might be the issue here? 
>>
>> Connecting to Red Pitaya: rp-F07516.local
>> Uploading: tut_spec.fpg
>> These are the devices in your design ...
>> ['acc_cnt', 'acc_len', 'accum0_snap_ss_bram', 'accum0_snap_ss_ctrl', 
>> 'accum0_snap_ss_status', 'accum1_snap_ss_bram', 'accum1_snap_ss_ctrl', 
>> 'accum1_snap_ss_status', 'accumdat_snap_ss_bram', 'accumdat_snap_ss_ctrl', 
>> 'accumdat_snap_ss_status', 'adc_dv', 'adc_sample_cnt', 
>> 'adc_voltage_snap_ss_bram', 'adc_voltage_snap_ss_ctrl', 
>> 'adc_voltage_snap_ss_status', 'fft_sync_inc0', 'fft_sync_inc1', 
>> 'reg_cntrl', 'snap_gap', 'sync_cnt', 'sync_reg', 'sys_block', 
>> 'sys_board_id', 'sys_clkcounter', 'sys_rev', 'sys_rev_rcs', 
>> 'sys_scratchpad']
>> Traceback (most recent call last):
>>   File "tut_spec.py", line 38, in 
>> spec0=fpga.snapshots.accum0_snap_ss.read(arm=False)['data']
>>   File "/usr/local/lib/python2.7/dist-packages/casperfpga/snap.py", line 
>> 227, in read
>> rawdata, rawtime = self.read_raw(**kwargs)
>>   File "/usr/local/lib/python2.7/dist-packages/casperfpga/snap.py", line 
>> 333, in read_raw
>> bram_dmp['length'] / (self.width_bits / 8)))
>> RuntimeError: accum0_snap_ss.read_uint() - expected 16384 bytes, got 32
>>
>>

-- 
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/77f027f3-c878-43c1-ab28-b77f3582d4f8%40lists.berkeley.edu.

[casper] Re: Red Pitaya Tutorial 2 Reg

[Aravind Venkitasubramony]

Sorry for the confusion. I meant the wide(ish) spectrometer tutorial 3

On Monday, April 6, 2020 at 3:58:50 PM UTC-6, Aravind Venkitasubramony 
wrote:
>
> Does the spectrometer tutorial work with the 14 bit Red Pitaya board as 
> well? The tutorial mentions the 10 bit board, but I am using the 14 bit 
> board version. 
>
> Also, going through the spectrometer tutorial with the 14 bit board, I get 
> the following message at the terminal when executing the python command. 
> Can someone help me with what might be the issue here? 
>
> Connecting to Red Pitaya: rp-F07516.local
> Uploading: tut_spec.fpg
> These are the devices in your design ...
> ['acc_cnt', 'acc_len', 'accum0_snap_ss_bram', 'accum0_snap_ss_ctrl', 
> 'accum0_snap_ss_status', 'accum1_snap_ss_bram', 'accum1_snap_ss_ctrl', 
> 'accum1_snap_ss_status', 'accumdat_snap_ss_bram', 'accumdat_snap_ss_ctrl', 
> 'accumdat_snap_ss_status', 'adc_dv', 'adc_sample_cnt', 
> 'adc_voltage_snap_ss_bram', 'adc_voltage_snap_ss_ctrl', 
> 'adc_voltage_snap_ss_status', 'fft_sync_inc0', 'fft_sync_inc1', 
> 'reg_cntrl', 'snap_gap', 'sync_cnt', 'sync_reg', 'sys_block', 
> 'sys_board_id', 'sys_clkcounter', 'sys_rev', 'sys_rev_rcs', 
> 'sys_scratchpad']
> Traceback (most recent call last):
>   File "tut_spec.py", line 38, in 
> spec0=fpga.snapshots.accum0_snap_ss.read(arm=False)['data']
>   File "/usr/local/lib/python2.7/dist-packages/casperfpga/snap.py", line 
> 227, in read
> rawdata, rawtime = self.read_raw(**kwargs)
>   File "/usr/local/lib/python2.7/dist-packages/casperfpga/snap.py", line 
> 333, in read_raw
> bram_dmp['length'] / (self.width_bits / 8)))
> RuntimeError: accum0_snap_ss.read_uint() - expected 16384 bytes, got 32
>
>

-- 
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/ba63c1ae-b5d8-4bae-8fa1-fd62793f5f58%40lists.berkeley.edu.