Re: [casper] Continuous streaming of spectrum on red pitaya

[Adam Isaacson]

Dear Fazal,

I don't believe the 1GbE block will work for the Red Pitaya as this block
is for Programmable Logic (PL). The Red Pitaya supports a Zynq processor
and so it has a Hard Processor Software region (PS) and PL. The 1GbE is
connected to the Zynq directly and we use AXI Lite interconnect to
interface this with the standard software register yellow blocks, BRAM and
snap shots that you use in Simulink. These are located in the PL region of
the device.

This is not to say that we can't create a 1GbE yellow block, but according
to what I know, this has not been done. Here is a list of the tutorials for
the Red Pitaya. It will give you an idea of the current functionality
supported:

https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/

Kind regards,

Adam


On Fri, Oct 27, 2023 at 8:13 AM Fazal Kareem 
wrote:

> Thanks Cedric!I looked into the red pitaya hardware docs and also some
> casper documentation, but I couldn't find whether the casper 1Gbe yellow
> block can be used on red pitaya designs. Can someone comment on this?Best
> regards,FazalOn Wed, Oct 25, 2023 at 4:02 PM Cedric Viou
> & ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
>
> 
> Thanks Cedric!
>
> I looked into the red pitaya hardware docs and also some casper
> documentation, but I couldn't find whether the casper 1Gbe yellow block can
> be used on red pitaya designs. Can someone comment on this?
>
> Best regards,
> Fazal
>
> On Wed, Oct 25, 2023 at 4:02 PM Cedric Viou 
> wrote:
>
>> Hi,
>>
>> I wrote what you described for ROACH2 (1GbE, 2048-FFT, XX*+YY*+XY*):
>>
>>- Firmware and fpga setup ->
>>
>> https://github.com/CedricDViou/NRT_2G_channelizer/tree/master/firmware/adc_sst/adc_sst_v7.*
>>
>> 
>>- Data capture (plot or record) ->
>>https://github.com/CedricDViou/NRT_2G_channelizer/tree/master/SEFRAM
>>
>>
>> However I doubt the 1G interface is the same on Red-Pitaya.
>> That could be a starting point if you can use the Red-Pitaya 1G 

Re: [casper] Continuous streaming of spectrum on red pitaya

[Adam Isaacson]

Dear Fazal,

We never focused on streaming the data out of the Red Pitaya when we
initially ported it to the CASPER toolflow in 2019. We had to use snap
shots to get the data. Maybe some others have worked on this since then and
can offer better support, but that was the status when I last worked with
the Red Pitaya.

It would certainly be very useful to add this feature, if it is still
missing.

Kind regards,

Adam

On Tue, Oct 24, 2023 at 11:00 AM Fazal Kareem 
wrote:

> Hi,I am trying to make a streaming setup from Red-Pitaya after doing an
> FFT and a power accumulation. I hope this will reduce the data enough to
> accommodate streaming on the RP board. Does anyone have a design file that
> could help me get the data out of the board into a file on
> m ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
>
> 
> Hi,
>
> I am trying to make a streaming setup from Red-Pitaya after doing an FFT
> and a power accumulation. I hope this will reduce the data enough to
> accommodate streaming on the RP board. Does anyone have a design file that
> could help me get the data out of the board into a file on my computer? The
> snap block is giving me a lot of issues. If anyone has figured out
> streaming on RP, your help would be much appreciated.
>
> Thank you,
> Fazal
>
> --
> Fazal Kareem
> Indian Pulsar Timing Array
> Centre of Excellence in Space Sciences India
> Indian Institute of Science Education and Research Kolkata
>
>
> --
> 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/CABUzwDPazcYZx6CcDGT8wF2ycZq%2BMvyH5FcD%3DED3vO90xD%3DUUQ%40mail.gmail.com
> 
> .
>

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, 

Re: [casper] Question on Casperfpga python 3.8 version

[Adam Isaacson]

ted()=True. I’m using: Toolflow: Ubuntu 18.04LTS,
> Python ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
>
> <https://za.report.cybergraph.mimecast.com/alert-details/?dep=yl2lXqDYoP%2FiKjCsaJIVMA%3D%3DfwMNStY6Uuq%2BYvlJ4lVaGrQcX26DRKUPwZc%2BvyCbpXUQu6FzyJvDV%2FMpaVF3oCSkfIRJVePac2mMYk2W2658eyA5Z0IvCw2Is%2BGou97032a1MIqtqD1qSbCtq%2FWWAeww8eqUHmdRrNtGgyrzNLEtiw6Zj2tPgRriMlyepKjsBt45Sjl7cm38ObvYRtnaNZObdxC%2BKeCXwlHn75G00Lks0c8sdHAFzIA0C9vwzHCGwOd%2BAx9cy8fKEByhGCSwCaR3RlSZiP9Du%2FC8PMw5NqCdvwAAXTgKnuVM%2FiW6K%2FqaOZhcFZ64mZUrbhfKYXXaNEhwgZWcb2ojZHzdEodPzCoqq5mUZOfGINtMHs%2BJm3pSak%2FK2hRTWs8t%2BbVP%2FqYp6v4ZMLCiMs5ysORc%2BdY0aZ5yM0oyRWrwZvA8%2BnAWPP6ws%2Fv88pL5uGUUsVEQ5mzmiwyntBXYI%2FOusjgt3OADiYhG8%2FQldl0va%2BrQ67ghk3M2oTnn%2BzriGIppWPhCTvLnBekNnLe1H47fz6JCfRVrdH0vMoT6k7%2BeizmYvPfEVVU12fUmZ84Bt89l3C2WfM6fudzvLNrEsoZ31P5AgO0telOM6h5PawMcary4cOqL2e7pUWUBoz4e6ykb5zs0nxM1jM7jn%2FxplQfivPiuhqkSh405Bb56%2FYSzVko5c8O87OjXdGI%3D>
>
> Hi, I think my questions are for Adam and Co.,
>
>
>
> I can program a .fpg file into Red Pitaya but I cannot program one into
> SKARAB.  Please see attachments, note errors in SKARAB programming
> screenshot and also note fpga.is_connected()=True.
>
>
>
> I’m using:
>
> Toolflow: Ubuntu 18.04LTS, Python 3.6 (Virtual environment), Matlab
> R2018a, Vivado 2019.1.1.
>
> casperfpga: Ubuntu 18.04LTS, Python 2.7 (non-Virtual environment)
>
>
>
> Note I’m using non-virtual environment for casperfpga.  I’ve looked at
> older emails from Adam where he used non-virtual for casperfpga, but below
> specifies virtual.  Has something changed/been discovered with programming
> SKARAB?  Not sure why my non-virtual environment would work for Pitaya but
> not SKARAB.
>
>
>
> Things I’ve considered or tried include:
>
>
>
>- Able to ping SKARAB copper port and fiber ports.
>- Set mtu=9000 on my host, per Peralex documentation.
>- Thought of programming SKARAB by hostname instead of IP address, but
>don’t know if it even has a hostname or what it would be.
>
>
>
> Note this is the first time I’m programming the SKARAB, does something
> need to be set up for first time?
>
>
>
> Thank you so much in advance!   -- Jeff
>
>
>
>
>
> *From:* casper@lists.berkeley.edu  *On Behalf
> Of *Adam Isaacson
> *Sent:* Monday, May 29, 2023 4:53 AM
> *To:* casper@lists.berkeley.edu
> *Subject:* Re: [casper] Question on Casperfpga python 3.8 version
>
>
>
> Dear June,
>
>
>
> I am sorry you are encountering this problem. SKARAB has only been
> baselined and fully tested using Python 2.7 for casperfpga. Yes, some
> attempts have been made to port it to Python 3.8, but as far as I am aware
> there have been issues that were never fully sorted out. It looks like you
> may be encountering those.
>
>
>
> I would try to run it using Python 2.7 first. NB: SKARAB baseline testing
> suggested versions:
>
>
>
> *Toolflow*: Ubuntu 18.04LTS, Python 3.6 (Virtual environment), Matlab
> R2018a, Vivado 2019.1.1.
>
> *casperfpga*: Ubuntu 18.04LTS, Python 2.7 (Virtual environment)
>
>
>
> It should be pointed out that work has been done on the toolflow to get it
> to work with Ubuntu 18.04LTS, Python 3.8, Matlab R2021a and Vivado 2021.1.
> NB: Please note that we had issues running some of the tutorials and that
> the base driver IP for Ethernet and most drivers remain at the Vivado
> 2019.1.1 version for SKARAB, so it is not fully ported at all levels.
>
>
>
> It should be pointed out that at this point our DSP team are currently
> using SKARABs for new development with these new versions, so they may end
> up sorting all these issues out in the long run, but if you want a fully
> baselined and tested SKARAB version now then I would stick with the
> recommended baseline versions.
>

Re: [casper] Re: zcu216_tut_spec.fpg RuntimeError: no programming informs yet. Odd?

[Adam Isaacson]

 ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
>
> <https://za.report.cybergraph.mimecast.com/alert-details/?dep=qmx%2Fn%2FiZdMMoBIefbJFGMg%3D%3D4qKZgaAlbL%2FIzYgEJI9UCYf1R2RaqDFNdM43CHo%2FbUKrV7YDIos0uu1efS6jD9WPzWgsV5GpmDHyQAUuj9XNI2h0iqK2lwL3KOrSWK1QjviRTzn1jDEPs0xgpORrA0NTD6W4UheovF9UANgfpR9UyHEDTVTuCluQ0cSC1Z1WW07AP%2F5iJskDiMESQtMSFbNmXJ9Lvm%2BSZcokqD3HBprerVkQls0tUq35Qj%2BjxAHb46J0vscFOJIRnri17tBfr6TmTiFdfazH346GkTVMQ5OZMEgIcdmpmqMhUIV3gFd%2BcJXLdDhuWibN9DFvCz6fjT48qPU2gMIVZ06Fx9at9Trtpm0OZXIJuNCTHujEXV%2FORU8wA7avN96N4s%2Fv5J7D2rBIbJfdWdC2SFQQZ2sR3K4VRl0ECBf006eRSglD8u%2B8BROZ%2BM4iDdfyb%2BEA%2BKWkPVCv4BYU%2BOZlxJvewhg%2B%2F8QKtt6r%2B7TF%2FA7awasEAMXP1Mx3yAY4hE%2BDDuugCL9z7JO129uosVC0mexRH8HYR4wSQ%2FVLSbrtTPj%2B7pYw57lCE%2BnidPhaIG9HbQDbik1RhRESP7mWfZTAsJcvptODvoSH%2BuCSaNTmbihtv6zX2jm94sZyVtJZPiJ7hjYq5I6RmesF2RI2Kq6tNEgnW5wMRFlUWiQZnQhZ7fbTPrUYtfzIR5aPqs7DV%2B6P2ITwXejWb2W63ND06gCcsZBDfq7h16D4UoCrMYhKA72oQQPmd8neOx3Qd1mvQ3LsR2xtR6tsfk9e7QlmmpnajURGrrPSd2OvWQ%3D%3D>
> Hello Adam,
>
> Here is a method for determining the FPGA part number on a ZCU216.
>
> 1) Connect the ZCU216 to a network switch or router by its RJ45 ethernet,
> and boot it into an SD card.  Connect a computer to the same network, and
> install Vivado.
>
> 2) In Vivado , menus  `Flow >> Open Hardware Manager`
>
> 3) Click  `Open Target >> Open New Target..`
>
> 4) Next >> Next
>
> 5) Set "Connect To" to `Local server` .  `Next`
>
> 6) Click on the items on the list until the `Hardware Devices` table is
> populated by stuff.
>
> 7)  Select the item within the `Hardware Devices` table that is *not *arm***
> .  What you have selected will turn blue.
>
> 8) Press `Next`  Press `Finish`
>
> 9) A form on the left middle will be `Hardware Device Properties` , listed
> there is `Part:`.   That is your FPGA.
>
> Mine reads  xczu49dr
>
>
> On Friday, July 14, 2023 at 9:53:45 AM UTC-4 Adam Isaacson wrote:
>
>> Hi Ken,
>>
>> This is normally stored in the yaml file in your
>> mlib_devel/jasper_library/platforms/zcu216.yaml file - see attached png
>> image. The RFSoC device that I have in a repo with Matlab R2018a is:
>> xczu49dr-ffvf1760-2-e-es1, but it may be a production device in the latest
>> mlib_develrepo, not sure. It depends whether Xilinx made production silicon
>> for this FPGA or left it as an engineering sample.
>>
>> Kind regards,
>>
>> Adam
>>
>> On Fri, Jul 14, 2023 at 3:13 AM Ken Semanov  wrote:
>>
>>> I attempted to retrieve the exact chip used in the FPGA here, but  this
>>> casperized image does not contain  lspci,  lshw, nor even hwinfo.I
>>> sniffed around /sys/bus  for an hour and got nowhere.  Anyone know where
>>> the FPGA information is hiding?
>>>
>> On Thursday, July 13, 2023 at 8:20:07 PM UTC-4 Ken Semanov wrote:
>>>
>> I am attempting to load the bitstream `zcu216_tut_spec.fpg`  located here,
>>>>
>>>>
>>>> https://github.com/casper-astro/tutorials_devel/tree/main/rfsoc/tut_spec/prebuilt/zcu216
>>>> <https://github.com/casper-astro/tutorials_devel/tree/main/rfsoc/tut_spec/prebuilt/zcu216>
>>>>
>>>> The call to `fpga.upload_to_ram_and_program()` causes
>>>> transport_katcp.py:654  to invoke an exception ,
>>>>
>>>>  RuntimeError: 132.177.x.x: no programming informs yet. Odd?
>>>>
>>>> I have been sending bitstreams to the board all afternoon with no
>>>> problems like this, so this is likely a problem with the fpg file.
>>>> However,  here is some more information.
>>>>
>>>> In [5]: casperfpga.__version__
>>>> Out[5]: '0.4.4.dev1336+py38.276ee44'
>>>>
>>>> root@dhcp-132-177-143-xxx:/home/casper# more /etc/hosts
>>>> 127.0.0.1
>>>> <http://127.0.0.1>
>>>> localhost
>>>> ::1 localhoot6.localdomain6 localhost6
>>>>
>>>> root@dhcp-132-177-143-xxx:/home/casper# ping -c 2 localhost
>>>> PING localhost (127.0.0.1
>>>> <http://127.0.0.1>)
>>>> 56(84) bytes of data.
>>>>
>>> 64 bytes from localhost (127.0.0.1
>>>> <http://127.0.0.1>:
>>>> icmp_seq=1 ttl=64 time=0.061 ms
>>>> 64 bytes from localhost (127.0.0.1
>>>> <http://127.0.0.1>:
>>>> icmp_seq=2 ttl=64 time=0.040 ms
>>>>
>>>
>>>> --- localhost ping statistics ---
>>>> 2 packets transmitted, 2 received, 0% packet loss, time 1016ms
>>>> rtt min/avg/max/mdev = 0.040/0.050/0.061/0.010 ms
>>>>
>>

Re: [casper] Question on Casperfpga python 3.8 version

[Adam Isaacson]

Dear June,

I am sorry you are encountering this problem. SKARAB has only been
baselined and fully tested using Python 2.7 for casperfpga. Yes, some
attempts have been made to port it to Python 3.8, but as far as I am aware
there have been issues that were never fully sorted out. It looks like you
may be encountering those.

I would try to run it using Python 2.7 first. NB: SKARAB baseline testing
suggested versions:

*Toolflow*: Ubuntu 18.04LTS, Python 3.6 (Virtual environment), Matlab
R2018a, Vivado 2019.1.1.
*casperfpga*: Ubuntu 18.04LTS, Python 2.7 (Virtual environment)

It should be pointed out that work has been done on the toolflow to get it
to work with Ubuntu 18.04LTS, Python 3.8, Matlab R2021a and Vivado 2021.1.
NB: Please note that we had issues running some of the tutorials and that
the base driver IP for Ethernet and most drivers remain at the Vivado
2019.1.1 version for SKARAB, so it is not fully ported at all levels.

It should be pointed out that at this point our DSP team are currently
using SKARABs for new development with these new versions, so they may end
up sorting all these issues out in the long run, but if you want a fully
baselined and tested SKARAB version now then I would stick with the
recommended baseline versions.

Good luck!

Kind regards,

Adam

On Mon, May 29, 2023 at 9:56 AM June Tantiparimongkol 
wrote:

> Dear all,Due to the upgrade of 'casperfpga' library from python 2.7 to
> 3.8, I have tried to upgrade my software to a newer version. But still got
> stuck on problems that I still can't properly install and use it as I have
> followed the information on https://casper-tool
>  ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
>
> 
> Dear all,
>
> Due to the upgrade of '*casperfpga*' library from python 2.7 to 3.8, I
> have tried to upgrade my software to a newer version. But still got stuck
> on problems that I still can't properly install and use it as I have
> followed the information on
> https://casper-toolflow.readthedocs.io/en/latest/src/How-to-install-casperfpga.html
> .
> I have pulled '*casperfpga*' repository from
> https://github.com/casper-astro/casperfpga.git
>  on
> *py38* 

Re: [casper] Roach2 progremote error & CASPER slack account

[Adam Isaacson]

Hi Austin,

Here is an invite to the CASPER slack group:
https://join.slack.com/t/casper-astro/shared_invite/zt-1s7l3vt1z-1TdvVDh6Y4ZFRoimzXrUgw
.

Kind regards,

Adam


On Fri, Mar 31, 2023 at 9:28 PM Marc  wrote:

> On Fri, Mar 31, 2023 at 6:38 PM Austin Dymont 
> wrote:Hello,Hi  My name is Austin Dymont, a new graduate student at the
> University of Chicago. I'm in need some help regarding the setup of a
> ROACH2. I'm running into an issue with programming the
>  ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
>
> 
>
>
> On Fri, Mar 31, 2023 at 6:38 PM Austin Dymont 
> wrote:
>
>> Hello,
>>
>
> Hi
>
>
>> My name is Austin Dymont, a new graduate student at the University of
>> Chicago. I'm in need some help regarding the setup of a ROACH2. I'm running
>> into an issue with programming the roach with a new .fpg file. I followed
>> through with some of the intro tutorial from the toolflow
>> .
>> The tutorial was able to connect to the ROACH2 and begin talking to it,
>> checked by pinging and the is_connected() returned true. It errored when it
>> tried to run progremote.
>>
>> INFO:192.168.X.XX:192.168.X.XX: uploading 
>> tutorial/roach2/tut_intro/roach2_tut_intro.fpg, programming when done
>> 
>> ('progremote request(Request to client 192.168.X.XX failed.) on host 
>> 192.168.X.XX failed',))
>>
>>
>
>  If you telnet (or nc) to the roach on port 7147 while you do this, there
> might be some messages telling us a bit more. And if you type
>
> ?log-level debug
>
> on that connection, you might get more detailed feedback. Let us know what
> you see and hopefully we can point you in the right direction.
>
> On that connection you could also try to program fpg files by hand, though
> that will involve a second netcat - it works in a similar way to ftp.
>
> Regarding the uboot prompt: There are standalone tftp servers as well as
> one part of dnsmasq, and if you do a printenv at the uboot prompt you can
> see what those run macros expand 

[casper] Re: Skarab for BINGO radiotelescope: assistance

[Adam Isaacson]

Dear Amilcar,

The CASPER group has been in Italy on their annual CASPER workshop. I have
just returned. The others return tomorrow. The guys have worked hard on the
toolflow and are taking some nice relaxing time off.

I am not sure what tutorials you have issues with. I have discovered a
problem with the following SKARAB tutorials due to the SKARAB ADC yellow
block changes due to the sync changes.

Important CASPER documentation that you may not be aware of:

CASPER Website: https://casper.berkeley.edu/
CASPER Toolflow: https://casper-toolflow.readthedocs.io/en/latest/
CASPER Tutorials:
https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/
CASPER SKARAB ADC Tutorials that you can use:
1)
https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/skarab/tut_spec/tut_spec_byp.html.
The DDC mode will not work. I discovered it had the old ADC yellow block
with sync inputs- @Mathews Chirindo  will fix this.
2)
https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/skarab/tut_adc/tut_adc_index.html.
This is still pointing to the www.github.com/ska-sa/mlib_devel repo and
must move to casper-astro rep.

CASPER Communication is via 2 channels:

1) Slack group:
https://join.slack.com/t/casper-astro/shared_invite/zt-1fbpcvi5i-5gPOqiqfj1RDxO3qsCU~2Q
2) CASPER email group (auto subscribe as follows):
casper@lists.berkeley.edu and
to subscribe to the email list: casper+subscr...@lists.berkeley.edu
3) The SKARAB team is SARAO, Peralex and INAF.

Please indicate the versions of Ubuntu, Matlab, Vivado and Python you are
using and what tutorial you have an issue with or what your problem is and
I will do my best to assist you. The versions are mentioned in the CASPER
document, but we have baselined SKARAB on:

Ubuntu 18.04LTS, Python 3.6, Matlab R2018a update pack 6, Vivado 2019.1.1.

You will see that SKARAB now runs on Ubuntu 20.04LTS, Matlab R2021a update
5, Vivado 2021.1 and Python 3.8. Please note the IP is still sitting at
2019.1.1 and it has not all be properly verified with these versions. If
you use any other versions then you do so at your own risk. We will support
as best as we can. Remember, this is a collaboration and so we require
everyone to contribute and not just the well known CASPER developers - no
names mentioned :).

I really hope this helps you. Glad to see SKARAB is being well used
throughout the world :). Long live SKARAB.

Kind regards,

Adam, Clifford and the SKARAB team



>
>  Forwarded Message 
> Subject: Skarab for BINGO radiotelescope: assistance
> Date: Mon, 12 Sep 2022 17:20:27 -0300
> From: Amilcar Queiroz  
> To: David Moschella  ,
> Elcio Abdalla  , Elcio Abdalla
>  , Carlos Alexandre Wuensche
>  , Edmar Gurjao
>  , Clifford van Dyk
>  , Cesar Strauss
>  
>
> Dear David and Clifford,
>
>We are preparing some of the Skarabs to start receiving RF data and
> process them. We were able to follow the Casper tutorial, but there are
> still some problems that are preventing us from finalizing the process. In
> particular, when we have to export the code to the fpga. Now, I understand
> that this is in principle a software problem and we should be able to have
> some assistance from Casper forum (casper@lists.berkeley.edu). But this
> also is not working, since this group seems to be off.
>
>   So, can you point to some person or group we could discuss this whole
> process with?
>
> Best regards,
> Amilcar
>
>
>
> --
> Disclaimer: http://www2.peralex.com/disclaimer.html
>
>

-- 
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%3DnH0Z%3D4MaWh14Y3u3HEcriJjWyjU6sR%2BYWQOUVStzyHEMg%40mail.gmail.com.

Re: [casper] RA Instruments using CASPER hardware and tools

[Adam Isaacson]

Ciao Morag,

Not Radio Astronomy, but RADAR this time - FORT (FMCW Optical Radar
Tracker) uses ROACH2 and a version of the CASPER Tools. Mike Movius ran
this project - check out my old company
https://www.reutechradar.com/products/defence/tracking-radar.

Con calore,

Adam



On Wed, Aug 31, 2022 at 5:56 PM Andrea Melis  wrote:

> Hi Morag,
>
> Please add the SARDARA (Sardinia Roach2-based Digital Architecture for
> Radio Astronomy) platform. Details here: SArdinia Roach2-based Digital
> Architecture for Radio Astronomy (SARDARA) | Journal of Astronomical
> Instrumentation (worldscientific.com)
> 
>
> Thanks!
>
> Andrea
>
>
>
> Il giorno mer 31 ago 2022 alle ore 12:53 Morag Brown 
> ha scritto:
>
>> Ciao dalla Sardegna, collaborati!
>>
>> I'm hoping to put together a more up-to-date list of instruments that
>> have been built using CASPER hardware and tools. The most current list was
>> compiled in 2016 for the "A Decade of Developing Radio-Astronomy
>> Instrumentation using CASPER Open-Source Technology" paper by Jack et al,
>> so it could probably use updating.
>>
>> The list is currently as follows:
>>
>> *Spectrometers and packetizers -*
>> Fly’s Eye
>> GUPPY
>> CASPER
>> BPSR
>> GAVRT
>> SERENDIP V.v
>> HiTREKS
>> NUPPI
>> Skynet
>> RATTY
>> cycSpec
>> C-BASS
>> HIPSTER
>> KuPol
>> VEGAS
>> ALMA Phasing Project
>> Leuschner
>> R2DBE
>> DSN Transient Observatory
>> VGOS
>> AVN-Ghana
>> COMAP
>>
>> *MKID readout systems -*
>> Columbia MKID
>> Mustang2
>> DARKNESS
>> MEC
>> BLAST-TNG
>> HOLMES
>>
>> *Correlators and beamformers -*
>> KAT7
>> PAPER
>> ATA
>> LEDA
>> ARI
>> MAD
>> pocketcorr
>> Medicina FFTT
>> GMRT
>> Meteor
>> AMI
>> MeerKAT AR-1
>> FLAG
>> BIRALES
>> Starburst
>> AMiBA
>> EOVSA
>> SWARM
>> MeerKAT
>> HERA
>>
>> If you are not (or know of any instruments that are not) on this list,
>> please reach out to me for it to be added?
>>
>> Grazie!
>> Morag
>>
>>
>>
>> --
>> 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/CAGH-0TcON2s8K2JqXe0OAWWMeUeuKrnGSzhfRJS%2BWym%2BZiiE_A%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CALJdLK6yvEmH5rrBXP1kz4WHe%2BvsgqcYWoY8bd9L6WaRLMS9Lw%40mail.gmail.com
> 
> .
>

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

[casper] SKARAB HMC Walking Ones Full Coverage Test Ready

[Adam Isaacson]

Hi Casperites,

I have created a proper test for the HMCs on the SKARAB. It performs a
walking ones test on all 256 bits and the full memory location coverage
(2^27-1). There is a script that will test all three mezzanines - very
basic, needs work to pass arguments etc. There is a more complete script
that will test the HMC mezzanine of your choice. It is located here:
https://github.com/ska-sa/mlib_devel/tree/devel/jasper_library/test_models/scripts/skarab_hmc_fc_test
(fc
= full coverage). You call the skarab_hmc_fc_test.py with the following
command: python skarab_hmc_fc_test.py  -m <0,1,2> e.g.
if you are targeting mezzanine 0 then you would have "python
skarab_hmc_fc_test.py 10.0.0.7 -m 0.

Some statistics: It takes 54.67s to test one HMC on the board and 164s (2
min and 44 secs) to test all three HMCs on the board. It reconfigures the
FPGA between link 2 and link 3 then reports the consolidated results. It
will indicate if the Link fails or not. We have a faulty HMC in our lab and
it is able to detect the fault with this test.

Hope it helps if you have any HMC issues.

Kind regards,

*Adam Isaacson*
Hardware Manager
South African Radio Astronomy Observatory (SARAO)

Address: 2 Fir Street, Black River Park (North Gate Entrance), Observatory,
Cape Town, 7925
Tel: +27 21 506 7380  | Cell: +27 82 563 9602
Email: aisaac...@sarao.ac.za 
Website: www.sarao.ac.za <http://www.ska.ac.za/>

-- 
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%3DnHCY8oDDD8yTYeHF%3DzzZua8sWkh4ATLu_TQ6_M1hjNZtg%40mail.gmail.com.

Re: [casper] Fix - Simulink R2021a crashes on startup on Ubuntu 18.04

[Adam Isaacson]

Well done, Morag and team! That is a great catch and very helpful to me and
others!

Kind regards,

Adam

On Thu, Jun 9, 2022 at 2:43 PM Morag Brown  wrote:

> Hey all,
>
> I had a quick look in the mail archive and didn't see anything on this,
> but it's not impossible others will come across/have come across the same
> issue I've encountered, so figured I'd potentially save some people future
> frustrations and heart attacks.
>
> There's an issue with later versions of Matlab (R2021a and up) on older
> versions of Ubuntu (18.04 and down) where opening Simulink intermittently
> causes Matlab to crash with some variation of the following error:
>
> *Inconsistency detected by ld.so: ../elf/dl-tls.c: 517:
> _dl_allocate_tls_init: Assertion `listp != NULL' failed!*
>
> This is due to a bug in the glibc library present on older versions of
> Linux distros that doesn't play nicely with the new way Matlab does some
> things. Fortunately, Mathworks doth provide an answer. Not so fortunately,
> their official answer is "upgrade to a newer operating system with a
> version of glibc that doesn't have this bug". Lol.
>
> But they also kindly provide a solution
>  for those of us
> who can't just upgrade; an unofficial patch of the glibc libraries that
> fixes this bug for various OS versions. This of course comes with the major
> caveat that modifying system files is done at your own risk - all processes
> in the OS share glibc, so the patch will affect your whole system, not just
> Matlab, and this could cause weirdness.
>
> So if you find yourself in the same position I was yesterday, wondering if
> you should risk it all just for Simulink - I'm happy to report that I
> applied this patch, the universe did not end and nothing on my machine
> *seems* to be broken. Great success.
>
> That is all,
> Morag
>
> --
> 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/CAGH-0Tc-dJ0AUnC21S5oTP-pRXyhMC_Ld%2B8KyQ31NuSFZ7HfkQ%40mail.gmail.com
> 
> .
>

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

Re: [casper] Casper RFSoC toolflow setup

[Adam Isaacson]

Well done, Kaj, Mitch and Jack! :).

Kind regards,

Adam

On Mon, Feb 28, 2022 at 9:26 PM Kaj Wiik  wrote:

> First, I apologize my frustrated tone in my previous messages, those
> resulted
> from months of endless Python package dependency problems,
> incompatibilities
> between Ubuntu and Matlab versions etc.
>
> Thanks to efforts by Mitch Burnett and Jack Hickish, we were able to get
> things
> working. I have written a condensed instructions how to set up the
> toolflow in
> here: https://github.com/KajWiik/Casper_RFSoC/blob/main/README.md
>
> I'll prepare pull requests to the Casper documentation after deadines of
> some
> other projects.
>
> Thanks,
> Kaj
>
> --
> 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/fb40878d-9729-8b59-a071-6d64b46244ca%40utu.fi
> .
>

-- 
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%3DnFH8V6AZ6XqabWXdSq6%3D%2BMYT7BgEMVa_4cPWe_GGfii_g%40mail.gmail.com.

Re: [casper] Different Software Versions

[Adam Isaacson]

Hi Kaj,

We are definitely an open collaboration :). A lot of people have done good
work documenting what we have. This includes Morag and many others. Mitch
has done amazing work and has done his best to document everything, but the
RFSoC is new, so there will be teething issues and we ask for more patience.

The whole concept of PRP was discussed last year and to be honest I haven't
used it in earnest yet. I still do native installs.

I understand your frustration, but we are doing our best as most of the
contributers volunteer their time too. Feel free to use the slack channel
even though I didn't.

Kind regards,

Adam




On Mon, 21 Feb 2022, 10:40 PM Kaj Wiik,  wrote:

>
>
> On 21/02/2022 22:15, Morag Brown wrote:
>
> > While I think most people on this mailing list can certainly share your
> > frustrations with getting the toolflow to work, I think it's important
> to
> > emphasize that this is an open collaboration that many contribute to
> without it
> > strictly speaking being part of their critical work duties.
>
> I certainly understand that and personally I have been trying to
> contribute by
> doing pull requests, trying to ask well formulated questions and sharing
> my
> successes and solutions. And I have done it outside of my work duties to
> support
> a project that I find important. So I have been there and done that.
>
> > As such, writing and maintaining documentation and testing toolflow
> > functionality across all configurations of operating systems and
> software
> > versions is difficult. However we do try our best at these things, and
> > definitely try to help however we can whenever someone faces an issue
> that has
> > either not been documented or even just not yet encountered by
> developers.
> > The PRP stuff was presented at the 2021 CASPER conference, and has yet
> to make
> > it's way into our docs. But as Jonathon has said, we do have a CASPER
> slack,
> > with a PRP channel, and other channels where more help could potentially
> be found.
>
> What I find very disturbing is that there seems to be a working solution
> that
> would have saved months of time and that is known to many but no-one cared
> to
> mention it before.
>
> Is this a really an _open_ _collaboration_?
>
> Kaj
>
> --
> 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/491ca6ed-b73d-cce9-f0c7-e1808b87d33b%40utu.fi
> .
>

-- 
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%3DnH63tAw7tuX59_wL-8a3Xxqf_v8gT04oLq1QqddVyN-XA%40mail.gmail.com.

Re: [casper] Different Software Versions

[Adam Isaacson]

Hi Kaj and Wesley,

You are both right. The Python upgrades have proved a problem and it would
help to list it in the documents.

The requirements.txt can be too general though using versions "<" or ">".

RFSOC is a new development, so I understand there could be bugs. I was more
referring to the older developments. My email was not aimed at anyone
particular :). I learnt my lesson over the years (or maybe I didn't) and
with SKARAB.

Kind regards,

Adam



On Mon, 21 Feb 2022, 1:32 PM Wesley New,  wrote:

> Hi Kaj,
>
> There is generally a requirements.txt in the root of the mlib_devel which
> should list any python dependencies and appropriate versions. I am not sure
> how well this is kept uptodate though.
>
> Regards
>
> Wes
>
>
>
> On Mon, Feb 21, 2022 at 1:24 PM Kaj Wiik  wrote:
>
>> Hi Adam,
>>
>> I am sorry but I missed your reply too.
>>
>> The reason for us to experiment with different versions was to get RFSoC
>> (specifically ZCU111) stuff working (by following the documentation in
>> https://github.com/casper-astro/tutorials_devel/blob/master/docs/tutorials/rfsoc/tut_getting_started.md
>> ). If I understand correctly, the original toolflow in the casper repo does
>> not (yet) support RFSoC's?
>>
>> We will now try to get the Ubuntu 20.04 based versions working, thanks
>> Mitch, because Ubuntu 20.04 will be supported longer (perhaps until my
>> retirement ;-)). I still have the 18.04 container so I could try out your
>> repo too.
>>
>> I think one of the main problems is that after one group gets everything
>> working, there will be Python package upgrades that later installers get
>> (without intention) and suddenly the toolflow is not working anymore. I
>> think it would be very useful if the versions of all Python packages of a
>> working setup would be listed in the documentation.
>>
>> Many thanks to all who support and develop the Casper toolchain, it
>> certainly is not an easy task!
>>
>> Best regards,
>> Kaj
>>
>> On 2/21/22 12:22, Adam Isaacson wrote:
>> > Hi Casperites,
>> >
>> > I hope you are well. I have been reading the mail list and there are
>> lots of queries about which version of Ubuntu, Python, Matlab and Simulink.
>> >
>> > We have documented this quite well on our Casper website, but I have
>> noticed that some people try it on Windows, different versions and expect
>> it to work first time around.
>> >
>> > My honest opinion is that the odds of this working would be slight. My
>> advice is to rather stick to the mentioned versions, as those have been
>> tested. You are welcome to try new versions, but my feeling is that it
>> mostly won't work. My advice is to stick to the software versions.
>> >
>> > SARAO and CASPER spend a lot of time testing with specific versions. We
>> then move onto other projects and move onto newer software versions. This
>> is more efficient in my opinion. If there is a major bug then we upgrade.
>> >
>> > Kind regards,
>> >
>> > Adam
>> >
>> > --
>> > 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 > 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%3DnEv0CTDQsW4bpaTXk-6ZB%3D5nsPnb_7%2B5%2BO1Bk8ECwXBxQ%40mail.gmail.com
>> <
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnEv0CTDQsW4bpaTXk-6ZB%3D5nsPnb_7%2B5%2BO1Bk8ECwXBxQ%40mail.gmail.com?utm_medium=email_source=footer
>> >.
>>
>> --
>> 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/29234ed5-7d35-7d5b-2d62-c59198839b56%40utu.fi
>> .
>>
> --
> 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/ca

[casper] Different Software Versions

[Adam Isaacson]

Hi Casperites,

I hope you are well. I have been reading the mail list and there are lots
of queries about which version of Ubuntu, Python, Matlab and Simulink.

We have documented this quite well on our Casper website, but I have
noticed that some people try it on Windows, different versions and expect
it to work first time around.

My honest opinion is that the odds of this working would be slight. My
advice is to rather stick to the mentioned versions, as those have been
tested. You are welcome to try new versions, but my feeling is that it
mostly won't work. My advice is to stick to the software versions.

SARAO and CASPER spend a lot of time testing with specific versions. We
then move onto other projects and move onto newer software versions. This
is more efficient in my opinion. If there is a major bug then we upgrade.

Kind regards,

Adam

-- 
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%3DnEv0CTDQsW4bpaTXk-6ZB%3D5nsPnb_7%2B5%2BO1Bk8ECwXBxQ%40mail.gmail.com.

Re: [casper] Simulink window does not open when Matlab is started by startsg

[Adam Isaacson]

Hi Kaj and Jack,

I am not sure if this helps or not. We use Ubuntu 18.04LTS, Vivado 2021.1
and Matlab R2019a. Sys generator is no longer available. It now uses the
Xilinx add on Model Composer. Wesley created a "startmc" file to fix this.
I know my startsg did not work. Try our repo:
www.github.com/ska-sa/mlib_devel (alveo_u50) branch, I think.

Try it and let me know. Ask Wesley for help if not. If this has nothing to
do with the issue then my apologies and sorry for leading you astray.

Kind regards,

Adam

On Sat, 12 Feb 2022, 4:26 PM Kaj Wiik,  wrote:

> Hi,
>
> I installed kde-full but the error stays, maybe I should downgrade to
> 18.04...
>
> On the other hand, if that Simulink window is good enough for you, then
> for sure
> it is good enough for me :-D! I guess that error message does not affect
> to
> other functionalities...
>
> Thanks,
> Kaj
>
>
> On 12/02/2022 15:28, Jack Hickish wrote:
> > I think that's pretty much what mine looks like. :)
> >
> > On Sat, 12 Feb 2022 at 13:08, Kaj Wiik  > > wrote:
> >
> > Hi Jack,
> >
> > It indeed might be the fastest way to follow your setup. Screenshot
> of the
> > 'simulink' window I get is attached.
> >
> > Thanks,
> > Kaj
> >
> >
> >
> > On 12/02/2022 14:47, Jack Hickish wrote:
> >  > Hi Kaj,
> >  >
> >  > Not sure whether it is at all relevant, but these days when faced
> with
> > any sort
> >  > of probably OS/sysgen/MATLAB version combination issues I start
> > by installing
> >  > the kde-full package.
> >  >
> >  > I'll also add that I'm running MATLAB 2019a / Vivado 2020.2
> without issue on
> >  > Ubuntu 18.04.
> >  >
> >  > Cheers
> >  > Jack
> >  >
> >  > On Sat, 12 Feb 2022 at 12:23, Kaj Wiik  > 
> >  > >> wrote:
> >  >
> >  > Hmm, it seems that a window *is* opened but it is totally
> different
> > than the
> >  > normal Simulink window (looks oldfashioned with large fonts).
> Still,
> > ideas how
> >  > to get the 'correct' GUI window are welcomed.
> >  >
> >  > Thanks,
> >  > Kaj
> >  >
> >  > On 12/02/2022 11:35, Kaj Wiik wrote:
> >  >  > Hi Casperites,
> >  >  >
> >  >  > I am trying to install the RFSoC toolchain following the
> > instructions from
> >  >  >
> >  >
> >
> https://github.com/casper-astro/tutorials_devel/blob/master/docs/tutorials/rfsoc/tut_getting_started.md
> > <
> https://github.com/casper-astro/tutorials_devel/blob/master/docs/tutorials/rfsoc/tut_getting_started.md
> >
> >  >
> >   <
> https://github.com/casper-astro/tutorials_devel/blob/master/docs/tutorials/rfsoc/tut_getting_started.md
> <
> https://github.com/casper-astro/tutorials_devel/blob/master/docs/tutorials/rfsoc/tut_getting_started.md
> >>
> >  >
> >  >  >
> >  >  >
> >  >  > I am using Ubuntu 20.04 LTS, Vivado 2020.2, and Matlab
> 2019a (with
> > Simulink)
> >  >  >
> >  >  > The problem is that Simulink window appears if Matlab is
> started
> > in normal
> >  >  > environment, in python3 venv but _not if Matlab is started
> by
> > startsg_.
> >  >  >
> >  >  > The error message is:
> >  >  >
> -
> >  >  > Starting Vivado/Vitis Sysgen
> >  >  > Type xlDoc to open the Xilinx System Generator help
> documentation.
> >  >  > Type demo blockset xilinx to view the demos available for
> Xilinx
> > System
> >  > Generator.
> >  >  > Tip of the day: Learn more about Support for multiple
> clock domains.
> >  >  >
> >  >  >  >> simulink
> >  >  > Warning: MATLABWindow application failed to launch. Unable
> to
> > launch the
> >  >  > MATLABWindow application
> >  >  >  > In sltemplate.ui.StartPage/showWithFallback
> >  >  >In sltemplate.ui.StartPage.show
> >  >  >
> >  >  >  >> cd(matlabroot)
> >  >  >  >> ! bin/glnxa64/MATLABWindow
> >  >  > bin/glnxa64/MATLABWindow: symbol lookup error:
> >  >  > /lib/x86_64-linux-gnu/libgnutls.so.30: undefined symbol:
> > __gmpz_limbs_write
> >  >  >
> --
> >  >  >
> >  >  > I have tried to play with different libgmp versions as
> suggested
> > by some
> >  >  > Matlab/Xilings mailing lists but nothing has worked.
> >  >  >
> >  >  > I ask in this list because this seems to be a casper
> toolflow related
> >  > problem.
> >  >  >
> >  >  > My startsg.local is
> >  >  >
> --
> >  >  > export 

Re: [casper] Toolflow problems and a fix

[Adam Isaacson]

Thanks Kaj,

Good luck. Our Alveo tool flow will use Ubuntu 18.04.5 LTS and Matlab
R2021a for now.

Kind regards,

Adam

On Thu, 03 Feb 2022, 12:34 PM Kaj Wiik,  wrote:

> Hi Adam,
>
> Yes, indeed wheel stuff does not seem to affect anything. I made a pull
> request
> and it was merged.
>
> I am currently installing an Ubuntu 20.04 LXD container for RFSoC
> experiments as
> it is supported by that part of the toolchain (see:
>
> https://github.com/casper-astro/tutorials_devel/blob/master/docs/tutorials/rfsoc/tut_getting_started.md),
>
> let's see how it works out :-).
>
> Thanks,
> Kaj
>
>
> On 03/02/2022 07:12, Adam Isaacson wrote:
> > Hi Kaj,
> >
> > Thanks for this. Yes, my wheels fail now, but doesn't seem to be an
> issue. I
> > think Ubuntu 16.04.5 LTS has some python updates, which cause this
> issues. I
> > guess as long as we keep track then this is fine.
> >
> > Creating firmware and installs that work for everyone does come with its
> issues.
> >
> > Well spotted.
> >
> > Kind regards,
> >
> > Adam
> >
> > On Fri, 21 Jan 2022, 5:01 PM Kaj Wiik,  kjw...@utu.fi>> wrote:
> >
> > Hi Casperites!
> >
> > We had a strange problem that when we installed a toolflow for a new
> user,
> > it failed. An untouched original toolflow worked fine.
> >
> > It seems that there is a new version of PyYAML that is not
> compatible with
> > the toolflow (or other packages) and it must be pinned. Here's our
> fixed
> > requirements.txt:
> >
> > numpy<1.19
> > colorlog
> > PyYAML<=5.4.1
> > pyaml
> > odict
> > #xml2vhdl requirements
> > lxml
> > -e
> > git+
> http://github.com/casper-astro/xml2vhdl#egg=xml2vhdl_ox-0.2.2-py3.5.egg=scripts/python/xml2vhdl-ox
> > <
> http://github.com/casper-astro/xml2vhdl#egg=xml2vhdl_ox-0.2.2-py3.5.egg=scripts/python/xml2vhdl-ox
> >
> >
> >
> > We have also been getting an error like "Failed building wheel for
> odict
> > Failed building wheel for PyYAML". It doesn't seem to be causing any
> problem
> > but installing the 'wheel' package *before* the requirements fixes
> that.
> >
> > I hope this helps...
> >
> > Cheers,
> > Kaj
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "casper@lists.berkeley.edu <mailto: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
> > <mailto:casper%2bunsubscr...@lists.berkeley.edu>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/7340a957-263f-9553-cc11-64cc1834e0ce%40utu.fi
> > <
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/7340a957-263f-9553-cc11-64cc1834e0ce%40utu.fi
> >.
> >
> > --
> > 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
> > <mailto: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%3DnEPiT6Cqc5rzBv6Yr1jNYF9fCqBhZm0hSv6pkCJLADC_A%40mail.gmail.com
> > <
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnEPiT6Cqc5rzBv6Yr1jNYF9fCqBhZm0hSv6pkCJLADC_A%40mail.gmail.com?utm_medium=email_source=footer
> >.
>
> --
> 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/8ff5aa7f-af3b-c6d1-674f-4470ef095951%40utu.fi
> .
>

-- 
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%3DnEDUHvNtuk4PPqxK9cb72aujMksZcC5ACPH%3DJqFbbH5%2Bg%40mail.gmail.com.

Re: [casper] Toolflow problems and a fix

[Adam Isaacson]

Hi Kaj,

Thanks for this. Yes, my wheels fail now, but doesn't seem to be an issue.
I think Ubuntu 16.04.5 LTS has some python updates, which cause this
issues. I guess as long as we keep track then this is fine.

Creating firmware and installs that work for everyone does come with its
issues.

Well spotted.

Kind regards,

Adam

On Fri, 21 Jan 2022, 5:01 PM Kaj Wiik,  wrote:

> Hi Casperites!
>
> We had a strange problem that when we installed a toolflow for a new user,
> it failed. An untouched original toolflow worked fine.
>
> It seems that there is a new version of PyYAML that is not compatible with
> the toolflow (or other packages) and it must be pinned. Here's our fixed
> requirements.txt:
>
> numpy<1.19
> colorlog
> PyYAML<=5.4.1
> pyaml
> odict
> #xml2vhdl requirements
> lxml
> -e git+
> http://github.com/casper-astro/xml2vhdl#egg=xml2vhdl_ox-0.2.2-py3.5.egg=scripts/python/xml2vhdl-ox
>
>
> We have also been getting an error like "Failed building wheel for odict
> Failed building wheel for PyYAML". It doesn't seem to be causing any
> problem but installing the 'wheel' package *before* the requirements fixes
> that.
>
> I hope this helps...
>
> Cheers,
> Kaj
>
> --
> 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/7340a957-263f-9553-cc11-64cc1834e0ce%40utu.fi
> .
>

-- 
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%3DnEPiT6Cqc5rzBv6Yr1jNYF9fCqBhZm0hSv6pkCJLADC_A%40mail.gmail.com.

Re: [casper] RE: Red Pitaya programming/clocking issue?

[Adam Isaacson]

Hi Jeffrey,

Thanks, this looks spot on.

Kind regards,

Adam

On Thu, 03 Feb 2022, 12:12 AM 'Kobesky, Jeffrey CIV USN NRL ()
Washington DC (USA)' via casper@lists.berkeley.edu, <
casper@lists.berkeley.edu> wrote:

> Hello Nitika,
>
>
>
> I’m not using conda environment so I can’t comment on that,  but:
>
>
>
> 1.  To clear the “Odd?” problem I ssh’d into red pitaya and added
> “127.0.0.1 localhost” line to etc/hosts on red pitaya.
>
>
>
> 3.  To clear the “value seems to also be varying rapidly rather than
> incrementing steadily as expected” problem I updated casperfpga from
> version 0.1.1 to 0.4.4.  This can be done by doing:
>
>
>
> ~/casperfpga$ sudo pip install -r requirements
>
> ~/casperfpga$ sudo pip install .
>
>
>
> instead of:
>
>
>
> ~/casperfpga$ sudo pip install -r requirements
>
> ~/casperfpga$ sudo pip install casperfpga
>
>
>
> i.e., doing it the first way installs from the local repo instead of the
> remote repo which I think contains an outdate version of casperfpga.  You
> can verify your version is ipython by:
>
>
>
> In[x] casperfpga.--version--   (not sure I have the syntax exactly right)
>
>
>
> Hope that helps -- Jeff
>
>
>
> [image: cid:image001.png@01D1BCE1.A1D37B70]
>
> *Jeffrey Kobesky *
>
> Electronics Engineer
>
> Naval Research Laboratory
>
> Information Technology Division Code 
>
> Bldg 1   Room 222
>
> 4555 Overlook Ave SW
>
> Washington, DC  20375
>
> Office 202.404.7109Mobile 443.243.1554
>
> jeffrey.kobe...@nrl.navy.mil
>
>
>
>
>
> *From:* Yadlapalli, Nitika 
> *Sent:* Tuesday, January 25, 2022 6:34 PM
> *To:* casper@lists.berkeley.edu
> *Subject:* [casper] Red Pitaya programming/clocking issue?
>
>
>
> Hi all!
>
>
>
> I am getting started with casper on a Red Pitaya 125-14. I've been
> following the tutorial about using the ADC/DAC boards (
> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/tut_adc_dac.html)
> and have run into a few issues:
>
>
>
>1. I'm not able to use upload the upload_to_ram_and_program method
>with the .fpg file. I get this "ERROR:10.42.0.69:10.42.0.69: no
>programming informs yet. Odd?" ​and I don't seem to be able to
>activate the tcpborphserver on the red pitaya either to fix it as I've seen
>in a previous archive thread.
>2.
>
>3. I can use the .bof file for programming the red pitaya, so I've
>been moving forward with that. If I try to get the clock speed, however,
>using estimate_fpga_clock(), the output estimated clock speed changes
>wildly with time and is never consistent with the 125 MHz speed I expect.
>Additionally, if I try to read the adc_samp_cnts register as outlined in
>the tutorial, the value seems to also be varying rapidly rather than
>incrementing steadily as expected.
>
>
>
> Has anyone encountered these issues before? I have all the packages
> installed in a conda environment.
>
>
>
>
>
> Best,
>
> Nitika
>
>
>
> Nitika Yadlapalli (she/hers)
>
> PhD Candidate | Astronomy
>
> California Institute of Technology
>
>
>
> --
> 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/BYAPR03MB3752B864ED192276D1253C48DA5F9%40BYAPR03MB3752.namprd03.prod.outlook.com
> 
> .
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/d06885fb859d4869b6d7c058b9234f82%40nrl.navy.mil
> 
> .
>

-- 
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%3DnGTPneYuc%2BF1UpPFzekm-1V6d807SndKj6TeYr-REvFMA%40mail.gmail.com.

Re: [casper] truly spectacular!

[Adam Isaacson]

Hi Jonathan and others,

A great team effort for all of us. CASPER played a huge role. Well done to
the whole community.

Kind regards,

Adam

On Wed, 02 Feb 2022, 3:33 AM 'Jonathan Weintroub' via
casper@lists.berkeley.edu,  wrote:

> https://arxiv.org/pdf/2201.10541.pdf
>
>
> https://www.nytimes.com/2022/01/31/science/milky-way.html?auth=login-email=email
>
> Well done SARAO and CASPER and all involved.
>
> Jonathan
>
>
>
> --
> 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/932D6C79-7003-449E-9C85-3DAE86C8F3A2%40cfa.harvard.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%3DnE_7xqzcug1%3Dsu7fsL9_%3Dk8jVF4ypfE2V_e9p36QDpTPg%40mail.gmail.com.

Re: [casper] CASPER Hardware page showing 404 error

[Adam Isaacson]

Hi Indrajit,

Please try this for hardware - it works:

https://github.com/casper-astro/casper-hardware#casper-hardware

I can confirm that I have the same issue with the ADC link. There is
definitely an issue when it comes to all the ADC modules - the only ADC
module I can get to is this:

https://github.com/casper-astro/casper-hardware/tree/master/Mezzanine_Boards/ADCs/ADC16x250-8

I think what is needed is to copy all the old ADC wiki documents to this
folder (Mezzanine_Boards/ADCs). @Jonathon Kocz  when you
are back from leave then you can point out where these old files are
located and we can copy it over, thanks. I suspect they are located in the
old wiki and haven't been copied over. I tried looking at older commits,
but I can't seem to find them - haven't tried very hard.

Season's greetings to all of you too - until next year. Stay safe!

Kind regards,

Adam



On Fri, Dec 24, 2021 at 6:48 AM Indrajit Barve  wrote:

> Dear Casper team,
>
> The link to the following hardware page is showing error 404 on github
> webpage:
> https://github.com/casper-astro/casper-hardware/blob/master/ADC2x400-14
> and old CASPER : http://casper.astro.berkeley.edu/wiki/Hardware
> Any updates on that.
>
> Season's Greetings
>
> Thanks and regards
> Indrajit
>
> --
> 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/999A9B18-B44E-49FC-8349-01D39A4DC55D%40getmailspring.com
> 
> .
>

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

Re: [casper] Calculating Arctan on FPGA

[Adam Isaacson]

Dear Eoin,

It has been a while since I played with the cordic algorithm. I used this
for Radar signal processing in the day. The Xilinx should work, but if not
try opencores.org and look for arithmetic operations. Refer to
https://opencores.org/projects/cf_cordic. I can't remember the exact Cordic
algorithm I used back then, but it was from Opencores and it did work well
on the Altera FPGAs.

Just remember that you will need to properly pipeline the CORDIC function
i.e. it will take longer than 1 clock cycle for the data to be valid. I
think I had 4 or 5 cycle pipeline delay.

I hope this helps!

Kind regards,

Adam



On Mon, Dec 13, 2021 at 2:55 PM baldwin  wrote:

> Hi Guys,
>
> Quick question; I'm just wondering what is the best way to calculate
> arctan on the FPGA? I am currently using the Xilinx CORDIC block to take
> I and Q and use them to calculate phase, but have found this to give
> unreliable data. While it sometimes gives out the correct phase value,
> it often just gives completely nonsensical results. Just wondering if
> anybody else has ever had similar issues.
>
> All the best,
>
> Eoin.
>
> --
> 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/6a1e1ff7f781ec963db9c826b973adec%40cp.dias.ie
> .
>

-- 
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%3DnGkhwS19ciLM6Lv8WdqWLnDKk%2B3JTyV6b%2BwqAP5z-XZwg%40mail.gmail.com.

Re: [casper] Synchronize a cluster of Red Pitayas using CASPER

[Adam Isaacson]

Hi Stefan,

Yes, that is correct. The changes that you make to myproj,xpr will be
overwritten should you rerun the toolflow. However, if you make the changes
in the file locations that Jack and I showed then it won't. Good luck!

Kind regards,

Adam

On Wed, Nov 3, 2021 at 4:23 PM Haensel, Stefan 
wrote:

> Hi Adam and hi Jack,
>
>
>
> Adding the PINs and changing the input of the MMCM in the red_pitaya.v
> file sounds doable.
>
> Maybe I start with the “myproj.xpr” file. But I assume, that the changes
> in the myproj.xpr file will not exists anymore once I rerun the workflow.
>
>
>
> It will talk some time until I will get a running project, but I will let
> you know, how I solved it or ask further questions, if I have trouble.
>
>
>
> Best Regards,
>
> Stefan
>
>
>
>
>
> *Von:* Adam Isaacson 
> *Gesendet:* Mittwoch, 3. November 2021 14:03
> *An:* Casper Lists 
> *Betreff:* Re: [casper] Synchronize a cluster of Red Pitayas using CASPER
>
>
>
> Hi Jack and Stefan,
>
>
>
> I am not sure if we ever used the SATA connector or rather my memory
> thinks not. On top of what Jack has suggested then you will also need to
> add the SATA pin outs to the platform yaml file below - you will need to
> add the pins of choice here, otherwise the generated top.v file won't
> connect the top level pins to the infrastructure:
>
>
>
>
> https://github.com/casper-astro/mlib_devel/blob/390b7c262f0f7418c45bfb98f5aa969a0a432564/jasper_library/platforms/red_pitaya_14.yaml
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcasper-astro%2Fmlib_devel%2Fblob%2F390b7c262f0f7418c45bfb98f5aa969a0a432564%2Fjasper_library%2Fplatforms%2Fred_pitaya_14.yaml=04%7C01%7Cstefan.haensel%40siemens.com%7C777deb4e80334e267d8c08d99ec991e9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637715412329167059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=rOW94tleZBFhHApyGgVHqbbhAF%2FNymvngrdtlRqV8Mc%3D=0>
>
>
>
> I assume you are using the Red Pitaya 14 bit DAC and ADC since you have
> the version with the SATA interface? If you are using anything else then
> there will be other modifications to be made e.g. making provision for the
> 16 bit ADC.
>
>
>
> This may also help - explanation of the Red Pitaya hardware:
>
>
>
>
> https://github.com/casper-astro/casper-hardware/blob/master/FPGA_Hosts/RED_PITAYA/README.md
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcasper-astro%2Fcasper-hardware%2Fblob%2Fmaster%2FFPGA_Hosts%2FRED_PITAYA%2FREADME.md=04%7C01%7Cstefan.haensel%40siemens.com%7C777deb4e80334e267d8c08d99ec991e9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637715412329167059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=9Wls1uj4%2BR0X%2B5mxPcdfsSCNyIObZXe38Rcghnihlgc%3D=0>
>
>
>
> These are definitely the main files you will need to change the MMCM
> parameters to produce a clock frequency of your choice and route out the
> synchronised clock. Good luck and feel free to use our slack group
> for support - invite below!
>
>
>
>
> https://join.slack.com/t/casper-astro/shared_invite/zt-wmdj9maf-Mlp_98lQtzjA1n1Be~5oOA
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjoin.slack.com%2Ft%2Fcasper-astro%2Fshared_invite%2Fzt-wmdj9maf-Mlp_98lQtzjA1n1Be~5oOA=04%7C01%7Cstefan.haensel%40siemens.com%7C777deb4e80334e267d8c08d99ec991e9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637715412329177019%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=bOFtwxYIAuAuLtxi54a0yPP13dwCpzwiDEONJfFyEzo%3D=0>
>
>
>
> Kind regards,
>
>
>
> Adam
>
>
>
> On Wed, Nov 3, 2021 at 2:39 PM Jack Hickish  wrote:
>
> Hi Stefan,
>
> Sounds fun! Depending what exactly you need to mess with you might
> need to dig around a bit, but as a starting point -- this is where the
> main RP infrastructure is instantiated:
>
>
> https://github.com/casper-astro/mlib_devel/blob/390b7c262f0f7418c45bfb98f5aa969a0a432564/jasper_library/yellow_blocks/red_pitaya.py#L75
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcasper-astro%2Fmlib_devel%2Fblob%2F390b7c262f0f7418c45bfb98f5aa969a0a432564%2Fjasper_library%2Fyellow_blocks%2Fred_pitaya.py%23L75=04%7C01%7Cstefan.haensel%40siemens.com%7C777deb4e80334e267d8c08d99ec991e9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637715412329186968%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=btWXGRMMY4U3VDlesWrNUuuOYMF2aw0LT1oxfUiiKXk%3D=0>
>
> That python file also controls what external pins get hooked up where,
> so you mi

Re: [casper] Synchronize a cluster of Red Pitayas using CASPER

[Adam Isaacson]

Hi Jack and Stefan,

I am not sure if we ever used the SATA connector or rather my memory thinks
not. On top of what Jack has suggested then you will also need to add the
SATA pin outs to the platform yaml file below - you will need to add the
pins of choice here, otherwise the generated top.v file won't connect the
top level pins to the infrastructure:

https://github.com/casper-astro/mlib_devel/blob/390b7c262f0f7418c45bfb98f5aa969a0a432564/jasper_library/platforms/red_pitaya_14.yaml

I assume you are using the Red Pitaya 14 bit DAC and ADC since you have the
version with the SATA interface? If you are using anything else then there
will be other modifications to be made e.g. making provision for the 16 bit
ADC.

This may also help - explanation of the Red Pitaya hardware:

https://github.com/casper-astro/casper-hardware/blob/master/FPGA_Hosts/RED_PITAYA/README.md

These are definitely the main files you will need to change the MMCM
parameters to produce a clock frequency of your choice and route out the
synchronised clock. Good luck and feel free to use our slack group
for support - invite below!

https://join.slack.com/t/casper-astro/shared_invite/zt-wmdj9maf-Mlp_98lQtzjA1n1Be~5oOA

Kind regards,

Adam

On Wed, Nov 3, 2021 at 2:39 PM Jack Hickish  wrote:

> Hi Stefan,
>
> Sounds fun! Depending what exactly you need to mess with you might
> need to dig around a bit, but as a starting point -- this is where the
> main RP infrastructure is instantiated:
>
>
> https://github.com/casper-astro/mlib_devel/blob/390b7c262f0f7418c45bfb98f5aa969a0a432564/jasper_library/yellow_blocks/red_pitaya.py#L75
>
> That python file also controls what external pins get hooked up where,
> so you might have to change various bits of it.
>
> which instantiates the sources
>
>
> https://github.com/casper-astro/mlib_devel/blob/master/jasper_library/hdl_sources/infrastructure/red_pitaya.v
> and
>
> https://github.com/casper-astro/mlib_devel/blob/master/jasper_library/hdl_sources/infrastructure/red_pitaya.tcl
>
> Does modifying these get you where you need to be?
>
> Of course, there is probably a  "proper" way to do this, which might
> involve doing something like adding a "sata_clk" input to the Red
> Pitaya platform block "clock sources" options, and carrying the
> parameterization through the build chain.
>
> For starters, you could also open the
> /myproj/myproj.xpr vivado project and modify it as
> per the guide you linked, rather than trying to mess with the toolflow
> straight out the gate.
>
> I'm not wildly familiar with the RP platform, so maybe someone else
> has more wisdom to share.
>
> Cheers
> Jack
>
> On Wed, 3 Nov 2021 at 11:34, Haensel, Stefan 
> wrote:
> >
> > Hello,
> >
> > I try to synchronize several Red Pitayas (RPs) to the same clock. For
> that RP has a SATA connector to hand over the clock to the next RP as
> written here:
> > https://www.koheron.com/blog/2016/11/29/red-pitaya-cluster
> >
> > For that I need to change the PLL of the slave RPs. Is there somewhere a
> documentation, which describes how to change IP blocks? How is the PLL
> generated right now with the CASPER workflow?
> >
> > Is it possible to open a PLL wizard and just change the settings or can
> I supply a variable, that controls the phase shift of a mixed-mode clock?
> >
> > Thanks,
> > Stefan
> >
> >
> >
> > --
> > 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/AM8PR10MB42747E1BA98B233BAF7041AD828C9%40AM8PR10MB4274.EURPRD10.PROD.OUTLOOK.COM
> .
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSmaHETLNEykuoYh9GMSkKuxU4%3DD-4WOvkzk-h30a1oSQg%40mail.gmail.com
> .
>

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

Re: [casper] HBM memory

[Adam Isaacson]

Hi John, Jack, Benjamin and Mitch,

Thanks for all this information. I was just thinking of your RFSOC
parameterized yellow block yesterday Mitch. I am happy to have your
expertise too. We are not using Vitis for now (we are creating our own DFX
partition/static shell), but we will have the capability to do so in the
future.

John, we are also using the XDMA for control messages. We are using the
100GbE core for our AXI streaming for now - tested at 98.8Gbps (not with
our tool flow setup yet) in its own project. I prefer to keep data and
control separate for debugging, unlike SKARAB.

I will be in touch. Thanks for sparking all this interest, Jack.

Kind regards,

Adam



On Wed, 06 Oct 2021, 4:48 AM Mitch Burnett,  wrote:

> Hi Jack, Adam, Benjamin,
>
> I hope you do not mind me chime in a bit on the block diagram/IPI/RTL
> discussion a bit. As you point out Jack, handling IPI/block designs in the
> toolflow was clunky. But, adding RFSoC to the toolflow to fully support the
> platform for any board with the part and add the RFDC yellow block required
> IPI and Vitis. I believe that the way this was addressed removes much of
> that clunkiness that also provides a a general reuse framework for the
> development of an HBM yellow block and any other IP that we may want to
> support that is best targeted by that flow.
>
> A little about how this is done and what it looks like: A block design is
> created and persistent through the life time of the middleware stage of the
> toolflow. This allows yellow blocks to now access the block design,
> instance the target IP, apply parameters, and expose its interface to the
> rest of casper and the design. Collecting parameters form the mask and
> applying them to IPI is done by a mapping or proxy-like object approach
> were the parameters presented/gathered by simulink are parsed into a python
> class that the yellow block can use as it needs to make its decisions but
> is also automatically parsed out to create the required tcl command for the
> IPI portion of the design. To support this there are added methods to
> follow much of what was already a familiar way these generator objects
> worked to hopefully provide a consistent developer framework. From here,
> supporting Vitis extended off this and works very similar by adding the
> required classes/methods but also following other conventions in the
> toolflow that make it familiar and extendable.
>
> If you think this may help you I would be interested in hearing your
> thoughts and am happy to get together to go over more of the details and
> help in any way I can.
>
> Best,
>
> Mitch
>
> On Oct 5, 2021, at 12:02 PM, Adam Isaacson  wrote:
>
> Hi Benjamin and Jack,
>
> Nice to hear from you Benjamin :). Yes, I agree that IPI is much easier to
> use than RTL. We are targeting the toolflow to generate a Block Diagram
> with the HBM integrated within it. The idea is to connect and test in
> Vivado first.
> Then create a tcl script based on the block diagram and then get the
> toolflow to generate the tcl script for us. We will need to parameterise
> our yellow block to be inline with the IPI generation, so that is
> cumbersome, but once it is
> finalised then it won't be too much effort - I hope!
>
> I will definitely be in touch. Thanks, Benjamin, this is useful
> information. What were you using the HBM for? Are you continually writing
> and reading? Are you using Random memory access? Are you using
> sequential memory access? How are you testing the HBM?
>
> Kind regards,
>
> Adam
>
> On Tue, Oct 5, 2021 at 12:55 PM Jack Hickish 
> wrote:
>
>> Thanks Benjamin -- I've had a look at the IPI stuff and it seems like it
>> should be straightforward to use. I just find dealing with IPI in the
>> toolflow much clunkier than RTL. But between your work and Adam/Grant's I'm
>> sure it shouldn't take too long to get something working.
>> I hadn't thought about the XDMA integration -- I don't really have a
>> requirement for that but i can think of some handy use cases. Thanks for
>> bringing it to my attention.
>>
>> Cheers
>> Jack
>>
>> On Tue, 5 Oct 2021 at 05:41, Benjamin H Hlophe 
>> wrote:
>>
>>> Hi Adam,
>>>
>>> I found its much easier using IP Integrator to use the HBM (It has a lot
>>> of easier configuration on IPI).
>>>
>>> I did a design connecting the HBM to PCIe on the VCU128.
>>>
>>> Without a single line of HDL code just configuring the IP Integrator and
>>> the memory map.
>>>
>>> It works very well also Xilinx has the PCIe drivers for bridging the HBM
>>> to be visible to the XDMA or QDMA.
>>>
>>> <55237d0c-db3d-4

Re: [casper] HBM memory

[Adam Isaacson]

Great, I will be in touch :).

Kind regards,

Adam

On Mon, 04 Oct 2021, 10:10 PM Jack Hickish,  wrote:

> That would be spectacular!
>
> Thanks Adam!
>
> On Mon, 4 Oct 2021, 21:06 Adam Isaacson,  wrote:
>
>> Hi Jack,
>>
>> This is exactly what I have been tasked with. I have a meeting with Grant
>> Hampson (CSIRO) who has the HBM working in RTL to find out more information
>> on the 15th Oct.
>>
>> Maybe we could work together on this?
>>
>> Kind regards,
>>
>> Adam
>>
>>
>>
>> On Mon, 04 Oct 2021, 8:59 PM Jack Hickish,  wrote:
>>
>>> Hi CASPERites,
>>>
>>> Hope everyone is keeping well.
>>>
>>> It looks like I'm imminently going to have to dip my toe (and then
>>> probably my entire self) in the world of HBM, in order to make some
>>> reasonably large data transposes / packet construction buffers. (For the
>>> interested, I'm using a VU37P AlphaData ADM-PCIe-9H7).
>>>
>>> Ultimately I'm probably going to try and make a yellow block with an
>>> interface that looks vaguely like a block ram, or the QDR transpose block
>>> of old.
>>>
>>> Before I start, I thought I'd shout out in case anyone had already
>>> looked at making a yellow block like this, and/or felt the urge to share
>>> any of their hard-won HBM wisdom.
>>>
>>> Cheers,
>>>
>>> Jack
>>>
>>> --
>>> 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/CAG1GKS%3Dy5ey26oR-yUe%2BkVKdCqegRV4q7K1dnzgw1WkiqoXCfQ%40mail.gmail.com
>>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKS%3Dy5ey26oR-yUe%2BkVKdCqegRV4q7K1dnzgw1WkiqoXCfQ%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> 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%3DnE7w%2B_GSms43QW_q6FFsZcxLHaw8X7OGVcFByybSA8APg%40mail.gmail.com
>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnE7w%2B_GSms43QW_q6FFsZcxLHaw8X7OGVcFByybSA8APg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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/CAG1GKSmP7sSp%2BQurWFLPJd3yztLUv5PocWtTi65PZ9ZRyA426Q%40mail.gmail.com
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSmP7sSp%2BQurWFLPJd3yztLUv5PocWtTi65PZ9ZRyA426Q%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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%3DnHMaeW593tmCUde4YMdvEpa1UQXdfQ2UmL0jwZZTmCM_w%40mail.gmail.com.

Re: [casper] HBM memory

[Adam Isaacson]

Hi Jack,

This is exactly what I have been tasked with. I have a meeting with Grant
Hampson (CSIRO) who has the HBM working in RTL to find out more information
on the 15th Oct.

Maybe we could work together on this?

Kind regards,

Adam



On Mon, 04 Oct 2021, 8:59 PM Jack Hickish,  wrote:

> Hi CASPERites,
>
> Hope everyone is keeping well.
>
> It looks like I'm imminently going to have to dip my toe (and then
> probably my entire self) in the world of HBM, in order to make some
> reasonably large data transposes / packet construction buffers. (For the
> interested, I'm using a VU37P AlphaData ADM-PCIe-9H7).
>
> Ultimately I'm probably going to try and make a yellow block with an
> interface that looks vaguely like a block ram, or the QDR transpose block
> of old.
>
> Before I start, I thought I'd shout out in case anyone had already looked
> at making a yellow block like this, and/or felt the urge to share any of
> their hard-won HBM wisdom.
>
> Cheers,
>
> Jack
>
> --
> 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/CAG1GKS%3Dy5ey26oR-yUe%2BkVKdCqegRV4q7K1dnzgw1WkiqoXCfQ%40mail.gmail.com
> 
> .
>

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

[casper] Massive In-Network Processing for the World’s Largest Radio Telescope (SKA-Low)

[Adam Isaacson]

Dear Casperites,

Here is a Xilinx presentation by Dr Grant Hampson  (CSIRO) on the work they
are doing for SKA low - using Alveo U50 cards. You may need to register for
the Xilinx ondemand viewing. Well done to Dr Grant Hampson - this is
impressive. SARAO is doing something similar, but we are integrating with
our CASPER toolflow for now. I will keep you posted.

There are lots of other good presentations ondemand as well, so check it
out!

https://xilinx.cventevents.com/event/f7c4412f-572a-4b8b-b8d0-6b92aae2cf0d/summary

Kind regards,

*Adam Isaacson*
Hardware Manager
South African Radio Astronomy Observatory (SARAO)

Address: 2 Fir Street, Black River Park (North Gate Entrance), Observatory,
Cape Town, 7925
Tel: +27 21 506 7380  | Cell: +27 82 563 9602
Email: aisaac...@sarao.ac.za 
Website: www.sarao.ac.za <http://www.ska.ac.za/>

-- 
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%3DnEjfsug4Gg2Z1S%2BerdhUn3t2AYS25nMBkuSYXaCih81sg%40mail.gmail.com.

Re: [casper] Red Pitaya STEMlab 125-14-Z7020

[Adam Isaacson]

Dear Mutsuo and Sebastian,

Here is the CASPER hardware Red Pitaya board list - we only support 125-10
and the original 125-14. The rest will need to be added, but as Wesley said
we are focusing on the Alveo boards right now. We will gladly assist you if
you wish to target a new board. I would suggest attending the Hardware
Porting Workshop in 2022 if it happens.

https://github.com/casper-astro/casper-hardware/blob/master/FPGA_Hosts/RED_PITAYA/README.md

We never targeted the SATA interface, I don't think so at least.

Kind regards,

Adam

On Mon, Aug 2, 2021 at 1:04 PM Sebastian Antonio Jorquera Tapia <
sebastian.jorqu...@ug.uchile.cl> wrote:

> The old 7010 redpitaya also has sata ports, you could sync several of them
> using that port
> https://www.koheron.com/blog/2016/11/29/red-pitaya-cluster
> But the 7010 redpitaya ADCs uses a crystal as its main clock, so you have
> to move some resistances to feed another clock to the ADCs
> https://redpitaya.readthedocs.io/en/latest/developerGuide/125-14/extADC.html
> So in theory you could share a common clock to the fpga via the sata port
> and then feed it to the adcs.
> btw I havent sync several of those.. We just have one redpitaya and
> successfully feed the ADCs clock with the fpga, but we made that outside
> the casper environment just using vivado. To my knowledge casper dont
> support the modified board.
>
>
>
> El sáb, 31 jul 2021 a las 6:15, IRspec Ogura ()
> escribió:
>
>> Dear Sirs,
>>
>> We are developing an InGaAs SWIR camera and hoping to use SOC-FPGA for
>> related real-time processing
>> in a user frendly manner.
>>
>> I wonder who prepared the elaborate tutorial for Casper project.
>>
>> It will be very nice to get the Casper module for STEMlab 125-14-Z7020
>> and its line by line tutorial.
>> STEMlab 125-14-Z7020 is a Red Pitaya’s new board and it has Sata
>> interface for synchronization.
>> It will save labor and cost to use plural of simple boards rather than
>> make one board more complicated and restrict them to the specific
>> applications.
>>
>> I appreciate any information about Casper and Red pitaya.
>>
>>
>> https://www.redpitaya.com/p76/stemlab-125-14-z7020
>>
>> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html
>>
>> Sincerely,
>>
>> Mutsuo Ogura, Dr. Eng.
>> IRspec Corp.
>> Takezono 2-6-2,
>> Tsukuba, Ibaraki 305-0032
>> E-mail: og...@irspec.com
>> Tel:+81-29-859-6910 Mobile:090-4452-2627
>> Fax: 050-6861-1411
>> http://www.irspec.com/E%20top.html
>>
>> --
>> 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/20210731191524.88CC.33551042%40irspec.com
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAASoV%3DOzT4b6-HM8Bb_RjYeAkZ1Hp33DywwB8sZFAmzoYZuJ6Q%40mail.gmail.com
> 
> .
>

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

[casper] SKARAB and Red Pitaya Builds on Ubuntu 18.04LTS

[Adam Isaacson]

Dear Casperities,

I can't remember if I published anything officially, but I finally
installed my desktop with OS Ubuntu 18.04LTS to work with the current
toolflow and the planned new toolflow. I am about 6 months behind
publishing this, but I can now say that the toolflow for SKARAB and the Red
Pitaya builds fine using Ubuntu 18.04LTS.

I had a few issues with the Python Numpy and Odict wheels failing to
install properly using the pip install,  but this is not needed. Thanks to
my colleague, Morag Brown for providing this info on the wheel installs.

"No issues on 18.04. Python wheels are just an easier way that pip tries to
install things. If it can't build the wheels properly then it defaults to
doing a standard package installation - so as long as it's not complaining
that the packages aren't working, you're good to go :slightly_smiling_face:
"

I hope this helps!

Kind regards,

Adam

-- 
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%3DnGQMenD9Ky6cEe6qq%2B1y7LvTAQ%3DwfkwRTdhOGnxgwwWfw%40mail.gmail.com.

Re: [casper] python version for casperfpga

[Adam Isaacson]

Hi Jeff,

Well done on sorting this out - looking forward to this dark energy sensor
;).

Thanks for sharing these links. Just a reminder, that our toolflow supports
Matlab R2018a. The GUI socket timeout issue is because you are using Matlab
R2019a, I think? If you don't use Matlab R2018a, Vivado 2019.1.1 then you
can run into these issues.

The "no programming informs yet. Odd?" issue has burnt me on the Red Pitaya
boards too. Alexander Raymond from the CfA figured the solution out -
thanks Alex.

Thanks for the useful feedback Jeff!

Kind regards,

Adam


On Tue, 11 May 2021, 2:55 PM 'Kobesky, Jeffrey CIV USN NRL ()
Washington DC (USA)' via casper@lists.berkeley.edu, <
casper@lists.berkeley.edu> wrote:

> Spiro,  Adam,
>
>
>
> Thanks for the info. I’ve successfully programmed Red Pitaya_Tutorial 1,
> orange light is blinking, so now I can move onto dark energy sensors next
> (kidding).  I think my main problem was I did not understand the different
> python environments and how they could be used with the Simulink/Vivado
> toolflow and casperfpga, so the info below definitely helped me.
>
>
>
> Otherwise two specific problems were “GUI socket server timed out” solved
> by this post
> https://www.mail-archive.com/casper@lists.berkeley.edu/msg07886.html and
> “no programming informs yet.  Odd?” solved by adding “127.0.0.1 localhost”
> to /etc/hosts on the RP, per this post
> https://www.mail-archive.com/casper@lists.berkeley.edu/msg07885.html .
>
>
>
> Hope this helps other people just starting out!   – Jeff
>
>
>
> Jeffrey Kobesky
>
> Electronics Engineer, Naval Research Laboratory
>
> O: (202) 404-7109 M: (443) 243-1554
>
> OS:  Pop!_OS 18.04 LTS (derived from Ubuntu 18.04 LTS)
>
> Vivado 19.1.1MATLAB 2018amlib_devel branch:  master
>
> Python 2.7 for casperfpga and 3.6 running in (casper_venv) for toolflow
>
> Devices:  Red Pitaya, SKARAB
>
>
>
>
>
> *From:* Spiro Sarris 
> *Sent:* Wednesday, May 5, 2021 6:55 AM
> *To:* casper@lists.berkeley.edu
> *Subject:* Re: [casper] python version for casperfpga
>
>
>
> Hi Jeff,
>
> I have one more suggestion that might help.  When your python
> installation(s) become more complicated, sometimes the seemingly simple
> command "pip" or "pip3" doesn't do what you expect.  It can install
> packages or search for dependencies in directories that you don't expect
> (not matching the python installation / environment that you intend to
> install packages).  I have found helpful to use the command
>
> $ python -m pip 
>
> instead of
>
> $ pip 
>
>
>
> In my experience, this command format has allowed pip to search
> dependencies and install packages to the intended python (the same python
>  referred to by "python" in the command line).
>
>
>
> Cheers,
>
> Spiro
>
>
>
> On Tue, 2021-05-04 at 22:06 +0200, Adam Isaacson wrote:
>
> Hi Jeff,
>
>
>
> Please see my feedback in red below.
>
>
> 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, May 4, 2021 at 4:34 PM 'Kobesky, Jeffrey CIV USN NRL ()
> Washington DC (USA)' via casper@lists.berkeley.edu <
> casper@lists.berkeley.edu> wrote:
>
> Hello CASPER,
>
>
>
> I thought I had the Python stuff figured out, but turns out I'm completely
> lost.
>
>
>
>
>
> AI: No worries, there is still plenty that I don't understand :).
>
>
>
> I followed the instructions on this page:
> https://casper-toolflow.readthedocs.io/en/latest/src/How-to-install-casperfpga.html
>
>
>
> I did both the upper set of instructions using pip, and the lower set of
> instructions using the "traditional method". Both result in errors in the
> third set of instructions using ipython.  Am I supposed to do these steps
> in the vitual python environment casp-venv, or in non-virtual environment,
> or does it matter.  I've actually tried both, and neither works for me.
>
>
>
>
>
> AI: It all depends on which repo and branch you are using. Maybe specify
> the repo and branch. It looks like you are using casper-astro/casperfpga
> repo, but I could be wrong. There is a python 3 branch, which is not
> supported for the SKARAB and the python 2 branch, which is supported for
> SKARAB and SARAO uses that. Personally, I use a virtual environment (Python
> 3.5) for the toolflow and no virtual environment for casperpfga (python
> 2.7). I haven't tested all the permutations, but I know 

Re: [casper] python version for casperfpga

[Adam Isaacson]

Hi Jeff,

Please see my feedback in red below.

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, May 4, 2021 at 4:34 PM 'Kobesky, Jeffrey CIV USN NRL ()
Washington DC (USA)' via casper@lists.berkeley.edu <
casper@lists.berkeley.edu> wrote:

> Hello CASPER,
>
>
>
> I thought I had the Python stuff figured out, but turns out I'm completely
> lost.
>

AI: No worries, there is still plenty that I don't understand :).

>
>
> I followed the instructions on this page:
> https://casper-toolflow.readthedocs.io/en/latest/src/How-to-install-casperfpga.html
>
>
>
> I did both the upper set of instructions using pip, and the lower set of
> instructions using the "traditional method". Both result in errors in the
> third set of instructions using ipython.  Am I supposed to do these steps
> in the vitual python environment casp-venv, or in non-virtual environment,
> or does it matter.  I've actually tried both, and neither works for me.
>

AI: It all depends on which repo and branch you are using. Maybe specify
the repo and branch. It looks like you are using casper-astro/casperfpga
repo, but I could be wrong. There is a python 3 branch, which is not
supported for the SKARAB and the python 2 branch, which is supported for
SKARAB and SARAO uses that. Personally, I use a virtual environment (Python
3.5) for the toolflow and no virtual environment for casperpfga (python
2.7). I haven't tested all the permutations, but I know that works for me.

>
>
> In the first set of instructions using pip, should I be using pip or pip3?
>

AI: Once again pip is for python 2.7 and above. Pip3 is for python 3.5 and
above. If the branch you are using has "py3" in the name then you will need
pip3. All the other branches use Python 2.7 and so pip is fine.

>
>
> Some possible clues:
>
>
>
> (casper_venv) labrat@pop-os:~$ python --version Python 3.6.9
>
> (casper_venv) labrat@pop-os:~$ pip --version pip 9.0.1 from
> /home/labrat/casper_venv/lib/python3.6/site-packages (python 3.6)
>
> (casper_venv) labrat@pop-os:~$ deactivate labrat@pop-os:~$ python
> --version Python 3.6.9 labrat@pop-os:~$ pip --version pip 9.0.1 from
> /usr/lib/python2.7/dist-packages (python 2.7)
>

AI: These versions should work, but I haven't tested on them. I think my
pip version was 8.1, Python 3.5 and Python 2.7.

>
>
> The closest I got in ipython, I think, yielded this (which is probably
> wrong version, but at least no errors):
>
>
>
> In [1]: import casperfpga
>
>
>
> In [2]: casperfpga.__version__
>
> Out[2]: '0.0+unknown.202105040928'
>

AI: It looked like it has installed correctly. Don't worry too much about
the "unknown" version. We have a ska-sa/casperfpga repo and the branch is
devel. if you install this casperfpga version then you won't see the
"unknown" in the field. I think once we have merged our changes into the
casper-astro/ casperfpga repo then this field will be populated.  Do you
have a board that you can connect to? Have you tried reading and writing
registers? That is the true test.

>
>
> Sorry for the discombobulated post, but I think there must be something
> basic I’m just not understanding.
>

AI: Please also send screen captures of the install errors - helps with the
debugging.

>
>
> Thanks  -- Jeff
>
>
>
> *From:* Adam Isaacson 
> *Sent:* Friday, April 16, 2021 5:18 AM
> *To:* Casper Lists 
> *Subject:* Re: [casper] python version for casperfpga
>
>
>
> Hi Jeff,
>
>
>
> This is great information. We had a recent "wheel" support request and it
> turns out it is not needed, but nice that you figured out how to install
> it. This should be added to our readthedocs.
>
>
>
> Thanks Jeff! Let me know how the SKARAB and Red Pitaya testing goes.
>
>
> 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 15, 2021 at 10:26 PM 'Kobesky, Jeffrey CIV USN NRL ()
> Washington DC (USA)' via casper@lists.berkeley.edu <
> casper@lists.berkeley.edu> wrote:
>
> Hello CASPER,
>
>
>
> FYI, I ran into slight issue “building wheel” during:  (casper_venv)
>  ~/mlib_devel$ pip3 install –r requirements.txt
>
>
>
> See RED text in attached screenshot.  But I believe everything installed,
> even with the two errors.
>
>
>
> Anyway, I believe error was caused because “wheel” was not part of my
> python installation.
>
>
>
> I d

Re: [casper] python version for casperfpga

[Adam Isaacson]

Hi Jeff,

This is great information. We had a recent "wheel" support request and it
turns out it is not needed, but nice that you figured out how to install
it. This should be added to our readthedocs.

Thanks Jeff! Let me know how the SKARAB and Red Pitaya testing goes.

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 15, 2021 at 10:26 PM 'Kobesky, Jeffrey CIV USN NRL ()
Washington DC (USA)' via casper@lists.berkeley.edu <
casper@lists.berkeley.edu> wrote:

> Hello CASPER,
>
>
>
> FYI, I ran into slight issue “building wheel” during:  (casper_venv)
>  ~/mlib_devel$ pip3 install –r requirements.txt
>
>
>
> See RED text in attached screenshot.  But I believe everything installed,
> even with the two errors.
>
>
>
> Anyway, I believe error was caused because “wheel” was not part of my
> python installation.
>
>
>
> I did:  (casper_venv) $ sudo apt install python-wheel-common
>
>
>
> Then re-ran (casper_venv)  ~/mlib_devel$ pip3 install –r requirements.txt
> , no wheel errors.
>
>
>
> Hope this helps someone.  – Jeff
>
>
>
> Jeffrey Kobesky
>
> Electronics Engineer
>
> Naval Research Laboratory
>
> O: (202) 404-7109
>
> M: (443) 243-1554
>
> OS:  Pop!_OS 18.04 LTS (derived from Ubuntu 18.04 LTS)
>
> Vivado 19.1.1
>
> MATLAB 2018a
>
> mlib_devel branch:  master
>
> Python 2.7 and 3.6, running in (casper_venv)
>
> Devices:  Red Pitaya, SKARAB
>
>
>
>
>
> *From:* Adam Isaacson 
> *Sent:* Thursday, April 15, 2021 3:53 AM
> *To:* Casper Lists 
> *Subject:* Re: [casper] python version for casperfpga
>
>
>
> Hi Jeff,
>
>
>
> Well done on solving your problem. I must say I missed the single
> underscore completely :). It is wonderful when casperites solve their own
> problems :).
>
>
>
> Yes, please keep me posted on Pop OS! or Pop!_OS. I had to look that up to
> be honest. I see it is indeed derived from Ubuntu 18.04LTS. If it works
> then we will update the documentation - this is what CASPER is about =
> collaboration!
>
>
>
> Great to have your energies Jeff.
>
>
> 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 14, 2021 at 5:19 PM 'Kobesky, Jeffrey CIV USN NRL ()
> Washington DC (USA)' via casper@lists.berkeley.edu <
> casper@lists.berkeley.edu> wrote:
>
> All good info, please keep hijacking J
>
>
>
> I do want to add to the original post.  I figured out the original error I
> got was because I used single underscores (casperfpga._version_) instead of
> double underscores (casperfpga.__version__) in ipython.  It’s always the
> mundane details that get me.  But now at least I do understand the Python
> virtual environment which I’ve never used before but seems like a good idea.
>
>
>
> Also, Adam, my operating system is Pop OS! 18.04 - which was derived from
> Ubuntu 18.04 - so I’ll report back on the SKARAB/Red Pitaya under that
> operating system.
>
>
>
> Thanks again – jeff.
>
>
>
> Jeffrey Kobesky
>
> Electronics Engineer
>
> Naval Research Laboratory
>
> O: (202) 404-7109
>
> M: (443) 243-1554
>
>
>
> *From:* Adam Isaacson 
> *Sent:* Wednesday, April 14, 2021 4:23 AM
> *To:* Casper Lists 
> *Subject:* Re: [casper] python version for casperfpga
>
>
>
> Hi Jeff and everyone,
>
>
>
> While we are hacking Jeff's thread (apologies, but this will be useful
> info), please note that our toolflow only supports the following Red Pitaya
> devices: STEMlab125-10 (10 bit ADC and DAC) and STEMlab125-14 (14 bit ADC
> and DAC). There are another three Red Pitaya boards that we don't support
> yet - check out:
>
>
>
> 1) CASPER Hardware:
> https://github.com/casper-astro/casper-hardware#casper-hardware
>
> 2) Red Pitaya Hardware comparison:
> https://redpitaya.readthedocs.io/en/latest/developerGuide/125-10/vs.html
>
>
>
> We encourage anyone who would like to add these boards to the toolflow and
> we are happy to support you in the process. I highly recommend attending
> the Hardware Porting Workshops that explain how to use the toolflow for
> development and target new hardware. The next Hardware Porting Workshop is
> likely to be next year, but an email will be sent out with these details
> once defined.
>
>
>
> Just a reminder of our CASPER conference that i

Re: [casper] python version for casperfpga

[Adam Isaacson]

Hi Jeff,

Well done on solving your problem. I must say I missed the single
underscore completely :). It is wonderful when casperites solve their own
problems :).

Yes, please keep me posted on Pop OS! or Pop!_OS. I had to look that up to
be honest. I see it is indeed derived from Ubuntu 18.04LTS. If it works
then we will update the documentation - this is what CASPER is about =
collaboration!

Great to have your energies Jeff.

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 14, 2021 at 5:19 PM 'Kobesky, Jeffrey CIV USN NRL ()
Washington DC (USA)' via casper@lists.berkeley.edu <
casper@lists.berkeley.edu> wrote:

> All good info, please keep hijacking J
>
>
>
> I do want to add to the original post.  I figured out the original error I
> got was because I used single underscores (casperfpga._version_) instead of
> double underscores (casperfpga.__version__) in ipython.  It’s always the
> mundane details that get me.  But now at least I do understand the Python
> virtual environment which I’ve never used before but seems like a good idea.
>
>
>
> Also, Adam, my operating system is Pop OS! 18.04 - which was derived from
> Ubuntu 18.04 - so I’ll report back on the SKARAB/Red Pitaya under that
> operating system.
>
>
>
> Thanks again – jeff.
>
>
>
> Jeffrey Kobesky
>
> Electronics Engineer
>
> Naval Research Laboratory
>
> O: (202) 404-7109
>
> M: (443) 243-1554
>
>
>
> *From:* Adam Isaacson 
> *Sent:* Wednesday, April 14, 2021 4:23 AM
> *To:* Casper Lists 
> *Subject:* Re: [casper] python version for casperfpga
>
>
>
> Hi Jeff and everyone,
>
>
>
> While we are hacking Jeff's thread (apologies, but this will be useful
> info), please note that our toolflow only supports the following Red Pitaya
> devices: STEMlab125-10 (10 bit ADC and DAC) and STEMlab125-14 (14 bit ADC
> and DAC). There are another three Red Pitaya boards that we don't support
> yet - check out:
>
>
>
> 1) CASPER Hardware:
> https://github.com/casper-astro/casper-hardware#casper-hardware
>
> 2) Red Pitaya Hardware comparison:
> https://redpitaya.readthedocs.io/en/latest/developerGuide/125-10/vs.html
>
>
>
> We encourage anyone who would like to add these boards to the toolflow and
> we are happy to support you in the process. I highly recommend attending
> the Hardware Porting Workshops that explain how to use the toolflow for
> development and target new hardware. The next Hardware Porting Workshop is
> likely to be next year, but an email will be sent out with these details
> once defined.
>
>
>
> Just a reminder of our CASPER conference that is taking place the week of
> the 17th May via Zoom and is completely free! If interested please check
> out:
>
>
>
> https://casper.berkeley.edu/index.php/meetings-workshops/
>
>
>
> Sorry for the additional advertising! ;)
>
>
> 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 14, 2021 at 8:02 AM Morag Brown  wrote:
>
> Hi all,
>
>
>
> To add to Amish's info, for ease of access, the design files for said
> projects can be found here
> <https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya>.
>
>
>
> Morag
>
>
>
> (Sorry Jeffrey!)
>
>
>
> On Wed, Apr 14, 2021 at 7:55 AM Amish Patel  wrote:
>
> Xin chào, Hien,
>
>
>
> CASPER's Tutorials
> <https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/> have
> three small projects that use the Red Pitaya with the CASPER toolflow.
> First, you will need to do some general setup
> <https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html>
>  for
> the Red Pitaya, and (if necessary) install casperfpga on a machine you plan
> on using to interface with it.
>
>
>
> Please do let us know if this is what you are looking for, and/or if you
> have any questions once you're working through it.
>
>
> Regards
>
>
>
> Amish Patel
>
> SARAO
>
>
>
> (Apologies to Jeffrey for hijacking your thread!)
>
>
>
>
>
> On Wed, 14 Apr 2021 at 04:20, Hien Vo Bich  wrote:
>
> Greeting
>
> Can any one point out the link to some small projects that use the Red
> Pitya board with the CASPER flow ?
>
> Regards
>
> Hien Vo
>
> Vietnamese German University
>
>
>
> On T

Re: [casper] python version for casperfpga

[Adam Isaacson]

Hi Jeff and everyone,

While we are hacking Jeff's thread (apologies, but this will be useful
info), please note that our toolflow only supports the following Red Pitaya
devices: STEMlab125-10 (10 bit ADC and DAC) and STEMlab125-14 (14 bit ADC
and DAC). There are another three Red Pitaya boards that we don't support
yet - check out:

1) CASPER Hardware:
https://github.com/casper-astro/casper-hardware#casper-hardware
2) Red Pitaya Hardware comparison:
https://redpitaya.readthedocs.io/en/latest/developerGuide/125-10/vs.html

We encourage anyone who would like to add these boards to the toolflow and
we are happy to support you in the process. I highly recommend attending
the Hardware Porting Workshops that explain how to use the toolflow for
development and target new hardware. The next Hardware Porting Workshop is
likely to be next year, but an email will be sent out with these details
once defined.

Just a reminder of our CASPER conference that is taking place the week of
the 17th May via Zoom and is completely free! If interested please check
out:

https://casper.berkeley.edu/index.php/meetings-workshops/

Sorry for the additional advertising! ;)

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 14, 2021 at 8:02 AM Morag Brown  wrote:

> Hi all,
>
> To add to Amish's info, for ease of access, the design files for said
> projects can be found here
> <https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya>.
>
> Morag
>
> (Sorry Jeffrey!)
>
> On Wed, Apr 14, 2021 at 7:55 AM Amish Patel  wrote:
>
>> Xin chào, Hien,
>>
>> CASPER's Tutorials
>> <https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/> have
>> three small projects that use the Red Pitaya with the CASPER toolflow.
>> First, you will need to do some general setup
>> <https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html>
>>  for
>> the Red Pitaya, and (if necessary) install casperfpga on a machine you plan
>> on using to interface with it.
>>
>> Please do let us know if this is what you are looking for, and/or if you
>> have any questions once you're working through it.
>>
>> Regards
>>
>> Amish Patel
>> SARAO
>>
>> (Apologies to Jeffrey for hijacking your thread!)
>>
>>
>> On Wed, 14 Apr 2021 at 04:20, Hien Vo Bich  wrote:
>>
>>> Greeting
>>> Can any one point out the link to some small projects that use the Red
>>> Pitya board with the CASPER flow ?
>>> Regards
>>> Hien Vo
>>> Vietnamese German University
>>>
>>> On Tue, Apr 13, 2021 at 9:59 PM Adam Isaacson 
>>> wrote:
>>>
>>>> Hi Jeff,
>>>>
>>>> The toolflow is normally used with a Python virtual environment setup
>>>> with Python 3. The casperfpga tool (provides comms to the board) uses just
>>>> python 2.7. This is the way we use the toolflow and casperpfga at SARAO
>>>> (South African Radio Astronomy Observatory). We support the SKARAB and Red
>>>> Pitaya. There are Python 3 versions for casperfpga, but we haven't really
>>>> tested these on the SKARAB or Red Pitaya.
>>>>
>>>> I have been using Ubuntu 16.04LTS, but I know this also works on Ubuntu
>>>> 18.04LTS. I still need to test my SKARAB on Ubuntu 18.04LTS, which I will
>>>> do in the next couple of weeks.
>>>>
>>>> Here is some documentation to install the toolflow on your system and
>>>> explains the virtual environment:
>>>>
>>>>
>>>> https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html
>>>>
>>>>  Here is some documentation to install casperfpga on your system:
>>>>
>>>>
>>>> https://casper-toolflow.readthedocs.io/projects/casperfpga/en/latest/How-to-install-casperfpga.html
>>>>
>>>> Here are the ska-sa (SARAO) repos which has the latest for SKARAB and
>>>> Red Pitaya:
>>>>
>>>> 1) https://github.com/ska-sa/casperfpga/tree/devel (casperfpga)
>>>> 2) https://github.com/ska-sa/mlib_devel/tree/devel (toolflow)
>>>>
>>>> Here are the casper-astro repos, which the majority of the CASPER
>>>> community uses:
>>>>
>>>> 1) https://github.com/casper-astro/mlib_devel - this actually does
>>>> work with the SKARAB and Red Pitaya too. You still need a Python 3 virtual
>>>> environment if your 

Re: [casper] python version for casperfpga

[Adam Isaacson]

Hi Jeff,

The toolflow is normally used with a Python virtual environment setup with
Python 3. The casperfpga tool (provides comms to the board) uses just
python 2.7. This is the way we use the toolflow and casperpfga at SARAO
(South African Radio Astronomy Observatory). We support the SKARAB and Red
Pitaya. There are Python 3 versions for casperfpga, but we haven't really
tested these on the SKARAB or Red Pitaya.

I have been using Ubuntu 16.04LTS, but I know this also works on Ubuntu
18.04LTS. I still need to test my SKARAB on Ubuntu 18.04LTS, which I will
do in the next couple of weeks.

Here is some documentation to install the toolflow on your system and
explains the virtual environment:

https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html

 Here is some documentation to install casperfpga on your system:

https://casper-toolflow.readthedocs.io/projects/casperfpga/en/latest/How-to-install-casperfpga.html

Here are the ska-sa (SARAO) repos which has the latest for SKARAB and Red
Pitaya:

1) https://github.com/ska-sa/casperfpga/tree/devel (casperfpga)
2) https://github.com/ska-sa/mlib_devel/tree/devel (toolflow)

Here are the casper-astro repos, which the majority of the CASPER community
uses:

1) https://github.com/casper-astro/mlib_devel - this actually does work
with the SKARAB and Red Pitaya too. You still need a Python 3 virtual
environment if your default python package is 2.7.
2) https://github.com/casper-astro/casperfpga - this should work with
SKARAB and Red Pitaya too (Python 2.7)
3) https://github.com/casper-astro/casperfpga/tree/py3-merge - this works
with SNAP, but I haven't tested it on SKARAB or the Red Pitaya. It may work
on the Red Pitaya, but I believe there are still issues with SKARAB (Python
3)

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 Tue, Apr 13, 2021 at 4:36 PM 'Kobesky, Jeffrey CIV USN NRL ()
Washington DC (USA)' via casper@lists.berkeley.edu <
casper@lists.berkeley.edu> wrote:

> Hello CASPER,
>
>
>
> I’m installing tool flow and am confused about which python version to use
> for casperfpga.  I have both python 2.7 and 3.6 on my machine.
>
>
>
> For my equipment (red pitaya and skarab) this link
> https://casper-toolflow.readthedocs.io/en/latest/ says to use python3.
> But if I follow the steps in this link
> https://casper-toolflow.readthedocs.io/en/latest/src/How-to-install-casperfpga.html
> then casperfpga gets installed under the python 2.7 folder.
>
>
>
> This leads to errors (for example, I get error doing
> “casperfpga._version_” in ipython), but I think I can clear those errors by
> reconfiguring python versioning on my machine.
>
>
>
> For now, big picture questions are:  Should we really be using python3 for
> casperfpga with red pitaya and skarab?  If so is there a script available
> that would install casperfpga in the correct python3 folder?  I’ve looked
> in the email archives but can’t find answers.
>
>
>
> Thanks!  -- Jeff
>
>
>
> Jeffrey Kobesky
>
> Electronics Engineer
>
> Naval Research Laboratory
>
> O: (202) 404-7109
>
> M: (443) 243-1554
>
>
>
> --
> 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/cfbc6d4fdd764eac96224b1df77016aa%40nrl.navy.mil
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/cfbc6d4fdd764eac96224b1df77016aa%40nrl.navy.mil?utm_medium=email_source=footer>
> .
>

-- 
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%3DnHqgYbkB2eymR-Vf6k6Lsug-YS14TZfPYEMhZKBx-yMFw%40mail.gmail.com.

Re: [casper] Failed to install `virtualenv`

[Adam Isaacson]

Hi Xin,

Thanks for letting us know - it is useful to have the feedback. I think the
gratitude must go to Morag here :).

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, Mar 30, 2021 at 3:50 PM Xin Cui  wrote:

> Hi Morag, Adam,
>
>
>
> I would like to give you an update on my toolflow configuration. As Morag
> suggested, the errors message I posted in my previous email are not
> problems for the toolflow configuration. I finished all the configuration
> following the steps in the instruction, now I can start up the Matlab from
> executing the `startsg` file.
>
>
>
> I am going through the tutorial for SNAP. I will get back to you if I have
> further questions.
>
>
>
> Thanks for helping!
>
> *
>
> Xin Cui
>
> Electronic Support Team
>
> Addr:McGill University, Department of Physics
>
> 3600 University Street
>
> Rutherford Physics Building
>
> Montreal Quebec
>
> H3A 2T8
>
> Office:  Room 228
>
> Tel:   (514) 398-7025
>
> *
>
>
>
>
>
> *From: *Xin Cui 
> *Sent: *March 26, 2021 10:32 AM
> *To: *casper@lists.berkeley.edu
> *Subject: *RE: [casper] Failed to install `virtualenv`
>
>
>
> Hi Morag,
>
>
>
> Thanks for your detailed explanation. It is very informative and helpful.
> In that case, I think I will move forward with the toolflow configuration.
> I will get back to you if I have other questions.
>
>
>
> Thanks again!
>
> *
>
> Xin Cui
>
> Electronic Support Team
>
> Addr:McGill University, Department of Physics
>
> 3600 University Street
>
> Rutherford Physics Building
>
> Montreal Quebec
>
> H3A 2T8
>
> Office:  Room 228
>
> Tel:   (514) 398-7025
>
> *
>
>
>
>
>
> *From: *Morag Brown 
> *Sent: *March 26, 2021 10:23 AM
> *To: *casper@lists.berkeley.edu
> *Subject: *Re: [casper] Failed to install `virtualenv`
>
>
>
> Hi Xin,
>
>
>
> > However, the last line mentioned that some packages installed
> successfully. Should I care about the error messages?
>
> I think you can disregard those messages (but someone please correct me if
> I'm wrong). As far as I know, a wheel is a ready to install package
> distribution that makes installation easier/faster. I think if pip can't
> build a wheel for a package, it then reverts to installing it directly, and
> it seems those direct installs were successful.
>
>
>
> > So, should I install a python3 under virtual environment, or run `sudo
> pip3 install`?
>
> So a virtual environment is a local python environment that is isolated
> from your operating system's python version. The idea is that you can
> install specific dependencies/packages in the virtual environment without
> affecting anything in the system python version. If you create a python 3
> virtual environment, then python 3 will be installed in that environment by
> default. If you activate the virtual environment and just run *"pip3
> install ", *the package will install in your virtual
> environment. If you run *"sudo pip3 install"* even if you've activated
> your virtual environment, the package will be installed in your system's
> python version.
>
>
>
> So if you're using a virtual environment, don't use sudo or the packages
> won't be installed in your virtual env.
>
>
>
> Hope this helps!
>
> Morag
>
>
>
> On Fri, Mar 26, 2021 at 4:03 PM Xin Cui  wrote:
>
> Hi Morag,
>
>
>
> Thanks a lot for your feedback. I can move forward after doing your
> suggested commands. But I got the following error message after running
> `pip3 install -r requirements.txt`:
>
>
>
> However, the last line mentioned that some packages installed
> successfully. Should I care about the error messages?
>
>
>
> From the instruction, it reads that if the python3 is installed in system
> environment, I need to run `pip3 install` as administrator. As I mentioned,
> I installed the python3 by using `sudo`, so I think the python3 should have
> been installed in the system, but not the virtual environment. So, should I
> install a python3 under virtual environment, or run `sudo pip3 install`?
>
> *From:* Morag Brown 
> *Sent:* March 26, 2021 2:05 AM
> *To:* casper@lists.berkeley.edu 
> *Subject:* Re: [casper] Failed to install `virtualenv`
>
>
>
> Hi Xin,
>
>
>
> Using virtua

Re: [casper] Failed to install `virtualenv`

[Adam Isaacson]

Hi Xin,

Morag explained it very well and has actually updated the readthedocs with
all the necessary information - just checked my notes. The readthedocs
section has actually been updated with the correct info, so my instructions
won't help.

I have been able to install without the wheel issue, but I guess try and
get the tooflow to work. I would be interested to hear whether you have any
success or not. That is why I wanted you to try: "pip install -r
requirements.txt" from your virtual environment, which must be python 3 if
you followed Morag's instructions. I wanted to see if that maybe worked,
but it is up to you. Try with the wheel issue and let us know.

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, Mar 26, 2021 at 4:41 PM Xin Cui  wrote:

> Hi Adam,
>
>
>
> Thanks a lot for helping. As Morag has commented, I feel more confident to
> move to the next step on setting up the environment. But I am also
> interested to see your install instructions. Is it different from what I
> referred from the CASPER website, or is it an updated version?
>
>
>
> Thanks,
>
> *
>
> Xin Cui
>
> Electronic Support Team
>
> Addr:McGill University, Department of Physics
>
> 3600 University Street
>
> Rutherford Physics Building
>
> Montreal Quebec
>
> H3A 2T8
>
> Office:  Room 228
>
> Tel:   (514) 398-7025
>
> *
>
>
>
>
>
> *From: *Adam Isaacson 
> *Sent: *March 26, 2021 10:17 AM
> *To: *Casper Lists 
> *Subject: *Re: [casper] Failed to install `virtualenv`
>
>
>
> Hi Xin,
>
>
>
> You are in the python 3 virtual environment, I think. Once you are in the
> virtual environment then you just need to run "pip install -r
> requirements.txt". The pip will call pip3 by default. I am not sure what
> pip3 will do. If you are still struggling then I can send you the install
> instructions that I sent Kaj.
>
>
> 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, Mar 26, 2021 at 4:03 PM Xin Cui  wrote:
>
> Hi Morag,
>
>
>
> Thanks a lot for your feedback. I can move forward after doing your
> suggested commands. But I got the following error message after running
> `pip3 install -r requirements.txt`:
>
>
>
> However, the last line mentioned that some packages installed
> successfully. Should I care about the error messages?
>
>
>
> From the instruction, it reads that if the python3 is installed in system
> environment, I need to run `pip3 install` as administrator. As I mentioned,
> I installed the python3 by using `sudo`, so I think the python3 should have
> been installed in the system, but not the virtual environment. So, should I
> install a python3 under virtual environment, or run `sudo pip3 install`?
>
> *From:* Morag Brown 
> *Sent:* March 26, 2021 2:05 AM
> *To:* casper@lists.berkeley.edu 
> *Subject:* Re: [casper] Failed to install `virtualenv`
>
>
>
> Hi Xin,
>
>
>
> Using virtualenv no longer works - people smarter and more knowledgeable
> than I way know why.
>
>
>
> As an alternative, you can use "*python3 -m venv*" to create a virtual
> environment. Sourcing the venv is the same (*source
> /path/to/venv/bin/activate*), and then install the requirements.txt file
> within the venv as per the rest of the instructions
>
>
>
> Will update the docs to reflect this new method when I get a chance. Sorry
> for the frustration!
>
>
>
> Morag
>
>
>
> On Fri, 26 Mar 2021, 04:03 Xin Cui,  wrote:
>
> Hello,
>
>
>
> I am trying to set up working environment to run SNAP. According to the 
> instruction 
> <https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html>,
>  I finished the installation of Matlab and Vivado on Ubuntu16.04. Now I am 
> trying to create Python3 virtual environment. I failed to install the virtual 
> environment by running `sudo pip3 install virtualenv`, I got the following 
> error message:
>
>
>
>
>
> There is only one command I ran differently from the instruction
> <https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html>
> :
>
> `apt-get install python3 python3-pip`
>
> I used `sudo` when I ran this command. I am not sure if it matters.
>
>
>
>

Re: [casper] casperfpga on python3

[Adam Isaacson]

Hi Guillermo,

The branch that Danny sent you is the correct branch to use
https://github.com/casper-astro/casperfpga/tree/py3-merge. The branch in
the ska-sa repo is still a work in progress and needs to be fully tested. I
have a feeling that both branches may not work for the SKARAB hardware -
needs some tweaks. I can say that python 2.7 casperfpga works just fine for
SKARAB though.

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, Mar 22, 2021 at 3:53 PM Guillermo Gancio  wrote:

> Hi Danny,
>
> Thank you very much, it seems to be ok!
> What I did was...
> Clone the git, change the branch to py3-merge, pip install -r
> requirements, python setup.py install...
>
> Then from from Ipython I got:
>
> In [1]: import casperfpga
>
> In [2]: casperfpga.__version__
> Out[2]: '0.4.4.dev1032+py3.merge.c536a4d'
> In [6]: fpga.is_connected()
> Out[6]: True
>
>
> Thank you very much!
>
>
> El lun, 22 mar 2021 a las 10:35, Danny C Price ()
> escribió:
> >
> > Hi Guillermo,
> >
> > You could try this branch:
> https://github.com/casper-astro/casperfpga/tree/py3-merge
> >
> > This works for my purposes in Py3 (with the snap board), with the *huge*
> caveat that adc calibration doesnt work. (Ive heard that this has been
> solved by Aaron and Jonathon but not merged).
> >
> > Cheers,
> > Danny
> >
> >
> > On Mon, 22 Mar 2021, 21:28 Guillermo Gancio,  wrote:
> >>
> >> Dear all,
> >>
> >> I'm trying the python3-port of casperfpga, from
> >> https://github.com/ska-sa/casperfpga/tree/python3-port
> >> I had to fix some minnor issues like
> >> "except KatcpClientError, e: " to "(except KatcpClientError, e):
> >> and
> >> "from thread" to "from _thread"
> >> which I'm not sure if they are ok
> >> And then I got the following error while doing "import casperfpga" in
> >> ipython, that I cannot figure out..
> >>
> >>
> /home/user1/casperfpga3/lib/python3.7/site-packages/katcp/resource_client.py
> >> in ()
> >> 847'{1!s}'.format(sensor_name,
> reply))
> >> 848 # Register with the ABC
> >> --> 849
> resource.KATCPSensorsManager.register(KATCPClientResourceSensorsManager)
> >> 850
> >> 851 class KATCPClientResourceRequest(resource.KATCPRequest):
> >>
> >> AttributeError: type object 'KATCPSensorsManager' has no attribute
> 'register'
> >>
> >> Any idea?
> >> Thanks.
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "casper@lists.berkeley.edu" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to casper+unsubscr...@lists.berkeley.edu.
> >> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CA%2BEePfS%3DVnQKv-E%2ByQpDOWJm7gRxZn2HcX8N-2K-JefPqvHX2g%40mail.gmail.com
> .
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "casper@lists.berkeley.edu" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to casper+unsubscr...@lists.berkeley.edu.
> > To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAAtMgq%3DdgbqHJK4iGw8t1Zfeji1dbLrcHOMUoP6FWs%2BpWd%2BC8w%40mail.gmail.com
> .
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CA%2BEePfSJmqiL4mPdVNU%2B8kKmQEZdGDkm8zjdBOuwh4r75XFC3A%40mail.gmail.com
> .
>

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

Re: [casper] quantum entanglement sensing using high-speed digital sampling and cross-multiplies

[Adam Isaacson]

Hi Neil,

Yes, we use Python 3 for our CASPER toolflow (with a virtual python
environment) and our comms package casperfpga is written in Python 2.7. We
are working on a Python 3 version. The tooflow consists of a frontend,
middlend and backend. The frontend, middlend and backend all use Python. In
basic terms, the front end uses python to extract critical information from
the Simulink file and yellow blocks. The middlend is then run to create the
top.v and the rest of the RTL connects using python and the backend uses
python to call Vivado to do the compile -creates tcl scripts and xdc files
etc. Obviously this is a simple explanation and the python does a lot more.

There is no cost for python - your only costs will be Matlab/Simulink
(speak to your supplier for a quote) and Vivado license (speak to supplier
for a quote). No other costs are needed.

SARAO is working on a toolflow that supports Vitis, which is completely
free and the libraries are open source. We are targeting the Alveo
platforms, which means the Vivado license is included in the free web pack
license, so no Vivado license is needed. Just a Matlab/Simulink license. We
do plan to phase this out at some point, but it might take a long time. A
lot of our CASPER DSP libraries have been around a long time and it
wouldn't make sense to get rid of them yet.

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, Mar 19, 2021 at 11:01 PM Dan Werthimer 
wrote:

>
>
> hi neil,
>
> if you want to sample your band with breaking it up into sub-bands,
> there are a few samplers at 60 Gsps and beyond.
>
> vadatech has a pricy 8 bit 56 Gsps ADC board.
> jpl and jonathan kocz got one, but i don't think they've had a chance to
> play with it yet.
>
> intel recently demo'ed a 64 Gsps 8 bit ADC, but i don't think it's
> available yet.
>
> best wishes,
>
> dan
>
>
>
>
>
>
> On Fri, Mar 19, 2021 at 1:46 PM salmon.na via casper@lists.berkeley.edu <
> casper@lists.berkeley.edu> wrote:
>
>> Hi Dan,
>>
>>
>>
>> Thanks for those great options. Those sampling rates are the sort that
>> I’m looking for. I can probably operate with a smaller RF band to start
>> with, to make the task a little less difficult.
>>
>>
>>
>> Hi Francios,
>>
>>
>>
>> Thanks for helping out here. I don’t have academic licences but I could
>> buy a commercial Mathworks licence. However, I tend to use Python now in
>> place of Matlab, so does the CASPER technology work also with Python? If so
>> would I need to buy a licence to use the CASPER hardware with Python, any
>> idea of costs? (no way am I anywhere near a product it’s all pretty much a
>> research activity, profit is nowhere in sight, stay afloat if lucky)
>>
>>
>>
>> Many thanks to you both for help.
>>
>> Best wishes, Neil
>>
>>
>>
>> *From:* Dan Werthimer 
>> *Sent:* 19 March 2021 17:41
>> *To:* CASPER Mailing List 
>> *Subject:* Re: [casper] quantum entanglement sensing using high-speed
>> digital sampling and cross-multiplies
>>
>>
>>
>>
>>
>>
>>
>> hi neil,
>>
>>
>>
>> there's a quad 16 Gsps 4 bit ADC FMC board developed by CFA/Smithsonian
>> that connects to a VCU128 FPGA board that might be useful for your work.
>>
>> the analog bandwidth of the ADC doesn't get up to 30 GHz, so you'd have
>> to mix down your band before digitizing.
>>
>> you could break your 20 GHz band up into three pieces of 6.6 GHz each
>> (using analog mixers and filters), and use three of the four ADC's on the
>> board,
>>
>> or break it up into four pieces of 5 GHz each and use all four ADC's.
>>
>>
>>
>> another, less expensive solution is to break your 20 GHz band up into
>> eight pieces of 2.4 GHz each,  (and loosing a bit of the 20 GHz),
>>
>> then you could use a ZCU208 octal 5 Gsps 14 bit ADC/FPGA board.
>>
>>
>>
>> best wishes,
>>
>>
>>
>> dan
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Mar 19, 2021 at 3:57 AM Francois Kapp 
>> wrote:
>>
>> Hi Neil,
>>
>>
>>
>> Second question first - you can access CASPER technology from anywhere.
>> The software licensing may be different if you do not get academic
>> discounts from Mathworks, and Xilinx may also charge you something
>> depending on your exact situation.  Both companies are generous to academic
>> users.
>>
>>
>>
>&g

Re: [casper] Problem with casperfpga

[Adam Isaacson]

Hi Guillermo,

I am so glad to hear that you worked it out and timeously too.

Good luck with the design work.

Just a note that my health has taken a turn for the worse, so I will be
stopping with CASPER support for the time-being. I have handed over my
duties (SARAO Hardware Manager) to Wesley New who I know will do his best
to support you going forward if he is available.

Have a great 2021 going forward.

With warmth,

Adam

On Mon, 15 Feb 2021, 7:07 PM Guillermo Gancio,  wrote:

> Hi Adam,
>
> Thanks for your help, at the end I managed to make it work! after
> hitting the keyboard with my head several times I realized that pip
> was pointing to python3,
> so, using pip2 did the trick..(still with the same issue, I'm
> going to the shame corner for a while)
>
> Again thanks Adam and all for the comments.
>
>
>
>
>
>
>
>
>
>
>
> El dom, 14 feb 2021 a las 6:24, Adam Isaacson ()
> escribió:
> >
> > Hi Guillermo,
> >
> > Thanks for the added clarity. There is definitely an issue with your
> casperfpga install.
> >
> > I think we need to be able to Ipython, import casperfpga and read back
> the version before doing anything.
> >
> > I will check out your particular githash version on Monday and see if
> there are any issues. I suggest you delete casperfpga and all references
> from your machine and then follow both set of installs as mentioned in:
> >
> > https://github.com/casper-astro/casperfpga#installation
> >
> > Kind regards,
> >
> > Adam
> >
> >
> > On Sun, 14 Feb 2021, 1:12 AM Guillermo Gancio, 
> wrote:
> >>
> >> Hi Adam,
> >>
> >> Thanks for your reply,
> >> The idea is to start by program a redpitaya with the bof file from the
> git/tutorial, so at this point i'm not using any model/slx, mlib_evel. Can
> this afect the casperfpga for the communication with a casperized board?
> >>
> >> The problem that I have is right after "import casperfpga", I put the
> complete error in a txt file with it, for (I hope) a better clarity.
> >> The ipython is executed from my home directory.
> >>
> >> Thanks again,
> >>
> >>
> >>
> >>
> >> El vie, 12 feb 2021 a las 14:01, Adam Isaacson ()
> escribió:
> >>>
> >>> Hi Guillermo,
> >>>
> >>> Please can I have a more detailed screenshot of your steps. I don't
> just want to see the error. I want to see all the steps proceeding the
> error. This is not clear to me from your screen shot.
> >>>
> >>> 1) What board are you targeting? I see you are using the tengbe
> library? Is this perhaps a ROACH2 or SNAP? ROACH2 may or may not have
> issues when using the latest casperfpga githash, so be aware. There is a
> ROACH2 casperfpga githash, but it doesn't have all the latest fixes.
> >>> 2) Send me your slx, so that I can build and verify if needed
> >>> 3) What repo of mlib_devel (include the githash and branch) and
> casperfpga are you using?
> >>>
> >>> I know I have had that progska issue before when running ipython under
> the casperfpga cloned directory. This is clearly a new issue now related to
> the tengbe component.
> >>>
> >>> Please note that I am busy installing my new Ubuntu 18.04LTS machine
> and so it will take some time for me to look at this further until my
> development is setup and working properly.
> >>>
> >>> 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, Feb 12, 2021 at 6:09 PM Guillermo Gancio 
> wrote:
> >>>>
> >>>> Hi,
> >>>> Thanks for all the replies, I tried with " I think try going into the
> >>>> progska directory, `make && make install` then try again? It's been a
> >>>> while since I've done this." with no success..
> >>>>
> >>>> Then I follow the steps from Adam with no success, but a different
> error
> >>>> The install procedure goes without any error.
> >>>>
> >>>> 1) You are not running the python3 virtual machine. No virtual machine
> >>>> should be used.
> >>>> That's correct, I'm not using a virtual machine (or virtual env)
> >>>>
> >>>> 2) When yo

Re: [casper] Problem with casperfpga

[Adam Isaacson]

Hi Guillermo,

Thanks for the added clarity. There is definitely an issue with your
casperfpga install.

I think we need to be able to Ipython, import casperfpga and read back the
version before doing anything.

I will check out your particular githash version on Monday and see if there
are any issues. I suggest you delete casperfpga and all references from
your machine and then follow both set of installs as mentioned in:

https://github.com/casper-astro/casperfpga#installation

Kind regards,

Adam


On Sun, 14 Feb 2021, 1:12 AM Guillermo Gancio,  wrote:

> Hi Adam,
>
> Thanks for your reply,
> The idea is to start by program a redpitaya with the bof file from the
> git/tutorial, so at this point i'm not using any model/slx, mlib_evel. Can
> this afect the casperfpga for the communication with a casperized board?
>
> The problem that I have is right after "import casperfpga", I put the
> complete error in a txt file with it, for (I hope) a better clarity.
> The ipython is executed from my home directory.
>
> Thanks again,
>
>
>
>
> El vie, 12 feb 2021 a las 14:01, Adam Isaacson ()
> escribió:
>
>> Hi Guillermo,
>>
>> Please can I have a more detailed screenshot of your steps. I don't just
>> want to see the error. I want to see all the steps proceeding the error.
>> This is not clear to me from your screen shot.
>>
>> 1) What board are you targeting? I see you are using the tengbe library?
>> Is this perhaps a ROACH2 or SNAP? ROACH2 may or may not have issues when
>> using the latest casperfpga githash, so be aware. There is a ROACH2
>> casperfpga githash, but it doesn't have all the latest fixes.
>> 2) Send me your slx, so that I can build and verify if needed
>> 3) What repo of mlib_devel (include the githash and branch) and
>> casperfpga are you using?
>>
>> I know I have had that progska issue before when running ipython under
>> the casperfpga cloned directory. This is clearly a new issue now related to
>> the tengbe component.
>>
>> Please note that I am busy installing my new Ubuntu 18.04LTS machine and
>> so it will take some time for me to look at this further until my
>> development is setup and working properly.
>>
>> 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, Feb 12, 2021 at 6:09 PM Guillermo Gancio 
>> wrote:
>>
>>> Hi,
>>> Thanks for all the replies, I tried with " I think try going into the
>>> progska directory, `make && make install` then try again? It's been a
>>> while since I've done this." with no success..
>>>
>>> Then I follow the steps from Adam with no success, but a different
>>> error
>>> The install procedure goes without any error.
>>>
>>> 1) You are not running the python3 virtual machine. No virtual machine
>>> should be used.
>>> That's correct, I'm not using a virtual machine (or virtual env)
>>>
>>> 2) When you run "ipython" you are doing it outside the closed
>>> "casperfpga" repo. This is important
>>> Aha, I was inside casperfpga, when doing it outside the casperfpga
>>> directory I got other error
>>> " KeyError: 'casperfpga/tengbe_mmap.txt' "
>>>
>>> 3) point three gives the error, so I can't get the casperfpga_version-
>>>
>>>  4) What githash of casperfpga are you using?
>>> git rev-parse HEAD gives: eac2d4625c88da575a7fe82df2582cf2be43e37e
>>>
>>>
>>>
>>> Thanks again!!!
>>> Cheers,
>>>
>>>
>>> El vie, 12 feb 2021 a las 4:17, Adam Isaacson ()
>>> escribió:
>>> >
>>> > Hi Guillermo,
>>> >
>>> > The instructions you are following should work to install casperfpga.
>>> I find the following install procedure works for me:
>>> >
>>> > # remove current casperfpga install files
>>> > 1) $ cd /usr/local/lib/python2.7/dist-packages
>>> > 2) $ sudo rm -rf casper*
>>> >
>>> > # clone the repository to your working directory
>>> > 3) $ cd /path/to/working/directory
>>> > 4) $ git clone https://github.com/casper-astro/casperfpga.git
>>> > 5) $ cd casperfpga
>>> > 6) $ git checkout master
>>> > 7) $ sudo pip install -r requirements.txt
>>> > 8) $ sudo python setup.py install
>>> >
>&g

Re: [casper] Problem with casperfpga

[Adam Isaacson]

Hi Guillermo,

Please can I have a more detailed screenshot of your steps. I don't just
want to see the error. I want to see all the steps proceeding the error.
This is not clear to me from your screen shot.

1) What board are you targeting? I see you are using the tengbe library? Is
this perhaps a ROACH2 or SNAP? ROACH2 may or may not have issues when using
the latest casperfpga githash, so be aware. There is a ROACH2 casperfpga
githash, but it doesn't have all the latest fixes.
2) Send me your slx, so that I can build and verify if needed
3) What repo of mlib_devel (include the githash and branch) and casperfpga
are you using?

I know I have had that progska issue before when running ipython under the
casperfpga cloned directory. This is clearly a new issue now related to the
tengbe component.

Please note that I am busy installing my new Ubuntu 18.04LTS machine and so
it will take some time for me to look at this further until my development
is setup and working properly.

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, Feb 12, 2021 at 6:09 PM Guillermo Gancio  wrote:

> Hi,
> Thanks for all the replies, I tried with " I think try going into the
> progska directory, `make && make install` then try again? It's been a
> while since I've done this." with no success..
>
> Then I follow the steps from Adam with no success, but a different
> error
> The install procedure goes without any error.
>
> 1) You are not running the python3 virtual machine. No virtual machine
> should be used.
> That's correct, I'm not using a virtual machine (or virtual env)
>
> 2) When you run "ipython" you are doing it outside the closed
> "casperfpga" repo. This is important
> Aha, I was inside casperfpga, when doing it outside the casperfpga
> directory I got other error
> " KeyError: 'casperfpga/tengbe_mmap.txt' "
>
> 3) point three gives the error, so I can't get the casperfpga_version-
>
>  4) What githash of casperfpga are you using?
> git rev-parse HEAD gives: eac2d4625c88da575a7fe82df2582cf2be43e37e
>
>
>
> Thanks again!!!
> Cheers,
>
>
> El vie, 12 feb 2021 a las 4:17, Adam Isaacson ()
> escribió:
> >
> > Hi Guillermo,
> >
> > The instructions you are following should work to install casperfpga. I
> find the following install procedure works for me:
> >
> > # remove current casperfpga install files
> > 1) $ cd /usr/local/lib/python2.7/dist-packages
> > 2) $ sudo rm -rf casper*
> >
> > # clone the repository to your working directory
> > 3) $ cd /path/to/working/directory
> > 4) $ git clone https://github.com/casper-astro/casperfpga.git
> > 5) $ cd casperfpga
> > 6) $ git checkout master
> > 7) $ sudo pip install -r requirements.txt
> > 8) $ sudo python setup.py install
> >
> > Please confirm/provide the following for me:
> >
> > 1) You are not running the python3 virtual machine. No virtual machine
> should be used.
> >
> > 2) When you run "ipython" you are doing it outside the closed
> "casperfpga" repo. This is important
> >
> > 3) Run the following steps at the terminal:
> >
> >   a) ipython
> >
> >   b) import casperfpga
> >
> >   c) casperfpga.__version__ (What version do you read back?)
> >
> >  4) What githash of casperfpga are you using?
> >
> >  5) Send screen captures - this helps with debugging!
> >
> > 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, Feb 12, 2021 at 8:09 AM Colm Bracken 
> wrote:
> >>
> >> Have you definitely downloaded and installed all the python programs?
> >>
> >> On Thu 11 Feb 2021, 5:02 PM Guillermo Gancio, 
> wrote:
> >>>
> >>> Hi all,
> >>> I'm having a silly error that I Can't figure out.
> >>> I'm installing casperfpga on a Ubuntu 18.04, python 2.7 and I get the
> error,
> >>>
> >>> ImportError: No module named progska
> >>>
> >>> I followed the steps from
> https://github.com/casper-astro/casperfpga#installation with no apparent
> errors...
> >>>
> >>> Thanks!
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups "casper@lists.berkeley.edu" group.
&g

Re: [casper] Problem with casperfpga

[Adam Isaacson]

Hi Guillermo,

The instructions you are following should work to install casperfpga. I
find the following install procedure works for me:

# remove current casperfpga install files
1) $ cd /usr/local/lib/python2.7/dist-packages
2) $ sudo rm -rf casper*
# clone the repository to your working directory
3) $ cd /path/to/working/directory
4) $ git clone https://github.com/casper-astro/casperfpga.git
5) $ cd casperfpga
6) $ git checkout master
7) $ sudo pip install -r requirements.txt
8) $ sudo python setup.py install

Please confirm/provide the following for me:

1) You are not running the python3 virtual machine. No virtual machine
should be used.

2) When you run "ipython" you are doing it outside the closed
"casperfpga" repo. This is important

3) Run the following steps at the terminal:

  a) ipython

  b) import casperfpga

  c) casperfpga.__version__ (What version do you read back?)

 4) What githash of casperfpga are you using?

 5) Send screen captures - this helps with debugging!

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, Feb 12, 2021 at 8:09 AM Colm Bracken  wrote:

> Have you definitely downloaded and installed all the python programs?
>
> On Thu 11 Feb 2021, 5:02 PM Guillermo Gancio,  wrote:
>
>> Hi all,
>> I'm having a silly error that I Can't figure out.
>> I'm installing casperfpga on a Ubuntu 18.04, python 2.7 and I get the
>> error,
>>
>> ImportError: No module named progska
>>
>> I followed the steps from
>> https://github.com/casper-astro/casperfpga#installation with no apparent
>> errors...
>>
>> Thanks!
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To view this discussion on the web visit
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CA%2BEePfQiGYL3iG5E4V19SXXGhoSUDnLjkzsUT3CSaOOu_W7OQA%40mail.gmail.com
>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CA%2BEePfQiGYL3iG5E4V19SXXGhoSUDnLjkzsUT3CSaOOu_W7OQA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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/CAEx9wh_d85iT2fM9TJ77ug1MVus_Qy3henpyGVY8zmkbBJCgrQ%40mail.gmail.com
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAEx9wh_d85iT2fM9TJ77ug1MVus_Qy3henpyGVY8zmkbBJCgrQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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%3DnF%3DuePD5zB8F%2B8s4SboXXwBSSS9r9rE7Zp%2B4PTBY1_Y6g%40mail.gmail.com.

Re: [casper] New setup installation problems (python setup.py egg_info" failed with error code 1) [Success!!!]

[Adam Isaacson]

Hi Kaj,

Excellent! :). I am glad you are finally sorted and I was happy to assist
where I could. Looking forward to that beer in better times ;).

I suggest that you go on the CASPER slack group and ask there about ZCU111.
There is a #RFSoC channel, which will provide you all the information on
ZCU111. I would also ask Wei Liu who did some excellent work on the ZCU111
- alas, I don't have his new email address.

My other suggestion is that you create a new CASPER email thread regarding
the ZCU111 - people might miss your request.

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 Wed, Feb 3, 2021 at 3:39 PM Kaj Wiik  wrote:

> Hi Adam,
>
>   Infos, 0 Warnings, 0 Critical Warnings and 0 Errors encountered.
> write_cfgmem completed successfully
> INFO: [Common 17-206] Exiting Vivado at Wed Feb  3 13:27:22 2021...
> Created
> /home/kjwiik/mlib_devel/jasper_library/test_models/test_snap_adc/outputs/test_snap_adc_2021-02-03_1321.bof
> Created
> /home/kjwiik/mlib_devel/jasper_library/test_models/test_snap_adc/outputs/test_snap_adc_2021-02-03_1321.fpg
> (casper-venv) kjwiik@casper:~/test$
>
> Jippii!!
>
> I cannot say how happy and grateful I am, many thanks to all and
> especially Adam for his patient and friendly advice
>
> Huhhuh, that was a tough one.
>
> The next step as our target is RFSoC/ZCU111: I noticed that there is a
> simple test for ZCU111, I'll try that and report. I'll also try to look how
> to use the yellow blocks from https://github.com/liuweiseu/ZCU111
>
> Does anyone have something to test the ADC's, tutorials maybe? Perhaps
> some tutorials could be ported to ZCU111?
>
> > My guess is that if you compile the slx files I suggested in the
> previous thread or the above then It will work. In other words, I believe
> your toolflow should be fully functioning now. Time for a beer maybe? ;)
>
> Indeed. When this pandemic is over, I hope to meet you and buy you one :-D!
>
> Cheers!
>
> Kaj
>
> --
> 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/e631756d-f9c5-c610-7a5d-6ca959a73b58%40utu.fi
> .
>

-- 
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%3DnFZ2zkLidctq854ZxKh-dq4pxFi-JOhziZXx31g5ErqaQ%40mail.gmail.com.

Re: [casper] New setup installation problems (python setup.py egg_info" failed with error code 1)

[Adam Isaacson]

 model
terminationWarning: did not properly cleanup after previous model
terminationWarning: did not properly cleanup after previous model
terminationWarning: did not properly cleanup after previous model
terminationWarning: did not properly cleanup after previous model
termination- Version Log
--
Version Path
System Generator 2019.1 /opt/Xilinx/Vivado/2019.1
Matlab 9.4.0.949201 (R2018a) Update 6   /opt/Matlab/R2018a
Vivado 2019.1   /opt/Xilinx/Vivado/2019.1
Warning: did not properly cleanup after previous model terminationWarning:
did not properly cleanup after previous model
termination- Version Log
--
Version Path
System Generator 2019.1 /opt/Xilinx/Vivado/2019.1
Matlab 9.4.0.949201 (R2018a) Update 6   /opt/Matlab/R2018a
Vivado 2019.1   /opt/Xilinx/Vivado/2019.1
Warning: did not properly cleanup after previous model terminationWarning:
did not properly cleanup after previous model terminationWarning: did not
properly cleanup after previous model terminationWarning: did not properly
cleanup after previous model terminationWarning: did not properly cleanup
after previous model terminationWarning: did not properly cleanup after
previous model terminationWarning: did not properly cleanup after previous
model terminationWarning: did not properly cleanup after previous model
terminationWarning: did not properly cleanup after previous model
terminationWarning: did not properly cleanup after previous model
terminationWarning: did not properly cleanup after previous model
terminationWarning: did not properly cleanup after previous model
terminationWarning: did not properly cleanup after previous model
terminationWarning: did not properly cleanup after previous model
terminationWarning: did not properly cleanup after previous model
terminationWarning: did not properly cleanup after previous model
termination- Version Log
--
Version Path
System Generator 2019.1 /opt/Xilinx/Vivado/2019.1
Matlab 9.4.0.949201 (R2018a) Update 6   /opt/Matlab/R2018a
Vivado 2019.1   /opt/Xilinx/Vivado/2019.1
XSG generation complete.

*Front End compile complete*

To complete your compile, run the following command in a terminal.
Remember to source your startsg.local environment first!

I noticed there are other SNAP slx files that you can try:

1) test_snap_adc.slx - definitely generates the sysgen and builds (tested
it on my side)! Maybe you can try this?
2) Tutorials: https://casper-tutorials.readthedocs.io/en/latest/ (SNAP)

My guess is that if you compile the slx files I suggested in the previous
thread or the above then It will work. In other words, I believe your
toolflow should be fully functioning now. Time for a beer maybe? ;)

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, Feb 3, 2021 at 12:11 PM Adam Isaacson  wrote:

> Hi Kaj,
>
> Okay, at least you are synthesising now - well done! It looks like it
> can't find the sysgen entity in your top.v. This can happen if your system
> generator did not run correctly.
>
> Please can you do the following for me:
>
> 1) zip up your "test_snap" folder under "jasper_library/test_models" and
> send it to me- please include the test_snap.slx model.
> 2) Just to make sure this is not a test_snap.slx issue. Please will you
> build the following files under jasper_library/test_models just to make
> sure:
> a) "test_red_pitaya.slx"
> b) "skarab_fgbe.slx"
>
> I will compile the "test_snap.slx" on my side and let you know if it fails.
>
> 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, Feb 3, 2021 at 11:30 AM Kaj Wiik  wrote:
>
>> Hi Adam,
>>
>> I am very sorry, you are absolutely right, I did not edit the file :-(.
>>
>> After editing, that part worked but now after running the command line
>> from matlab, I got an error
>>
>> ERROR: [Synth 8-439] module 'test_snap' not found
>> [/home/kjwiik/mlib_devel/jasper_library/test_models/test_snap/myproj/myproj.srcs/sources_1/imports/test_snap/top.v:614]
>>
>> Screen capture is attached.
>>
>> Thanks,
>> Kaj
>>
>>
>> On 02/02/2021 20:16, Adam Isaacson wrote:
>&

Re: [casper] New setup installation problems (python setup.py egg_info" failed with error code 1)

[Adam Isaacson]

Hi Kaj,

Okay, at least you are synthesising now - well done! It looks like it can't
find the sysgen entity in your top.v. This can happen if your system
generator did not run correctly.

Please can you do the following for me:

1) zip up your "test_snap" folder under "jasper_library/test_models" and
send it to me- please include the test_snap.slx model.
2) Just to make sure this is not a test_snap.slx issue. Please will you
build the following files under jasper_library/test_models just to make
sure:
a) "test_red_pitaya.slx"
b) "skarab_fgbe.slx"

I will compile the "test_snap.slx" on my side and let you know if it fails.

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, Feb 3, 2021 at 11:30 AM Kaj Wiik  wrote:

> Hi Adam,
>
> I am very sorry, you are absolutely right, I did not edit the file :-(.
>
> After editing, that part worked but now after running the command line
> from matlab, I got an error
>
> ERROR: [Synth 8-439] module 'test_snap' not found
> [/home/kjwiik/mlib_devel/jasper_library/test_models/test_snap/myproj/myproj.srcs/sources_1/imports/test_snap/top.v:614]
>
> Screen capture is attached.
>
> Thanks,
> Kaj
>
>
> On 02/02/2021 20:16, Adam Isaacson wrote:
> > Hi Kaj,
> >
> > Well, your virtualenv looks correct. The packages are the correct ones.
> I assume all is good with the virtualenv. I noticed the following on your
> side that you have this constructor error I was talking about - did you
> edit the castro.py file that I listed in my previous thread or are you
> using the casper-astro/mlib_devel (casper-astro-soak-test branch which
> contains my castro.py edit fix)? Please send me a more complete screen
> capture from the time you run Matlab to when the error occurs. Also send me
> your startsg.local file, so that I can investigate.
> >
> > I assume you did the following under "mlib_devel":
> >
> > 0) Make sure you are using my latest castro.py changes, as explained
> above and previous email thread - "5) You will need to edit line 32 of
> castro.py (located in the same folder as mlib_devel/jasper_library), so
> that it is "c = yaml.load(fh, Loader=yaml.Loader) . Refer to
> https://github.com/yaml/pyyaml/issues/266 <
> https://github.com/yaml/pyyaml/issues/266>for more info on this version
> change issue. I tested the build with my original working virtualenv and
> the newly generated virtualenv and it works for both. Don't worry, I will
> be committing this change once I have done a bit more investigation - maybe
> adding versions in requirements.txt is not a bad idea for future support".
> > 1) Under "mlib_devel" ./startsg to set your environment and run Matlab.
> > 2) You opened the slx file
> > 3) You ran "jasper_frontend" in the Matlab command window.
> > 4) You opened another terminal
> > 5) In the new terminal under "mlib_devel" you typed "source startsg
> startsg.local". This sets up the environment variables using your new
> terminal.
> > 6) You cut and paste the last line out of the matlab command window and
> you pasted it into the new terminal and then build.
> >
> > I think your issue according to your screen capture is that you don't
> have the castro.py mod I made. Please check and let me know.
> >
> > In terms of providing virtual environments. I think what we need to do
> is provide VMs without Matlab and Vivado licensing, so the users can just
> start. A few years back we investigated containers, which are much smaller
> hard disk wise. Alas, we had issues getting the container to work on other
> machines. VMs are bulky, but may be the best answer. We will discuss during
> the next CASPER meeting.
> >
> > Kaj, I think you are close! Hang in there :).
> >
> > Kind regards,
> >
> > Adam Isaacson
> > South African Radio Astronomy Observatory (SARAO)
> > Hardware Manager
> > Cell: (+27) 825639602
> > Tel:  (+27) 215067300
> > email: aisaac...@ska.ac.za <mailto:aisaac...@ska.ac.za>
> >
> >
> >
> >
> >
> > On Tue, Feb 2, 2021 at 8:00 PM Kaj Wiik  kaj.w...@utu.fi>> wrote:
> >
> > Hi all,
> >
> > An idea: what if you shipped a working python venv as tgz with the
> toolflow?
> >
> > Cheers,
> > Kaj
> >
> > On 02/02/2021 18:33, Kaj Wiik wrote:
> >  > Hi Adam,
> >  >
> >  > The screen capture of
> ../casper-venv/lib64/python3.5/site-packages is attached.
> >  >
> &

Re: [casper] Issue compiling design from previous version.

[Adam Isaacson]

Hi Guillermo,

I am glad you sorted it out trying to recreate your steps. Maybe you were
actually opening the R2016a file or autosave version of that again?

Anyway, looks like you beat Murphy - well done :).

Thanks for letting us know.

Kind regards,

Adam




On Tue, 02 Feb 2021, 10:27 PM Guillermo Gancio,  wrote:

> Hi Adam,
>
> Thanks for you answer, and as Murphy said, if it can fail, it
> willbut in this case it didn't fail...
> I was preparing the files from scratch to attach them correctly and to
> copy the error, but in the process it worked ok, I mean, I open the
> m2016a version in the m2018a, updated with "update_casper_blocks",
> save the m2018a model, close everything, reopen the recently updated
> and saved m2018a model, and it compiled ok...
> I guess that with the several tests that I did I have some mix of
> versions
>
> If I find what the actual problem was I'll let you know.
>
> Thanks!
>
>
>
> El mar, 2 feb 2021 a las 3:05, Adam Isaacson ()
> escribió:
> >
> > Hi Guillermo,
> >
> > Interesting. Please send me the following:
> >
> > 1) screen capture of the errors you get before you do
> "update_casper_blocks".
> > 2) please attach your R2016a slx file
> > 3) please attach your new saved R2018a slx file.
> >
> > I will then investigate and get back to you.
> >
> > Kind regards,
> >
> > Adam
> >
> >
> > On Tue, 02 Feb 2021, 2:59 AM Guillermo Gancio, 
> wrote:
> >>
> >> Dearest CasperAmigos,
> >>
> >> I'm having the following issue, I'm trying to compile a simulink
> >> design from m2016a into a m2018a, if I try to compile it directly I
> >> got several errors, but if I do "update_casper_blocks(bdroot)" the
> >> model compiles ok..
> >>
> >> Now if I save the updated model and reopen it again, I have to do
> >> "update_casper_blocks(bdroot)" again, what I mean is that every time
> >> that the model is opened, I have to update it with
> >> update_casper.--
> >>
> >> I'm not sure if this is the normal procedure, or if there is a way to
> >> save the model in order to avoid the "update." every time.
> >>
> >> Cheers.
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "casper@lists.berkeley.edu" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to casper+unsubscr...@lists.berkeley.edu.
> >> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CA%2BEePfQc_e33QqiK2MZvLV_wjYaRGCNkOioN%3DJAnKJKgXBH3xw%40mail.gmail.com
> .
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "casper@lists.berkeley.edu" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to casper+unsubscr...@lists.berkeley.edu.
> > To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnHQU_CE%3D0qRgs7vQwEBKbLqWCQdDfyje149C1zK0cVptQ%40mail.gmail.com
> .
>
>
>
> --
> Instituto Argentino de Radioastronomia
> [Argentine Institute of Radioastronomy]
>
> Guillermo M. Gancio
> Responsable Área Observatorio
> [Head of Observatory]
>
> Tel: (0054-0221) 482-4903 Int: 106
> Mail laboralggan...@iar.unlp.edu.ar
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CA%2BEePfSPOvCEF9sbKpk66%3DUKwmeBYnApSOtp-UVHBpCvzzhMrA%40mail.gmail.com
> .
>

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

Re: [casper] New setup installation problems (python setup.py egg_info" failed with error code 1)

[Adam Isaacson]

Hi Kaj,

Well, your virtualenv looks correct. The packages are the correct ones. I
assume all is good with the virtualenv. I noticed the following on your
side that you have this constructor error I was talking about - did you
edit the castro.py file that I listed in my previous thread or are you
using the casper-astro/mlib_devel (casper-astro-soak-test branch which
contains my castro.py edit fix)? Please send me a more complete screen
capture from the time you run Matlab to when the error occurs. Also send me
your startsg.local file, so that I can investigate.

I assume you did the following under "mlib_devel":

0) Make sure you are using my latest castro.py changes, as explained above
and previous email thread - "5) You will need to edit line 32 of castro.py
(located in the same folder as mlib_devel/jasper_library), so that it is "c
= yaml.load(fh, Loader=yaml.Loader) . Refer to
https://github.com/yaml/pyyaml/issues/266
<https://github.com/yaml/pyyaml/issues/266>for more info on this version
change issue. I tested the build with my original working virtualenv and
the newly generated virtualenv and it works for both. Don't worry, I will
be committing this change once I have done a bit more investigation - maybe
adding versions in requirements.txt is not a bad idea for future support".
1) Under "mlib_devel" ./startsg to set your environment and run Matlab.
2) You opened the slx file
3) You ran "jasper_frontend" in the Matlab command window.
4) You opened another terminal
5) In the new terminal under "mlib_devel" you typed "source startsg
startsg.local". This sets up the environment variables using your new
terminal.
6) You cut and paste the last line out of the matlab command window and you
pasted it into the new terminal and then build.

I think your issue according to your screen capture is that you don't have
the castro.py mod I made. Please check and let me know.

In terms of providing virtual environments. I think what we need to do is
provide VMs without Matlab and Vivado licensing, so the users can just
start. A few years back we investigated containers, which are much smaller
hard disk wise. Alas, we had issues getting the container to work on other
machines. VMs are bulky, but may be the best answer. We will discuss during
the next CASPER meeting.

Kaj, I think you are close! Hang in there :).

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, Feb 2, 2021 at 8:00 PM Kaj Wiik  wrote:

> Hi all,
>
> An idea: what if you shipped a working python venv as tgz with the
> toolflow?
>
> Cheers,
> Kaj
>
> On 02/02/2021 18:33, Kaj Wiik wrote:
> > Hi Adam,
> >
> > The screen capture of ../casper-venv/lib64/python3.5/site-packages is
> attached.
> >
> > When I opened the test_snap.slx, I got several
> > "Warning: did not properly cleanup after previous model termination"
> > errors. Maybe there are some leftovers in hidden dirs from the previous
> incarnation of the Ubuntu system (homedir is not destroyed). I of course
> removed all visible files and dirs... I think this is not related to the
> problem below.
> >
> > I then started venv in another terminal, "cd ~test", from there "source
> ../mlib_devel/startsg" and ran
> > "
> > /home/kjwiik/casper-venv/bin/python
> /home/kjwiik/mlib_devel/jasper_library/exec_flow.py -m
> /home/kjwiik/mlib_devel/jasper_library/test_models/test_snap.slx
> --middleware --backend --software
> > "
> > I got unfortunately an error message and a number of deprecation
> warnings, screen capture is attached.
> >
> > Thanks,
> > Kaj
> >
> > On 2/1/21 6:29 PM, Adam Isaacson wrote:
> >> Hi Kaj,
> >>
> >> Please can you go to your virtual environment directory:
> ../casper-venv/libpython3.5/site-packages and do a "ls -la". It will list
> all the packages installed. There should be colorlog, lxml, numpy, odict,
> pip, pkg_resources,pyaml,setuptools and yaml python packages. Please can
> you send me a screen capture, thanks?
> >>
> >> It looks like your pyyaml did eventually install correctly though at
> the end - let's assume for now all is good with your virtual environment.
> You may be able to continue trying to build your slx file in the toolflow
> now. Try the next step.
> >>
> >> 1)
> https://casper-toolflow.readthedocs.io/en/latest/src/Configuring-the-Toolflow.html
> >> 2)
> https://casper-toolflow.readthedocs.io/en/latest/src/Running-the-Toolflow.html
> >>
> >> Let me know what you get.
> >>
> >> Kind regards,
> >>
>

Re: [casper] Issue compiling design from previous version.

[Adam Isaacson]

Hi Guillermo,

Interesting. Please send me the following:

1) screen capture of the errors you get before you do
"update_casper_blocks".
2) please attach your R2016a slx file
3) please attach your new saved R2018a slx file.

I will then investigate and get back to you.

Kind regards,

Adam


On Tue, 02 Feb 2021, 2:59 AM Guillermo Gancio,  wrote:

> Dearest CasperAmigos,
>
> I'm having the following issue, I'm trying to compile a simulink
> design from m2016a into a m2018a, if I try to compile it directly I
> got several errors, but if I do "update_casper_blocks(bdroot)" the
> model compiles ok..
>
> Now if I save the updated model and reopen it again, I have to do
> "update_casper_blocks(bdroot)" again, what I mean is that every time
> that the model is opened, I have to update it with
> update_casper.--
>
> I'm not sure if this is the normal procedure, or if there is a way to
> save the model in order to avoid the "update." every time.
>
> Cheers.
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CA%2BEePfQc_e33QqiK2MZvLV_wjYaRGCNkOioN%3DJAnKJKgXBH3xw%40mail.gmail.com
> .
>

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

Re: [casper] New setup installation problems (python setup.py egg_info" failed with error code 1)

[Adam Isaacson]

Hi Kaj,

Please can you go to your virtual environment directory:
../casper-venv/libpython3.5/site-packages and do a "ls -la". It will list
all the packages installed. There should be colorlog, lxml, numpy, odict,
pip, pkg_resources,pyaml,setuptools and yaml python packages. Please can
you send me a screen capture, thanks?

It looks like your pyyaml did eventually install correctly though at the
end - let's assume for now all is good with your virtual environment. You
may be able to continue trying to build your slx file in the toolflow now.
Try the next step.

1)
https://casper-toolflow.readthedocs.io/en/latest/src/Configuring-the-Toolflow.html
2)
https://casper-toolflow.readthedocs.io/en/latest/src/Running-the-Toolflow.html

Let me know what you get.

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, Feb 1, 2021 at 6:13 PM Kaj Wiik  wrote:

> Sorry, I sent a wrong screenshot, here's a correct one...
> https://seafile.utu.fi/f/50b186da6c404a7db4ee
>
> Kaj
>
> On 2/1/21 6:05 PM, Kaj Wiik wrote:
> > Hi all!
> >
> > Many thnks for looking into this, I have followed the emails over the
> > week but couldn't do any testing because of other commitments.
> >
> > I tried to follow the suggested procedure accurately but still got an
> > error. Well, in addition to that I ran update and had to 'apt-get
> > install python3-venv' to get venv working.
> >
> > The error I got is 'Running setup.py bdist_wheel for PyYAML ... error',
> > see the attached screenshot for the full log (here's a link to the log:
> > https://seafile.utu.fi/f/a464c7711d6e441c8898/?dl=1).
> >
> > As I am not a python user (Julia, C and Perl only...), I have no idea
> > what wheels it is trying to turn ;-).
> >
> > Any ideas?
> >
> > Thanks again,
> > Kaj
> >
> >
> > On 1/29/21 12:42 PM, Adam Isaacson wrote:
> >> Okay, so it turns out that creating the virtual environment for python
> >> using "virtualen -p python3 " does not work. This is what
> >> you need to do in order to create a successful virtual environment and
> >> get your designs to build. I tested it on a brand new virtual
> >> environment and it works. Thanks to Clifford van Wyk (Peralex), Morag
> >> Brown and Jack Hickish for their assistance. The docs will definitely
> >> need to be updated - we will add this to the agenda for the CASPER
> >> meeting.
> >>
> >> The following needs to be done if you want to generate a proper
> >> virtual environment that will build in the toolflow - Kaj, I recommend
> >> the below way:
> >>
> >> 1) Create the virtual environment: "python3 -m venv ".
> >> The old way of using virtualenv -p python 3  just
> >> doesn't work. Thanks to Jack and Morag for pointing this out to me.
> >> 2) Activate the environment: "source /bin/activate"
> >> 3) Go to the mlib_devel directory and edit the requirements.txt file.
> >> It should have "numpy<1.19" (thanks for your sleuth work, Jack!). Now
> >> save the file.
> >> 4) Go to mlib_devel directory and type exactly: "pip install -r
> >> requirements.txt". This will install without error or issues. if you
> >> check the site-packages in the virtual environment you will see what I
> >> mean - all the python packages will be installed properly in your
> >> virtual environment.
> >> 5) You will need to edit line 32 of castro.py (located in the same
> >> folder as mlib_devel/jasper_library), so that it is "c = yaml.load(fh,
> >> Loader=yaml.Loader) . Refer to
> >> https://github.com/yaml/pyyaml/issues/266
> >> <https://github.com/yaml/pyyaml/issues/266>for more info on this
> >> version change issue. I tested the build with my original working
> >> virtualenv and the newly generated virtualenv and it works for both.
> >> Don't worry, I will be committing this change once I have done a bit
> >> more investigation - maybe adding versions in requirements.txt is not
> >> a bad idea for future support.
> >>
> >> You can now start your matlab session and build your designs :). Hooray!
> >>
> >
>
> --
> 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/4f852e11-4725-c8e8-03fe-d84add6a4198%40utu.fi
> .
>

-- 
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%3DnHacLga2eCWexYa5RChnq-pJ3muqWb_rQx%3Dd3W3Jk-dkw%40mail.gmail.com.

Re: [casper] New setup installation problems (python setup.py egg_info" failed with error code 1)

[Adam Isaacson]

Hi Guillermo,

Thank you for the email. This is very useful information. I am glad the
additional documentation helped. CASPER is looking at porting the current
toolflow to Ubuntu 18.04LTS and it seems like you have already got that
working - well done. Of course, we would need to compile all hardware
platforms and make sure that they are still functional before we say Ubuntu
18.04 is good to go :).

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, Jan 29, 2021 at 9:45 PM Guillermo Gancio  wrote:

> Hi CasperAmigos,
>
> I want to thank you for sharing all this information that is extremely
> helpful, I was having  this problem for some time that I thought was
> due to my lack of experience, and it turns out that... it was due to
> my lack of experience but also for these configs...
> I did all the steps mentioned, on the following configuration and I
> was able to compile the SNAP tutorials. I couldn't test it on HW for
> now.
>
> Ubuntu 18.04.5 LTS
> Matlab 2018a
> Xilinx vivado 2019.1.3
>
> I hope this information is a bit useful.
>
> Cheers.
>
>
>
>
>
> El vie, 29 ene 2021 a las 7:40, Adam Isaacson ()
> escribió:
> >
> > Hi Casperites,
> >
> > Just some corrections from my previous email below - got the numpy
> version update incorrect:
> >
> > Okay, so it turns out that creating the virtual environment for python
> using "virtualen -p python3 " does not work. This is what you
> need to do in order to create a successful virtual environment and get your
> designs to build. I tested it on a brand new virtual environment and it
> works. Thanks to Clifford van Wyk (Peralex), Morag Brown and Jack Hickish
> for their assistance. The docs will definitely need to be updated - we will
> add this to the agenda for the CASPER meeting.
> >
> > The following needs to be done if you want to generate a proper virtual
> environment that will build in the toolflow - Kaj, I recommend the below
> way:
> >
> > 1) Create the virtual environment: "python3 -m venv ".
> The old way of using virtualenv -p python 3  just doesn't
> work. Thanks to Jack and Morag for pointing this out to me.
> > 2) Activate the environment: "source /bin/activate"
> > 3) Go to the mlib_devel directory and edit the requirements.txt file. It
> should have "numpy<1.19" (thanks for your sleuth work, Jack!). Now save the
> file.
> > 4) Go to mlib_devel directory and type exactly: "pip install -r
> requirements.txt". This will install without error or issues. if you check
> the site-packages in the virtual environment you will see what I mean - all
> the python packages will be installed properly in your virtual environment.
> > 5) You will need to edit line 32 of castro.py (located in the same
> folder as mlib_devel/jasper_library), so that it is "c = yaml.load(fh,
> Loader=yaml.Loader) . Refer to https://github.com/yaml/pyyaml/issues/266
> for more info on this version change issue. I tested the build with my
> original working virtualenv and the newly generated virtualenv and it works
> for both. Don't worry, I will be committing this change once I have done a
> bit more investigation - maybe adding versions in requirements.txt is not a
> bad idea for future support.
> >
> > You can now start your matlab session and build your designs :). Hooray!
> >
> > NB: I am now going to commit and do a pull request for casper-astro to
> review.
> >
> > 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, Jan 28, 2021 at 9:41 PM Adam Isaacson 
> wrote:
> >>
> >> Hi Casperites,
> >>
> >> Okay, so it turns out that creating the virtual environment for python
> using "virtualen -p python3 " does not work. This is what you
> need to do in order to create a successful virtual environment and get your
> designs to build. I tested it on a brand new virtual environment and it
> works. Thanks to Clifford van Wyk (Peralex), Morag Brown and Jack Hickish
> for their assistance. The docs will definitely need to be updated - we will
> add this to the agenda for the CASPER meeting.
> >>
> >> The following needs to be done if you want to generate a proper virtual
> environment that will build in the toolflow - Kaj, I recommend the below
> way:
> >>
> >> 1) Create the virtual environment: "pyth

Re: [casper] New setup installation problems (python setup.py egg_info" failed with error code 1)

[Adam Isaacson]

Hi Casperites,

Just some corrections from my previous email below - got the numpy version
update incorrect:

Okay, so it turns out that creating the virtual environment for python
using "virtualen -p python3 " does not work. This is what you
need to do in order to create a successful virtual environment and get your
designs to build. I tested it on a brand new virtual environment and it
works. Thanks to Clifford van Wyk (Peralex), Morag Brown and Jack Hickish
for their assistance. The docs will definitely need to be updated - we will
add this to the agenda for the CASPER meeting.

The following needs to be done if you want to generate a proper virtual
environment that will build in the toolflow - Kaj, I recommend the below
way:

1) Create the virtual environment: "python3 -m venv ". The
old way of using virtualenv -p python 3  just doesn't work.
Thanks to Jack and Morag for pointing this out to me.
2) Activate the environment: "source /bin/activate"
3) Go to the mlib_devel directory and edit the requirements.txt file. It
should have "numpy<1.19" (thanks for your sleuth work, Jack!). Now save the
file.
4) Go to mlib_devel directory and type exactly: "pip install -r
requirements.txt". This will install without error or issues. if you check
the site-packages in the virtual environment you will see what I mean - all
the python packages will be installed properly in your virtual environment.
5) You will need to edit line 32 of castro.py (located in the same folder
as mlib_devel/jasper_library), so that it is "c = yaml.load(fh,
Loader=yaml.Loader) . Refer to https://github.com/yaml/pyyaml/issues/266
<https://github.com/yaml/pyyaml/issues/266>for more info on this version
change issue. I tested the build with my original working virtualenv and
the newly generated virtualenv and it works for both. Don't worry, I will
be committing this change once I have done a bit more investigation - maybe
adding versions in requirements.txt is not a bad idea for future support.

You can now start your matlab session and build your designs :). Hooray!

NB: I am now going to commit and do a pull request for casper-astro to
review.

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, Jan 28, 2021 at 9:41 PM Adam Isaacson  wrote:

> Hi Casperites,
>
> Okay, so it turns out that creating the virtual environment for python
> using "virtualen -p python3 " does not work. This is what you
> need to do in order to create a successful virtual environment and get your
> designs to build. I tested it on a brand new virtual environment and it
> works. Thanks to Clifford van Wyk (Peralex), Morag Brown and Jack Hickish
> for their assistance. The docs will definitely need to be updated - we will
> add this to the agenda for the CASPER meeting.
>
> The following needs to be done if you want to generate a proper virtual
> environment that will build in the toolflow - Kaj, I recommend the below
> way:
>
> 1) Create the virtual environment: "python3 -m venv ". The
> old way of using virtualenv -p python 3  just doesn't work.
> Thanks to Jack and Morag for pointing this out to me.
> 2) Activate the environment: "source /bin/activate"
> 3) Go to the mlib_devel directory and edit the requirements.txt file. It
> should have "numpy<1.9" (thanks for your sleuth work, Jack!). Now save
> the file.
> 3) Go to mlib_devel directory and type exactly: "pip install -r
> requirements.txt". This will install without error or issues. if you check
> the site-packages in the virtual environment you will see what I mean - all
> the python packages will be installed properly in your virtual environment.
> 4) You will need to edit line 32 of castro.py (located in the same folder
> as mlib_devel/jasper_library), so that it is "c = yaml.load(fh,
> Loader=yaml.Loader) . Refer to https://github.com/yaml/pyyaml/issues/266
> <https://github.com/yaml/pyyaml/issues/266>for more info on this version
> change issue. I tested the build with my original working virtualenv and
> the newly generated virtualenv and it works for both. Don't worry, I will
> be committing this change once I have done a bit more investigation - maybe
> adding versions in requirements.txt is not a bad idea for future support.
>
> You can now start your matlab session and build your designs :). Hooray!
>
> 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, Jan 28, 2021 at 9:55 AM Adam Isaacson  wrote:
>
>> Hi David,
>>
>> Yes, it was a bit of a rabbit

Re: [casper] New setup installation problems (python setup.py egg_info" failed with error code 1)

[Adam Isaacson]

Hi Casperites,

Okay, so it turns out that creating the virtual environment for python
using "virtualen -p python3 " does not work. This is what you
need to do in order to create a successful virtual environment and get your
designs to build. I tested it on a brand new virtual environment and it
works. Thanks to Clifford van Wyk (Peralex), Morag Brown and Jack Hickish
for their assistance. The docs will definitely need to be updated - we will
add this to the agenda for the CASPER meeting.

The following needs to be done if you want to generate a proper virtual
environment that will build in the toolflow - Kaj, I recommend the below
way:

1) Create the virtual environment: "python3 -m venv ". The
old way of using virtualenv -p python 3  just doesn't work.
Thanks to Jack and Morag for pointing this out to me.
2) Activate the environment: "source /bin/activate"
3) Go to the mlib_devel directory and edit the requirements.txt file. It
should have "numpy<1.9" (thanks for your sleuth work, Jack!). Now save the
file.
3) Go to mlib_devel directory and type exactly: "pip install -r
requirements.txt". This will install without error or issues. if you check
the site-packages in the virtual environment you will see what I mean - all
the python packages will be installed properly in your virtual environment.
4) You will need to edit line 32 of castro.py (located in the same folder
as mlib_devel/jasper_library), so that it is "c = yaml.load(fh,
Loader=yaml.Loader) . Refer to https://github.com/yaml/pyyaml/issues/266
<https://github.com/yaml/pyyaml/issues/266>for more info on this version
change issue. I tested the build with my original working virtualenv and
the newly generated virtualenv and it works for both. Don't worry, I will
be committing this change once I have done a bit more investigation - maybe
adding versions in requirements.txt is not a bad idea for future support.

You can now start your matlab session and build your designs :). Hooray!

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, Jan 28, 2021 at 9:55 AM Adam Isaacson  wrote:

> Hi David,
>
> Yes, it was a bit of a rabbit hole exercise, but we (between Kaj and
> Peralex) worked our way through it and now debugging other issues :).
>
> You raise a valid point. There is no reason we shouldn't port to Ubuntu
> 18.04LTS or higher. It makes sense with what Kaj and Peralex are
> experiencing.
>
> Please note, my team (SARAO) is baselining the SKARAB work at Ubuntu
> 16.04LTS. We are coming to the end of the MeerKAT development for the F and
> X engines. I do believe there are those that have got the toolflow to work
> on Ubuntu 18.04LTS. I know Wesley New has struggled to get the SKARAB
> toolflow to work using Ubuntu 18.04LTS. I haven't tried it on my side yet.
>
> My team's focus this year is to update the toolflow to work with Vitis and
> target those Alveo boards. This will definitely involve moving to a newer
> version of Ubuntu. For now that is likely to be Ubuntu 18.04LTS, Vitis
> 2020.2 and Vivado 2020.2.
>
> I think this is something we should discuss at the next CASPER meeting on
> the 11th Feb. We should allocate a resource for this, but SARAO is focusing
> on other areas for now.
>
> Thanks for your email :).
>
> 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, Jan 28, 2021 at 12:09 AM David MacMahon 
> wrote:
>
>> Wow, thanks for these truly awesome forensics, Adam!  It sounds like you
>> went down a rabbit hole and lived to tell the tale.  I'm sure many of us
>> will benefit from these details.
>>
>> Sorry if this is a FAQ, but what are the prospects for moving the tool
>> flow beyond Ubuntu 16.04?  That release is really starting to show its age,
>> especially since its stock Python3 is only 3.5.  (Though to be fair, Python
>> is at least partly to blame due to its poor track record on version
>> compatibility.  :P)
>>
>> Cheers,
>> Dave
>>
>> On Jan 27, 2021, at 13:00, Adam Isaacson  wrote:
>>
>> Hi Kaj,
>>
>> I am including the CASPER community in this email thread as it applies to
>> everyone.
>>
>> Interesting, so I have run into another person with the same virtualenv
>> install issue that you encountered as shown in red below. I have been
>> helping him debug too on a new machine and I am pleased to say that his
>> virtualenv is now working. It seems like the new Ubuntu 16.04LTS installs
>> come with a newer version of virtualenv wh

Re: [casper] New setup installation problems (python setup.py egg_info" failed with error code 1)

[Adam Isaacson]

Hi David,

Yes, it was a bit of a rabbit hole exercise, but we (between Kaj and
Peralex) worked our way through it and now debugging other issues :).

You raise a valid point. There is no reason we shouldn't port to Ubuntu
18.04LTS or higher. It makes sense with what Kaj and Peralex are
experiencing.

Please note, my team (SARAO) is baselining the SKARAB work at Ubuntu
16.04LTS. We are coming to the end of the MeerKAT development for the F and
X engines. I do believe there are those that have got the toolflow to work
on Ubuntu 18.04LTS. I know Wesley New has struggled to get the SKARAB
toolflow to work using Ubuntu 18.04LTS. I haven't tried it on my side yet.

My team's focus this year is to update the toolflow to work with Vitis and
target those Alveo boards. This will definitely involve moving to a newer
version of Ubuntu. For now that is likely to be Ubuntu 18.04LTS, Vitis
2020.2 and Vivado 2020.2.

I think this is something we should discuss at the next CASPER meeting on
the 11th Feb. We should allocate a resource for this, but SARAO is focusing
on other areas for now.

Thanks for your email :).

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, Jan 28, 2021 at 12:09 AM David MacMahon  wrote:

> Wow, thanks for these truly awesome forensics, Adam!  It sounds like you
> went down a rabbit hole and lived to tell the tale.  I'm sure many of us
> will benefit from these details.
>
> Sorry if this is a FAQ, but what are the prospects for moving the tool
> flow beyond Ubuntu 16.04?  That release is really starting to show its age,
> especially since its stock Python3 is only 3.5.  (Though to be fair, Python
> is at least partly to blame due to its poor track record on version
> compatibility.  :P)
>
> Cheers,
> Dave
>
> On Jan 27, 2021, at 13:00, Adam Isaacson  wrote:
>
> Hi Kaj,
>
> I am including the CASPER community in this email thread as it applies to
> everyone.
>
> Interesting, so I have run into another person with the same virtualenv
> install issue that you encountered as shown in red below. I have been
> helping him debug too on a new machine and I am pleased to say that his
> virtualenv is now working. It seems like the new Ubuntu 16.04LTS installs
> come with a newer version of virtualenv which is not compatible with python
> 3.5 - fun, fun, fun. This definitely applies to all Casperites who are
> installing the toolflow on their new machines.
>
> kjwiik@casperx:~/work$ virtualenv -p python3 casper_venv
> Traceback (most recent call last):
>File "/usr/local/bin/virtualenv", line 7, in 
>  from virtualenv.__main__ import run_with_catch
>File
> "/home/kjwiik/.local/lib/python3.5/site-packages/virtualenv/__init__.py",
> line 3, in 
>  from .run import cli_run, session_via_cli
>File
> "/home/kjwiik/.local/lib/python3.5/site-packages/virtualenv/run/__init__.py",
> line 13, in 
>  from .plugin.activators import ActivationSelector
>File
> "/home/kjwiik/.local/lib/python3.5/site-packages/virtualenv/run/plugin/activators.py",
> line 6, in 
>  from .base import ComponentBuilder
>File
> "/home/kjwiik/.local/lib/python3.5/site-packages/virtualenv/run/plugin/base.py",
> line 9, in 
>  from importlib_metadata import entry_points
>File
> "/home/kjwiik/.local/lib/python3.5/site-packages/importlib_metadata/__init__.py",
> line 88
>  dist: Optional['Distribution'] = None
>  ^
> SyntaxError: invalid syntax
> kjwiik@casperx:~/work$
>
> I want you to check the following versions for me:
>
> 1) virtualenv -> type "virtualenv --version" at the prompt. You should get
> 16.7.5. If not then you will need to uninstall the virtualenv by typing:
> "pip3 uninstall virtualenv" and then we will need to install the 16.7.5
> version. To install an exact version then type: "pip3 install
> virtualenv==16.7.5". The use of "sudo" with "-H" arguments may or may not
> be needed. The installs will guide you.
>
> 2) What is your Ubuntu 16.04LTS version? -> type "lsb_release -a". I am
> using Ubuntu 16.04.7 LTS, Xenial.
>
> 3) What is your pip3 version? -> type "pip3 --version". I am using pip
> 8.1.1.
>
> 4) What is your python version? -> type: "python --version". I am using
> python version 2.7.12
>
> 5) What is your python3 version? -> type: "python3 --version". I am using
> python3 version 3.5.2.
>
> Please make sure all these versions are the same before continuing. I
> suspect that the latest Ubuntu 16.04LTS installs have made some upgrades
> t

Re: [casper] New setup installation problems (python setup.py egg_info" failed with error code 1)

[Adam Isaacson]

Hi Kaj,

I am including the CASPER community in this email thread as it applies to
everyone.

Interesting, so I have run into another person with the same virtualenv
install issue that you encountered as shown in red below. I have been
helping him debug too on a new machine and I am pleased to say that his
virtualenv is now working. It seems like the new Ubuntu 16.04LTS installs
come with a newer version of virtualenv which is not compatible with python
3.5 - fun, fun, fun. This definitely applies to all Casperites who are
installing the toolflow on their new machines.

kjwiik@casperx:~/work$ virtualenv -p python3 casper_venv
Traceback (most recent call last):
   File "/usr/local/bin/virtualenv", line 7, in 
 from virtualenv.__main__ import run_with_catch
   File
"/home/kjwiik/.local/lib/python3.5/site-packages/virtualenv/__init__.py",
line 3, in 
 from .run import cli_run, session_via_cli
   File
"/home/kjwiik/.local/lib/python3.5/site-packages/virtualenv/run/__init__.py",
line 13, in 
 from .plugin.activators import ActivationSelector
   File
"/home/kjwiik/.local/lib/python3.5/site-packages/virtualenv/run/plugin/activators.py",
line 6, in 
 from .base import ComponentBuilder
   File
"/home/kjwiik/.local/lib/python3.5/site-packages/virtualenv/run/plugin/base.py",
line 9, in 
 from importlib_metadata import entry_points
   File
"/home/kjwiik/.local/lib/python3.5/site-packages/importlib_metadata/__init__.py",
line 88
 dist: Optional['Distribution'] = None
 ^
SyntaxError: invalid syntax
kjwiik@casperx:~/work$

I want you to check the following versions for me:

1) virtualenv -> type "virtualenv --version" at the prompt. You should get
16.7.5. If not then you will need to uninstall the virtualenv by typing:
"pip3 uninstall virtualenv" and then we will need to install the 16.7.5
version. To install an exact version then type: "pip3 install
virtualenv==16.7.5". The use of "sudo" with "-H" arguments may or may not
be needed. The installs will guide you.

2) What is your Ubuntu 16.04LTS version? -> type "lsb_release -a". I am
using Ubuntu 16.04.7 LTS, Xenial.

3) What is your pip3 version? -> type "pip3 --version". I am using pip
8.1.1.

4) What is your python version? -> type: "python --version". I am using
python version 2.7.12

5) What is your python3 version? -> type: "python3 --version". I am using
python3 version 3.5.2.

Please make sure all these versions are the same before continuing. I
suspect that the latest Ubuntu 16.04LTS installs have made some upgrades
that are incompatible.

Once these versions are as above then try the following step to create the
virtual env:

1) Type: "virtualenv -p python3 ". This should create
a folder with the same name as "name_of_virtual_env". There should be no
issues with the install. It should complete without issues.
2) To activate the virtual environment -> type: "source
//bin/activate
3) Once activated then you can deactivate it by typing "deactivate".
4) If the virtual environment is activated then if you type "python" you
should get version 3.5.2
5) If the virtual environment is deactivated then if you type "python" you
should get 2.7.12.

I think if you can achieve this then you are ready to install the toolflow
by following these steps:

1)
https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html#
2)
https://casper-toolflow.readthedocs.io/en/latest/src/How-to-install-Matlab.html
3)
https://casper-toolflow.readthedocs.io/en/latest/src/How-to-install-Xilinx-Vivado.html
4)
https://casper-toolflow.readthedocs.io/en/latest/src/Configuring-the-Toolflow.html
5)
https://casper-toolflow.readthedocs.io/en/latest/src/Running-the-Toolflow.html
6) https://casper-toolflow.readthedocs.io/projects/casperfpga/en/latest/ (This
is how to install casperfpga)

@Jonathon Kocz  : we will need to update the docs to
reflect this new information. I will wait until both parties have working
systems before updating the ReadtheDocs. One of the parties is using a
proxy and has some additional information on how to install with a proxy
that will be useful for other casperites.

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 Sun, Jan 24, 2021 at 8:09 PM Adam Isaacson  wrote:

> Hi Kaj,
>
> Are you running a python virtual environment using python 3.5? Once you
> start the virtual environment and type python you should see version 3.5.2
> or something like that. It doesn't look like it. Here is some documentation
> that should be helpful - make sure you follow these steps:
>
> 1) How to configure the toollflow:
> https://casper-toolflow.readthe

Re: [casper] New setup installation problems (python setup.py egg_info" failed with error code 1)

[Adam Isaacson]

Hi Kaj,

Are you running a python virtual environment using python 3.5? Once you
start the virtual environment and type python you should see version 3.5.2
or something like that. It doesn't look like it. Here is some documentation
that should be helpful - make sure you follow these steps:

1) How to configure the toollflow:
https://casper-toolflow.readthedocs.io/en/latest/src/Configuring-the-Toolflow.html
2) Running the toolflow:
https://casper-toolflow.readthedocs.io/en/latest/src/Running-the-Toolflow.html

Does your startsg.local file look like this:

export XILINX_PATH=/opt/Xilinx/Vivado/2019.1export
MATLAB_PATH=/usr/local/MATLAB/R2018aexport PLATFORM=lin64export
JASPER_BACKEND=vivado
# over-ride the MATLAB libexpat version with the OS's one.# Using
LD_PRELOAD=${LD_PRELOAD}:"..." rather than just LD_PRELOAD="..."#
ensures that we preserve any other settings already configuredexport
LD_PRELOAD=${LD_PRELOAD}:"/usr/lib/x86_64-linux-gnu/libexpat.so"
# Activate a custom python environment on loadexport
CASPER_PYTHON_VENV_ON_START=/home/user/work/casper_venv


You must run everything from the virtual environment in order to work. The
last line in the startsg.local will automatically start your virtual
environment session, but you can also do it manually e.g. source
~/venv/bin/activate will give you the following "(venv)
aisaacson@adam-cm:~/work/git_work/ska-sa/2019_1/mlib_devel$".
The red (venv) tells you that you are in the virtual python environment.
Remember you also need to install requirements.txt while the virtual
environment is running.

Then all you really need to do is run "./startsg" at the prompt and it
should open up Matlab where you can build your slx file by typing in
"jasper" or "jasper_frontend. if you use "jasper_frontend" then it will
just compile sysgen and the simulink frontend. You can then open another
terminal session and under "mlib_devel" type "source startsg
startsg.local". This will make sure everything is in your path. You can
then copy and paste the exec_flow.py command from the Matlab command window
and then it should build the middle end and backend. Remember to start the
virtual environment for this terminal window as well. This should all be in
the above docs, but if you are still struggling then please send us a step
by step terminal screen capture, so we can see if you are doing everything
correctly, thanks.

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 Sun, Jan 24, 2021 at 7:15 PM Kaj Wiik  wrote:

> Hi!
>
> A followup...
>
> I was able to start (but not run, see below...) the toolflow with the
> following modifications:
>
> - to run jasper_frontend, I had to install python-yaml. I tried first to
> add python3-yaml but it seems that the toolflow is mixing python2 and
> python3?
>
> - I added 'export LM_LICENSE_FILE=/opt/Xilinx/Xilinx.lic' and
> 'export MLIB_DEVEL_PATH=~/mlib_devel' to startsg.local
>
> When matlab gave a command line and I run it, I got the following error
> message that I do not (yet!) understand:
>
> kjwiik@casperx:~/tmp$ source ../mlib_devel/startsg.local
> kjwiik@casperx:~/tmp$ /usr/bin/python
> /home/kjwiik/mlib_devel/jasper_library/exec_flow.py -m
> /home/kjwiik/mlib_devel/jasper_library/test_models/test_zcu111.slx
> --middleware --backend --software
> Starting compile
> Starting Toolflow!
> Frontend is simulink
> Setting compile directory:
> /home/kjwiik/mlib_devel/jasper_library/test_models/test_zcu111
> /home/kjwiik/mlib_devel/jasper_library/platforms/zcu111.yaml
> {'backend_target': 'vivado', 'name': 'zcu111', 'fpga':
> 'xczu28dr-ffvg1517-2-e', 'mmbus_architecture': 'AXI4-Lite', 'sources':
> [], 'cfgbvs': 'GND', 'provides': ['sys_clk'], 'config_voltage': 1.8,
> 'pins': {'clk_100_p': {'loc': 'AM15', 'iostd': 'LVDS'}, 'clk_100_n':
> {'loc': 'AN15', 'iostd': 'LVDS'}, 'led': {'loc': ['AR13', 'AP13',
> 'AR16', 'AP16', 'AP15', 'AN16', 'AN17', 'AV15'], 'iostd': 'LVCMOS18'}},
> 'mmbus_base_address': 2684354560, 'mmbus_address_alignment': 4,
> 'manufacturer': 'Xilinx', 'constraints': []}
> sw_reg
> Traceback (most recent call last):
>File "/home/kjwiik/mlib_devel/jasper_library/exec_flow.py", line 197,
> in 
>  tf.gen_periph_objs()
>File "/home/kjwiik/mlib_devel/jasper_library/toolflow.py", line 363,
> in gen_periph_objs
>  self.peripherals[pk], self.plat))
>File
> "/home/kjwiik/mlib_devel/jasper_library/yellow_blocks/yellow_block.py",
> line 65, in make_block
>  return cls(blk,platform,hdl_root=hdl_root)
>File
> "/home/kjwiik/mlib_devel/jasper_library/yellow_blocks/yellow_block.py",
> line 92,

Re: [casper] New setup installation problems (python setup.py egg_info" failed with error code 1)

[Adam Isaacson]

Hi Casperites,

For those of you that want to join the CASPER slack group and haven't yet
then here is a general invite -
https://join.slack.com/t/casper-astro/shared_invite/zt-l6cfvyt2-ZRkrj2UZV_sX_iKO_Vr95A.
It is valid for 31 days.

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, Jan 22, 2021 at 7:24 PM Jonathon Kocz  wrote:

> Hi Kaj,
>
> I have invited you and Derek to the casper slack - please let me know if
> you run into any trouble.
>
> A couple of notes on the ZCU111: The ZCU111 branch on casper-astro is a
> bit out of date. Wei Liu recently completed yellow blocks for the ZCU111.
> These have not yet been merged into the main casper repository I hope to do
> this merge into the soak-test branch in the near future). Until then, for
> those that missed Wei's email, they can be found here:
> https://github.com/liuweiseu/ZCU111 As far as I am aware this is the most
> up to date code for the ZCU111 in the casper toolflow.
>
> There are several people subscribed to the ZCU111 casper slack channel,
> though there hasn't really been communication on it since inception,
> however, some discussion regarding the ZCU111 has taken place on the #rfsoc
> channel, and I recommend checking out the history there as well.
>
> Cheers,
> Jonathon
>
> On Fri, 22 Jan 2021 at 08:50, Kaj Wiik  wrote:
>
>> Hi!
>>
>> I tried a bit different route: I installed python3-numpy and
>> python3-setuptools-git Ubuntu packages first and commented out numpy
>> from requirements.txt. At least the installation went fine using these
>> workarounds.
>>
>> About ZCU111 Slack channel, I am very interested (and my colleague
>> derek.mc...@utu.fi also), could you please send us an invitation?
>>
>> Many thanks for your kind help!
>>
>> Kaj
>>
>> On 1/20/21 10:22 PM, Dan Werthimer wrote:
>> >
>> > hi kaj,
>> >
>> > regarding your interest in ZCU111:
>> > there's a casper slack channel on RFSOC that you might find useful.
>> > wei liu recently developed a casper ADC yellow block for the ZCU111.
>> >
>> > best wishes,
>> >
>> > dan
>> >
>> >
>> >
>> > Dan Werthimer
>> > Marilyn and Watson Alberts Chair
>> > Astronomy Dept and Space Sciences Lab
>> > University of California, Berkeley
>> >
>> >
>> > On Wed, Jan 20, 2021 at 12:17 PM Kaj Wiik > > <mailto:kaj.w...@utu.fi>> wrote:
>> >
>> >
>> >
>> > On 20/01/2021 18:49, Jack Hickish wrote:
>> >
>> >  > I've been using Ubuntu 18.04 LTS without issues, at least with
>> > the boards which use Vivado 2019. I'm not sure  what versions of
>> > python the OS came with, but I'm currently running the toolflow in a
>> > python 3.6.9 virtual env.
>> >
>> > I first tried with Ubuntu 18.04 LTS but I got stuck with a problem
>> > with Matlab and some system library versions.
>> >
>> > I think I'll change the requirements.txt file to read "numpy<1.19"
>> > and try with that first.
>> >
>> > I am very interested of all information and experiences with Casper
>> > on ZCU111. Thanks to Adam for pointing out of a mlib_devel ZCU111
>> > branch, I haven't noticed that!
>> >
>> > Thanks!
>> >
>> > Kaj
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "casper@lists.berkeley.edu
>> > <mailto: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
>> > <mailto:casper%2bunsubscr...@lists.berkeley.edu>.
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/020a6f84-ded9-49cc-2d4a-00a766e743be%40utu.fi
>> .
>> >
>> > --
>> > 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
>> > <mailto:casper+unsubscr...@lists.berkeley.edu>.
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/a/lists.

Re: [casper] New setup installation problems (python setup.py egg_info" failed with error code 1)

[Adam Isaacson]

Hi Jack and Kaj,

@Jack: well done for figuring it out. This isn't the first time that we
have had this issue. I have seen similar things with using casperfpga. We
tested on machines that had previous python installs and casperfpga worked
fine. I then tried to install it on a completely clean machine and ended up
with similar issues. We eventually fixed that and have had no issues since.
It does mean we need to look at our test environment and make sure we have
a clean machine when we are testing builds during Busy Week in future. I
know this is not your problem, but I will definitely discuss it with
Jonathon Kocz going forward. We will be installing the toolflow on a brand
new machine in the next couple of days if we run into the same issue then I
will let you know.

@Kaj: Wei Liu should be able to help you with the ZCU111 branch if you need
assistance. I only have his Berkeley email address, but maybe Dan W has his
new address?

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 Wed, Jan 20, 2021 at 10:22 PM Dan Werthimer 
wrote:

>
> hi kaj,
>
> regarding your interest in ZCU111:
> there's a casper slack channel on RFSOC that you might find useful.
> wei liu recently developed a casper ADC yellow block for the ZCU111.
>
> best wishes,
>
> dan
>
>
>
> Dan Werthimer
> Marilyn and Watson Alberts Chair
> Astronomy Dept and Space Sciences Lab
> University of California, Berkeley
>
>
> On Wed, Jan 20, 2021 at 12:17 PM Kaj Wiik  wrote:
>
>>
>>
>> On 20/01/2021 18:49, Jack Hickish wrote:
>>
>> > I've been using Ubuntu 18.04 LTS without issues, at least with the
>> boards which use Vivado 2019. I'm not sure  what versions of python the OS
>> came with, but I'm currently running the toolflow in a python 3.6.9 virtual
>> env.
>>
>> I first tried with Ubuntu 18.04 LTS but I got stuck with a problem with
>> Matlab and some system library versions.
>>
>> I think I'll change the requirements.txt file to read "numpy<1.19" and
>> try with that first.
>>
>> I am very interested of all information and experiences with Casper on
>> ZCU111. Thanks to Adam for pointing out of a mlib_devel ZCU111 branch, I
>> haven't noticed that!
>>
>> Thanks!
>>
>> Kaj
>>
>> --
>> 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/020a6f84-ded9-49cc-2d4a-00a766e743be%40utu.fi
>> .
>>
> --
> 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/CAGHS_vHQ1bTha%3DFjCe0sGddd3Gt6GrYkh8dgz_eKDWXebf87iQ%40mail.gmail.com
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAGHS_vHQ1bTha%3DFjCe0sGddd3Gt6GrYkh8dgz_eKDWXebf87iQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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%3DnEunq4HfUSXqyfJ9qrco5wtrU0qFghNXA__pS3g%2BmdLSg%40mail.gmail.com.

Re: [casper] New setup installation problems (python setup.py egg_info" failed with error code 1)

[Adam Isaacson]

Hi Kaj,

This is odd. I know that Ubuntu 16.04LTS, Matlab R2018a and Vivado 2019.1.1
with python 3 (3.5 is fine) should work fine. What repo versions are you
using for the toolflow?

Have you tried the following repos just to make sure they build?

1) https://github.com/casper-astro/mlib_devel (master branch)

2) https://github.com/casper-astro/mlib_devel (casper-astro-soak-test)

3) If all else fails, https://github.com/ska-sa/mlib_devel (devel branch)

These should definitely work - well, they were verified during Busy Week
2020 and other . Try build a red pitaya tutorial with these and see what
happens? What hardware are you targeting? ZCU111? Maybe there is an issue
with the ZCU111 branch in https://github.com/casper-astro/mlib_devel. I
haven't tested this.

If you get the Red Pitaya, SKARAB or SNAP tutorials working then you
know there is nothing wrong with your setup.

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, Jan 20, 2021 at 6:49 PM Jack Hickish  wrote:

> Hi Kaj,
>
> I think there are a few options
>
> 1. Get python >=3.6
> 2. Find out which version of numpy is supported by python 3.5 and use that
> (it's crazy to me that pip doesn't just get the right version)
> 3. Use a later Ubuntu which may or may not Just Work. (At the very least,
> Ubuntu 18.04 seems to have python >=3.6 available via apt)
>
> I've been using Ubuntu 18.04 LTS without issues, at least with the boards
> which use Vivado 2019. I'm not sure  what versions of python the OS came
> with, but I'm currently running the toolflow in a python 3.6.9 virtual env.
>
> Cheers
> Jack
>
> On Wed, 20 Jan 2021 at 16:28, Kaj Wiik  wrote:
>
>>
>> Hi Jack,
>>
>> Thanks for a very quick reply!
>>
>> Python is the most recent one that is shipped with Ubuntu 16.04:
>>
>> kjwiik@casperx:~/mlib_devel$ python3 --version
>> Python 3.5.2
>>
>> This leads to two questions :-):
>> - can a more recent Ubuntu version be used (with ZCU111)?
>> or
>> - should I try to install e.g. anaconda python, is the most recent
>> version of python3 compatible with Casper?
>>
>> Many thanks,
>> Kaj
>>
>> On 1/20/21 6:10 PM, Jack Hickish wrote:
>> > Hi Kaj,
>> >
>> > What python version are you using? If that error is complaining that
>> > numpy is using f-string syntax
>> > <https://realpython.com/python-f-strings/> then maybe it's a
>> python<3.6
>> > issue.
>> >
>> > Cheers
>> > Jack
>> >
>> > On Wed, 20 Jan 2021 at 15:45, Kaj Wiik > > <mailto:kjw...@utu.fi>> wrote:
>> >
>> > Hi!
>> >
>> > As per instructions, I installed an (obsolete!) Ubuntu 16.04 with
>> > Matlab
>> > 2018a and Vivado 2019.1.1. Matlab install went fine but when I try
>> to
>> > install requirements for the toolflow, I get the following error
>> > message:
>> >
>> > ---
>> > kjwiik@casperx:~/mlib_devel$ pip3 install -r requirements.txt
>> > Collecting numpy (from -r requirements.txt (line 1))
>> > Using cached
>> >
>> https://files.pythonhosted.org/packages/51/60/3f0fe5b7675a461d96b9d6729beecd3532565743278a9c3fe6dd09697fa7/numpy-1.19.5.zip
>> >   Complete output from command python setup.py egg_info:
>> >   Traceback (most recent call last):
>> > File "", line 1, in 
>> > File "/tmp/pip-build-ehdaxa8b/numpy/setup.py", line 68
>> >   f"NumPy {VERSION} may not yet support Python "
>> >^
>> >   SyntaxError: invalid syntax
>> >
>> >   
>> > Command "python setup.py egg_info" failed with error code 1 in
>> > /tmp/pip-build-ehdaxa8b/numpy/
>> > You are using pip version 8.1.1, however version 20.3.3 is
>> available.
>> > You should consider upgrading via the 'pip install --upgrade pip'
>> > command.
>> > ---
>> >
>> >
>> https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html
>> >
>> > Any ideas?
>> >
>> > Thanks,
>> > Kaj
>> >
>> > kaj.w...@utu.fi <mailto:kaj.w...@utu.f

Re: [casper] Happy New Year!

[Adam Isaacson]

Hi Dave,

Happy New Year to you too! Thanks for the article. I thought I would share
this one with the community on the Xilinx Versal ACAP

-
https://www.eejournal.com/article/why-does-xilinx-say-that-its-new-7nm-versal-acap-isnt-an-fpga/

In Xilinx's words they are a platform company and no longer an FPGA
company. This definitely seems the case when looking at their products. In
fact most new Xilinx devices like the Zynq, RFSoC are more System on Chip
(SOC) devices that contain FPGA fabric. They are so much more.

The Versal contains programmable logic (adaptive logic), AI and CPU. I
believe that the user software decides what part on the Versal gets
targeted or not. I believe INAF were investigating these devices last year.
It would be great to get some feedback.

Exciting new changes coming. We are still focusing on the Xilinx Alveo with
Vitis, which basically sees the FPGA functionality as RTL kernels which can
be used for accelerating the hardware if necessary. CSIRO is doing the same.

Let us hope that the AMD/Xilinx merger doesn't cause too many issues.

Kind regards,

Adam

On Mon, 04 Jan 2021, 9:41 PM David MacMahon,  wrote:

> Happy New Year to the CASPER community!!!  It's hard to imagine 2021 not
> being better than 2020... :P
>
> Here's some intriguing AMD/Xilinx news for you:
>
> https://hothardware.com/news/amd-patent-hybrid-cpu-fpga-design-xilinx
>
> In addition to (instead of?) embedding CPUs in FPGAs it looks like FPGAs
> will be embedded in CPUs.  Not sure how useful this will be for CASPER, but
> it will bet interesting to see what this looks like when it's a real
> product and not just a patent.
>
> Cheers,
> Dave
>
> --
> 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/2954161E-F25E-44D2-9160-B31B0175BC0C%40berkeley.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%3DnEo%2BjfVGxjzQVNma-4rFj2eD1my7qkCKj7N3aMtF3ntog%40mail.gmail.com.

Re: [casper] Red Pitaya SDRlab 122-16

[Adam Isaacson]

Hi Sean,

We currently only support the 125-10 and 125-14 Red Pitaya hardware
modules, but if you or your organisation wanted to add this board as part
of the ongoing CASPER support for hardware then go for it. You can always
do a pull request to casper-astro/mlib_devel once done and then we can
include it.

The current CASPER developers are focusing on other toolflow needs and will
not have time to add this yet. We also have our hardware porting workshops
in 2021, which you could attend where the developers can help you/show you
how to port the toolflow to work with this board.

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, Oct 15, 2020 at 6:46 PM Sean Mckee  wrote:

>
> Hello Casperites,
>
> I was looking at the new Red Pitaya board that has come out recently:
>
> https://www.redpitaya.com/Catalog/p52/sdrlab-122-16-standard-kit?cat=c102
>
> It features wider out-of-the box bandwidth (no front end filtering), a
> bigger FPGA, and 16-bit ADCs. Are there any plans to add casper support for
> this board?
>
> Regards,
> Sean
>
> --
> 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/7e082d5b-873b-427a-a05a-e483e784cc0en%40lists.berkeley.edu
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/7e082d5b-873b-427a-a05a-e483e784cc0en%40lists.berkeley.edu?utm_medium=email_source=footer>
> .
>

-- 
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%3DnHdn6s1bHuLWsvzfUOj%2BNjogna42DUzTH9SESNWRN0Kcw%40mail.gmail.com.

Re: [casper] Red Pitaya Wide(-ish)band Spectrometer Tutorial

[Adam Isaacson]

Hi Paul,

Glad you came right! @Mathews: thanks for supporting Paul!


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, Sep 21, 2020 at 12:08 PM Paul Akumu  wrote:

> Hi Mathews and Adam,
>
> It seems the problem was with the incorrect installation of casperfpga.
> After the reinstallation of casperfpga, everything worked fine.  The
> version number was initially returning *0.0+unknown.202008281536 *and
> after reinstalling I got the correct version number as
> *3.3.dev929+devel.2a78685* and then it worked.
>
> Thanks for the support!
> Paul.
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
> <#m_211453264034393763_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Mon, Aug 31, 2020 at 11:13 AM Mathews Chirindo 
> wrote:
>
>> Hi Paul
>>
>> I want to try and get more information about your setup so we can see how
>> we can assist you further.
>>
>> So, what version of Linux are you using? I am using Ubuntu 16.04 LTS. And
>> are you running the python script under python 3 virtual environment, see
>> https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html?highlight=virtual%20environment#pre-requisites
>>  or
>> are you running with just standard python 2.7.
>>
>> Thanks
>> Mathews
>>
>> On Fri, Aug 28, 2020 at 1:38 PM Paul Akumu  wrote:
>>
>>> Hi  Mathews,
>>>
>>> I am using Matlab 2018a and Vivado 2019.1.1
>>>
>>> When I run casperfpga.__version__, I get
>>> *0.0+unknown.202008281536 *
>>>
>>> Thanks,
>>> Paul.
>>>
>>> On Fri, Aug 28, 2020 at 3:24 PM Mathews Chirindo 
>>> wrote:
>>>
>>>> Hi Paul
>>>>
>>>> I had to try the following from my side:
>>>>
>>>> 1. I cloned the repos from casper-astro mlib_devel
>>>> https://github.com/casper-astro/mlib_devel/tree/devel [devel branch]
>>>> and https://github.com/casper-astro/tutorials_devel [master branch]
>>>> 2. I successfully compiled the first tutorial
>>>> https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_intro
>>>>  and
>>>> programmed the red pitaya - tested all good.
>>>> 3. I successfully compiled the second tutorial
>>>> https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_adc_dac
>>>>  and
>>>> programmed the red pitaya - tested all good.
>>>> 4. I ran the tut_spec.py script at
>>>> https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_spec
>>>>  using
>>>> the tut_spec.fpg file. No issues.
>>>> 5. I ran the tut_spec.py script at
>>>> https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_spec
>>>>  using
>>>> the fpg file that I compiled from tut_spec.slx. No issues.
>>>>
>>>> I am using Matlab 2018a and Vivado 2019.1. Can you refine which ones
>>>> you use particularly eg 2018a or 2018b and 2019.1 or 2019.2. I am not sure
>>>> about compatibility, though.
>>>>
>>>> It seems there is no problem with the design files in the repos.
>>>>
>>>> What do you get if you run: casperfga.__version__
>>>>
>>>> Further investigations will follow.
>>>>
>>>> Thanks
>>>> Mathews
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Aug 28, 2020 at 8:50 AM Adam Isaacson 
>>>> wrote:
>>>>
>>>>> Hi Paul,
>>>>>
>>>>> Thanks, I will investigate further and get back to you.
>>>>>
>>>>> 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, Aug 27, 2020 at 10:49 PM Paul Akumu 
>>>>> wrote:
>>>>>
>>>>>> Hi Adam,
>>>>>>
>>>>>> I

Re: [casper] RedPitaya Compilation Error: "script generated with Vivado <2019.1.1> beign run as <2019.1>"

[Adam Isaacson]

Hi Xavier,

Option 3 is the correct choice. I think if you had installed Vivado 2019.2
then it should have just compiled. Vivado is mostly backwards compatible
and so Vivado 2019.1 won't necessarily recognise vivado 2019.1.1 scripting.
I think that is your issue.

Anyway, great tips from Jonathon going forward - always use the versions as
specified in the readthedocs first!

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, Sep 9, 2020 at 8:10 AM Xavier Bosch 
wrote:

> Hi Jonathon,
>
> Thank you for your response. SOLVED!
> I opted to follow option 3) i.e.: install 2019.1.1 and it worked like a
> charm!
> ReadTheDocumetns webpage is correct, asks for 2019.1.1, I am surprised by
> the level of version dependency of these TCL scripts.
> Thank you again,
> Best,
> XB
>
>
> On Tue, Sep 8, 2020 at 11:02 PM Jonathon Kocz  wrote:
>
>> Hi Xavi,
>>
>> As I found recently, the block diagram tcl scripts are *really* pedantic
>> about the version they are run in. If it doesn't match, they just don't
>> run, and then the design can't be compiled.
>>
>> Checking out git, it looks like this happened during the last hardware
>> porting workshop, and the docs should have been updated to be accurate a
>> few months ago. - It looks like they ask for Vivado 2019.1.1
>> https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html,
>> but there might be a page we missed with old instructions. If there is one
>> with 2019.1 listed, can you let me know and I'll get it fixed.
>>
>> A few things you could try:
>>
>> 1) Edit the tcl script for the block diagram so it checks for version
>> 2019.1 instead of 2019.1.1 (a little risky, but it might work -
>> https://github.com/casper-astro/mlib_devel/blob/master/jasper_library/hdl_sources/infrastructure/red_pitaya.tcl
>> line 23)
>> 2) Regenerate the block diagram as the error message suggests (a bit more
>> effort than 1, but not too bad)
>> 3) Upgrading to 2019.1.1 should solve the problem.
>>
>> Cheers,
>> Jonathon
>>
>>
>> On Tue, 8 Sep 2020 at 22:13, Xavier Bosch 
>> wrote:
>>
>>> Hi all,
>>>
>>> I installed a fresh 16.04 Ubuntu with Xilinx Vivado 2019.1 and Matalb
>>> 2018a, as readthedocs suggested for the RedPitaya board.
>>> I am using the master branch from mlib_devel commit
>>> ee6841c5b6392e1a9e6b302e2edbe875034efdcf from Thu 28 May, 2020.
>>>
>>> I created the  pithon3 virtual environment and installed the
>>> requirements
>>> As a comment my stratsg.local file is correctly populated except for the
>>> variable  "XML2VHDL_PATH", that I do not know how to configure, it seems a
>>> new parameter to me.
>>>
>>> I succeeded in compiling an old SNAP design, no problems. Then I
>>> proceeded to do a new design inspired by the Wide-ish band Spectrometer
>>> Tutorial and I got an error message as follows (see screenshot):
>>>
>>>
>>> *ERROR: [BD_TCL-109] This script was generated using Vivado <2019.1.1>
>>> and is being run in <2019.1> of Vivado. Please run the script in Vivado
>>> <2019.1.1> then open the design in Vivado <2019.1>. Upgrade the design by
>>> running "Tools => Report => Report IP Status...", then run write_bd_tcl to
>>> create an updated script.*
>>> *WARNING: [Vivado 12-818] No files matched
>>> '/home/javierb/workspace/designs/rpitaya_test01/myproj/myproj.srcs/sources_1/bd/red_pitaya/red_pitaya.bd
>>> <http://red_pitaya.bd>'*
>>> *# generate_target all [get_files [get_property directory
>>> [current_project]]/myproj.srcs/sources_1/bd/red_pitaya/red_pitaya.bd
>>> <http://red_pitaya.bd>]*
>>> *WARNING: [Vivado 12-818] No files matched
>>> '/home/javierb/workspace/designs/rpitaya_test01/myproj/myproj.srcs/sources_1/bd/red_pitaya/red_pitaya.bd
>>> <http://red_pitaya.bd>'*
>>> *# make_wrapper -files [get_files [get_property directory
>>> [current_project]]/myproj.srcs/sources_1/bd/red_pitaya/red_pitaya.bd
>>> <http://red_pitaya.bd>] -top*
>>> *# add_files -norecurse [get_property directory
>>> [current_project]]/myproj.srcs/sources_1/bd/red_pitaya/hdl/red_pitaya_wrapper.vhd*
>>> *ERROR: [Vivado 12-172] File or Directory
>>> '/home/javierb/workspace/designs/rpitaya_test01/myproj/myproj.srcs/sources_1/bd/red_pitaya/hdl/red_pitaya_wrapper.vhd'
>>> does not exist*
>>> *

Re: [casper] Ultrascale+HBM DSP48's + CASPER FFT

[Adam Isaacson]

Thanks, Jonathon. It is possible I sent in a SR to Xilinx at the time. We
should probably be using Vivado 2020.1 - contains other sysgen fixes.

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, Aug 28, 2020 at 10:30 PM Jonathon Kocz  wrote:

> Thanks Adam. Good to know it wasn't just me!
>
> As an update: I installed Vivado 2020.1 this afternoon. Running with
> matlab 2019a it does seem they fixed the issue, and it compiles without
> error.
>
> Caveat: I've only tested with simple counters. I haven't yet looked to see
> what in the toolflow might need updating before it is fully compatible with
> vivado 2020.
>
> Cheers,
> Jonathon
>
> On Fri, 28 Aug 2020 at 03:55, Adam Isaacson  wrote:
>
>> Hi Jonathon,
>>
>> We have the same issue for our 1K channeliser using the Alveo U280 boards
>> - see screen capture. To fix this we changed the Simulink counters not to
>> use DSP - not very practical, but at least we got the compile through. I
>> have looked at the DSP architecture for the Virtex UltraScale+ with HBM and
>> it definitely has the DSP architecture. We used Matlab R2018a and Vivado
>> 2019.1.1 and Vivado 2019.2 - they all had this issue. I believe it to be a
>> Simulink/sysgen bug. I never got around to logging a support request with
>> Xilinx yet, as we were focusing on the Alveo U280 100GbE testing. We
>> haven't looked into this much more yet.
>>
>> This is from Andrew van der Byl: "The - a snag.There seems to be an
>> issue when counters are set to use DSP logic. Jasper_frontend fails (see
>> attached pic) if a counter is set to use DSP (it's fine when Fabric or
>> behavioural is selected). You can regenerate the issue by changing any of
>> the counters in the base design to use DSP. The DSP slices used in the
>> PFB are fine though. I did have to change all counters in the design that
>> by default are set to use DSP slices or the build would fail. Thought
>> I'd give you the heads up. I'll start to work in the rest of the logic and
>> build in some test logic as well".
>>
>> 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, Aug 28, 2020 at 2:31 AM Jonathon Kocz  wrote:
>>
>>> Hi CASPER,
>>>
>>> I was wondering if anyone had encountered difficulties in compiling
>>> larger CASPER FFTs for Ultrascale+ HBM devices?
>>>
>>> I have found I can compile the CASPER FFTs fine for Ultrascale+ devices,
>>> but HBM devices seem to object ("Cannot target DSP48 on this device,
>>> virtexuplusHBM").
>>>
>>> As far as I know DSP48E2 should be backward compatible with DSP48E1 (and
>>> certainly as other Ultrascale+ devices will compile, this seems to be true).
>>>
>>> The only thing I've been able to find specifically relating to HBM
>>> devices is that the number you can cascade may be different due to the
>>> difference in SLRs with the HBM interface (UG579).
>>>
>>> Is this just Simulink needing an update (I've tried Vivado 2019.1.1 and
>>> 2019.2, both with Matlab 2019a), do we finally need to explicitly change
>>> the DSP48's in the toolflow to be E2 for devices like this, or is there
>>> something more fundamental I'm missing?
>>>
>>> Thanks,
>>> Jonathon
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "casper@lists.berkeley.edu" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to casper+unsubscr...@lists.berkeley.edu.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAPU71P8xjbD%2BwSSWPRK-qYVOVt-umBxmLQiYWmAAncyrgobF1A%40mail.gmail.com
>>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAPU71P8xjbD%2BwSSWPRK-qYVOVt-umBxmLQiYWmAAncyrgobF1A%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> 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://grou

Re: [casper] Red Pitaya Wide(-ish)band Spectrometer Tutorial

[Adam Isaacson]

Hi Paul,

I have spoken with my colleague Mathews Chirindo who will be investigating
this further for you. He made the most recent changes to the toolflow and
tested the tutorials for the Red Pitaya recently. He will give you feedback
on this thread.

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, Aug 28, 2020 at 8:50 AM Adam Isaacson  wrote:

> Hi Paul,
>
> Thanks, I will investigate further and get back to you.
>
> 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, Aug 27, 2020 at 10:49 PM Paul Akumu  wrote:
>
>> Hi Adam,
>>
>> I have tried the recommended repos but the error still persists.
>>
>> Kind regards,
>> Paul.
>>
>> On Thu, Aug 27, 2020 at 11:00 AM Adam Isaacson 
>> wrote:
>>
>>> Hi Paul,
>>>
>>> Thanks for confirming. Please can you try the latest commits and
>>> following repos:
>>>
>>> 1) mlib_devel - https://github.com/ska-sa/mlib_devel
>>> <https://github.com/ska-sa/mlib_devel> (devel branch)
>>> 2) casperfpga - https://github.com/ska-sa/casperfpga (devel branch)
>>>
>>> These repos contain the latest Red Pitaya fixes. If the problem still
>>> persists then I will investigate further. I just want to make sure that we
>>> have merged all the relevant fixes in the casper-astro repo from the ska-sa
>>> repo.
>>>
>>> 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, Aug 26, 2020 at 8:39 PM Paul Akumu  wrote:
>>>
>>>> Hi Adam,
>>>>
>>>> Yes, I built the slx files and generated the fpg files for the first
>>>> two tutorials.
>>>>
>>>> For the third tutorial, I first opened the slx file in Simulink and
>>>> compiled it but got an error when I tried to upload and program. Then I
>>>> tried updating the model as described under "Updating an Existing Toolfow
>>>> Installation" using update_casper_blocks(bdroot) before compiling
>>>> again but got the same error report. Finally, I tried using the fpg file
>>>> provided which also resulted in the same error.
>>>>
>>>> Thanks,
>>>> Paul.
>>>>
>>>>
>>>>
>>>>
>>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>>>>  Virus-free.
>>>> www.avast.com
>>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
>>>> <#m_3990562732980485248_m_5458899884828230806_m_6900430746832513320_m_497581565406995344_m_7518126369254170950_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>>
>>>> On Wed, Aug 26, 2020 at 3:49 PM Adam Isaacson 
>>>> wrote:
>>>>
>>>>> Hi Paul,
>>>>>
>>>>> Thanks for your email. It looks like your mlib_devel and casperfpga
>>>>> version are fairly recent and contain the BRAM 32 bit fixes that we made.
>>>>> It seems I committed this particular fpg file 9 months ago, so it might 
>>>>> not
>>>>> of contained all these fixes then. I am quite certain it was working for
>>>>> me, but maybe I committed the incorrect file at the time. You say the 
>>>>> first
>>>>> two tutorials were successful and I know the second tutorial has a
>>>>> snapshot, so your build environment must work. I am assuming you build the
>>>>> slx files and generated the fpg files for the first two tuts, of course.
>>>>> Correct me if wrong!
>>>>>
>>>>> Please try and rebuild the spectrometer slx file and test the fpg
>>>>> generated file. Let me know if you get the same issue. If you don't then I
>>>>> must have checked a suspect fpg file in this repo and we can easily fix
>>>>> that, if that is the case.
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Adam Isaacson
>>>>> South African Radio 

Re: [casper] Red Pitaya Wide(-ish)band Spectrometer Tutorial

[Adam Isaacson]

Hi Paul,

Thanks, I will investigate further and get back to you.

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, Aug 27, 2020 at 10:49 PM Paul Akumu  wrote:

> Hi Adam,
>
> I have tried the recommended repos but the error still persists.
>
> Kind regards,
> Paul.
>
> On Thu, Aug 27, 2020 at 11:00 AM Adam Isaacson 
> wrote:
>
>> Hi Paul,
>>
>> Thanks for confirming. Please can you try the latest commits and
>> following repos:
>>
>> 1) mlib_devel - https://github.com/ska-sa/mlib_devel
>> <https://github.com/ska-sa/mlib_devel> (devel branch)
>> 2) casperfpga - https://github.com/ska-sa/casperfpga (devel branch)
>>
>> These repos contain the latest Red Pitaya fixes. If the problem still
>> persists then I will investigate further. I just want to make sure that we
>> have merged all the relevant fixes in the casper-astro repo from the ska-sa
>> repo.
>>
>> 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, Aug 26, 2020 at 8:39 PM Paul Akumu  wrote:
>>
>>> Hi Adam,
>>>
>>> Yes, I built the slx files and generated the fpg files for the first two
>>> tutorials.
>>>
>>> For the third tutorial, I first opened the slx file in Simulink and
>>> compiled it but got an error when I tried to upload and program. Then I
>>> tried updating the model as described under "Updating an Existing Toolfow
>>> Installation" using update_casper_blocks(bdroot) before compiling again
>>> but got the same error report. Finally, I tried using the fpg file provided
>>> which also resulted in the same error.
>>>
>>> Thanks,
>>> Paul.
>>>
>>>
>>>
>>>
>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>>>  Virus-free.
>>> www.avast.com
>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
>>> <#m_5458899884828230806_m_6900430746832513320_m_497581565406995344_m_7518126369254170950_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>> On Wed, Aug 26, 2020 at 3:49 PM Adam Isaacson 
>>> wrote:
>>>
>>>> Hi Paul,
>>>>
>>>> Thanks for your email. It looks like your mlib_devel and casperfpga
>>>> version are fairly recent and contain the BRAM 32 bit fixes that we made.
>>>> It seems I committed this particular fpg file 9 months ago, so it might not
>>>> of contained all these fixes then. I am quite certain it was working for
>>>> me, but maybe I committed the incorrect file at the time. You say the first
>>>> two tutorials were successful and I know the second tutorial has a
>>>> snapshot, so your build environment must work. I am assuming you build the
>>>> slx files and generated the fpg files for the first two tuts, of course.
>>>> Correct me if wrong!
>>>>
>>>> Please try and rebuild the spectrometer slx file and test the fpg
>>>> generated file. Let me know if you get the same issue. If you don't then I
>>>> must have checked a suspect fpg file in this repo and we can easily fix
>>>> that, if that is the case.
>>>>
>>>> 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, Aug 24, 2020 at 10:52 PM Paul Akumu  wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I am new to the Toolfow and I have been following the Red Pitaya
>>>>> tutorials. I have Matlab 2018 and Vivado 2019 installed. I was able to
>>>>> follow the first two tutorials which compiled and uploaded via casperfpga
>>>>> successfully. When following the wide band spectrometer tutorial I tried 
>>>>> to
>>>>> program the red Pitaya with the fpg file provided for the tutorial
>>>>> here
>>>>> <https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut

Re: [casper] Red Pitaya Wide(-ish)band Spectrometer Tutorial

[Adam Isaacson]

Hi Paul,

Thanks for confirming. Please can you try the latest commits and following
repos:

1) mlib_devel - https://github.com/ska-sa/mlib_devel
<https://github.com/ska-sa/mlib_devel> (devel branch)
2) casperfpga - https://github.com/ska-sa/casperfpga (devel branch)

These repos contain the latest Red Pitaya fixes. If the problem still
persists then I will investigate further. I just want to make sure that we
have merged all the relevant fixes in the casper-astro repo from the ska-sa
repo.

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, Aug 26, 2020 at 8:39 PM Paul Akumu  wrote:

> Hi Adam,
>
> Yes, I built the slx files and generated the fpg files for the first two
> tutorials.
>
> For the third tutorial, I first opened the slx file in Simulink and
> compiled it but got an error when I tried to upload and program. Then I
> tried updating the model as described under "Updating an Existing Toolfow
> Installation" using update_casper_blocks(bdroot) before compiling again
> but got the same error report. Finally, I tried using the fpg file provided
> which also resulted in the same error.
>
> Thanks,
> Paul.
>
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
> <#m_497581565406995344_m_7518126369254170950_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Wed, Aug 26, 2020 at 3:49 PM Adam Isaacson  wrote:
>
>> Hi Paul,
>>
>> Thanks for your email. It looks like your mlib_devel and casperfpga
>> version are fairly recent and contain the BRAM 32 bit fixes that we made.
>> It seems I committed this particular fpg file 9 months ago, so it might not
>> of contained all these fixes then. I am quite certain it was working for
>> me, but maybe I committed the incorrect file at the time. You say the first
>> two tutorials were successful and I know the second tutorial has a
>> snapshot, so your build environment must work. I am assuming you build the
>> slx files and generated the fpg files for the first two tuts, of course.
>> Correct me if wrong!
>>
>> Please try and rebuild the spectrometer slx file and test the fpg
>> generated file. Let me know if you get the same issue. If you don't then I
>> must have checked a suspect fpg file in this repo and we can easily fix
>> that, if that is the case.
>>
>> 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, Aug 24, 2020 at 10:52 PM Paul Akumu  wrote:
>>
>>> Hello,
>>>
>>> I am new to the Toolfow and I have been following the Red Pitaya
>>> tutorials. I have Matlab 2018 and Vivado 2019 installed. I was able to
>>> follow the first two tutorials which compiled and uploaded via casperfpga
>>> successfully. When following the wide band spectrometer tutorial I tried to
>>> program the red Pitaya with the fpg file provided for the tutorial here
>>> <https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_spec>,
>>> but got the following response/error;
>>>
>>> Connecting to Red Pitaya: 192.168.200.151
>>> 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
>>>

Re: [casper] Red Pitaya Wide(-ish)band Spectrometer Tutorial

[Adam Isaacson]

Hi Paul,

Thanks for your email. It looks like your mlib_devel and casperfpga version
are fairly recent and contain the BRAM 32 bit fixes that we made. It seems
I committed this particular fpg file 9 months ago, so it might not of
contained all these fixes then. I am quite certain it was working for me,
but maybe I committed the incorrect file at the time. You say the first two
tutorials were successful and I know the second tutorial has a snapshot, so
your build environment must work. I am assuming you build the slx files and
generated the fpg files for the first two tuts, of course. Correct me if
wrong!

Please try and rebuild the spectrometer slx file and test the fpg generated
file. Let me know if you get the same issue. If you don't then I must have
checked a suspect fpg file in this repo and we can easily fix that, if that
is the case.

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, Aug 24, 2020 at 10:52 PM Paul Akumu  wrote:

> Hello,
>
> I am new to the Toolfow and I have been following the Red Pitaya
> tutorials. I have Matlab 2018 and Vivado 2019 installed. I was able to
> follow the first two tutorials which compiled and uploaded via casperfpga
> successfully. When following the wide band spectrometer tutorial I tried to
> program the red Pitaya with the fpg file provided for the tutorial here
> <https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_spec>,
> but got the following response/error;
>
> Connecting to Red Pitaya: 192.168.200.151
> 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
>
> I also tried compiling the .slx file and got the same error while trying
> to upload and program.
>
> The version of casperfpga and mlib_devel are as follows:
> mlib_devel commit id = a9e87d994cf5f512fa0ea555ec7495d8dedc0855
> caspserfpga commit id = c2258ea014340a7376d504e7128198ed2cfa5442
>
> What could be the problem?
>
> Thanks,
> Paul.
>
>
>
>
> --
> 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/ac1e497b-3ebd-420c-a6c2-41d0beef7102n%40lists.berkeley.edu
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/ac1e497b-3ebd-420c-a6c2-41d0beef7102n%40lists.berkeley.edu?utm_medium=email_source=footer>
> .
>

-- 
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%3DnHmA%2B%2BOVoa53Uqy%3D7f7EouqYFo%2Bz-n_hPiCOtDau9Tmxw%40mail.gmail.com.

Re: [casper] Simulink message error with FFT_BIPLEX_REAL_4x module

[Adam Isaacson]

Hi Xavier,

Okay, great! I am glad you sorted it out.

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, Aug 5, 2020 at 8:13 PM Xavier Bosch 
wrote:

> Hi Adam,
>
> It was a software version problem. I installed the Matlab 2018a version
> and now it works.
> Summary:
>
>- Ubuntu 16.04.6 LTS, Xilinx 2018.1 and Matlab 2019a it does not work.
>- Ubuntu 16.04.6 LTS, Xilinx 2018.1 and Matlab 2018a it  does  work.
>
>
> Thank you for your response!
> Best,
> XB
>
> On Tue, Aug 4, 2020 at 10:27 AM Adam Isaacson  wrote:
>
>> Hi Xavier,
>>
>> What hardware platform are you using? The latest toolflow has been tested
>> with Ubuntu 16.04LTS, Matlab R2018a (update pack 6) and Vivado 2019.1.1.
>> This is supported for SNAP, SKARAB and the Red Pitaya. ROACH2 still
>> supports the old tool flow, which uses ISE 14.7 and something like Matlab
>> R2012b.
>>
>> I am suspecting that one of the sysgen parameters in Vivado 2018.1 is
>> different to Vivado 2019.1.1. Some of the Matlab/Simulink mask init scripts
>> would have been updated to support the sysgen in Vivado 2019.1.1. This is
>> likely part of your issue. Is it not possible for you to use the versions
>> specified in the toolflow ReadtheDocs first before trying different
>> versions?
>>
>> 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 Tue, Aug 4, 2020 at 5:35 PM Xavier Bosch 
>> wrote:
>>
>>> Hi all,
>>> I installed a fresh virtual machine with UB18.04 with Matlab 2019.1
>>> (Readthedocs recommends Matlab2018.1) and Vivado 2018.1, cloned the last
>>> mlib_devel repository and finally get the startgs script ready.
>>>
>>> When placing a new FFT_BIPLEX_REAL_4x block in the simulink canvas I get
>>> the following error message (see attached screenshot) related to a function
>>> that cannot evaluate a model parameter. Has anyone had a similar problem?
>>> I tried with different modules and all work great, just the FFT ones are
>>> giving me trouble.
>>>
>>> When upgrading an already existing design it gives me the same error and
>>> when compiling the same old design I got an error related to floating point
>>> missing information.
>>> Could this be a problem related to Matlab 2019? I do not have fast
>>> access to a 2018 version.
>>>
>>> Thank you,
>>> XB
>>>
>>> --
>>> 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/CAMehrA0QuM8O%2Bb%2BOt2sFSuDuRHJpo_yYE7HwPB%2BzWYNASatMoQ%40mail.gmail.com
>>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAMehrA0QuM8O%2Bb%2BOt2sFSuDuRHJpo_yYE7HwPB%2BzWYNASatMoQ%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> 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%3DnEsQqnTju6%2BxHskCrG1Nmz7CowKqTKjy-hCEkYmdcPmkQ%40mail.gmail.com
>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CADTJ%3DnEsQqnTju6%2BxHskCrG1Nmz7CowKqTKjy-hCEkYmdcPmkQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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/CAMehrA0Sw80EdOr_8_zZuo%2BcsXEJ_H5r7Mt4_EVZF4zXTYX6gQ%40mail.gmail.com
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAMehrA0Sw80EdOr_8_zZuo%2BcsXEJ_H5r7Mt4_EVZF4zXTYX6gQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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%3DnG1O7EGL%2BS-fh1%2BK2v%2B1CfDiNSL%3DV%2B_1hih3PSxk0dRjA%40mail.gmail.com.

Re: [casper] Simulink message error with FFT_BIPLEX_REAL_4x module

[Adam Isaacson]

Hi Xavier,

What hardware platform are you using? The latest toolflow has been tested
with Ubuntu 16.04LTS, Matlab R2018a (update pack 6) and Vivado 2019.1.1.
This is supported for SNAP, SKARAB and the Red Pitaya. ROACH2 still
supports the old tool flow, which uses ISE 14.7 and something like Matlab
R2012b.

I am suspecting that one of the sysgen parameters in Vivado 2018.1 is
different to Vivado 2019.1.1. Some of the Matlab/Simulink mask init scripts
would have been updated to support the sysgen in Vivado 2019.1.1. This is
likely part of your issue. Is it not possible for you to use the versions
specified in the toolflow ReadtheDocs first before trying different
versions?

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 Tue, Aug 4, 2020 at 5:35 PM Xavier Bosch 
wrote:

> Hi all,
> I installed a fresh virtual machine with UB18.04 with Matlab 2019.1
> (Readthedocs recommends Matlab2018.1) and Vivado 2018.1, cloned the last
> mlib_devel repository and finally get the startgs script ready.
>
> When placing a new FFT_BIPLEX_REAL_4x block in the simulink canvas I get
> the following error message (see attached screenshot) related to a function
> that cannot evaluate a model parameter. Has anyone had a similar problem?
> I tried with different modules and all work great, just the FFT ones are
> giving me trouble.
>
> When upgrading an already existing design it gives me the same error and
> when compiling the same old design I got an error related to floating point
> missing information.
> Could this be a problem related to Matlab 2019? I do not have fast access
> to a 2018 version.
>
> Thank you,
> XB
>
> --
> 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/CAMehrA0QuM8O%2Bb%2BOt2sFSuDuRHJpo_yYE7HwPB%2BzWYNASatMoQ%40mail.gmail.com
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAMehrA0QuM8O%2Bb%2BOt2sFSuDuRHJpo_yYE7HwPB%2BzWYNASatMoQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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%3DnEsQqnTju6%2BxHskCrG1Nmz7CowKqTKjy-hCEkYmdcPmkQ%40mail.gmail.com.

Re: [casper] Timing analysis

[Adam Isaacson]

Hi Sebastian,

No, please continue to ask these questions. They are good questions and it
forces me to think :). There is always room for improvement, but I can only
focus on so much at a time.

Yes, that is correct. We use the same red_pitaya.v and red_pitaya.tcl to
generate the Zynq block diagram in all configurations. I am going into
weekend mode now, so will be happy to respond to any new questions on
Monday :).

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, Jul 3, 2020 at 7:32 PM Sebastian Antonio Jorquera Tapia <
sebastian.jorqu...@ug.uchile.cl> wrote:

> Sorry If I push too hard on the mmcm thing jaja.
> I just wanted to know if there was an underlying reason for using the mmcm
> (maybe a clock stability across the board or something like that), but I
> agree it is the right thing to do If you want to be open to work in every
> possible configuration. I think you use the same red_pitaya.v in every
> configuration, it's that correct?
>
> Thanks, again for the response!
>
>
> El vie., 3 jul. 2020 a las 13:18, Adam Isaacson ()
> escribió:
>
>> Hi Sebastian,
>>
>> Apologies, you are indeed correct. The Zynq PS does generate the AXI_CLK
>> (FCLK_CLK0) and it is set to 100MHz for the Red Pitaya. The ADC and DSP
>> MMCMs have nothing to do with it.
>>
>> Yes, the dsp_mmcm is in order not to be forced to work at the crystal
>> frequency. If I remember correctly, we prevent modification so that the
>> user doesn't need to know the actual ADC sample clock frequency. He just
>> needs to specify "adc_clk" and the toolfllow will ensure everything runs at
>> 125MHz. You could argue that it is important to know this information as
>> well. If you would like to alter the platform yellow block clock frequency
>> then you will need to use "sys_clk".
>>
>> This is a collaboration and if you want to make improvements towards the
>> toolfow then you are most welcome to. The Red Pitaya was created as a
>> CASPER teaching platform and if you feel there are improvements that can be
>> made then why not make them and send a pull request for reviewing - CASPER
>> encourages this and is always looking for new developers :). I am happy to
>> support you in investigating your timing issues, so feel free to send me
>> your design if you are allowed to share 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 Fri, Jul 3, 2020 at 5:50 PM Sebastian Antonio Jorquera Tapia <
>> sebastian.jorqu...@ug.uchile.cl> wrote:
>>
>>> Thanks for the detailed response!
>>> So the dsp_mmcm its in order to not be forced to work at the crystal
>>> frequency. But that's odd because when you select to work at the adc_clk in
>>> the xsg yellow box you can't modify the frequency, so the whole system
>>> (except the dac) is running at 125.
>>> I think the zynq ps should generate the axi clock.
>>>
>>>
>>>
>>> El vie., 3 jul. 2020 a las 11:22, Adam Isaacson ()
>>> escribió:
>>>
>>>> Hi Sebastian,
>>>>
>>>> Yes, you are correct. The toolflow uses Vivado as its backend and so
>>>> will do the same. Jack makes a good point and I think maybe one of the
>>>> future requirements for the toolflow will be to clearly indicate if the
>>>> design has failed timing or not. I still think it is useful to generate the
>>>> bit file even if there are timing failures - sometimes it is useful to
>>>> still test the design even with timing failures. The final released version
>>>> should never have timing failures though.
>>>>
>>>> Yes, we have two MMCMs for the Red Pitaya/SKARAB. The reason is that we
>>>> are unable to generate all the required frequencies with one MMCM and we
>>>> need the MMCM because we are not just using the 125MHz clock for ADC
>>>> sampling. We also have a DAC that uses 250MHz and I think the processor and
>>>> AXI interface for reading registers runs on 100MHz or maybe lower for Red
>>>> Pitaya. I can't quite remember now. It could also be useful to run the DSP
>>>> (sysgen) at a higher clock frequency. You will notice that the ADC yellow
>>>> block and DAC yellow blocks all have data valid signals and the relevant
>>>> FIFO buffering for 

Re: [casper] Timing analysis

[Adam Isaacson]

Hi Sebastian,

Apologies, you are indeed correct. The Zynq PS does generate the AXI_CLK
(FCLK_CLK0) and it is set to 100MHz for the Red Pitaya. The ADC and DSP
MMCMs have nothing to do with it.

Yes, the dsp_mmcm is in order not to be forced to work at the crystal
frequency. If I remember correctly, we prevent modification so that the
user doesn't need to know the actual ADC sample clock frequency. He just
needs to specify "adc_clk" and the toolfllow will ensure everything runs at
125MHz. You could argue that it is important to know this information as
well. If you would like to alter the platform yellow block clock frequency
then you will need to use "sys_clk".

This is a collaboration and if you want to make improvements towards the
toolfow then you are most welcome to. The Red Pitaya was created as a
CASPER teaching platform and if you feel there are improvements that can be
made then why not make them and send a pull request for reviewing - CASPER
encourages this and is always looking for new developers :). I am happy to
support you in investigating your timing issues, so feel free to send me
your design if you are allowed to share 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 Fri, Jul 3, 2020 at 5:50 PM Sebastian Antonio Jorquera Tapia <
sebastian.jorqu...@ug.uchile.cl> wrote:

> Thanks for the detailed response!
> So the dsp_mmcm its in order to not be forced to work at the crystal
> frequency. But that's odd because when you select to work at the adc_clk in
> the xsg yellow box you can't modify the frequency, so the whole system
> (except the dac) is running at 125.
> I think the zynq ps should generate the axi clock.
>
>
>
> El vie., 3 jul. 2020 a las 11:22, Adam Isaacson ()
> escribió:
>
>> Hi Sebastian,
>>
>> Yes, you are correct. The toolflow uses Vivado as its backend and so will
>> do the same. Jack makes a good point and I think maybe one of the future
>> requirements for the toolflow will be to clearly indicate if the design has
>> failed timing or not. I still think it is useful to generate the bit file
>> even if there are timing failures - sometimes it is useful to still test
>> the design even with timing failures. The final released version should
>> never have timing failures though.
>>
>> Yes, we have two MMCMs for the Red Pitaya/SKARAB. The reason is that we
>> are unable to generate all the required frequencies with one MMCM and we
>> need the MMCM because we are not just using the 125MHz clock for ADC
>> sampling. We also have a DAC that uses 250MHz and I think the processor and
>> AXI interface for reading registers runs on 100MHz or maybe lower for Red
>> Pitaya. I can't quite remember now. It could also be useful to run the DSP
>> (sysgen) at a higher clock frequency. You will notice that the ADC yellow
>> block and DAC yellow blocks all have data valid signals and the relevant
>> FIFO buffering for this. I think the Red Pitaya spectrometer tutorial runs
>> the sysgen clock at 125MHz. If you do the second tutorial: ADC and DAC you
>> will see the effects of a toggling data valid signal. Also, even though it
>> would be great to have one clock frequency for timing purposes, it wouldn't
>> make sense to run non-critical interfaces such as the AXI comms registers
>> at a higher clock frequency than it needs to be. It makes sense to use a
>> lower clock frequency for this. We were running the SKARAB comms interface
>> at 156.25MHz and in the end dropped this to 40MHz, so that we could meet
>> timing.
>>
>> 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 Fri, Jul 3, 2020 at 5:00 PM Sebastian Antonio Jorquera Tapia <
>> sebastian.jorqu...@ug.uchile.cl> wrote:
>>
>>> Yes, Its my own design. I ask because when you run the synthesis and
>>> implementation in Vivado it lets you continue and generate the bitstream
>>> even if you have timing violations, so i think the casper tool could do the
>>> same.
>>>
>>> I have another question.. looking at the report my timing errors are
>>> related to the adc_mmcm. Why does the system use an mmcm if the 125Mhz are
>>> given by an external crystal and there is no modification to the frequency?
>>> Its not enough to use a IBUFGDS?
>>> Also I see a second mmcm named dsp_clk_mmcm feeded by the same adc
>>> clock, I d

Re: [casper] Timing analysis

[Adam Isaacson]

Hi Sebastian,

Yes, you are correct. The toolflow uses Vivado as its backend and so will
do the same. Jack makes a good point and I think maybe one of the future
requirements for the toolflow will be to clearly indicate if the design has
failed timing or not. I still think it is useful to generate the bit file
even if there are timing failures - sometimes it is useful to still test
the design even with timing failures. The final released version should
never have timing failures though.

Yes, we have two MMCMs for the Red Pitaya/SKARAB. The reason is that we are
unable to generate all the required frequencies with one MMCM and we need
the MMCM because we are not just using the 125MHz clock for ADC sampling.
We also have a DAC that uses 250MHz and I think the processor and AXI
interface for reading registers runs on 100MHz or maybe lower for Red
Pitaya. I can't quite remember now. It could also be useful to run the DSP
(sysgen) at a higher clock frequency. You will notice that the ADC yellow
block and DAC yellow blocks all have data valid signals and the relevant
FIFO buffering for this. I think the Red Pitaya spectrometer tutorial runs
the sysgen clock at 125MHz. If you do the second tutorial: ADC and DAC you
will see the effects of a toggling data valid signal. Also, even though it
would be great to have one clock frequency for timing purposes, it wouldn't
make sense to run non-critical interfaces such as the AXI comms registers
at a higher clock frequency than it needs to be. It makes sense to use a
lower clock frequency for this. We were running the SKARAB comms interface
at 156.25MHz and in the end dropped this to 40MHz, so that we could meet
timing.

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 Fri, Jul 3, 2020 at 5:00 PM Sebastian Antonio Jorquera Tapia <
sebastian.jorqu...@ug.uchile.cl> wrote:

> Yes, Its my own design. I ask because when you run the synthesis and
> implementation in Vivado it lets you continue and generate the bitstream
> even if you have timing violations, so i think the casper tool could do the
> same.
>
> I have another question.. looking at the report my timing errors are
> related to the adc_mmcm. Why does the system use an mmcm if the 125Mhz are
> given by an external crystal and there is no modification to the frequency?
> Its not enough to use a IBUFGDS?
> Also I see a second mmcm named dsp_clk_mmcm feeded by the same adc clock,
> I didnt look very carefully but guided by its name I assume it gives the
> clock to the sysgen model. Why use a second clock, if its running at the
> same frequency as the first mcmm?
>
>
> El vie., 3 jul. 2020 a las 5:38, Jack Hickish ()
> escribió:
>
>> This is probably a good conversation to have amongst the developers. ISE
>> used to not deliver bitstreams unless you set an environment flag. I'm not
>> sure it wouldn't make sense for the current toolflow to do the same.
>>
>> Timing failure warnings _are_ printed to the MATLAB prompt, but not in as
>> shouty a way as they probably should be. I've tweaked them to be more
>> obvious and this change will probably/hopefully be merged in the next major
>> mlib_devel release.
>>
>> Cheers
>> Jack
>>
>> On Fri, 3 Jul 2020, 8:51 am Adam Isaacson,  wrote:
>>
>>> Hi Sebastian,
>>>
>>> No, the timing analysis is performed during implementation - routing
>>> phase and post routing optimisation phase. Bit generation occurs after this
>>> - whether the design meets timing or not.
>>>
>>> Are you compiling tutorials or your own custom Red Pitaya design? The
>>> tutorials should meet timing.
>>>
>>> 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, Jul 3, 2020 at 5:46 AM Sebastian Antonio Jorquera Tapia <
>>> sebastian.jorqu...@ug.uchile.cl> wrote:
>>>
>>>>
>>>> Hello Casperites,
>>>> Just a little question regarding the order of compilation.. I just
>>>> compile a red pitaya design using the casper tool chain who generates the
>>>> bitstream and says that the backend  is completed! But when I open the
>>>> project with vivado I could see that the implementation had a time
>>>> violation of 2.5ns in the setup time of signals related to the adc clock..
>>>>
>>>> So my question is, the time analysis is made after the bitstream ar

Re: [casper] Timing analysis

[Adam Isaacson]

Hi Sebastian,

No, the timing analysis is performed during implementation - routing phase
and post routing optimisation phase. Bit generation occurs after this -
whether the design meets timing or not.

Are you compiling tutorials or your own custom Red Pitaya design? The
tutorials should meet timing.

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, Jul 3, 2020 at 5:46 AM Sebastian Antonio Jorquera Tapia <
sebastian.jorqu...@ug.uchile.cl> wrote:

>
> Hello Casperites,
> Just a little question regarding the order of compilation.. I just compile
> a red pitaya design using the casper tool chain who generates the bitstream
> and says that the backend  is completed! But when I open the project with
> vivado I could see that the implementation had a time violation of 2.5ns in
> the setup time of signals related to the adc clock..
>
> So my question is, the time analysis is made after the bitstream are
> generated?
>
> --
> 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/4fb01928-987b-4d87-b62c-3ed40cd579f9n%40lists.berkeley.edu
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/4fb01928-987b-4d87-b62c-3ed40cd579f9n%40lists.berkeley.edu?utm_medium=email_source=footer>
> .
>

-- 
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%3DnHjK6ELYzZgKCrou4-xUCEFS9svRkkWqFGUFV7abmYy6Q%40mail.gmail.com.

Re: [casper] Red Pitaya access registers of snap blocks from PS

[Adam Isaacson]

Hi Sean et al,

I have recently submitted a pull request to casper-astro/casperfpga master
branch that fixes the casperfpga progska install error - thanks to Tyrone
van Balla who fixed this. This should be merged shortly once reviewed and
accepted. As everyone says, it is not needed for the Red Pitaya.

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, Jun 1, 2020 at 8:12 PM Wesley New  wrote:

> Hi Sean.
>
> progska is a c utility that we use to speed up the programming of the
> skarab boards and is not needed for the RP.
>
>
> On Mon, 01 Jun 2020, 7:23 PM Sean Mckee,  wrote:
>
>> Hi Jack,
>>
>> I did try installing casperfpga on the red pitaya, but it appears that
>> one of the libraries (progska, if I recall correctly) requires 64-bit. It
>> was giving me ELFCLASS64 error. Not sure if there's a work around, but I'm
>> pretty comfortable writing C code to run on the red pitaya to manage the
>> registers, so that's the direction I've gone.
>>
>> Thanks!
>> Sean
>>
>> On Monday, June 1, 2020 at 3:59:13 AM UTC-6, Jack Hickish wrote:
>>>
>>> Hi Sean,
>>>
>>> Just to explicitly add to wes's advice - in addition to the telnet
>>> interface on localhost, you can "just" install full blown casperfpga to
>>> your red pitaya, and connect via localhost using the scripts you already
>>> have. Unless your performance requirements are such that python is out of
>>> the question, this is probably the easiest thing to do.
>>>
>>> Cheers
>>> Jack
>>>
>>>
>>> On Sun, 31 May 2020, 10:45 pm Sean Mckee,  wrote:
>>>
>>>> Hi Wesley,
>>>>
>>>> Thank you, that's what I was looking for!
>>>>
>>>> On Sunday, May 31, 2020 at 12:54:31 PM UTC-6, wesley wrote:
>>>>>
>>>>> Hi Sean,
>>>>>
>>>>> These are all good questions and Ill try to point you in the right
>>>>> direction.
>>>>>
>>>>> So if you followed this tutorial to setup your red pitaya:
>>>>> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html#running-the-script-on-a-preloaded-rp-sd-card
>>>>> You should have tcpborphserver installed on the PS. You can telnet
>>>>> into tcpborphserver and issue register read and writes that way. ie you
>>>>> could telnet into tcpborphserver on localhost form the RP using a python
>>>>> script and run your tasks that way. If I remember correctly tcpboprhserver
>>>>> can address a register by name so you shouldnt need to worry about memory
>>>>> maps, but if you are you can look at the fpg file that you uploaded and 
>>>>> the
>>>>> header will contain the memory map. You can also see the memory map in a
>>>>> file called coreinfo.tab in your build directory.
>>>>>
>>>>> Hope this helps.
>>>>>
>>>>> Wesley New
>>>>> South African SKA Project
>>>>> +2721 506 7300
>>>>> www.ska.ac.za
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, May 31, 2020 at 7:56 PM Sean Mckee 
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm trying to determine how I would go about finding/using the
>>>>>> addresses of the memory mapped registers being used by the FPGA, from the
>>>>>> PS side of the Red Pitaya. For example, in the spectrometer tutorial, 
>>>>>> there
>>>>>> are several registers used to control the design, and others to pull data
>>>>>> out from the design. If I access the Red Pitaya from my computer using 
>>>>>> the
>>>>>> casperfpga.py module, these registers are all conveniently named and the
>>>>>> python module has tools to read data from snap blocks, write to the reset
>>>>>> and trigger registers, etc.
>>>>>>
>>>>>> Is there a convenient way to have this same level of control on the
>>>>>> red pitaya itself? I would like to write code that runs on the PS to
>>>>>> monitor these registers and handle the data output. From what I can
>>>>>> currently find, I will need to open the /dev/mem file and use the mmap()
>>>&

Re: [casper] Writing data to SD card

[Adam Isaacson]

Hi Sean,

The Casperised Red Pitaya is running a Linux OS (Debian/Ubuntu), together,
with tcpborphserver on the PS. Tcpborphserver interacts with casperfpga on
your host PC for comms. I am able to ssh into the Red Pitaya and copy files
across using scp. This is all stored on the SD card, so it should easily be
possible to store data on the SD card. I am not sure what rate.

Check out:
https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html?highlight=SD
 and
https://redpitaya.readthedocs.io/en/latest/developerGuide/os/debian.html

I have also used a Raspberry Pi for this type of application in the past
and it works well for data logging. 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 Wed, May 20, 2020 at 5:47 PM Mugundhan vijayaraghavan <
v.vaishnav151...@gmail.com> wrote:

> Hi Sean,
>
> This help document says that the sd card is mounted as the read only /opt
> file system.
>
> https://redpitaya.readthedocs.io/en/latest/developerGuide/software/clt.html?highlight=store%20data#saving-data-buffers
>
> Having said that, red-pitaya GPIOs provide access to SPI interfaces to the
> PS side to connect a SD card and use that for data storage. This has been
> done with Raspberry Pi. So, in principle, should be possible with the
> RedPitaya as well.
>
> Another option is to use an SPI implementation from the PL side, accessing
> the GPIOs (there are about 16), if one is comfortable with using only hdl.
>
> Sincerely,
>
> Mugundhan
>
>
>
>
> On Wed, May 20, 2020 at 8:55 PM Sean Mckee  wrote:
>
>>  Hello all,
>>
>> I'm working on a project that has a Red Pitaya mounted in a drone. It
>> will be monitoring and correlating two antenna inputs. Because the red
>> pitaya will be in a drone, I need to store the processed data coming out of
>> the FPGA onto the SD card. Is this something anyone has worked with in the
>> Casper framework? I can't seem to find much documentation on accomplishing
>> this. It seems like I might need to write some monitoring software for the
>> programming system separately from the programming of the FPGA.
>>
>> I would like to achieve a continuous stream from the FPGA to the SD card
>> of 2 megabytes/sec.
>>
>> Thanks for any insight you might have into this!
>>
>> -Sean
>>
>> --
>> 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/efcfb627-b710-4ba9-87d9-e92ec0c466cb%40lists.berkeley.edu
>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/efcfb627-b710-4ba9-87d9-e92ec0c466cb%40lists.berkeley.edu?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> V. Mugundhan
>
> --
> 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/CAD560xkwqc5%3DVOU_YU1ydXUmZEwXsHNugJ5sqAbBnZvEvf5R%3Dg%40mail.gmail.com
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAD560xkwqc5%3DVOU_YU1ydXUmZEwXsHNugJ5sqAbBnZvEvf5R%3Dg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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%3DnEjNN1AGEmsz_9GDcu_CkfFdEavxdgZBdYA%3DKzJm%2Bh8vA%40mail.gmail.com.

Re: [casper] casperfpga module error: no module named bitfield

[Adam Isaacson]

Hi Sean and Wael,

Yes, that is correct. Casperfpga is only supported with python 2.x for now.
We have been working on porting this to python3. I know at SARAO we have a
python3 compatible version, but I haven't tested it fully yet.

You are welcome to try and let me/James Smith know:

https://github.com/ska-sa/casperfpga/tree/python3-port

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, May 7, 2020 at 2:38 AM Wael Farah  wrote:

> Hi Sean,
>
> I might be wrong, but this error is due to the fact that the
> casperfpga module that you are using (when you do "pip install" and/or the
> master branch of the github repo) is meant to work on python 2.x.
>
> What I can suggest doing is the following:
>
> Uninstall casperfpga
> >> pip uninstall casperfpga
>
> Then in your git directory, do a
> >> git checkout py3-merge
>
> This will switch to the python3 version of the module, and then install it.
>
> Hope this will fix the problem!
>
> Cheers,
> Wael
>
> On Wed, 6 May 2020 at 10:23, Sean Mckee  wrote:
>
>> Greetings Casperites,
>>
>> I'm new to Linux, and I think I must have some simple setting adjusted
>> incorrectly.
>>
>> I'm running ubuntu 16.04 and tried this on a fresh install.
>>
>> I first simply tried "pip install casperfpga", but this gave me the error
>> message:
>>
>> ERROR: Could not find a version that satisfies the requirement casperfpga
>> (from versions: none)
>> ERROR: No matching distribution found for casperfpga
>>
>> I then cloned from https://github.com/casper-astro/casperfpga.git and
>> installed. The installation seemed to go fine, but when I open up an
>> ipython instance and type "import casperfpga" I get the following:
>>
>> > 1 import casperfpga
>>
>> /home/sean/Casper/casper_venv/lib/python3.5/site-packages/casperfpga-0.1.3-py3.5-linux-x86_64.egg/casperfpga/__init__.py
>> in ()
>>   4
>>   5 # import all the main classes that we'll use often
>> > 6 from bitfield import Bitfield, Field
>>   7 from katadc import KatAdc
>>   8 from casperfpga import CasperFpga
>>
>> ImportError: No module named 'bitfield'
>>
>> I tried installing bitfield via "pip install bitfield", but this seems to
>> be a different version of bitfield than expected by casperfpga. I get this
>> error message:
>>
>> > 1 import casperfpga
>>
>> /home/sean/Casper/casper_venv/lib/python3.5/site-packages/casperfpga-0.1.3-py3.5-linux-x86_64.egg/casperfpga/__init__.py
>> in ()
>>   4
>>   5 # import all the main classes that we'll use often
>> > 6 from bitfield import Bitfield, Field
>>   7 from katadc import KatAdc
>>   8 from casperfpga import CasperFpga
>>
>> ImportError: cannot import name 'Field'
>>
>> All of this was run from a python 3 virtual environment. Any insight into
>> this?
>>
>> Thanks,
>> Sean
>>
>> --
>> 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/b00b1193-9742-480b-87df-f4e5a110b683%40lists.berkeley.edu
>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/b00b1193-9742-480b-87df-f4e5a110b683%40lists.berkeley.edu?utm_medium=email_source=footer>
>> .
>>
> --
> 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/CALO2pVeJM3N3khtta4dF1B7Unui7fGj9bP9Ooy_rR%3DOZzd-4wA%40mail.gmail.com
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CALO2pVeJM3N3khtta4dF1B7Unui7fGj9bP9Ooy_rR%3DOZzd-4wA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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%3DnE4RE3gVbJxfaVTjTkJQsBNcQsv1dRbK4bp6njbD%3DTarQ%40mail.gmail.com.

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

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 Th

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

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 

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
>> <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
>>>>&g

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

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

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

Re: [casper] Red Pitaya ADC_DAC Interface tutorial reg

[Adam Isaacson]

Hi Aravind,

Great news that you are up and running. The casper-astro/mlib_devel githash
tag you are showing me is the latest one and should work fine. You should
now try https://github.com/casper-astro/casperfpga and reinstall the same
way you did with the ska-sa casperfpga repo and just confirm that
everything is in working order.

My team will update the ReadtheDocs to include the casperfpga installs to
avoid confusion for others in the next couple of weeks.

>>The only issue I found was that with no input the red pitaya channel
outputs were close to -200 and not 0 as expected. Not sure if there is a
bias in the ADCs in the board?

Just remember there are also input ADC jumper settings for the Red Pitaya -
Low Voltage (LV - 2 Vpp) and High Voltage (HV - 40Vpp) - see
https://redpitaya.readthedocs.io/en/latest/developerGuide/125-10/vs.html.
Make sure your jumper settings are set to LV. I have seen bias on the other
boards. It does tend to differ from board to board. The original Red Pitaya
firmware also included a calibration algorithm for the ADCs, but for our
toolflow we are not using this. We have not explored the full
specifications of the ADC inputs - our goal is to provide a learning
platform for new CASPER users. I have noticed that if you are not using the
ADC inputs then they should be terminated (50 ohm SMA termination) - I have
noticed coupling between channels.

For more information on the Red Pitaya ADC inputs please read the Red
Pitaya ReadtheDocs in more detail. You can also contact the Red Pitaya
support engineer Nicu Irima (email: nicu.iri...@redpitaya.com) who will
assist you.

I have also invited you to the CASPER Red Pitaya slack group - feel free to
post your questions there too.

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 9, 2020 at 10:30 PM Aravind Venkitasubramony <
aravind.venkitasubram...@colorado.edu> wrote:

> Hi Adam
>
> Following your steps, I was able to successfully reinstall casperfpga and
> run the python file without any errors. I get the expected version number
> as you had suggested. Thanks for the detailed step by step instructions.
>
> The only issue I found was that with no input the red pitaya channel
> outputs were close to -200 and not 0 as expected. Not sure if there is a
> bias in the ADCs in the board?
>
> I have recompiled the tutorial 2 with the 10 bit version and attached the
> .fpg file
>
> When I run git rev-parse --branches from inside /../../mlib_devel I get
> 37cfd707e600d3ea005aa757d042084fc083c403
>
> Is this what you were looking for?
>
>
>
> On Thu, Apr 9, 2020 at 1:02 AM Adam Isaacson  wrote:
>
>> Hi Aravind,
>>
>> If you installed the correct casperfpga then I would expect the following:
>>
>> aisaacson@adam-cm:~$ cd work/git_work/ska-sa/
>> aisaacson@adam-cm:~/work/git_work/ska-sa$ ipython
>> Python 2.7.12 (default, Aug 22 2019, 16:36:40)
>> Type "copyright", "credits" or "license" for more information.
>>
>> IPython 2.4.1 -- An enhanced Interactive Python.
>> ? -> Introduction and overview of IPython's features.
>> %quickref -> Quick reference.
>> help  -> Python's own help system.
>> object?   -> Details about 'object', use 'object??' for extra details.
>>
>> In [1]: import casperfpga
>>
>> In [2]: casperfpga.__version__
>> Out[2]: '3.2.dev856+devel.8bd4e4f'  - "devel" indicates the branch and
>> "8bd4e4f" represents the githash - see
>> https://github.com/ska-sa/casperfpga/tree/devel.
>>
>> Please also send me the githash of your mlib_devel branch, so that I can
>> confirm. To install casperfpga properly then please do the following:
>>
>>
>> 1) cd /usr/local/lib/python2.7/dist-packages
>> 2) sudo rm - rf casper*
>> 3) Go to https://github.com/ska-sa/casperfpga/tree/devel and look at
>> Readme.md file.
>> 4) $ git clone https://github.com/ska-sa/casperfpga.git
>> 5) cd to casperfpga install directory
>> 6) git branch -a (should show that you are in master branch)
>> 7) git checkout devel (should place you in devel branch)
>> 8) sudo pip install -r requirements.txt
>> 9) sudo python setup.py install (if done correctly then you should see
>> reference to '3.2.dev856+devel.8bd4e4f in the build.
>> 10) Run ipython when you are out of the casperfpga directory (cd ..)
>> 11) import casperfpga
>> 12) casperfpga.__version__
>> NB: I tried to do the pip install first, but it didn't install properly
>> for me - this worked for me though.
>>
>> The attached script seems fine, but I notice that the fpg me

Re: [casper] Red Pitaya ADC_DAC Interface tutorial reg

[Adam Isaacson]

Hi Aravind,

If you installed the correct casperfpga then I would expect the following:

aisaacson@adam-cm:~$ cd work/git_work/ska-sa/
aisaacson@adam-cm:~/work/git_work/ska-sa$ ipython
Python 2.7.12 (default, Aug 22 2019, 16:36:40)
Type "copyright", "credits" or "license" for more information.

IPython 2.4.1 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help  -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: import casperfpga

In [2]: casperfpga.__version__
Out[2]: '3.2.dev856+devel.8bd4e4f'  - "devel" indicates the branch and
"8bd4e4f" represents the githash - see
https://github.com/ska-sa/casperfpga/tree/devel.

Please also send me the githash of your mlib_devel branch, so that I can
confirm. To install casperfpga properly then please do the following:


1) cd /usr/local/lib/python2.7/dist-packages
2) sudo rm - rf casper*
3) Go to https://github.com/ska-sa/casperfpga/tree/devel and look at
Readme.md file.
4) $ git clone https://github.com/ska-sa/casperfpga.git
5) cd to casperfpga install directory
6) git branch -a (should show that you are in master branch)
7) git checkout devel (should place you in devel branch)
8) sudo pip install -r requirements.txt
9) sudo python setup.py install (if done correctly then you should see
reference to '3.2.dev856+devel.8bd4e4f in the build.
10) Run ipython when you are out of the casperfpga directory (cd ..)
11) import casperfpga
12) casperfpga.__version__
NB: I tried to do the pip install first, but it didn't install properly for
me - this worked for me though.

The attached script seems fine, but I notice that the fpg metadata was
unable to resolve the PC hostname and so I don't see the githash of the
mlib_devel repo. Please send that to me, thanks. I am unable to programme
your fpg file as I have a 10 bit board with me only. Maybe try compile for
10 bits and at least I can test that fpg for you - this will ensure that
your mlib_devel repo is installed correctly.

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 9, 2020 at 1:18 AM Aravind Venkitasubramony <
aravind.venkitasubram...@colorado.edu> wrote:

> Thanks Adam.
>
> I removed all the casper installs as per your instructions and reinstalled
> casperfpga. I still get the similar error as before. And the version is
> also showing up as unknown.
>
> So I removed the packages in /usr/local/.. as you said, downloaded all the
> files in the location you had suggested, cd'ed in to the new folder and
> installed casperfpga as mentioned in the tutorial. I am able to connect to
> the red pitaya board, the led is blinking and everything, but get the
> similar error as before when reading the snapshot.
>
> On Wed, Apr 8, 2020 at 3:00 PM Adam Isaacson  wrote:
>
>> Hi Aravind,
>>
>> You can remove all casperfpga installs by doing the following:
>>
>> 1) cd /usr/local/lib/python2.7/dist-packages
>> 2) sudo rm - rf casper*
>>
>> This will remove all casperfpga installs.
>>
>> The version of casperfpga you read back didn't look right to me. It
>> should not be unknown. Once you install the link I sent you, you should
>> read back the branch and githash, I think.
>>
>> I will look at these files tomorrow.
>>
>> Kind regards,
>>
>> Adam
>>
>> On Wed, 08 Apr 2020, 8:06 PM Aravind Venkitasubramony, <
>> aravind.venkitasubram...@colorado.edu> wrote:
>>
>>> The version returned by is '0.0+unknown.202004081054'.
>>>
>>> Attached are the fpg and the py files.
>>>
>>> I tried to uninstall casperfpga and reinstall from the version you had
>>> provided. But now I get an error while running ipython and typing
>>> casperfpga in the terminal
>>>
>>> NameError Traceback (most recent call
>>> last)
>>>  in ()
>>> > 1 casperfpga
>>>
>>> NameError: name 'casperfpga' is not defined
>>>
>>> I am afraid if I have messed up the casperfpga installation. Is there a
>>> way to clean up all the casperfpga related files and install afresh?
>>>
>>>
>>>
>>> On Wed, Apr 8, 2020 at 12:58 AM Adam Isaacson 
>>> wrote:
>>>
>>>> Dear Aravind,
>>>>
>>>> The slx file looks correct. This issue does look familiar to me - we
>>>> used to have an issue with the snap shot byte ordering. I am wondering what
>>>> version of casperfpga you are using? Pleas

Re: [casper] Red Pitaya ADC_DAC Interface tutorial reg

[Adam Isaacson]

Hi Aravind,

You can remove all casperfpga installs by doing the following:

1) cd /usr/local/lib/python2.7/dist-packages
2) sudo rm - rf casper*

This will remove all casperfpga installs.

The version of casperfpga you read back didn't look right to me. It should
not be unknown. Once you install the link I sent you, you should read back
the branch and githash, I think.

I will look at these files tomorrow.

Kind regards,

Adam

On Wed, 08 Apr 2020, 8:06 PM Aravind Venkitasubramony, <
aravind.venkitasubram...@colorado.edu> wrote:

> The version returned by is '0.0+unknown.202004081054'.
>
> Attached are the fpg and the py files.
>
> I tried to uninstall casperfpga and reinstall from the version you had
> provided. But now I get an error while running ipython and typing
> casperfpga in the terminal
>
> NameError Traceback (most recent call last)
>  in ()
> > 1 casperfpga
>
> NameError: name 'casperfpga' is not defined
>
> I am afraid if I have messed up the casperfpga installation. Is there a
> way to clean up all the casperfpga related files and install afresh?
>
>
>
> On Wed, Apr 8, 2020 at 12:58 AM Adam Isaacson  wrote:
>
>> Dear Aravind,
>>
>> The slx file looks correct. This issue does look familiar to me - we used
>> to have an issue with the snap shot byte ordering. I am wondering what
>> version of casperfpga you are using? Please do the following in your
>> terminal:
>>
>> 1) ipython
>> 2) import casperfpga
>> 3) casperfpga.__version__
>>
>> Let me know what version you read back.
>>
>> I suspect you are using an old version of casperfpga with this bug. Try
>> using the following version of casperfpga:
>>
>> https://github.com/ska-sa/casperfpga/tree/devel
>>
>> Please also send me your python modified test scripts and fpg generated
>> file for 14 bits, thanks.
>>
>> 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 8:30 PM Aravind Venkitasubramony <
>> aravind.venkitasubram...@colorado.edu> wrote:
>>
>>> Thanks Adam!
>>>
>>> That was quite helpful. I was able to find the compiled slx files from
>>> the repository and comparing the two models definitely helped answer a lot
>>> of 101 level doubts.
>>>
>>> I only have the 14 bit RP board with me and I made the edits in the
>>> blocks as far as I understood from the tutorial. Since there were two
>>> separate yaml files for the 10 and 14 bit boards, I believe I did not have
>>> to make any changes there. The compile also went through without any issues
>>> and generated the fpg file. But when I run the python, I get the following
>>> error message
>>>
>>> connecting to the Red Pitaya...
>>> done
>>> programming the Red Pitaya...
>>> done
>>> arming snapshot block...
>>> done
>>> triggering the snapshot and reset the counters...
>>> done
>>> reading the snapshot...
>>> Traceback (most recent call last):
>>>   File "tut_adc_dac.py", line 54, in 
>>> adc_in = rp.snapshots.adc_in_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: adc_in_snap_ss.read_uint() - expected 4096 bytes, got 32
>>>
>>>
>>> The line 227 in the snap.py mentioned here addresses something specific
>>> to Red Pitaya as seen from the comments in the snap.py file and I did not
>>> follow what it was.
>>>
>>> This was the same error I got in the tutorial 3 as well in the
>>> spectrometer case. Since there is no bit growth issue here in the tutorial
>>> 2, I am not sure why this error message shows up here as well.
>>>
>>> I have attached the slx and fpg files I created for a 14 bit RP board
>>> for the tutorial 2.
>>>
>>> On Tue, Apr 7, 2020 at 2:52 AM Adam Isaacson 
>>> wrote:
>>>
>>>> Dear Aravind,
>>>>
>>>> I have fixed your slx file - see attached. There were a few issues:
>>>>
>>>> 1) 

Re: [casper] Red Pitaya ADC_DAC Interface tutorial reg

[Adam Isaacson]

Dear Aravind,

The slx file looks correct. This issue does look familiar to me - we used
to have an issue with the snap shot byte ordering. I am wondering what
version of casperfpga you are using? Please do the following in your
terminal:

1) ipython
2) import casperfpga
3) casperfpga.__version__

Let me know what version you read back.

I suspect you are using an old version of casperfpga with this bug. Try
using the following version of casperfpga:

https://github.com/ska-sa/casperfpga/tree/devel

Please also send me your python modified test scripts and fpg generated
file for 14 bits, thanks.

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

> Thanks Adam!
>
> That was quite helpful. I was able to find the compiled slx files from the
> repository and comparing the two models definitely helped answer a lot of
> 101 level doubts.
>
> I only have the 14 bit RP board with me and I made the edits in the blocks
> as far as I understood from the tutorial. Since there were two separate
> yaml files for the 10 and 14 bit boards, I believe I did not have to make
> any changes there. The compile also went through without any issues and
> generated the fpg file. But when I run the python, I get the following
> error message
>
> connecting to the Red Pitaya...
> done
> programming the Red Pitaya...
> done
> arming snapshot block...
> done
> triggering the snapshot and reset the counters...
> done
> reading the snapshot...
> Traceback (most recent call last):
>   File "tut_adc_dac.py", line 54, in 
> adc_in = rp.snapshots.adc_in_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: adc_in_snap_ss.read_uint() - expected 4096 bytes, got 32
>
>
> The line 227 in the snap.py mentioned here addresses something specific to
> Red Pitaya as seen from the comments in the snap.py file and I did not
> follow what it was.
>
> This was the same error I got in the tutorial 3 as well in the
> spectrometer case. Since there is no bit growth issue here in the tutorial
> 2, I am not sure why this error message shows up here as well.
>
> I have attached the slx and fpg files I created for a 14 bit RP board for
> the tutorial 2.
>
> On Tue, Apr 7, 2020 at 2:52 AM Adam Isaacson  wrote:
>
>> Dear Aravind,
>>
>> I have fixed your slx file - see attached. There were a few issues:
>>
>> 1) sw_reg reg_cntrl yellow block bitfield type was not set to boolean
>> 2) your snapshot, adc_in_snap, was not setup correctly. You have to
>> manually add the names in the snapshot fields - double click on the
>> snapshot and see "input" tab
>> 3) Your adc_sample_ctr was set to 9 bits and not 32 bits.
>>
>> It should compile fine now. My advice is that if you are struggling to
>> get your slx file to compile, then look at the completed design slx file in
>> github and make sure your design matches that. There is a completed slx
>> model and working fpg file for each tutorial.
>>
>> 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 10:28 AM Adam Isaacson 
>> wrote:
>>
>>> Dear Aravind,
>>>
>>> Did you know there is an existing, working and completed slx file
>>> (tut_adc_dac.slx) for this tutorial in:
>>>
>>>
>>> https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_adc_dac
>>>
>>> I would compare that file with your file attached and look for any
>>> differences. I am also going to look at your file and see if I can spot
>>> anything. Stay tuned.
>>>
>>> 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:53 AM Aravind Venkitasubramony <
>>> arve9...@colorado.edu> wrote:
>>>
>>>> 

Re: [casper] Red Pitaya ADC_DAC Interface tutorial reg

[Adam Isaacson]

Dear Aravind,

I have fixed your slx file - see attached. There were a few issues:

1) sw_reg reg_cntrl yellow block bitfield type was not set to boolean
2) your snapshot, adc_in_snap, was not setup correctly. You have to
manually add the names in the snapshot fields - double click on the
snapshot and see "input" tab
3) Your adc_sample_ctr was set to 9 bits and not 32 bits.

It should compile fine now. My advice is that if you are struggling to get
your slx file to compile, then look at the completed design slx file in
github and make sure your design matches that. There is a completed slx
model and working fpg file for each tutorial.

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 10:28 AM Adam Isaacson  wrote:

> Dear Aravind,
>
> Did you know there is an existing, working and completed slx file
> (tut_adc_dac.slx) for this tutorial in:
>
>
> https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_adc_dac
>
> I would compare that file with your file attached and look for any
> differences. I am also going to look at your file and see if I can spot
> anything. Stay tuned.
>
> 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:53 AM Aravind Venkitasubramony <
> arve9...@colorado.edu> wrote:
>
>> Hi
>>
>> I followed the tutorial and created the .slx file. While compiling I got
>> these errors from simulink.
>>
>>
>> Matching "From" for "Goto" 'rp_tut2/adc_in_snap/ss/goto_ss_we1' not found
>> [4 similar]
>> Component:Simulink | Category:Block warning
>> Output port 1 of 'rp_tut2/dac/rp_tut2_dac_dac0_data_i_in' is not
>> connected. [8 similar]
>> Component:Simulink | Category:Block warning
>> The input type propagated to this block did not match the specified type.
>>   Expected Type: Bool
>>   Actual Type: Fix_10_0
>>
>> Error occurred during "Rate and Type Error Checking".
>>
>>
>> Reported by:
>>   'rp_tut2/adc_in_snap/assert_b'
>> A summary of Sysgen errors has been written to
>> '/home/cet/RP_work/models/rp_tut2/rp_tut2_sysgen_error.log'
>>
>> Reported by:
>>   'rp_tut2/adc_in_snap/assert_b'
>>
>> I also notice that I do not get the "in_adc_data_valid" port shown in the
>> in the bit field snap block on the tutorial page. Other than that, I
>> recreated everything as mentioned in the tutorial page. I have attached the
>> .slx  and the sysgen error log files also alongwith
>>
>> --
>> 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/ddcf80a1-1118-4262-94a1-1e7cc66f0056%40lists.berkeley.edu
>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/ddcf80a1-1118-4262-94a1-1e7cc66f0056%40lists.berkeley.edu?utm_medium=email_source=footer>
>> .
>>
>

-- 
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%3DnFCBeu6L8r5Rc14hGQ8UX2M6b8dX%3DbfEqOgk5XsRnv76g%40mail.gmail.com.


rp_tut2.slx
Description: Binary data

Re: [casper] Red Pitaya ADC_DAC Interface tutorial reg

[Adam Isaacson]

Dear Aravind,

Did you know there is an existing, working and completed slx file
(tut_adc_dac.slx) for this tutorial in:

https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_adc_dac

I would compare that file with your file attached and look for any
differences. I am also going to look at your file and see if I can spot
anything. Stay tuned.

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:53 AM Aravind Venkitasubramony <
arve9...@colorado.edu> wrote:

> Hi
>
> I followed the tutorial and created the .slx file. While compiling I got
> these errors from simulink.
>
>
> Matching "From" for "Goto" 'rp_tut2/adc_in_snap/ss/goto_ss_we1' not found
> [4 similar]
> Component:Simulink | Category:Block warning
> Output port 1 of 'rp_tut2/dac/rp_tut2_dac_dac0_data_i_in' is not
> connected. [8 similar]
> Component:Simulink | Category:Block warning
> The input type propagated to this block did not match the specified type.
>   Expected Type: Bool
>   Actual Type: Fix_10_0
>
> Error occurred during "Rate and Type Error Checking".
>
>
> Reported by:
>   'rp_tut2/adc_in_snap/assert_b'
> A summary of Sysgen errors has been written to
> '/home/cet/RP_work/models/rp_tut2/rp_tut2_sysgen_error.log'
>
> Reported by:
>   'rp_tut2/adc_in_snap/assert_b'
>
> I also notice that I do not get the "in_adc_data_valid" port shown in the
> in the bit field snap block on the tutorial page. Other than that, I
> recreated everything as mentioned in the tutorial page. I have attached the
> .slx  and the sysgen error log files also alongwith
>
> --
> 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/ddcf80a1-1118-4262-94a1-1e7cc66f0056%40lists.berkeley.edu
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/ddcf80a1-1118-4262-94a1-1e7cc66f0056%40lists.berkeley.edu?utm_medium=email_source=footer>
> .
>

-- 
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%3DnGJ_XGEYUWkrjUA2XZkoJSzfhP5eBx%2BgAWwhQ0P%3DpjYmw%40mail.gmail.com.

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
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/77f027f3-c878-43c1-ab28-b77f3582d4f8%40lists.berkeley.edu?utm_medium=email_source=footer>
> .
>

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

Re: [casper] Red Pitaya Tutorial 1 reg

[Adam Isaacson]

Thx, Marc! 

On Sun, 05 Apr 2020, 11:10 AM Marc,  wrote:

>
>
> On Sat, Apr 4, 2020 at 2:55 PM Adam Isaacson  wrote:
>
>> Hi Aravind,
>>
>> Yes, you need casperfpga to configure the Red Pitaya. The tutorials
>> explains how to use casperfpga. The Zynq processor on the Red Pitaya is
>> running software called tcpborphserver. Casperfpga is a python comms
>> package communicates with the tcpborphserver. You can also telnet to
>> tcpborphserver directly on port 7147 and type "help?" It will give you a
>> list of commands.
>>
>
> Small correction - the command would be "?help".
>
> There are commands to read and write registers, and there is a utility
> called kcpfg which should make it possible to program an fpg file remotely
>
> regards
>
> marc
>
> --
> 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/CAGrhWaQMGrhJ0RHbMWZHf-V-vtC6fF%2BSze9fkJOjH1nuX%2BVZ%2Bw%40mail.gmail.com
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAGrhWaQMGrhJ0RHbMWZHf-V-vtC6fF%2BSze9fkJOjH1nuX%2BVZ%2Bw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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%3DnHvbnDEr5QLw2A96FfG1UfKKO9p5Ct8_-if8V5Cgaw4RQ%40mail.gmail.com.

Re: [casper] Red Pitaya Tutorial 1 reg

[Adam Isaacson]

Hi Aravind,

Yes, you need casperfpga to configure the Red Pitaya. The tutorials
explains how to use casperfpga. The Zynq processor on the Red Pitaya is
running software called tcpborphserver. Casperfpga is a python comms
package communicates with the tcpborphserver. You can also telnet to
tcpborphserver directly on port 7147 and type "help?" It will give you a
list of commands.

I suggest as a beginner to use casperfpga. It is not very well documented
compared to the Toolflow, but I am happy to guide you through it.

Kind regards,

Adam

On Fri, 03 Apr 2020, 6:13 PM Aravind Venkitasubramony, <
aravind.venkitasubram...@colorado.edu> wrote:

> Ok. So I need to install casperfpga in my Linux machine which will be the
> "server" in my case and proceed further with the next steps. Am I right?
>
> On Fri, Apr 3, 2020 at 3:38 AM Adam Isaacson  wrote:
>
>> Hi Aravind,
>>
>> David, is correct. This is for a specific setup. I think it was the
>> Hardware Porting Workshop for 2019. The Red Pitaya was connected to a
>> hardware server running casperfpga. The secure copy is a linux command that
>> allows you to copy your fpg file from your compile machine to the hardware
>> server with the python application casperfpga running on it. You then
>> program the board using casperfpga.
>>
>> In your case, you can just connect the Red Pitaya to your network and if
>> you install casperfpga on your compile machine then it will connect. The
>> hostname of your Red Pitaya is on the RJ45 connector on the board e.g.
>> rp-f04702.local". If you ping that you should get a response.
>>
>> To install casperfpga and run it check out the Readme.md :
>> https://github.com/casper-astro/casperfpga.
>>
>> Shout if any questions.
>>
>> 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 3, 2020 at 2:44 AM David MacMahon 
>> wrote:
>>
>>> Hi, Aravind,
>>>
>>> On Apr 2, 2020, at 17:19, Aravind Venkitasubramony <
>>> arve9...@colorado.edu> wrote:
>>>
>>>  am stuck on the secure copy step mentioned in the tutorial 1 - "As per
>>> the previous figure, navigate to the outputs folder and (secure)copy this
>>> across to a test folder on the workshop server. Instructions to do this are
>>> available here
>>> <https://github.com/casper-astro/tutorials_devel/blob/master/workshop_setup.md#getting-your-designs-on-to-hardware>
>>> ."
>>>
>>> What is the "workshop server" mentioned here according to my setup? Do I
>>> copy directly to rp-xx/katcp ? Can you please clarify that part?
>>>
>>>
>>> I'm not a Red Pitaya expert, but I think that part of the instructions
>>> was written for a specific setup that was running at a workshop where the
>>> Red Pitayas were being shared between multiple participants.  I think all
>>> you need to do for your local setup is ensure that the fpg file gets to a
>>> machine which can communicate with the Red Pitaya using casperfpga (if it's
>>> not already on such a machine).
>>>
>>> I'm sure others with more Red Pitaya experience can expand on or correct
>>> that as needed. :)
>>>
>>> HTH,
>>> Dave
>>>
>>> --
>>> 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/346E510A-6B20-42B0-B743-B2BF3B87EE15%40berkeley.edu
>>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/346E510A-6B20-42B0-B743-B2BF3B87EE15%40berkeley.edu?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> 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%3DnEh4MeoO4cHq0h3RvhsAp0V%2B%3DmytjKU9byz2nebAs4r3A%40mail.gmail.com
>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/

Re: [casper] Red Pitaya Tutorial 1 reg

[Adam Isaacson]

Hi Aravind,

David, is correct. This is for a specific setup. I think it was the
Hardware Porting Workshop for 2019. The Red Pitaya was connected to a
hardware server running casperfpga. The secure copy is a linux command that
allows you to copy your fpg file from your compile machine to the hardware
server with the python application casperfpga running on it. You then
program the board using casperfpga.

In your case, you can just connect the Red Pitaya to your network and if
you install casperfpga on your compile machine then it will connect. The
hostname of your Red Pitaya is on the RJ45 connector on the board e.g.
rp-f04702.local". If you ping that you should get a response.

To install casperfpga and run it check out the Readme.md :
https://github.com/casper-astro/casperfpga.

Shout if any questions.

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 3, 2020 at 2:44 AM David MacMahon  wrote:

> Hi, Aravind,
>
> On Apr 2, 2020, at 17:19, Aravind Venkitasubramony 
> wrote:
>
>  am stuck on the secure copy step mentioned in the tutorial 1 - "As per
> the previous figure, navigate to the outputs folder and (secure)copy this
> across to a test folder on the workshop server. Instructions to do this are
> available here
> <https://github.com/casper-astro/tutorials_devel/blob/master/workshop_setup.md#getting-your-designs-on-to-hardware>
> ."
>
> What is the "workshop server" mentioned here according to my setup? Do I
> copy directly to rp-xx/katcp ? Can you please clarify that part?
>
>
> I'm not a Red Pitaya expert, but I think that part of the instructions was
> written for a specific setup that was running at a workshop where the Red
> Pitayas were being shared between multiple participants.  I think all you
> need to do for your local setup is ensure that the fpg file gets to a
> machine which can communicate with the Red Pitaya using casperfpga (if it's
> not already on such a machine).
>
> I'm sure others with more Red Pitaya experience can expand on or correct
> that as needed. :)
>
> HTH,
> Dave
>
> --
> 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/346E510A-6B20-42B0-B743-B2BF3B87EE15%40berkeley.edu
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/346E510A-6B20-42B0-B743-B2BF3B87EE15%40berkeley.edu?utm_medium=email_source=footer>
> .
>

-- 
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%3DnEh4MeoO4cHq0h3RvhsAp0V%2B%3DmytjKU9byz2nebAs4r3A%40mail.gmail.com.

Re: [casper] (Red Pitaya 125-14) RuntimeError: no programming informs yet. Odd?

[Adam Isaacson]

Hi Jack and Lukas,

Yes, good point, Jack! Sysgen is not supported. We use the system edition
license, which covers everything.

It is just the 30 day evaluation license and the system edition license
that enables sysgen, it seems.

Kind regards,

Adam



On Thu, 13 Feb 2020, 2:51 PM Jack Hickish,  wrote:

> Hi Lukas,
>
> I think while you might be able to compile vivado projects and make fpg
> files with the webpack license, I don't think you'll be able to compile
> anything from simulink, since I don't think the webpack license includes
> System Generator support.
>
> Cheers
> Jack
>
> On Thu, 13 Feb 2020 at 12:43, Adam Isaacson  wrote:
>
>> Hi Lukas,
>>
>> Excellent, please thank Alex Raymond and not me. @Alex, much appreciated!
>>
>> The Zynq device on the Red Pitaya is a small one and I believe that the
>> web pack license should compile it, but I have not tested it as I have a
>> license.
>>
>> Try it out and see to confirm.
>>
>> Kind regards,
>>
>> Adam
>>
>> On Thu, 13 Feb 2020, 10:45 AM Lukas Karch,  wrote:
>>
>>> Thank you for all the help. Adding "127.0.0.1 localhost" to the host
>>> file worked. Afterwards I was able to program the fpga both with the
>>> tutorial .fpg file and a .fpg file I compiled myself.
>>> Just one more question. Do you happen to know if it is possible to
>>> compile .fpg files for the Red Pitaya using only Vivado WebPack.
>>> At the moment I'm using a 30 day evaluation license and I am wondering
>>> if compiling .fpg files will still work after it runs out.
>>>
>>> Adam Isaacson  hat am 11. Februar 2020 um 16:33
>>> geschrieben:
>>>
>>> Hi Lukas,
>>>
>>> Alexander Raymond from CfA remembers we may have had the same issue in
>>> Boston last year. Thanks, Alex! He suggests the following:
>>>
>>> "Adding 127.0.0.1 localhost to /etc/hosts worked for us in getting past
>>> the " *no programming informs yet. Odd?* “ error."
>>>
>>> Let us know how you progress.
>>>
>>> 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, Feb 11, 2020 at 10:06 AM Adam Isaacson < aisaac...@ska.ac.za>
>>> wrote:
>>>
>>> Hi Lukas,
>>>
>>> 1) Did you install casperfpga using the following exactly (ReadMe.md
>>> "installation" section):  https://github.com/casper-astro/casperfpga?
>>>
>>> 2) What casperfpga version are you using? Type "casperfpga.__version__"
>>> after you import casperfpga.
>>>
>>> 3) You are sure tcpborphserver is running? if it is not running then
>>> casperfpga will not work. Refer to:
>>>  
>>> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html
>>> <https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html>.
>>>
>>>
>>> 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, Feb 11, 2020 at 9:48 AM Lukas Karch < lu...@karch.info> wrote:
>>>
>>> Thank you for the quick response. I tried specifiying the port number
>>> but the same error appeared. I tried using the .fpg and python script you
>>> suggested and a very similar error message appeared:
>>> *lukas@lukas-HP-Pavilion-x360-Convertible-15-br1xx:~/Downloads$ python
>>> tut_adc_dac.py 10.42.0.69 -p -b tut_adc_dac.fpg*
>>> *connecting to the Red Pitaya...*
>>> *done*
>>> *programming the Red Pitaya...*
>>> *2020-02-11 08:09:51.39 ERROR 10.42.0.69 transport_katcp.py:594 -
>>> 10.42.0.69 <http://10.42.0.69>: no programming informs yet. Odd?*
>>> *ERROR:10.42.0.69:10.42.0.69: no programming informs yet. Odd?*
>>> *Traceback (most recent call last):*
>>> *File "tut_adc_dac.py", line 38, in *
>>> *rp.upload_to_ram_and_program(opts.fpg)*
>>> *File
>>> "/usr/local/lib/python2.7/dist-packages/casperfpga-0.1.2-py2.7-linux-x86_64.egg/casperfp

Re: [casper] (Red Pitaya 125-14) RuntimeError: no programming informs yet. Odd?

[Adam Isaacson]

Hi Lukas,

Excellent, please thank Alex Raymond and not me. @Alex, much appreciated!

The Zynq device on the Red Pitaya is a small one and I believe that the web
pack license should compile it, but I have not tested it as I have a
license.

Try it out and see to confirm.

Kind regards,

Adam

On Thu, 13 Feb 2020, 10:45 AM Lukas Karch,  wrote:

> Thank you for all the help. Adding "127.0.0.1 localhost" to the host file
> worked. Afterwards I was able to program the fpga both with the tutorial
> .fpg file and a .fpg file I compiled myself.
> Just one more question. Do you happen to know if it is possible to compile
> .fpg files for the Red Pitaya using only Vivado WebPack.
> At the moment I'm using a 30 day evaluation license and I am wondering if
> compiling .fpg files will still work after it runs out.
>
> Adam Isaacson  hat am 11. Februar 2020 um 16:33
> geschrieben:
>
> Hi Lukas,
>
> Alexander Raymond from CfA remembers we may have had the same issue in
> Boston last year. Thanks, Alex! He suggests the following:
>
> "Adding 127.0.0.1 localhost to /etc/hosts worked for us in getting past
> the " *no programming informs yet. Odd?* “ error."
>
> Let us know how you progress.
>
> 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, Feb 11, 2020 at 10:06 AM Adam Isaacson < aisaac...@ska.ac.za>
> wrote:
>
> Hi Lukas,
>
> 1) Did you install casperfpga using the following exactly (ReadMe.md
> "installation" section):  https://github.com/casper-astro/casperfpga?
>
> 2) What casperfpga version are you using? Type "casperfpga.__version__"
> after you import casperfpga.
>
> 3) You are sure tcpborphserver is running? if it is not running then
> casperfpga will not work. Refer to:
>  
> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html
> <https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html>.
>
>
> 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, Feb 11, 2020 at 9:48 AM Lukas Karch < lu...@karch.info> wrote:
>
> Thank you for the quick response. I tried specifiying the port number but
> the same error appeared. I tried using the .fpg and python script you
> suggested and a very similar error message appeared:
> *lukas@lukas-HP-Pavilion-x360-Convertible-15-br1xx:~/Downloads$ python
> tut_adc_dac.py 10.42.0.69 -p -b tut_adc_dac.fpg*
> *connecting to the Red Pitaya...*
> *done*
> *programming the Red Pitaya...*
> *2020-02-11 08:09:51.39 ERROR 10.42.0.69 transport_katcp.py:594 -
> 10.42.0.69 <http://10.42.0.69>: no programming informs yet. Odd?*
> *ERROR:10.42.0.69:10.42.0.69: no programming informs yet. Odd?*
> *Traceback (most recent call last):*
> *File "tut_adc_dac.py", line 38, in *
> *rp.upload_to_ram_and_program(opts.fpg)*
> *File
> "/usr/local/lib/python2.7/dist-packages/casperfpga-0.1.2-py2.7-linux-x86_64.egg/casperfpga/casperfpga.py",
> line 314, in upload_to_ram_and_program*
> *filename=filename, wait_complete=wait_complete)*
> *File
> "/usr/local/lib/python2.7/dist-packages/casperfpga-0.1.2-py2.7-linux-x86_64.egg/casperfpga/transport_katcp.py",
> line 596, in upload_to_ram_and_program*
> *'Odd?' % self.host)*
> *RuntimeError: 10.42.0.69 <http://10.42.0.69>: no programming informs yet.
> Odd?*
>
> Regarding the setup of the Red Pitaya, i mostly followed the instructions
> on this site:
> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html.
> Only "git clone https://github.com/ska-sa/katcp.git; did not work ( *fatal:
> unable to access 'https://github.com/ska-sa/katcp.git/
> <https://github.com/ska-sa/katcp.git/>': Could not resolve host: github.com
> <http://github.com>*), so I downloaded the github on my pc and used "scp
> -r" to copy it to my Red Pitaya.
> Regarding the casperfpga version, I followed the installation instructions
> on this site: https://github.com/casper-astro/casperfpga. At first I
> installed casperfpga using "sudo pip install casperfpga". Later I also
> tried "sudo python setup.py install" but it made no difference.
>
> Adam Isaacson < aisaac...@ska.ac.za> hat am 7. Februar 2020 um 16:26
> geschrieben:
>
> Hi Lukas,
>
> This proble

Re: [casper] (Red Pitaya 125-14) RuntimeError: no programming informs yet. Odd?

[Adam Isaacson]

Okay, have you also tried the recommended:

1) Adding 127.0.0.1 localhost to /etc/hosts, as suggested by Alex Raymond
in the previous email?

If that doesn't work then let's try do this without casperfpga for now. We
will use the underlying tcpborphserver:

1) ssh into your Red Pitaya: ssh root@rp-f0495e.local, password: root. The
"f0495e.local" is the host name of my red Pitaya, but your one will be on
your RJ45 Ethernet connector. Just make sure you use your host name and not
mine. You should be able to ping your board on the network using the
"f0XXXe.local" name and ssh into your board. You can also telnet into the
Red Pitaya on port = 7147.

2) It looks like your tcpborphserver is running, but you can make sure by
changing directory to the bin/tcpborphserver3 directory and running
"./tcpborphserver3". This should definitely start tcpborphserver if it
hasn't started.

3) Copy the fpg file across to the Red Pitaya. You should be able to
program the Red Pitaya by either typing a) "kcpfpg .fpg" or if
the fpg is executable then b) "./.fpg". You may need to be in the
same directory as the kcpfpg executable file. It should be in the
tcpborphserver directory. I am going on memory now. The programming is very
quick, so if it takes too long then you know you have an issue. There
should also be a flashing orange LED on one of the user LED outputs if
successful.

Let me know if you struggle with any of this. Each step should be
successful, so if this doesn't work then there is an issue with your setup.

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, Feb 12, 2020 at 10:00 AM Lukas Karch  wrote:

> 1) Yes I followed the instructions in the ReadMe.md installation section.
> 2) It says the casperfpga version is '0.0+unknown.202002120728'. I tried
> reinstalling casperfpga and afterwards it said: '0.0+unknown.202002120831'.
> 3) There is a process called tcpborphserver, so I assume the server is
> running:
> *USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND* *root 1571 0.0
> 0.3 1968 1452 ? Ss 13:59 0:00 /bin/tcpborphserver3*
>
> Adam Isaacson  hat am 11. Februar 2020 um 09:06
> geschrieben:
>
> Hi Lukas,
>
> 1) Did you install casperfpga using the following exactly (ReadMe.md
> "installation" section):  https://github.com/casper-astro/casperfpga?
>
> 2) What casperfpga version are you using? Type "casperfpga.__version__"
> after you import casperfpga.
>
> 3) You are sure tcpborphserver is running? if it is not running then
> casperfpga will not work. Refer to:
>  
> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html
> <https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html>.
>
>
> 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, Feb 11, 2020 at 9:48 AM Lukas Karch < lu...@karch.info> wrote:
>
> Thank you for the quick response. I tried specifiying the port number but
> the same error appeared. I tried using the .fpg and python script you
> suggested and a very similar error message appeared:
> *lukas@lukas-HP-Pavilion-x360-Convertible-15-br1xx:~/Downloads$ python
> tut_adc_dac.py 10.42.0.69 -p -b tut_adc_dac.fpg*
> *connecting to the Red Pitaya...*
> *done*
> *programming the Red Pitaya...*
> *2020-02-11 08:09:51.39 ERROR 10.42.0.69 transport_katcp.py:594 -
> 10.42.0.69 <http://10.42.0.69>: no programming informs yet. Odd?*
> *ERROR:10.42.0.69:10.42.0.69: no programming informs yet. Odd?*
> *Traceback (most recent call last):*
> *File "tut_adc_dac.py", line 38, in *
> *rp.upload_to_ram_and_program(opts.fpg)*
> *File
> "/usr/local/lib/python2.7/dist-packages/casperfpga-0.1.2-py2.7-linux-x86_64.egg/casperfpga/casperfpga.py",
> line 314, in upload_to_ram_and_program*
> *filename=filename, wait_complete=wait_complete)*
> *File
> "/usr/local/lib/python2.7/dist-packages/casperfpga-0.1.2-py2.7-linux-x86_64.egg/casperfpga/transport_katcp.py",
> line 596, in upload_to_ram_and_program*
> *'Odd?' % self.host)*
> *RuntimeError: 10.42.0.69 <http://10.42.0.69>: no programming informs yet.
> Odd?*
>
> Regarding the setup of the Red Pitaya, i mostly followed the instructions
> on this site:
> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html.
> Only "git clone https://github.com/ska-sa/katcp.git; did not work ( *fatal:
> unable to access 'h

Re: [casper] (Red Pitaya 125-14) RuntimeError: no programming informs yet. Odd?

[Adam Isaacson]

Hi Lukas,

Alexander Raymond from CfA remembers we may have had the same issue in
Boston last year. Thanks, Alex! He suggests the following:

"Adding 127.0.0.1 localhost to /etc/hosts worked for us in getting past the
"*no programming informs yet. Odd?* “ error."

Let us know how you progress.

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, Feb 11, 2020 at 10:06 AM Adam Isaacson  wrote:

> Hi Lukas,
>
> 1) Did you install casperfpga using the following exactly (ReadMe.md
> "installation" section): https://github.com/casper-astro/casperfpga?
>
> 2) What casperfpga version are you using? Type "casperfpga.__version__"
> after you import casperfpga.
>
> 3) You are sure tcpborphserver is running? if it is not running then
> casperfpga will not work. Refer to:
>  
> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html
> <https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html>
> .
>
> 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, Feb 11, 2020 at 9:48 AM Lukas Karch  wrote:
>
>> Thank you for the quick response. I tried specifiying the port number but
>> the same error appeared. I tried using the .fpg and python script you
>> suggested and a very similar error message appeared:
>> *lukas@lukas-HP-Pavilion-x360-Convertible-15-br1xx:~/Downloads$ python
>> tut_adc_dac.py 10.42.0.69 -p -b tut_adc_dac.fpg*
>> *connecting to the Red Pitaya...*
>> *done*
>> *programming the Red Pitaya...*
>> *2020-02-11 08:09:51.39 ERROR 10.42.0.69 transport_katcp.py:594 -
>> 10.42.0.69 <http://10.42.0.69>: no programming informs yet. Odd?*
>> *ERROR:10.42.0.69:10.42.0.69: no programming informs yet. Odd?*
>> *Traceback (most recent call last):*
>> *File "tut_adc_dac.py", line 38, in *
>> *rp.upload_to_ram_and_program(opts.fpg)*
>> *File
>> "/usr/local/lib/python2.7/dist-packages/casperfpga-0.1.2-py2.7-linux-x86_64.egg/casperfpga/casperfpga.py",
>> line 314, in upload_to_ram_and_program*
>> *filename=filename, wait_complete=wait_complete)*
>> *File
>> "/usr/local/lib/python2.7/dist-packages/casperfpga-0.1.2-py2.7-linux-x86_64.egg/casperfpga/transport_katcp.py",
>> line 596, in upload_to_ram_and_program*
>> *'Odd?' % self.host)*
>> *RuntimeError: 10.42.0.69 <http://10.42.0.69>: no programming informs
>> yet. Odd?*
>>
>> Regarding the setup of the Red Pitaya, i mostly followed the instructions
>> on this site:
>> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html.
>> Only "git clone https://github.com/ska-sa/katcp.git; did not work ( *fatal:
>> unable to access 'https://github.com/ska-sa/katcp.git/
>> <https://github.com/ska-sa/katcp.git/>': Could not resolve host: github.com
>> <http://github.com>*), so I downloaded the github on my pc and used "scp
>> -r" to copy it to my Red Pitaya.
>> Regarding the casperfpga version, I followed the installation
>> instructions on this site: https://github.com/casper-astro/casperfpga.
>> At first I installed casperfpga using "sudo pip install casperfpga". Later
>> I also tried "sudo python setup.py install" but it made no difference.
>>
>> Adam Isaacson  hat am 7. Februar 2020 um 16:26
>> geschrieben:
>>
>> Hi Lukas,
>>
>> This problem seems familiar to me, but I can't quite remember the
>> solution. These are possible suggestions to try:
>>
>> 1) Have you tried specifying the port number?  fpga =
>> casperfpga.CasperFpga('10.42.0.69', port=7147). I remember that was
>> necessary at some point.
>> 2) Try the actual ADC and DAC tutorial fpg and python script first and
>> see if that programs
>> https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_adc_dac.
>> The script and fpg does work and I have tested that. If it doesn't work
>> then it could be an issue with your casperfpga version or setup on the card
>> - something like that.
>>
>> Let's take it from there.
>>
>> Kind regards,
>>
>> Adam Isaacson
>> South African Radio Astronomy Observatory (SARAO)
>> Hardware Manager
>> Cell: (+27) 825639602
>> Tel:  (+27) 215067300
>> email: aisaa

Re: [casper] (Red Pitaya 125-14) RuntimeError: no programming informs yet. Odd?

[Adam Isaacson]

Hi Lukas,

1) Did you install casperfpga using the following exactly (ReadMe.md
"installation" section): https://github.com/casper-astro/casperfpga?

2) What casperfpga version are you using? Type "casperfpga.__version__"
after you import casperfpga.

3) You are sure tcpborphserver is running? if it is not running then
casperfpga will not work. Refer to:
 
https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html
<https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html>
.

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, Feb 11, 2020 at 9:48 AM Lukas Karch  wrote:

> Thank you for the quick response. I tried specifiying the port number but
> the same error appeared. I tried using the .fpg and python script you
> suggested and a very similar error message appeared:
> *lukas@lukas-HP-Pavilion-x360-Convertible-15-br1xx:~/Downloads$ python
> tut_adc_dac.py 10.42.0.69 -p -b tut_adc_dac.fpg*
> *connecting to the Red Pitaya...*
> *done*
> *programming the Red Pitaya...*
> *2020-02-11 08:09:51.39 ERROR 10.42.0.69 transport_katcp.py:594 -
> 10.42.0.69 <http://10.42.0.69>: no programming informs yet. Odd?*
> *ERROR:10.42.0.69:10.42.0.69: no programming informs yet. Odd?*
> *Traceback (most recent call last):*
> *File "tut_adc_dac.py", line 38, in *
> *rp.upload_to_ram_and_program(opts.fpg)*
> *File
> "/usr/local/lib/python2.7/dist-packages/casperfpga-0.1.2-py2.7-linux-x86_64.egg/casperfpga/casperfpga.py",
> line 314, in upload_to_ram_and_program*
> *filename=filename, wait_complete=wait_complete)*
> *File
> "/usr/local/lib/python2.7/dist-packages/casperfpga-0.1.2-py2.7-linux-x86_64.egg/casperfpga/transport_katcp.py",
> line 596, in upload_to_ram_and_program*
> *'Odd?' % self.host)*
> *RuntimeError: 10.42.0.69 <http://10.42.0.69>: no programming informs yet.
> Odd?*
>
> Regarding the setup of the Red Pitaya, i mostly followed the instructions
> on this site:
> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html.
> Only "git clone https://github.com/ska-sa/katcp.git; did not work ( *fatal:
> unable to access 'https://github.com/ska-sa/katcp.git/
> <https://github.com/ska-sa/katcp.git/>': Could not resolve host: github.com
> <http://github.com>*), so I downloaded the github on my pc and used "scp
> -r" to copy it to my Red Pitaya.
> Regarding the casperfpga version, I followed the installation instructions
> on this site: https://github.com/casper-astro/casperfpga. At first I
> installed casperfpga using "sudo pip install casperfpga". Later I also
> tried "sudo python setup.py install" but it made no difference.
>
> Adam Isaacson  hat am 7. Februar 2020 um 16:26
> geschrieben:
>
> Hi Lukas,
>
> This problem seems familiar to me, but I can't quite remember the
> solution. These are possible suggestions to try:
>
> 1) Have you tried specifying the port number?  fpga =
> casperfpga.CasperFpga('10.42.0.69', port=7147). I remember that was
> necessary at some point.
> 2) Try the actual ADC and DAC tutorial fpg and python script first and see
> if that programs
> https://github.com/casper-astro/tutorials_devel/tree/master/red_pitaya/tut_adc_dac.
> The script and fpg does work and I have tested that. If it doesn't work
> then it could be an issue with your casperfpga version or setup on the card
> - something like that.
>
> Let's take it from there.
>
> 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, Feb 7, 2020 at 11:59 AM Lukas Karch < lu...@karch.info> wrote:
>
> Hi all,
> I am an electrical engineering student, trying to use casper with a Red
> Pitaya 125-14. I followed the instructions on:
> https://casper-toolflow.readthedocs.io to install the necessary software
> on Ubuntu 16.04 and the first Red Pitaya tutorial on
> https://casper-tutorials.readthedocs.io/en/latest/tutorials/redpitaya/tut_intro.html#programming-the-fpga.
> Currently I am trying to program the FPGA on my Red Pitaya board with a
> .fpg file I have compiled. Unfortunately I keep getting the following
> runtime error:
>
> In [1]: import casperfpga
> In [2]: fpga = casperfpga.CasperFpga('10.42.0.69')
> In [3]: fpga.upload_to_ram_and_program('lk_2020-02-05_1003.fpg')
> 2020-02-07 10:13:04.17 ERROR 10.42.0.69 transport_katcp.py:594 -
> 10.42