[casper] CASPERFPGA and the Great Merge

[Wesley New]

Good day all.

There are many forks of CASPERFPGA floating around the community and we are
embarking on an effort to merge them into the main repository, to create
one branch to rule them all.

If you have branches that you think should be included in this merge please
let me know and Ill add them to the list.

Thanks for all the continued development and collaboration.

Regards

Wesley New
SARAO

-- 
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/CAE2vkmXCF0ghORuMfU8JG%3DQC5rWBT4XhYomrbsEBUKeP6e9euw%40mail.gmail.com.

Re: [casper] Different Software Versions

[Wesley New]

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/casper/CAE2vkmW%3DEXV%3D5g0ygWUZk_%3D40yJUzXVL84zy3_n62X6kcUUvyg%40mail.gmail.com.

Re: [casper] Skarab programming error "Skarab has not come back after programming"

[Wesley New]

Hi June,

Over what ethernet interface are you connecting to the SKARAB? 1GbE or
40GbE. IIRC the boot firmware comes with both a 1gbe and 1 of the 40gbe
interfaces built in. The designs you mention would only have the 1 or more
40gbe ethernet interfaces included. You would see the symptoms you are
describing if you initially connect via 1gbe and then it is not included in
the uploaded design.

Hope this helps.

Regards

Wes



On Mon, Jan 10, 2022 at 11:35 PM June Tantiparimongkol 
wrote:

> Hi! Casperities,
>
> I'm writing to you guys for question on Skarab upload and programming
> error. Now, we're trying to program some fpg file into the platform but it
> fails. The error shows "*ERROR 192.168.3.2 transport_skarab.py:755 -
> Skarab has not come back after programming.*"
> So, I have try on generate new fpg files with tutorial design without
> editing (in https://github.com/casper-astro/tutorials_devel.git ) and
> upload and program. After, when we upload and programm new fpg file from
> tut_intro, tut_40gbe, tut_hmc, it shows the same errors too (as shown in
> figure). On the other hand, it has no problem when we worked on tutorial by
> using the example fpg files which are provided within tutorial_devel
> folder. Also, it has no problem with new-generate fpg file from
> skarab_adc_test and tut_spec which we have to generate due to mezzanine
> site configuration.
>
> But there're some condition for our work that we have to generate new fpg
> file with our computer which has Ubuntu 20 OS due to our Ubuntu 18 OS has
> not enough resource to run on execution flow.
>
> So, I wonder that what is the problems. Could anyone suggest us about this
> please.
>
> Thanks and sincerely,
> -- June
> National Astronomical Research Institute of Thailand (NARIT)
> [image: Skarab has not come back after programming.png]
>
> --
> 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/CABKTCqFRWfX9ujJmfyXYF_h%3D_izsQB9MXM6yUxifByasV2Kv9g%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/CAE2vkmWHYEK0fnA35LOnBsvKJzXixB4_cgNB%3DYUgJckUwcmwRg%40mail.gmail.com.

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

[Wesley New]

Hi Mutsuo,

There was a small team that added support for the first 2 red pitaya boards
to be used as cheap tutorial hardware for evaluation of the CASPER tools.
The nature of CASPER is one of open-source and collaboration.
Unfortunately many of us won't have the time to focus on making a port for
the latest Red Pitaya, but we would certainly be able to point you in the
right direction and assist with any questions you have with regards to
adding support for the latest Red Pitaya board.

AT first glance, it looks like the FPGA is just the Zynq 7020 SOC rather
than the 7010. This will mean that the STEMlab 125-14 will work for the
STEMlab 125-14-Z7020 with a simple change to the target fpga. As for adding
sata sync support, you would need to examine how that is implemented and
possibly create a yellow block or include it into the board support
package.

Hope this helps and points you in the right direction.

Regards

Wes

On Sat, Jul 31, 2021 at 12:15 PM IRspec Ogura  wrote:

> 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/CAE2vkmXwW5PyMO8e4YYFQCp4abua0bSTLSs7C3JP4t2UixRuAA%40mail.gmail.com.

Re: [casper] Compiling for roach2 on RHEL7

[Wesley New]

As someone who has tried plenty of combinations of Matlab, Xilinx and OS
versions over the years with varying success. I would recommend installing
a VM with the supported versions. If you are keen to maximize compile
resources try using lxc or chroot.

Good luck.

On Tue, 30 Jun 2020, 10:55 PM Jonathon Kocz,  wrote:

> Hi Michael,
>
> You might be able to get 2014b to play nicely with the toolflow, but 2013b
> was the last supported version for ISE 14.7, so it would be better to go
> with that if you can. What sort of OS errors are you getting?
>
> One alternative, if you can't get RHEL to work, might be to create a VM of
> e.g. ubuntu 16.04 or similar to spin up when you need to do ROACH2 work.
>
> Cheers,
> Jonathon
>
>
>
> On Tue, 30 Jun 2020 at 13:29, Michael D'Cruze <
> michael.dcr...@manchester.ac.uk> wrote:
>
>> Hi everyone,
>>
>>
>>
>> I’m clutching at straws a little, but I’ve recently obtained a RHEL7
>> system for use with the Vivado toolflow. What we’d really like is to be
>> able to compile models using the “old” ISE toolflow on this new machine. I
>> wondered if anyone had been able to make this happen? I’ve got RHEL 7.8,
>> various Matlab versions, and ISE 14.7.
>>
>>
>>
>> There appear to be some fairly fundamental compatibility issues between
>> the OS and Matlab versions prior to 2014b, though I’m going to ask our
>> local IT support to look at this. Versions at least 2016b and later throw a
>> tantrum when casper_xps is run. 2014b is the most promising at the moment,
>> getting a fair way through casper_xps before complaining about certain
>> Matlab files requiring absolute paths. An internet search doesn’t yield
>> anything promising.
>>
>>
>>
>> Anyway, if you’ve been able to make a combination similar to what I’ve
>> got work correctly, please get in touch.
>>
>>
>>
>> Thanks!
>> Michael
>>
>>
>>
>> --
>> 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/DB6PR0102MB263086FDADB5B0F733879740AC6F0%40DB6PR0102MB2630.eurprd01.prod.exchangelabs.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAPU71P-Jt8Ua8LGeaTp5SLM04aEhCk9-wDE1i8p%3DqJfoVb_ftA%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/CAE2vkmUtocNgRvZzEkrCgU2hvfPqg_NuyZfS4ry4Wrg0-xKeOw%40mail.gmail.com.

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

[Wesley New]

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()
>>>>> command. But how do I find out which physical register corresponds to 
>>>>> which
>>>>> simulink block? And I assume that even a minor update to the simulink
>>>>> design could result in the registers being moved around, so what is a good
>>>>> way to account for this?
>>>>>
>>>>> Currently, I am trying to trace what happens when I call casperfpga
>>>>> commands from my computer. I understand the parsing of the commands and 
>>>>> the
>>>>> hand off to tcpborphserver, but I can't seem to unravel what is happening
>>>>> when the red pitaya receives these commands. I'm assuming this code is
>>>>> somewhere in the katcp library (https://github.com/ska-sa/katcp)?
>>>>>
>>>>> Hopefully someone kn

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

[Wesley New]

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() command. But how
> do I find out which physical register corresponds to which simulink block?
> And I assume that even a minor update to the simulink design could result
> in the registers being moved around, so what is a good way to account for
> this?
>
> Currently, I am trying to trace what happens when I call casperfpga
> commands from my computer. I understand the parsing of the commands and the
> hand off to tcpborphserver, but I can't seem to unravel what is happening
> when the red pitaya receives these commands. I'm assuming this code is
> somewhere in the katcp library (https://github.com/ska-sa/katcp)?
>
> Hopefully someone knows of a good resource to fill in my knowledge gaps.
>
> 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/7fcb1398-42a3-45a0-8da5-1801f2274d71%40lists.berkeley.edu
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/7fcb1398-42a3-45a0-8da5-1801f2274d71%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/CAE2vkmVR1ky10b0D2TER-rgD3K-PRnA3mmzgPDi%3D3ASjai%3D_-A%40mail.gmail.com.

Re: [casper] Red Pitaya - what operating system

[Wesley New]

Hi David.

Please note that there are a few bugs with the red pitaya that we are
slowly sorting out.

Vereese is right we just take the pre-installed OS an run tcpborphserver on
it. This way you still get to use the built-it functionality of the RP and
leverage the casper tools simultaneously.

Regards



Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za




On Wed, Jan 15, 2020 at 9:42 AM David Mc Carthy 
wrote:

> Thanks.
> On 1/14/20 11:25 PM, Adam Isaacson wrote:
>
> Hi David,
>
> This will also help you setup your sd card on the red pitaya :
> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html#guide-to-setting-up-your-new-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 Wed, Jan 15, 2020 at 8:22 AM Vereese Van Tonder 
> wrote:
>
>> Hi David,
>>
>> You should build the TCPBorphServer code on the Red Pitaya as the code
>> uses pre-defined compiler macros in order to figure out which architecture
>> you're using.
>>
>> On Wed, Jan 15, 2020 at 8:06 AM Vereese Van Tonder 
>> wrote:
>>
>>> Hi David,
>>>
>>> The server is TCPBorphServer and you can find it in the tcpborphserver3
>>> directory in the katcp directory located here:
>>> https://github.com/ska-sa/katcp.git
>>>
>>> TCPBorphServer is the control software for the Red Pitaya. It is a KATCP
>>> server program that listens for KATCP messages on port 7147. The KATCP
>>> specification can be found here:
>>> https://katcp-python.readthedocs.io/en/latest/_downloads/361189acb383a294be20d6c10c257cb4/NRF-KAT7-6.0-IFCE-002-Rev5-1.pdf
>>>
>>> I hope that helps.
>>>
>>> On Wed, Jan 15, 2020 at 1:42 AM David Mc Carthy 
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I'm working with Prof. Lubin's group in UCSB, and we interested in
>>>> trying out the Capser toolflow for spectrometry applications. We are
>>>> experimenting at first on a Red Pitaya (125-14) to establish
>>>> feasibility, obviously actual science will be done with something
>>>> larger.
>>>>
>>>> My question is what operating system image do I need to run on the Red
>>>> Pitaya? Also the docs imply some sort of bridging server to the Pitaya,
>>>> what package is that?
>>>>
>>>> I have followed the tutorials to the point where I have a .fpg and a
>>>> .bof image. However the tutorials at this point go straight to using
>>>> capserfpga, with reference to the infrastructure already setup at your
>>>> workshops. I have not been able to find any information on what the
>>>> Zynq
>>>> operating system/server programs are either in the various websites
>>>> I've
>>>> found or from the mailing list archives.
>>>>
>>>> Thanks in Advance,
>>>>
>>>> David Mc Carthy
>>>>
>>>> --
>>>> 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/250868aa-1d77-5be9-6b70-19ecf7c75a27%40ucsb.edu
>>>> .
>>>>
>>>
>>>
>>> --
>>> Kind Regards,
>>> Vereesé
>>>
>>
>>
>> --
>> Kind Regards,
>> Vereesé
>> --
>> 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/CAJZFCF909tHLo%3Dhvikk4GTjPE4bt8gTaeuit4fqo95cc7J9Fhw%40mail.gmail.com
>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAJZFCF909tHLo%3Dhvikk4GTjPE4bt8gTaeuit4fqo95cc7J9Fhw%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 receivi

Re: [casper] Roach 2 FPGA

[Wesley New]

Please use the supported version as listed here in the
documentation otherwise it is really hard to support.

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

Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za




On Fri, Dec 13, 2019 at 4:46 AM luis javier Ulloa 
wrote:

> You could use matlab 2013b,  because is the only thath works with this
> Roach 2, in my experience!
> Regands
>
> El jue., 12 de diciembre de 2019 19:34, Jael Nora Rojas Miguel <
> jael.ro...@pucp.edu.pe> escribió:
>
>> Could I use Roach 2 with Ubuntu 18.4 and Matlab 18 ?  Thanks a lot for
>> your help.
>>
>> --
>> 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/9c3a508e-8d01-4670-a235-06752ae41520%40lists.berkeley.edu
>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/9c3a508e-8d01-4670-a235-06752ae41520%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/CALo%3DeSLfZXr_6rgD%3DXCK_CFi36GKAGsFc%3DLVJ7XZHM8Yf0-B2Q%40mail.gmail.com
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CALo%3DeSLfZXr_6rgD%3DXCK_CFi36GKAGsFc%3DLVJ7XZHM8Yf0-B2Q%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/CAE2vkmUBZAnxX9xNhSy7bqSU-nkdxRqLKqGjWPFkNM%2Bb93nYyQ%40mail.gmail.com.

Re: [casper] jasper not working properly after upgrade

[Wesley New]

Hi Nitish

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

Hope this helps.

Regards

Wesley

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

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

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

[casper] Re: BSP request from INAF

[Wesley New]

Hi Alex, I have CCed the mailing list so that this information will be out
in the wild.

Firstly, here is a link to the SKARAB page on the wiki. It has all the
resources that one would need for the SKARABs.
https://casper.ssl.berkeley.edu/wiki/SKARAB

To use the CASPER tools, the BSP would need to be upgraded. The latest
images can be found here. https://github.com/ska-sa/skarab_bsp_images Adam
will respond with how to upload the new BSP images.

There is are 2 test designs in mlib_devel for the SKARAB ADC at
https://github.com/ska-sa/mlib_devel/tree/devel/jasper_library/test_models.

The Linux control software is built into CASPERFPGA and is in the devel
branch of the SKA repository here:
https://github.com/ska-sa/casperfpga/tree/devel There should be a function
to initialise the ADC. Amish should be able to elaborate here. The toolflow
will generate the "full" hdl design that can be opened in Vivado and
perused at ones leisure.

Please let me know if there are any other questions.

Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za




On Thu, Mar 7, 2019 at 12:06 PM Alex Bassios  wrote:

> Hi Adam/Jason/Wesley
>
>
>
> Andrea Melis from INAF has bought a SKARAB and ADC.
>
>
>
> See below.
>
>
>
> It is probably best that Andrea Melis and INAF stay inside the CASPER tool
> flow.  Is there something SARAO can send them?  Maybe this should be done
> via the CASPER mail list?
>
>
>
> What can you suggest?
>
>
>
> Alex
>
> 021-7107442
>
>
>
> *From:* David Moschella Cyntony 
> *Sent:* Wednesday, 06 March 2019 7:25 PM
> *To:* Alex Bassios 
> *Cc:* Clifford van Dyk 
> *Subject:* BSP request from INAF
>
>
>
> Hello,
>
>
>
> As you saw last week, Andrea Melis completed the SKARAB ATP and has
> accepted the SKARAB.
>
>
>
> He requested today that we provide the BSP, hopefully with a full VHDL
> template.
>
> He also requested "any personality already compiled with its Linux control
> software (for example, SDR applications)”
>
>
>
> Best Regards,
>
>
>
> *David A Moschella* | *Founder and President*
>
> *Cyntony Corporation *|* Lexington, MA, USA* |* www.cyntony.com
> <http://www.cyntony.com/>  *
>
> M: 617-407-0753 | O: 781-430-0675 |  dmosche...@cyntony.com
>
>
>
> Cyntony boosts system integrators with customer attuned℠ provision of
> high-value antenna and electronics products
>
> *VLF thru X band  **| DF, CREW, SIGINT, COMM, HPC  | Mounted, Dismounted,
> Fixed, Portable*
>
>
>
>
>
>
>
>
>
>
>
> --
> Disclaimer: http://www.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 post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] Raspberry pi 3 b+ support for SNAP board

[Wesley New]

Hi Nivek,

I would take a read through this
https://raspberrypi.stackexchange.com/questions/19354/raspberry-pi-with-boots-up-with-rainbow-screen

Also confirm that you have a power supply that can deliver 2.5A at 5v.

I have not used that image before, but you can plug the card into your PC
and check if it mounts correctly and the boot partition is there.





Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Wed, Aug 29, 2018 at 12:21 PM, Nivek Ghazi 
wrote:

> Hey Casper people,
>
> So, I recently got a raspberry pi 3 b+ and looking to get it working
> with the SNAP board. I've download the image from the SNAP bringup
> tutorial and tried to get it to boot but it fails (the raspberry pi
> basically just outputs a rainbow pattern on the monitor with the red
> power led on and stays there). I'm guessing it fails because the image
> was not compiled to run on this new raspberry pi. Is it possible to get
> the raspberry pi 3 b+ working with the SNAP board?
>
> thanks,
>
> Nivek Ghazi
>
> --
> 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 post to this group, send email to casper@lists.berkeley.edu.
>

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

Re: [casper] Configuring 40GbE Yellow Block in JASPER

[Wesley New]

Thanks Clifford for clearing that up. Yes, the hardware does support a
static IP but this is not currently supported in the CASPER tools. We only
require DHCP support and hence have not taken the time to implement support
for static IPs. But if that is something that you require, you are welcome
to add the functionality and we will support you as best we can.

Regards

Wesley

Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Thu, Jul 6, 2017 at 2:27 PM, Clifford van Dyk <cliffordvan...@gmail.com>
wrote:

> Hi Mark (and Wes)
>
> For clarity (and at risk of poking my nose in where I shouldn't), I just
> wanted to point out that the Skarab HW platform itself is quite flexible:
>
> It is possible to set up Skarabs to communicate directly with each other
> over the 40 GbE links (we do this all the time in production testing of the
> platforms). The typical setup involves using the 1 GbE port as the primary
> platform management port (hooking this up to a network, typically with DHCP
> support), and assigning IP addresses, ARP entries etc to the 40 GbE ports
> through commands sent to the platform over this management interface.
> Alternatively, it is also possible to drop the 40 GbE firmware stack
> entirely and implement any serial standard over the 8 (4TX+4RX) SERDES
> lines, if point-to-point links were all that were required. The advantage
> of this is that a significant amount of FPGA resource could be saved by
> moving to a lightweight interface (but routing would be lost).
>
> However, since this is not the way SKA-SA is currently using the platform,
> your support/compatibility with SKA-SA toolflow probably won't be as
> "out-the-box" as it is when sticking with the mainstream SKA-SA
> toolflow/firmware implementations.
>
> Kind regards,
> Clifford
>
>
> On 7/6/2017 11:08 AM, Wesley New wrote:
>
> Hi Mark.
>
> The SKARABs currently only work with a DHCP server. So all bets are off
> while attempting to send/receive data without the interface receiving an
> IP, Netmask and Gateway. My guess would be that you are sending data, but I
> am not sure what IP/MAC it would be sent to or from. Because the ARP table
> wouldn't be set up correctly prior to a DHCP response being received and
> processed. I would recommend using the SKARABs on a network or connected
> directly to a server. I don't see much of a use-case for point-to-point
> connections either (How would you get the data off the SKARABs).
>
> Also be careful of the promiscuous mode. It allows all data received on
> the interface through to the fabric. It is only meant for debugging network
> problems, kind of a tcpdump for the SKARAB. You should be able to send and
> receive data between 2 SKARABs without setting promiscuous mode.
>
> If you would like I can pull up some test model files where we send and
> receive data between 2 networked SKARABs. With functionality to configure
> data rates and packet sizes etc.
>
> Regards
>
> Wes
>
>
> Wesley New
> South African SKA Project
> +2721 506 7300 <+27%2021%20506%207300>
> www.ska.ac.za
>
>
>
> On Wed, Jul 5, 2017 at 10:46 PM, Peryer, Mark A. <
> mark.per...@cfa.harvard.edu> wrote:
>
>> Hello,
>>
>> I have solved my issue of not being able to receive data. Instead of
>> directly connecting the SKARABs, I routed them through a 40 GbE switch
>> where the DHCP server can assign both of the SKARABs an IP address. I am
>> still not sure why directly connecting them does not work, however that
>> appears to be what was causing the issue all along.
>>
>> Thanks for your help,
>>
>> Mark
>>
>> On Wed, Jul 5, 2017 at 4:20 PM, Peryer, Mark A. <
>> mark.per...@cfa.harvard.edu> wrote:
>>
>>> Hello,
>>>
>>> I am still having issues receiving data over 40 GbE. I currently have a
>>> direct connection between the transmitting and receiving SKARABs, both on
>>> the leftmost 40 GbE port of Mezzanine slot 3 . Using tcpdump on a server
>>> with a 40GbE interface, I was able to confirm that the SKARAB which
>>> transmits data is successfully doing so. Also, both SKARABs can
>>> successfully be pinged over 40GbE. Despite this, I am still unable to
>>> receive data on the other SKARAB, even when Promiscuous Mode is enabled. I
>>> did observe that the orange and green LEDs are turned on for both of the
>>> SKARAB's 40GbE ports. The green light blinks on the SKARAB that is
>>> transmitting data and the orange light blinks on the SKARAB that is
>>> receiving data, therefore it appears they are communicating with each
>>> other.
>>>
>>> Any other sugges

Re: [casper] Configuring 40GbE Yellow Block in JASPER

[Wesley New]

Hi Mark.

The SKARABs currently only work with a DHCP server. So all bets are off
while attempting to send/receive data without the interface receiving an
IP, Netmask and Gateway. My guess would be that you are sending data, but I
am not sure what IP/MAC it would be sent to or from. Because the ARP table
wouldn't be set up correctly prior to a DHCP response being received and
processed. I would recommend using the SKARABs on a network or connected
directly to a server. I don't see much of a use-case for point-to-point
connections either (How would you get the data off the SKARABs).

Also be careful of the promiscuous mode. It allows all data received on the
interface through to the fabric. It is only meant for debugging network
problems, kind of a tcpdump for the SKARAB. You should be able to send and
receive data between 2 SKARABs without setting promiscuous mode.

If you would like I can pull up some test model files where we send and
receive data between 2 networked SKARABs. With functionality to configure
data rates and packet sizes etc.

Regards

Wes


Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Wed, Jul 5, 2017 at 10:46 PM, Peryer, Mark A. <
mark.per...@cfa.harvard.edu> wrote:

> Hello,
>
> I have solved my issue of not being able to receive data. Instead of
> directly connecting the SKARABs, I routed them through a 40 GbE switch
> where the DHCP server can assign both of the SKARABs an IP address. I am
> still not sure why directly connecting them does not work, however that
> appears to be what was causing the issue all along.
>
> Thanks for your help,
>
> Mark
>
> On Wed, Jul 5, 2017 at 4:20 PM, Peryer, Mark A. <
> mark.per...@cfa.harvard.edu> wrote:
>
>> Hello,
>>
>> I am still having issues receiving data over 40 GbE. I currently have a
>> direct connection between the transmitting and receiving SKARABs, both on
>> the leftmost 40 GbE port of Mezzanine slot 3 . Using tcpdump on a server
>> with a 40GbE interface, I was able to confirm that the SKARAB which
>> transmits data is successfully doing so. Also, both SKARABs can
>> successfully be pinged over 40GbE. Despite this, I am still unable to
>> receive data on the other SKARAB, even when Promiscuous Mode is enabled. I
>> did observe that the orange and green LEDs are turned on for both of the
>> SKARAB's 40GbE ports. The green light blinks on the SKARAB that is
>> transmitting data and the orange light blinks on the SKARAB that is
>> receiving data, therefore it appears they are communicating with each
>> other.
>>
>> Any other suggestions on how to debug the reception data over 40 GbE
>> would be much appreciated, as I am still unsure what could be causing the
>> issue.
>>
>> Thanks,
>>
>> Mark
>>
>> On Fri, Jun 30, 2017 at 3:57 AM, Paul Prozesky <paul.proze...@gmail.com>
>> wrote:
>>
>>> Morning Mark
>>>
>>> Please have a look here for SKARAB 40gbe TX and RX models with demo
>>> software.
>>>
>>> https://github.com/ska-sa/mkat_fpga/tree/devel/source/skarab_dev/tut2
>>>
>>> Cheers
>>> Paul
>>>
>>>
>>> On 30 June 2017 at 07:46, Jason Manley <jman...@ska.ac.za> wrote:
>>>
>>>> Hi Mark
>>>>
>>>> The current SKARAB 40G yellowblock is a bit of a hack.
>>>>
>>>>   1) It is currently not parameterised, and is hard-coded for the first
>>>> port on Mezzanine slot 3.
>>>>
>>>>   2) The tx_valid and rx_valid lines are 4-bits wide, not 1 bit. This
>>>> will be rectified soon, but in the meanwhile, just feed the value "3" to
>>>> tx_valid to send packets.
>>>>
>>>>   3) Note that there was a recent change to the TX and RX 64-bit word
>>>> ordering (was previously incorrectly swapped). Make you built your
>>>> bitstreams with a recent git checkout.
>>>>
>>>> It's on our todo list to get it properly parameterised and to fix the
>>>> 4-bit weirdness, but it's not clear when we'll have that done.  In the
>>>> meanwhile, the 40G does work, and we are successfully using this first port
>>>> actively at SKA-SA.
>>>>
>>>> Some things you should try to help debug:
>>>>
>>>>   1) The microblaze will attempt to DHCP on the 40G interface. Did it
>>>> obtain a lease? Check your DHCP server logs.
>>>>
>>>>   2) Check (using casperfpga software) that the cores are actually
>>>> configured like you think. There was a version of microblaze that overwrote
>>>

Re: [casper] Uploading Jasper .fpg Files to SKARAB

[Wesley New]

Hi Mark,

By changing branches you would have over written any changes to your
vivado_config.sh script. You will need to make those changes again. I just
point them to the Vivado and Matlab install directories (Not the
executables) and to where mlib_devel is cloned. Make these changes to lines
1,3 & 4 in the script.

Dont worry about *cp:* cannot stat ‘/opt/Vivado2016_2/Vivado/
2016.2/lib/lnx64.o:/opt/Vivado2016_2/Vivado/2016.2/lib/lnx64.o/libstdc++.so.6’:
No such file or directory
we all get this issue.

Your problem is that it cant find the Matlab executable at *cp:* cannot
stat ‘/usr/local/bin/glnxa64/MATLAB’: No such file or directory

Ill update the documentation accordingly.

Regards

Wes

Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Wed, Jun 21, 2017 at 7:24 PM, Peryer, Mark A. <
mark.per...@cfa.harvard.edu> wrote:

> Hi Wesley,
>
> When using the jasper_vivado_2016_2 branch I was able to successfully run
> and compile jasper designs using Vivado 2016.2 and Matlab 2016b. However,
> now when I use the master branch and run the 'startsg' script I receive the
> following errors:
>
> *mperyer@nirvana:~/Jasper/mlib_devel$* ./startsg
> *Using default configuration:* /home/mperyer/Jasper/mlib_
> devel/vivado_config.sh
> /opt/Matlab/R2016b/bin:/opt/Vivado2016_2/Vivado/2016.2/
> bin:/opt/Vivado2016_2/Vivado_HLS/2016.2/bin:/opt/
> Vivado2016_2/SDK/2016.2/bin:/opt/Vivado2016_2/SDK/2016.2/
> gnu/microblaze/lin/bin:/opt/Vivado2016_2/SDK/2016.2/gnu/
> arm/lin/bin:/opt/Vivado2016_2/SDK/2016.2/gnu/microblaze/
> linux_toolchain/lin64_be/bin:/opt/Vivado2016_2/SDK/2016.2/
> gnu/microblaze/linux_toolchain/lin64_le/bin:/opt/
> Vivado2016_2/SDK/2016.2/gnu/aarch32/lin/gcc-arm-linux-
> gnueabi/bin:/opt/Vivado2016_2/SDK/2016.2/gnu/aarch32/lin/
> gcc-arm-none-eabi/bin:/opt/Vivado2016_2/SDK/2016.2/gnu/
> aarch64/lin/aarch64-linux/bin:/opt/Vivado2016_2/SDK/2016.2/
> gnu/aarch64/lin/aarch64-none/bin:/opt/Vivado2016_2/SDK/
> 2016.2/gnu/armr5/lin/gcc-arm-none-eabi/bin:/opt/Vivado2016_
> 2/SDK/2016.2/tps/lnx64/cmake-3.3.2/bin:/opt/Vivado2016_2/
> Vivado/2016.2/bin:/opt/Vivado2016_2/Vivado_HLS/2016.
> 2/bin:/opt/Vivado2016_2/SDK/2016.2/bin:/opt/Vivado2016_2/
> SDK/2016.2/gnu/microblaze/lin/bin:/opt/Vivado2016_2/SDK/
> 2016.2/gnu/arm/lin/bin:/opt/Vivado2016_2/SDK/2016.2/gnu/
> microblaze/linux_toolchain/lin64_be/bin:/opt/Vivado2016_
> 2/SDK/2016.2/gnu/microblaze/linux_toolchain/lin64_le/bin:/
> opt/Vivado2016_2/SDK/2016.2/gnu/aarch32/lin/gcc-arm-linux-
> gnueabi/bin:/opt/Vivado2016_2/SDK/2016.2/gnu/aarch32/lin/
> gcc-arm-none-eabi/bin:/opt/Vivado2016_2/SDK/2016.2/gnu/
> aarch64/lin/aarch64-linux/bin:/opt/Vivado2016_2/SDK/2016.2/
> gnu/aarch64/lin/aarch64-none/bin:/opt/Vivado2016_2/SDK/
> 2016.2/gnu/armr5/lin/gcc-arm-none-eabi/bin:/opt/Vivado2016_
> 2/SDK/2016.2/tps/lnx64/cmake-3.3.2/bin:/opt/Vivado2016_2/
> Vivado/2016.2/bin:/opt/Vivado2016_2/Vivado_HLS/2016.
> 2/bin:/opt/Vivado2016_2/SDK/2016.2/bin:/opt/Vivado2016_2/
> SDK/2016.2/gnu/microblaze/lin/bin:/opt/Vivado2016_2/SDK/
> 2016.2/gnu/arm/lin/bin:/opt/Vivado2016_2/SDK/2016.2/gnu/
> microblaze/linux_toolchain/lin64_be/bin:/opt/Vivado2016_
> 2/SDK/2016.2/gnu/microblaze/linux_toolchain/lin64_le/bin:/
> opt/Vivado2016_2/SDK/2016.2/gnu/aarch32/lin/gcc-arm-linux-
> gnueabi/bin:/opt/Vivado2016_2/SDK/2016.2/gnu/aarch32/lin/
> gcc-arm-none-eabi/bin:/opt/Vivado2016_2/SDK/2016.2/gnu/
> aarch64/lin/aarch64-linux/bin:/opt/Vivado2016_2/SDK/2016.2/
> gnu/aarch64/lin/aarch64-none/bin:/opt/Vivado2016_2/SDK/
> 2016.2/gnu/armr5/lin/gcc-arm-none-eabi/bin:/opt/Vivado2016_
> 2/SDK/2016.2/tps/lnx64/cmake-3.3.2/bin:/opt/Vivado2016_2/
> Vivado/2016.2/bin:/opt/Vivado2016_2/Vivado_HLS/2016.
> 2/bin:/opt/Vivado2016_2/SDK/2016.2/bin:/opt/Vivado2016_2/
> SDK/2016.2/gnu/microblaze/lin/bin:/opt/Vivado2016_2/SDK/
> 2016.2/gnu/arm/lin/bin:/opt/Vivado2016_2/SDK/2016.2/gnu/
> microblaze/linux_toolchain/lin64_be/bin:/opt/Vivado2016_
> 2/SDK/2016.2/gnu/microblaze/linux_toolchain/lin64_le/bin:/
> opt/Vivado2016_2/SDK/2016.2/gnu/aarch32/lin/gcc-arm-linux-
> gnueabi/bin:/opt/Vivado2016_2/SDK/2016.2/gnu/aarch32/lin/
> gcc-arm-none-eabi/bin:/opt/Vivado2016_2/SDK/2016.2/gnu/
> aarch64/lin/aarch64-linux/bin:/opt/Vivado2016_2/SDK/2016.2/
> gnu/aarch64/lin/aarch64-none/bin:/opt/Vivado2016_2/SDK/
> 2016.2/gnu/armr5/lin/gcc-arm-none-eabi/bin:/opt/Vivado2016_
> 2/SDK/2016.2/tps/lnx64/cmake-3.3.2/bin:/usr/local/sbin:/
> usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
>
> *EXECUTING:* /opt/Vivado2016_2/Vivado/2016.2/bin/sysgen
>
> *cp:* cannot stat ‘/opt/Vivado2016_2/Vivado/2016.2/lib/lnx64.o:/opt/
> Vivado2016_2/Vivado/2016.2/lib/lnx64.o/libstdc++.so.6’: No such file or
> directory
>
> *cp:* cannot stat ‘/usr/local/bin/glnxa64/MATLAB’: No such file or
&

Re: [casper] Uploading Jasper .fpg Files to SKARAB

[Wesley New]

Hi Mark,

The jasper_vivado_2016_2 is an older branch that has now been merged into
Master. There are a lot of changes that have happened subsequent to that in
master. So please use Master to rebuild the fpg file and try to program
again.

Ill remove that old branch shortly.

Regards

Wes

Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Wed, Jun 21, 2017 at 3:46 PM, Peryer, Mark A. <
mark.per...@cfa.harvard.edu> wrote:

> Hello,
>
> I am currently trying to upload a .fpg file to a SKARAB created with the
> jasper_vivado_2016_2 branch (commit 6172a4b) of https://github.com/ska-sa/
> mlib_devel. Using the latest version of casperfpga (commit ec0c355) from
> the devel branch, https://github.com/ska-sa/casperfpga/tree/devel, I
> receive the following error.
>
>
> import casperfpga
> fpga = casperfpga.CasperFpga('skarab-02')
> fpga.is_connected()
> True
> fpga.upload_to_ram_and_program('/home/mark.peryer/
> realtimeaphids_6_20_2017-6-20_1515.fpg')
>
> ERROR:casperfpga.transport_skarab:An older version of mlib_devel
> generated /home/mark.peryer/realtimeaphids_6_20_2017-6-20_1515.fpg.
> Please update to include the md5sum on the bitstream in the .fpg header.
>
> Any help would be appreciated.
>
> Thanks,
>
> Mark Peryer
>
> --
> 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 post to this group, send email to casper@lists.berkeley.edu.
>

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

Re: [casper] Unable to Load Firmware Image onto SKARAB

[Wesley New]

Hi Mark,

Firstly, welcome to the CASPER community.

The SKARAB has multiple images stored in Flash. These are meant only used
for the initial FPGA image at start up and a fall back image. This is a
Xilinx standard method of configuration. You should be using the
upload_to_ram_and_program function. This function uploads the your compiled
fpg file to the SDRAM and then triggers the Virtex to program itself from
the SDRAM. You will probably have overwritten the boot images. :(

import casperfpga

SKARAB_IP = '10.99.45.170'
SKARAB_FPG = 'skarab.fpg'

# skarab programming
skarab = casperfpga.CasperFpga(SKARAB_IP)
skarab.upload_to_ram_and_program(SKARAB_FPG)

Does the board come back after waiting some time?




Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Wed, Jun 14, 2017 at 7:16 PM, Peryer, Mark A. <
mark.per...@cfa.harvard.edu> wrote:

> Hello,
>
> After trying to reconfigure the flash memory on the Virtex7 FPGA with a
> new image, I am no longer able to connect to the SKARAB through casperfpga
> using the 1GigE port. When I enter the command fpga =
> casperfpga.SkarabFpga('169.254.128.213'), the following is output.
>
> DEBUG:casperfpga.casperfpga:169.254.128.213: now a CasperFpga
> DEBUG:casperfpga.skarab_fpga:Retransmit attempts: 0
> DEBUG:casperfpga.skarab_fpga:Waiting for response.
> DEBUG:casperfpga.skarab_fpga:No packet received: will retransmit
> DEBUG:casperfpga.skarab_fpga:Retransmit attempts: 1
> DEBUG:casperfpga.skarab_fpga:Waiting for response.
> DEBUG:casperfpga.skarab_fpga:No packet received: will retransmit
> DEBUG:casperfpga.skarab_fpga:Retransmit attempts: 2
> DEBUG:casperfpga.skarab_fpga:Waiting for response.
> DEBUG:casperfpga.skarab_fpga:No packet received: will retransmit
> ERROR:casperfpga.skarab_fpga:Socket timeout. Response packet not received.
>
> My thinking is that the firmware image loaded into the flash is corrupt
> and now the 1GigE port is disabled. Are these any other possible ways to
> load a firmware image into flash without using the 1GigE port, such as the
> USB port or JTAG header? If so, what would be the required procedure to do
> so?
>
> Thanks,
>
> Mark Peryer
>
> --
> 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 post to this group, send email to casper@lists.berkeley.edu.
>

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

Re: [casper] DDR Size on Roach2 rev2

[Wesley New]

Hi Adam,

This probably wouldn't work off-the-bat. You would need to make changes to
the controller. If you need to read the data back via the PPC, then you
would need to expand this interface as last time I checked it only
supported 2GB of the DIMM.

Regards

Wesley

Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Tue, Apr 11, 2017 at 5:27 PM, Schoenwald, Adam J. (GSFC-5640) <
adam.schoenw...@nasa.gov> wrote:

> Hi All,
>
> Has anyone tried a 16GB DDR stick on the ROACH2?
>
> Thanks,
>
> --Adam
>
>
>
> 
>
> Adam Schoenwald - Electrical Engineer
>
> Code 564/Instrument Electronics Development Branch
>
> NASA Goddard Space Flight Center
>
> 
>
>
>
> --
> 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 post to this group, send email to casper@lists.berkeley.edu.
>

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

Re: [casper] Re: Can't open tut3

[Wesley New]

Hi Claudio,

2012b does not support the newer slx file format. Try using an older
version of the tutorials with an mdl file.

You can try the mdl files from this commit:
https://github.com/casper-astro/tutorials_devel/tree/c195b501f67c4f2a4f051f258453e0751f9825fa/tut3

Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Sat, Mar 25, 2017 at 4:49 PM, Claudio Rivera <claudio14riv...@gmail.com>
wrote:

> Hi everyone
> It would be great if you could help me with this problem...
> I just install matlab r2012a and xilinx 14.7 (design suite: system
> edition), the license of xilinx was "vivado design suite no ise", (in
> ubuntu 12.04, 64 bit), I download the mlib_devel_master from casper and
> create the startsg.local file with the following path
>
> #!/bin/bash
> export MATLAB_PATH=/usr/local/MATLAB/R2012a
> export XILINX_PATH=/opt/Xilinx/14.7/ISE_DS
> export XILINX_PLATFORM=lin64
> export MLIB_DEVEL_PATH=/home/roach/Casper/mlib_devel-master
>
>
>
>   Then, in matlab I start simulink, and when I try to open tut3.slx, it
> stays stuck.
> Any idea?
>
> 2017-03-25 11:41 GMT-03:00 Claudio Rivera <claudio14riv...@gmail.com>:
>
>> Hi everyone
>> It would be great if you could help me with this problem...
>> I just install matlab r2012a and xilinx 14.7 (design suite: system
>> edition), the license of xilinx was "vivado design suite no ise", (in
>> ubuntu 12.04, 64 bit), I download the mlib_devel_master from casper and
>> create the startsg.local file with the following path
>>
>> #!/bin/bash
>> export MATLAB_PATH=/usr/local/MATLAB/R2012a
>> export XILINX_PATH=/opt/Xilinx/14.7/ISE_DS
>> export XILINX_PLATFORM=lin64
>> export MLIB_DEVEL_PATH=/home/roach/Casper/mlib_devel-master
>>
>>
>>
>>   Then, in matlab I start simulink, and when I try to open tut3.slx, it
>> stays stuck.
>> Any idea?
>>
>
> --
> 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 post to this group, send email to casper@lists.berkeley.edu.
>

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

Re: [casper] ADC Question of Roach2

[Wesley New]

Hi Haystek,

Firstly, please send these emails to the CASPER mailing list, there are a
lot of helpful people there.

I assume that you are trying to get data from the FPGA to your PC for
post-processing. If you look at tut3.py
<https://raw.githubusercontent.com/casper-astro/tutorials_devel/master/tut3/tut3.py>
this
will show you how to plot your spectrum from the captured data. Everything
you need is in tut3.

You will need a simulink design with your ADC connected to a snap block to
store the data. Compile and upload this bof file to the ROACH. Then you
will need to run a script similar to tut3.py to control the design and to
read the snap block over the network, as well as plot your data.

Regards

Wes


Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Tue, Oct 18, 2016 at 8:22 AM, Heystek Grobler <heystekgrob...@gmail.com>
wrote:

> Hi Wes
>
> I Hope you are still well. I have one more question and then I will be
> sorted for my project. I want to hook up an FM Antenna to the ADC and see
> if I can plot the spectrum of FM signals. How to I get the data from the
> ADC in oder to plot? I assume I have to create a .bof file somehow?
>
> I got the 3rd tutorial of casper working, and understand it. The third
> tutorial uses an already compiled .bof file.
>
> Do you perhaps know how I can do this?
>
> Thanks for all your help.
>
> Heystek
>

Re: [casper] XST options

[Wesley New]

Hi Gunter,

Also take a look at xps_base/XPS_ROACH2_base/system.xmp

There is an option for ShiftReg. I have not played with it myself, but it
might be what you are looking for.

Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Thu, Jul 7, 2016 at 5:49 PM, David MacMahon <dav...@astro.berkeley.edu>
wrote:

> Hi, Gunter,
>
> I think you are looking for the resynth_netlist function found in
> mlib_devel as the file resynth_netlist.m. I think the comments make it
> rather self-explanatory, but please let me know (via the mailing list) if
> it's not quite what you're after.
>
> Cheers,
> Dave
>
> On Jul 7, 2016, at 08:38, Guenter Knittel <gknit...@mpifr-bonn.mpg.de>
> wrote:
>
> Hi,
>
>
>
> I’m new to this list, and I would be grateful if somebody could give me a
> hint.
>
> I’m trying to speed-optimize a completed and working SL design, and it
> appears
>
> as if an old topic is a main problem. This is the default XST option to
> merge
>
> a chain of FFs into a shift register.
>
> What I’m trying to accomplish is to run casper_xps with the right XST
> options
>
> from the start. What I have learned so far is that the XST options are
> written
>
> into the file system_xst.scr, which is re-generated before each run. The
> file
>
> fast_runtime.opt only applies to tools running after XST.
>
> Now I’m trying to figure out which tool is actually assembling this scr
> file, and
>
> where it gets the options from. In the hope that I can change the default
> behavior.
>
> Can somebody give me a pointer? Or is my approach fundamentally wrong?
>
>
>
> Thanks a lot
>
> Gunter
>
> from MPIfR Bonn
>
>
>
>

Re: [casper] ddr3 cpu interface for roach2

[Wesley New]

Hi Mike,

This one got me a while back. I think you need to change the style option
in your mpd file to hdl. See page 47 of this document.
http://www.xilinx.com/support/documentation/sw_manuals/edk10_psf_rm.pdf

Regards

Wesley


Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Wed, Jun 15, 2016 at 10:30 AM, Mike Movius <mi...@reutech.co.za> wrote:

>
> Hi all,
>
> I have recently implemented a cpu interface for the ddr3 on the roach2. I
> am cleaning up the pcore in preparation to supply it to ska-sa for
> commiting into their repository after they vet the design. I based the
> design on the dram pcore for roach one but re-implemented the arbiter. I no
> longer need the read_history_fifo.ngc that was previously used in the
> arbiter but I can’t delete it from the pcore \netlist directory without my
> compile failing. I know I need to do something with the \data\.bbd file. I
> tried deleting the file and also just using an empty file as there are no
> coregen .ngc files required but neither worked. I know I am missing
> something small. Any help appreciated. Thanks, MM.
>
>
> Please consider the environment before printing this e-mail
>
> View the Reutech Radar System online disclaimer at
> http://www.rrs.co.za/links/E-maildisclaimer.asp
>

Re: [casper] ddr3 cpu interface for roach2

[Wesley New]

Hi Mike,

I know that JP did some great work on the DDR3 controller on ROACH2 you can
find the pcores here:
https://github.com/ska-sa/mlib_devel/tree/master/xps_base/XPS_ROACH2_base/pcores

This works, but just doesn't have a CPU interface, which you might/might
not need. Although, I seem to remember Rurik and Laura adding a CPU
interface at some stage. I tried briefly to get it working on the SKA-SA
repository and hit some OPB address mapping issues. We didn't have much
time and didn't need it, so never got around to completing it. The one
option is to use the CPU interface from the ROACH1 pcores, you would just
have to change the bus widths and the memory mapping.

Hope this puts you on the right path.

Regards

Wesley

Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Thu, Apr 7, 2016 at 12:23 PM, Mike Movius <mi...@reutech.co.za> wrote:

>
> Hi All,
>
> Does anyone know if there has been progress made on a CPU interface for
> the DDR3 on the Roach2? I have seen mention of some effort by various
> parties in the mail archive and was wondering if there is a mlib_devel repo
> somewhere that I might use. Even a partial implementation would help as a
> starting point. Thanks, MM.
>
>
> Please consider the environment before printing this e-mail
>
> View the Reutech Radar System online disclaimer at
> http://www.rrs.co.za/links/E-maildisclaimer.asp
>

Re: [casper] Complier problem - tut 1

[Wesley New]

Hi Louise,

This is should actually be changed to a warning. It used to be there to
ensure that the versions of Matlab and Xilinx were compatible and they were
the versions that we supported. You should be able to ignore it and
continue with the setup you have.

You can change the script to not give this error for your version by
editing this file
<https://github.com/ska-sa/mlib_devel/blob/master/xps_library/casper_xps.m>and
between lines 56 and 80.

Regards

Wesley

Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Wed, Apr 6, 2016 at 1:07 PM, Louise Forbes <lou...@optinum.co.za> wrote:

> Hi All
>
>
>
> I’m new to the CASPER workflow so I was working through tut 1
> <https://casper.berkeley.edu/wiki/Introduction_to_Simulink_ROACH2>
> (Introduction to Simulink ROACH2) on the website and got all the way to
> Compiling when I received the error as shown. I’m using MATLAB R2013b and
> ISE 14.7 on a Windows 64-but machine. I know someone who uses ISE 14.7 with
> MATLAB R2012b and Linux and has recently successfully done this tut. Is
> this a MATLAB, OS, both or neither problem?
>
>
>
> Any help would be appreciated.
>
> Thanks
>
> Regards
>
>
>
> *Louise Forbes*
>
> Application Engineer
>
> [image: OPTI-NUM solutions]
>
> Tel:  +27 11 325 6238
>
> Fax: +27 11 325 6239
>
> http://www.optinum.co.za
>
>
>
> Training: MATLAB® Fundamentals (CPD Accredited)
> <http://www.optinum.co.za/services/training_courses.php#_MATLAB_Fundamentals> 
> –
> 12-14 April 2016  (other 2016 training courses)
> <http://www.optinum.co.za/services/training.php>
>
> Training: Simulink for System Algorithm and Modelling
> <http://www.optinum.co.za/services/training_courses.php#Simulink_for_System_and_Algorithm_Modelling>
> 11-12 May 2016
>
>
>
> For more information or to book your place, contact sa...@optinum.co.za
>
>
>

Re: [casper] CASPER installation problems CRM:0028623

[Wesley New]

Hi Louise,

Yes this is because of you are running it on windows. We haven't run the
tools on windows in probably 5 years, which makes it hard for us to
support. I would suspect that the Python code is pretty platform
independent but there is no guarantee. Maybe someone else has and they can
provide some insight.

/ISE/sysgen/bin/lin64'  is in your Xilinx install directory. Have a look
there for this folder. You will also have to add this environment variable.

I would suggest dual booting with Ubuntu 14.04, there is a wiki page on how
to setup the tools here
<https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.x_and_Matlab_2012b>
.

Also please cc the casper mailing list on any questions as they will be of
use to others in the community. casper@lists.berkeley.edu You will need to
subscribe before being able to send to the list.

Regards

Wesley

Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Wed, Apr 6, 2016 at 10:58 AM, Louise Forbes <lou...@optinum.co.za> wrote:

> Hi All
>
>
>
> So I’ve hit a slight snag already.
>
> I downloaded the mlib_devel from your Git repository but when I run the
> startup script (I’ve attached it for reference) the lines below fail:
>
>
>
> addpath([getenv('XILINX_PATH'), '/ISE/sysgen/bin/lin64']);
>
> Does this fail because you’re using Linux and I’m on Windows? If so you
> know the appropriate Windows folder to direct this to?
>
>
>
> xlAddSysgen([getenv('XILINX_PATH'), '/ISE'])
>
> I get the following error
>
> Error using xlAddSysgen (line 91)
>
> System Generator has been installed in a different location, please remove
> Sysgen from java class path and MATLAB path
>
> Any ideas here?
>
>
>
> Thanks in advance
>
> Regards
>
>
>
> *Louise Forbes*
>
> Application Engineer
>
> [image: OPTI-NUM solutions]
>
> Tel:  +27 11 325 6238
>
> Fax: +27 11 325 6239
>
> http://www.optinum.co.za
>
>
>
> Training: MATLAB® Fundamentals (CPD Accredited)
> <http://www.optinum.co.za/services/training_courses.php#_MATLAB_Fundamentals> 
> –
> 12-14 April 2016  (other 2016 training courses)
> <http://www.optinum.co.za/services/training.php>
>
> Training: Simulink for System Algorithm and Modelling
> <http://www.optinum.co.za/services/training_courses.php#Simulink_for_System_and_Algorithm_Modelling>
> 11-12 May 2016
>
>
>
> For more information or to book your place, contact sa...@optinum.co.za
>
>
>

Re: [casper] Sysgen compilation error

[Wesley New]

This is an issue with dash in ubuntu, if you change your shell from dash to
bash it interprets the perl scripts properly.

Have you followed these steps when setting up your tools flow?
https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.x_and_Matlab_2012b

Particularly this step:

The syntax in the Xilinx Perl scripts is not supported under the Ubuntu
default shell Dash. Change the symbolic link sh -> dash to sh -> bash:

   - cd /bin/
   - sudo rm sh
   - sudo ln -s bash sh


Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Thu, Feb 11, 2016 at 12:58 PM, James Smith <jsm...@ska.ac.za> wrote:

> Haven't encountered that specific issue before but I see a capital letter
> in your path. That may be an issue.
> On 11 Feb 2016 12:44, "Mugundhan vijayaraghavan" <
> v.vaishnav151...@gmail.com> wrote:
>
>> Hello guys,
>>
>> I'm running matlab/xilinx and mssge tools on a ubuntu 14.04 system. When
>> I do casper_xps and start compiling, I get this strange error.
>>
>> standard exception: XNetlistEngine:
>> Exception message could not be parsed:
>> com.xilinx.sysgen.netlist.NetlistInternal: couldn't open first pass text
>> file at
>> /home/mugundhan/casper_designs/tut1/sysgen/sysgen/masterScript3888976111602024584.pl
>> line 559'
>>
>>
>> Reported by:
>> Unspecified
>>
>> Has anyone got this before ?
>>
>> Is there any workaround ?
>>
>>
>> --
>> the giver of moksha
>>
>

Re: [casper] Multicast on 10 gbe on ROACH-2?

[Wesley New]

Marc is correct. The ARP table is not involved in multicast. The multicast
MAC is just mapped from the multicast IP.

Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Thu, Nov 5, 2015 at 12:51 PM, Marc Welz <m...@ska.ac.za> wrote:

> David MacMhaon wrote:
>
> >> I think multicast transmit is easy (just populate the ARP table
> >> appropriately).  I think multicast receive is also supported with recent
> >> versions of the 10GbE yellow block.  You could probably check the
> >> mlib_devel git commit logs for the yellow block code to find clues.
>
> Not sure if the arp table is involved in this - the destination mac is
> (should be)
> generated algorithmically from the destination multicast IP address, though
> the above might be a unusual workaround.
>
> Sending is reasonably straighforward, as there is no control traffic
> involved.
> Reception does require a newer romfs/tcpborphserver where we get the kernel
> to issue IGMP requests on the 10Gbe interfaces, so that the traffic arrives
> at the particular port.
>
> regards
>
> marc
>
>

Re: [casper] Roach2 aux clocking and Bram's

[Wesley New]

The problem here is that the FVCO is not within the range of 600MHz to
1600MHz. This is an MMCM configuration issue as Dave has already mentioned.

I have recently fixed a similar bug in the SKA-SA mlib_devel repository. Is
this the repository that you are using?

I have tested the aux clock on this repository between 100MHz and 200MHz.

Thanks

Wes


Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Tue, Aug 4, 2015 at 11:41 PM, David MacMahon dav...@astro.berkeley.edu
wrote:

 Hi, Vereese,

 That's a very curious failure mode!  It's very interesting that everything
 worked fine when clocking via iADC, but not when clocking via your
 mezzanine board (or aux_clk) even though the fabric clock rate was the
 same.  I can think of two possible theories for what's going on (both
 alluded to in your email).

 The first theory is that the problem is somehow related to the address
 mapping.  Maybe under certain circumstances the memory map works out such
 that bram7 is accessed via an extra opb_to_opb bridge (or some other slight
 variation) compared to the other brams?  It would be interesting to compare
 the system.mhs and core_info.tab files for your various test builds so
 what's different between working builds and non-working builds.  What if
 you add additional unrelated BRAMs such that they appear earlier in the
 address map (maybe give them a lexicographically early name like
 aaa_bram0) or maybe enlarge the existing BRAMs?  That might push bram6
 (and others?) into the hypothetically troublesome address range.  Maybe
 clocking from the iADC changed the address map such that this hypothesized
 problem was avoided.

 The other theory is that some sort of MMCM (mis-)configuration is causing
 the MMCM to behave in a weird way.  I don't know what kind of problem that
 would be.  I've only seen issues when trying to use the ISERDES resources
 at fairly high bit rates, but the ~155 MHz clock should be fine.  I think
 the MMCM config options are shown in the system_map.mrp file, so maybe
 comparing working vs non-working versions of those files would be
 illuminating.

 When you tried to run aux_clk at faster than 143 MHz, what values did you
 use for MULTIPLY and DIVIDE?  It looks like the defaults would result in
 the same settings as the hardcoded values (with the exception of CLKOUT5)
 .  I think the MULTIPLY and DIVIDE parameters are intended to be used for
 sys_clk, so I'm not sure how they get set (or passed on) for aux_clk.

 Hope this helps,
 Dave

 On Aug 4, 2015, at 12:13 PM, Vereese Van Tonder wrote:

  Hi Everyone,
 
  I'm clocking a ROACH2 design from a mezzanine board at 155.52MHz. In the
 design I have 8 bram's each with a 16 bit address width and data width. I'm
 writing the bram's address counter value into the bram, (so at the first
 address write 0, at the second address write 1, ... at the last address
 write 2^16-1). The output bram's 0-6 shows the expected linear relationship
 however bram7 does the following (also see attached .png's):
 
  Address 0-16387: expected linear relationship with gradient = 1
  Address 16388 - 20476 (diff=4088): the output toggles between the
 expected behavior and the following set
 (4,12,20,...,252,4,12,20,...,252,..4,12,,252)
  Address 20477 - 36867: expected linear relationship with gradient = 1
  Address 36868 - 40956 (diff=4088): the output toggles between the
 expected behavior and the following set
 (4,12,20,...,252,4,12,20,...,252,..4,12,,252)
 
  The design works in simulation and when I clock the same design from the
 on board 100MHz system clock I don't get the problem anymore. I also saw
 that when I include only 7 brams and occupy the memory space
 102-0103 for bram0 . 0108-0109 for bram6 then I don't
 get the error but when I do include the 8th bram which occupies the space
 010E-010F then I get the error. I'm unsure whether this is a memory
 problem or a clocking speed error. I also clocked the design off an iadc
 running at 4*155.52=622.08 MHz and then the design worked.
 
  Then I tried compiling a design that clocks from the aux_clk input and
 the design fails because the FVCO is out of range, I found the input limit
 to be 143MHz. From an earlier post I saw that Dave said the limit is
 between 100MHz-200MHz as there are some hard-coded parameters in the MMCM
 of the roach_infrastructure_v1_00_a pcore. I modified the MMCM_BASE_aux_clk
 instantiation to take the parameter values instead of having the hard coded
 values as follows:
 
  .CLKFBOUT_MULT_F  (6), - .CLKFBOUT_MULT_F  (MULTIPLY)
  .CLKOUT1_DIVIDE (6), - .CLKOUT1_DIVIDE (DIVIDE), //THIS IS THE
 DIVISOR
  .CLKOUT2_DIVIDE (6), - .CLKOUT2_DIVIDE (DIVIDE),
  .CLKOUT3_DIVIDE (6), - .CLKOUT3_DIVIDE (DIVIDE),
  .CLKOUT4_DIVIDE (6), - .CLKOUT4_DIVIDE (DIVIDE),
  .CLKOUT5_DIVIDE (6), - .CLKOUT5_DIVIDE (DIVIDE/2),
  .CLKOUT6_DIVIDE (6), - .CLKOUT6_DIVIDE (MULTIPLY/DIVCLK

Re: [casper] constraints for qdr2/ROACH2

[Wesley New]

Hi Homin,

Both Jack and myself have worked on this and Jack seems to have found a fix
to get the QDRs working at any frequency!

Read this thread for more details about the issues we had
https://www.mail-archive.com/casper@lists.berkeley.edu/msg05924.html

This is an issue from when the board was designed and has caused us endless
trouble with the QDR controller. I constrained the first registers on the
FGPA to be the closest register to the physical pin so that we wouldnt have
the added problem with routing delays in the FPGA. This can be seen in the
system.ucf in the ska-sa/mlib_devel repository.

Regards

Wesley


Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Thu, May 28, 2015 at 3:13 AM, Homin Jiang ho...@asiaa.sinica.edu.tw
wrote:

 Dear All:

 Recently i found out the locations I/O pins for qdr2/ROACH2 are not in the
 same FPGA area.(from the Planahead/device map). Some of them are in the
 left edge of the device, and some of them are in the middle of the device.
 Is there someone experienced this problem and have constraints in hand to
 share with ?

 regards
 homin jiang

Re: [casper] QDR ROACH2: clocking at 145 MHz

[Wesley New]

Hey Guys,

Just to give you a bit of history on this issue. Normally the QDRs have
take a clock input and then return this clock aligned with the data out.
The QDRs on ROACH 2 were routed without this clock and with out th data
valid line to save pins on the FPGA. This would have been ok if the QDR
data and address lines werent routed to a wide range of FPGA banks, making
it hard to align up the data upon return to the FPGA. This is why we need
to calibrate and do all this trickery to get it working.

We have gotten it to work for the range of frequencies that we most
commonly use, between 200 and 240ish. Jack has pushed this up to around
300MHz, but the problem is that the large change in frequencies means that
the delay changes by more then a full cycle and thus calibration fails.
(Calibration is only shifting in 1/32 parts of the 200MHz clock period)

Jack has made a number of changes. One being that shifting the clock by 180
degrees so that the calibration range shifted by half a clock cycle and
this helped with getting it to calibrate at 300+MHz. I would assume you
would need to do the same but in the opposite direction.

Wes

Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Mon, May 25, 2015 at 8:04 AM, Juan-Pierre Jansen van Rensburg 
jvrensburg...@gmail.com wrote:

 Hi Jack

 I'm using the latest mlib_devel on the ska-sa git repo (commit 0d5c582),
 and I built against it, but with the changes of commit 72d879c.

 JP

 On Sat, May 23, 2015 at 2:20 AM, Jack Hickish jackhick...@gmail.com
 wrote:

 Hi JP,

 What mlib_devel are you using? Did you actually build against commit
 72d879c? I noticed you emailed a link to my repository which I specifically
 tweaked for my higher (312MHz) work, which I'm sure breaks *everything* at
 145.

 Cheers,
 Jack

 On Fri, 22 May 2015 at 06:41 Juan-Pierre Jansen van Rensburg 
 jvrensburg...@gmail.com wrote:

 Hi all,

 I'm trying to get the QDR on the ROACH-2 to work reliably at a clock
 speed of a 145 MHz. I'm assuming this is possible, since it has been
 pointed out in an earlier message
 http://www.mail-archive.com/casper%40lists.berkeley.edu/msg05736.html
 that the QDR should work above 120 MHz?

 I'm running the software calibration for the QDR (qdr_cal() in the
 qdr.py script) and the calibration seems to be successful, however after
 the calibration I write test patterns to the QDR but the data I read back
 is incorrect. What is  strange is that it doesn't do it for all the test
 patterns, mainly for the walking 0's and pseudo random numbers, and QDR0
 and QDR1 seem to be the main culprits for failure. I also don't have any
 QDR glitches at higher clock speeds (for instance at 200 MHz).

 I have been digging around and found this
 https://github.com/jack-h/mlib_devel/commits/ami-devel?page=8
 possible solution (see commit 72d879c). The REFCLK for the IDELATCTRL is
 set to a 100 MHz instead of the recommended 200 MHz. I have tried this, but
 I still get errors. I'm not sure if this is relevant but with this
 suggestion I have only found errors so far on QDR1?

 Does anyone have any suggestions?

 Thanks,
 JP van Rensburg

Re: [casper] ROACH-2 MSSGE 14.2 toolflow compilation takes too long time.

[Wesley New]

I would also suggest upgrading to 14.7, it is a pretty straight forward
upgrade. Just install 14.7 and point your startsg script to the correct
installation directory.



Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Fri, Apr 10, 2015 at 7:06 AM, Chaudhari Sandeep C. 
s...@gmrt.ncra.tifr.res.in wrote:

 Hi John,

 Thanks for your suggestion. I need to change my machine itself as
 it has only 8GB RAM and later on I realized that it is DDR2 and not even
 DDR3 RAM.


 Regards,
 Sandeep C. Chaudhari



 On Wed, 8 Apr 2015, John Ford wrote:

  Hi Glenn,

 Thanks for your reply.

 My machine has 8GB RAM and maximum java heap size shown in MATLAB
 was 2GB. Hence I tried to increase java heap size to MAX 2GB and compiled
 my old ROACH-1 design (mdl file later updated using
 'update_casper_blocks') which consists of iADC and snap block and found
 that it is taking 1:02hrs. But in default condition of 128MB took 53:00
 minutes.

 This is bit surprising.


 Since you're using more memory for the Matlab Java heap, you might be
 running out of physical memory and have begun paging to virtual memory.  8
 GB is marginal for these newer tools, unfortunatly.  Have you looked at
 the system activity with vmstat while compiling?

 John



 Regards,
 Sandeep C. Chaudhari
 GMRT-TIFR


 On Tue, 7 Apr 2015, G Jones wrote:


 Check your java heap size setting in MATLAB. The default value is often
 way
 too low. Search the mailing list archive for more details.

 On Apr 7, 2015 2:02 AM, Chaudhari Sandeep C.
 s...@gmrt.ncra.tifr.res.in
 wrote:
   Dear All,

   I started using ROACH-2 toolflow recently. When I tried
   to compile simple ROACH-1 design of iADC board with snap block
   it took 45-minuts to compile this design. Now when I started to
   compile ROACH-1 f-engine design on previous day and it is still
   in the stage of System Generation today.
   Can anyone tell why it is taking so much long time for
   compilation and how to reduce this compilation time?

   The installation details are as follows :

   
 -
   MATLAB Version: 8.0.0.783 (R2012b)
   MATLAB License Number: 732809
   Operating System: Linux 3.13.0-46-generic #79-Ubuntu SMP Tue Mar
   10 20:06:50 UTC 2015 x86_64
   Java Version: Java 1.6.0_17-b04 with Sun Microsystems Inc. Java
   HotSpot(TM) 64-Bit Server VM mixed mode
   
 -
   MATLABVersion
   8.0 (R2012b)
   Simulink  Version
   8.0 (R2012b)
   DSP System ToolboxVersion
   8.3 (R2012b)
   Fixed-Point Toolbox   Version
   3.6 (R2012b)
   Signal Processing Toolbox Version
   6.18 (R2012b)
   Xilinx System Generator   Version
   14.2 production build



   Thanks  regards,
   Sandeep C. Chaudhari
   GMRT,TIFR

Re: [casper] ROACH2 MKID Block and DDR3 DRAM

[Wesley New]

Hi Johnathan.

I can point you in the right direction for the first issue you are having.
It seems that no one has used that ADC on a ROACH2 before so you will need
to migrate the core to support Virtex 6. This is probably just a
replacement of the DCM with and MMCM, but there may be other issues.

You will need to edit this file:

https://github.com/casper-astro/mlib_devel/blob/master/xps_base/XPS_ROACH2_base/pcores/adc_mkid_interface_v1_00_a/hdl/vhdl/adc_mkid_interface.vhd

The DCM is at the end of the file.

You can see how the MMCM has been setup in the MKADC here:

https://github.com/casper-astro/mlib_devel/blob/master/xps_base/XPS_ROACH2_base/pcores/mkadc_interface_v1_00_a/hdl/vhdl/adc5g_dmux1_interface.vhd

For more info on the MMCM see the Xilinx Clocking Resource users guide.

Regards

Wesley


Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za



On Fri, Mar 6, 2015 at 2:54 AM, Gard, Johnathon D. johnathon.g...@nist.gov
wrote:

   Hello Everyone,

 I have a series of questions concerning the ROACH2 system and tool flow.

 OS = Ubuntu 14.04.2 LTS

 Tool flow = ISE 14.7, MATLAB R2012b, mlib-devel-master (casper-astro git
 clone)

 Hardware = MUSIC ADC/DAC board and MUSIC IF_Board from Techne Instruments
 (Rich Raffanti)





 First thing, syncing the FPGA clock to the ADC/DAC clock. Using the mkid
 adc or dac blocks from the xps library and selecting any one of the
 adc0_clk, adc1_clk, dac0_clk, or dac1_clk settings in the xsg_core_config
 results in errors in the compilation. There are usually one of two errors
 the come up “Cannot retarget DCM to MMCM” because of VCO frequencies being
 out of range or an input period of 0.00ns for the DCM. Looking at the
 Xilinx forums, they generally do not recommend letting the toolflow upgrade
 the DCM to a MMCM. There are a lot of complications that arise from this. I
 was wondering if anyone has a block set were they have already fixed this
 problem and have been able to use an external clock from the ZDOK
 connectors.



 I, at one point, found an email on the CASPER archive about this same
 problem and downloaded the attached block set. However this did not work
 either. I really wish I could find this email again.



 Another question I had was about the DDR3 DRAM.



 http://www.mail-archive.com/casper%40lists.berkeley.edu/msg04323.html



 I was if anyone has tried to change the IDELAYCTRL frequency so that the
 RAM can run at a higher clock speed. This work may be able to be tied into
 the PPC interface work or error free work from the following email.



 http://www.mail-archive.com/casper%40lists.berkeley.edu/msg05670.html



 I would be more than happy to try and help with this. I have an interest
 in the PPC interface but error free operation is more critical.



 Johnathon Gard

 National Institute of Standards and Technology

 Quantum Sensors Project​

Re: [casper] Error with mmcm

[Wesley New]

Hi Nishanth,

Clearly your multiply and divide parameters are not what you expect them to
be. The VCO frequency, needs to be between 600MHz and 1200MHz. VCO freq
equals input freq * Multiply Parameter. Make sure that it falls within the
correct range.

If you are changing the CASPER tools then you will need to have a look as
the scripts that calculate and set the Multiply and Divide parameters on
the VCO.

Regards

Wes


Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za



On Thu, Feb 12, 2015 at 8:41 PM, Nishanth Shivashankaran nshiv...@asu.edu
wrote:

 Hi All,

 I am trying to create a yellow block for the roach2 with the MUSIC
 adc/dac, I replaced the DCM with the MMCM.  I compiled the DAC and ADC
 portion separately. The DAC portion seems to work without any errors and I
 was able to put out tones and i visually saw it on the spectrum analyzer
 but the ADC portion is giving me some compilation error with the same clock
 frequency. I am using the same set of multipliers and dividers as the DAC.
 the error message says the ngdbuild is changing multipliers and dividers. I
 am wondering if anyone can help me with this problem.

 ERROR:LIT:667 - Block 'MMCM_ADV symbol

 physical_group_tut3_r2_adcdac_512_adc_mkid/tut3_r2_adcdac_512_adc_mkid/dcm_c
lk/tut3_r2_adcdac_512_adc_mkid/tut3_r2_adcdac_512_adc_mkid/MMCM_adc'
 has its
target frequency, FVCO, out of range. Valid FVCO range for speed grade
 -1
is 600MHz - 1200MHz. The computed FCVO is a function of the input
 frequency
CLKIN1_PERIOD, the division factor DIVCLK_DIVIDE, and the
 CLKFBOUT_MULT_F
attribute (FVCO = 1000*CLKFBOUT_MULT_F/(CLKIN1_PERIOD*DIVCLK_DIVIDE)).
 The
CLKIN_PERIOD attribute may have been set by ngdbuild based on the user
specified PERIOD constraint. The current calculated FVCO is 512.032770
 MHz.
Reference the V6 architecture Users Guide or search the Xilinx Answer
 Records
database for the error code.
 Errors found during logical drc.

 thanks
 Nishanth Shivashankaran

Re: [casper] Content Addressable Memory

[Wesley New]

Hi Kris,

Can you elaborate on your question?

Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za



On Wed, Feb 4, 2015 at 4:57 PM, Kristian Zarb Adami kris...@gmail.com
wrote:

 Hello all,

 has anyone implemented/know of an implementation of CAM inside the Casper
 consortium?

 regards,
 Kris

Re: [casper] software register

[Wesley New]

Can you elaborate on these errors?

A while ago the software registers were updated so you might have to
replace all of the software registers in you your design with the new on
from the library.

Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za



On Fri, Nov 7, 2014 at 3:55 AM, Homin Jiang ho...@asiaa.sinica.edu.tw
wrote:

 Hello:

 I am upgrading my system to xilinx 14.7 with Matlab 2012a and up to date
 mlib_devel library.
 I encountered errors by the software register in XPS library. Any one
 can help ?

 thanks
 homin

Re: [casper] License troubles

[Wesley New]

Try this:

source /opt/xilinx/14.3/ISE_DS/settings64.sh

then run the Xilinx Licence Config Manager

xlcm

From here you can choose your license file.


Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za



On Thu, Sep 11, 2014 at 6:01 PM, Andrea Giachero 
andrea.giach...@mib.infn.it wrote:

 Hi all,
 I'm very newcomer to the CASPER development environment, so I have started
 with the Roach2 rev.2 board trying to follow the Tutorial 1.

 I'm using Scientific Linux 6.2 (Carbon)/ Matlab 2012a / Xilinx ISE Design
 Suite 14.3 and I have some troubles when I start the compilation via
 casper_xps.

 The license error returned by the System Generator is reported below. Both
 ISE and Matlab show not license problems if used separately.

 I've also tried to export the XILINXD_LICENSE_FILE env (export
 XILINXD_LICENSE_FILE=.Xilinx/Xilinx.lic) but the problem remains.


 Could anyone have any suggestion?

 Thank you in advance for your help,

 Best, ag.



 ERROR: A license checkout has failed for System Generator for DSP (SysGen).

 Please launch Xilinx License Configuration Manager (xlcm) program to make
 sure that a valid license exists and it can be found by the program.
 In order to set XILINXD_LICENSE_FILE environment variable correctly do the
 following.
 1. Close the design and exit MATLAB.
 2. Set environment variable, XILINXD_LICENSE_FILE, to point to the valid
 license file or the license server.
 3. Relaunch MATLAB and start System Generator process.


 --- A message from the license manager --
 INFO:Security:71 - If a license for part 'xc6vsx475t' is available, it
 will be possible to use 'SysGen_TDP' instead of 'SysGen'.
 INFO:Security:61 - The XILINXD_LICENSE_FILE environment variable is not
 set.
 INFO:Security:63 - The LM_LICENSE_FILE environment variable is not set.
 INFO:Security:68 - For more information or for assistance in obtaining
 a license, please run the Xilinx License Configuration Manager
 (xlcm or Manage Xilinx Licenses.)
 INFO:Security:68a - user is roach2, on host freddo1.mib.infn.it.
 WARNING:Security:9b - No 'SysGen' feature version 2012.10 was available
 for part 'xc6vsx475t'.
 ERROR:Security:12 - No 'xc6vsx475t' feature version 2012.10 was available
 (-15),
 so 'SysGen_TDP' may not be used.

 -
 Cannot connect to license server system.
 The license server manager (lmgrd) has not been started yet,
 the wrong port@host or license file is being used, or the
 port or hostname in the license file has been changed.
 Feature: SysGen
 Server name: Freddo1
 License path:
 /home/freddo/roach2/.Xilinx/Xilinx.lic:/opt/Xilinx/14.3/ISE_DS/ISE/data/*.lic:/opt/Xilinx/14.3/ISE_DS/ISE/coregen/core_licenses/Xilinx.lic:/opt/Xilinx/14.3/ISE_DS/ISE/coregen/core_licenses/XilinxFree.lic:/opt/Xilinx/14.3/ISE_DS/EDK/data/core_licenses/Xilinx.lic:
 FLEXnet Licensing error:-15,570. System Error: 115 Operation now in
 progress
 For further information, refer to the FLEXnet Licensing documentation,
 available at www.flexerasoftware.com.Cannot connect to license server
 system.
 The license server manager (lmgrd) has not been started yet,
 the wrong port@host or license file is being used, or the
 port or hostname in the license file has been changed.
 Feature: xc6vsx475t
 Server name: Freddo1
 License path:
 /home/freddo/roach2/.Xilinx/Xilinx.lic:/opt/Xilinx/14.3/ISE_DS/ISE/data/*.lic:/opt/Xilinx/14.3/ISE_DS/ISE/coregen/core_licenses/Xilinx.lic:/opt/Xilinx/14.3/ISE_DS/ISE/coregen/core_licenses/XilinxFree.lic:/opt/Xilinx/14.3/ISE_DS/EDK/data/core_licenses/Xilinx.lic:
 FLEXnet Licensing error:-15,570. System Error: 115 Operation now in
 progress
 For further information, refer to the FLEXnet Licensing documentation,
 available at www.flexerasoftware.com.

 --
 
 Andrea Giachero, Postdoctoral Researcher
 University and INFN of Milano Bicocca
 Physics Department G. Occhialini
 Piazza della Scienza 3, I-20126, Milano - Italy
 andrea.giach...@mib.infn.it
 andrea.giach...@lngs.infn.it
 andrea.giach...@cern.ch
 tel: +39 02 6448 2456
 tel: +39 0862 437 724 (LNGS)
 web: giachero.mib.infn.it
  bit.ly/139sqHE
 

Re: [casper] License troubles

[Wesley New]

You should go to the 2nd tab Manage Licenses and the click on the Load
license button. This will tell you if the license is up to date and what
features it supports.

Hope this helps.

Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za



On Fri, Sep 12, 2014 at 2:26 PM, Andrea Giachero 
andrea.giach...@mib.infn.it wrote:

 Thanks Wesley for your answer.

 I've followed your instruction:

 - I've sourced the file;
 - I've launched xlcm;
 - Within xlcm I've tried to import the file Xilinx.lic using the button
 Copy License (maybe is it not the proper way to import the License?)

 The problem remains.

 I apologize, It' s the first time I'm working with the ISE environment, so
 I'm sure there is something stupid step I'm omitting.

 Best,

 ag.



 Try this:
 source /opt/xilinx/14.3/ISE_DS/settings64.sh
 then run the Xilinx Licence Config Manager
 xlcm
 From here you can choose your license file.

 Wesley New
 South African SKA Project
 +2721 506 7365
 www.ska.ac.za

Re: [casper] QDR vs DDR3 for new board

[Wesley New]

Aspw
On 21 Aug 2014 23:19, Matt Strader mstra...@physics.ucsb.edu wrote:

 Hi Casperites,

 We (UCSB and Fermilab) are currently designing a new DAC/ADC board
(12bits x 2.0 Gsps ADC, 14bits x 2.5 Gsps DAC) to interface with the ROACH2
for readout of future, larger MKID instruments.  The DAC/ADC board will
have it's own FPGA and it's own memory.

 We're currently deciding between adding QDRII+ SRAMs or DDR3 SDRAM chips
to the board.  My very limited experience with QDR and DDR2 on
ROACH1 suggests QDR is simpler to work with (because of the constant
latency), but it would take up many more pins on the FPGA for the width of
the data they provide.  Does anyone have other ideas of why to choose one
over the other?  If you were to design a board from scratch, which would
you choose?

 Thanks,
 Matt Strader
 UCSB Physics oDeptford a ad

Re: [casper] about Roach2 tutorials

[Wesley New]

Hi Wang,

The tutorials were initially designed for ROACH1 but it is pretty simple to
get them running on ROACH2. Just change the target board to ROACH2 in the
xps_config block and select the correct ROACH2 the GPIOs (If you are using
them) and then compile. Should be pretty seamless.

Regards

Wes

Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za




On Sun, Aug 17, 2014 at 7:25 AM, Wang Jinqing jqw...@shao.ac.cn wrote:

 Hi,

 I have started the Roach2 board with very simple counters .It seems goes
 well. Now I want to use the
 Tutorial 3: Wideband Spectrometer and Tutorial 4: Wideband Pocket
 Correlator. Based these two examples I  want to develop the project I
 want.But I found the tutorials are all for Roach1 board, how can it run
 smoothly on Roach2 ? Do you have tutorials that is suitable for Roach2. Best
 regards. Oliver Wang


  -原始邮件-
  发件人: casper-requ...@lists.berkeley.edu
  发送时间: 2014年8月15日 星期五
  收件人: casper@lists.berkeley.edu
  抄送:
  主题: casper Digest, Vol 81, Issue 9
 
  Send casper mailing list submissions to
   casper@lists.berkeley.edu
 
  To subscribe or unsubscribe via the World Wide Web, visit
 
 https://calmail.berkeley.edu/manage/list/listinfo/casper@lists.berkeley.edu
 
  or, via email, send a message with subject or body 'help' to
   casper-requ...@lists.berkeley.edu
 
  You can reach the person managing the list at
   casper-ow...@lists.berkeley.edu
 
  When replying, please edit your Subject line so it is more specific
  than Re: Contents of casper digest...
 
 
  Today's Topics:
 
 1. T1E problem is back (Rich Lacasse)
 
 
  --
 
  Message: 1
  Date: Thu, 14 Aug 2014 09:54:25 -0400
  From: Rich Lacasse rlaca...@nrao.edu
  Subject: [casper] T1E problem is back
  To: Alejandro Saez as...@nrao.edu, casper list
   casper@lists.berkeley.edu
  Message-ID: 53ecbf91.9010...@nrao.edu
  Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 
  Hi Alejandro,
 
  I installed the new ASUMMID personality you sent.  It produces a 1
  every 16 msec when enabled.  Looks good!
 
  I started doing timing tests but now have run into the situation where
  T1E fails, i.e., I cannot talk with the PIC FPGA.  I don't know if this
  is a result of the change I made in cleaning out unneeded code, or just
  a random occurrence.  I have power cycled the ROACH successfully but now
  it's in a bad mood.  I guess I had better put off my timing tests and
  see if I can figure out what going wrong with communications.  This may
  take a while... :(.
 
  Rich
 
 
 
  End of casper Digest, Vol 81, Issue 9
  *

Re: [casper] Send data to more than one IP address / tap_multicast function

[Wesley New]

Hi Pablo,

Multicast is only supported on ROACH2 and you will need to make sure that
your power pc is running the latest firmware.

Wes

Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za




On Mon, Jun 30, 2014 at 10:22 PM, Pablo Vasquez pvasq...@das.uchile.cl
wrote:

 Hi All,

 I'm trying to send a simple spectrometer data stream from the ROACH to
 more than one IP address.

 I've installed the corr-master library from GitHub which has a function
 called tap_multicast_add_send function in katcp_wrapper.py

 I'm trying to use it but I get an error message back from the ROACH, here
 I copy the prompt info:


 Connecting to server 172.17.89.179 on port 7147...  ok

 
 Trying multicast to PIC
 FAILURE DETECTED. Log entries:
 172.17.89.179: Starting thread Thread-1
 172.17.89.179: #version poco-0.1
 172.17.89.179: #build-state poco-0.2804
 172.17.89.179: Joining the multicast groups 0.0.0.69 - 0.0.0.70.
 172.17.89.179: ?tap-multicast-add PIC send 0.0.0.69+0

 172.17.89.179: !tap-multicast-add invalid unknown\_command
 172.17.89.179: received reply %r
 172.17.89.179: Request tap-multicast-add failed.
   Request: ?tap-multicast-add PIC send 0.0.0.69+0
   Reply: !tap-multicast-add invalid unknown\_command.
 None
 Traceback (most recent call last):
   File spectrometer_64bits_float_s12_dif_ed_sin_acc_data_upper_low3.py,
 line 297, in module
 exit_fail()
   File spectrometer_64bits_float_s12_dif_ed_sin_acc_data_upper_low3.py,
 line 160, in module
 fpga.tap_multicast_add_send('PIC', 69, n_addresses=1)
   File /usr/local/lib/python2.7/dist-packages/corr/katcp_wrapper.py,
 line 346, in tap_multicast_add_send
 reply, informs = self._request(tap-multicast-add, self._timeout,
 tap_dev, 'send', str(ip_str_first) + '+' + str(n_addresses-1))
   File /usr/local/lib/python2.7/dist-packages/corr/katcp_wrapper.py,
 line 196, in _request
 % (request.name, request, reply))
 RuntimeError: Request tap-multicast-add failed.
   Request: ?tap-multicast-add PIC send 0.0.0.69+0
   Reply: !tap-multicast-add invalid unknown\_command.


 Am I using the command correctly or I have some sort of library problem?

 Is there another way to get the info sent to another IP?

 Best Regards

 --
 Pablo Vasquez
 Ingeniero Eléctrico
 DAS Universidad de Chile
 (+562)29771119

Re: [casper] Error while compiling the mixer Casper DSP block

[Wesley New]

Are all the boxes ticked in your casper_xps window?

Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za




On Thu, May 29, 2014 at 7:29 AM, John Ford jf...@nrao.edu wrote:


 This can happen if your model is named using upper and lower case letters.
  What's your model name?

 John

  Hi everybody.
 
  I'm trying to use the Mixer DSP green block on my design using Roach
  virtex
  5 FPGA ubuntu 12.04 and xilinx 14.5.
 
  while compiling i get the following error:
 
 
 
  XSG generation complete.
  #
  ## Copying base system ##
  #
  Copying base package from:
   /opt/mlib_devel/xps_base/XPS_ROACH_base
  
  ## Copying custom IPs ##
  
  ##
  ## Creating Simulink IP ##
  ##
  Error using gen_xps_create_pcore (line 41)
  Cannot find any compiled XSG netlist. Have you run the Xilinx System
  Generator on your design ?
 
 
 
 
 
  I set the parameters in the block like this:
 
  Frequency Divisions(M)=8
  Mixing Frequency (?/M*2pi)=8
  number of parallel streams=8
  bit width=8
  Bram Latency=2
  Mult Latency=4
 
  Has anybody an idea of whats wrong here?
 
  I would appreciate any help.
 
  Thanks
 
 
  --
  *Edgardo Huaracán Durán*
 

Re: [casper] ISE 14.7 in ubuntu 12.04

[Wesley New]

chmod +x xsetup
On 13 May 2014 06:00, Rolando Paz flx...@gmail.com wrote:

 Sorry Jack, the problem is attached :-)

 It is a permissions problem :-)

 what should I do?


 Rolando Paz


 2014-05-12 21:41 GMT-06:00 Jack Hickish jackhick...@gmail.com:

 when you say it doesn't do anything...?

 It errors out? hangs? closes immediately? something else?

 On 12 May 2014 20:02, Rolando Paz flx...@gmail.com wrote:
  Hey Jack
 
  My problem is that I can not install ISE 14.7 on Ubuntu 12.04.
 
  When I run the command: ./xsetup does not do anything ...
 
  Do you have any idea about how to install ISE 14.7 on Linux?
 
  Best Regards
 
  Rolando Paz
 
 
 
  2014-05-12 20:55 GMT-06:00 Jack Hickish jackhick...@gmail.com:
 
  Hey Rolando,
 
  Have you followed these instructions:
 
 
 https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.x_and_Matlab_2012b
  ?
 
  Jack
 
  On 12 May 2014 18:55, Rolando Paz flx...@gmail.com wrote:
 
  Hi everyone.
 
  Someone managed to install ISE 14.7 in ubuntu 12.04?
 
  Best Regards
 
  Rolando Paz
 
 

Re: [casper] 10GB Ethernet

[Wesley New]

Here are links to the 2 cores that we use.

https://github.com/ska-sa/mlib_devel/tree/master/xps_base/XPS_ROACH2_base/pcores/kat_ten_gb_eth_v1_00_a

https://github.com/ska-sa/mlib_devel/tree/master/xps_base/XPS_ROACH2_base/pcores/ten_gb_eth_v3_00_a

Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za




On Mon, Feb 10, 2014 at 5:14 PM, Jason Manley jman...@ska.ac.za wrote:

 We were using Xilinx's free XAUI core for the PHY layer at one time... I'm
 not sure if that's still the case though because there was an effort to
 write our own at one time. It's been a while since I dug that deep into the
 toolflow.

 Jason

 On 10 Feb 2014, at 17:12, Madden, Timothy J. tmad...@aps.anl.gov wrote:

  Implementing a 10GB core is no easy task, considering you must sync.
 many serial transceivers together. Cool. Good job.
 
  Tim
 
  
  From: Jason Manley [jman...@ska.ac.za]
  Sent: Monday, February 10, 2014 9:09 AM
  To: Madden, Timothy J.
  Cc: Casper Lists
  Subject: Re: [casper] 10GB Ethernet
 
  We have implemented our own 10GbE core. It's free open-source!
 
  Jason
 
  On 10 Feb 2014, at 16:50, Madden, Timothy J. tmad...@aps.anl.gov
 wrote:
 
  Folks
 
  How does the 10GB Ethernet work on the Roach boards? In most Xilinx
 applications, the 10GB ethernet is generated by Xilinx IP blocks that have
 an expensive license, on the order of $22k.
 
  I have heard nothing about licensing fees for the 10GB Roach yellow
 block. Any ideas on this?
 
  Tim Madden
  Argonne Lab
 
 

Re: [casper] Aurora Yellow Block

[Wesley New]

Hi Norbert

Maybe share your gen_mhs.py file so that we can see the code that you are
trying to run.

Wes

Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za




On Thu, Feb 6, 2014 at 5:57 PM, Norbert Bonnici 
norbert.bonnici...@um.edu.mt wrote:

 Dear CASPERites,

 I'm currently building a yellow block for the Aurora core on the ROACH II.
 I've finished the pcore and currently in the final stages of writing the
 MATLAB OOP code.

 I've tried compiling at the current stage and hit this error:

 Reference to non-existent field 'board'.
 Error using gen_xps_mod_ucf (line 90)
 Error found during IP UCF generation in MHS

 Do you have any tips?

 Thanks in advance!

 Best regards,
 Norbert

Re: [casper] CASPER ISE 14.5 tool chain configuration problem

[Wesley New]

Thanks Nie,

Ill add this to the
https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14_and_Matlab_2012bpage

What OS are you using?

Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za




On Tue, Jan 14, 2014 at 4:57 AM, Nie Jun nie...@xao.ac.cn wrote:

  Hi guys,

 I encountered some problems while updating our development tool chain to
 14.5.

 1. I couldn't use FFT blocks, it would give out lots of errors like
 Initialization commands cannot be evaluated.

 2. The simulink displayed No blocks instead of the CASPER DSP blockset
 blocks.

 I searched in the mailing list and found one useful 
 posthttp://www.mail-archive.com/casper@lists.berkeley.edu/msg02970.htmlfrom 
 Mark Wagner. Finally I solved these two problems by giving all users
 the write privilege on the CASPER library directories.

 Just post in the mailing list in case of someone running into the same
 problems. Thanks!

 Cheers,
 Jun

Re: [casper] chipScope on the roach2

[Wesley New]

Hi David yes the ftdi chip hogs the bus. Ill send you a script to release
the jtag when I get into the office.

Regards

Wes
On 20 Nov 2013 21:53, DAVID SAROFF (RIT Student) dps7...@rit.edu wrote:

 Does anyone have experience using chipScope with Platform Cable USB II on
 roach2? I know it is not necessary given all the CASPER superstructure, but
 does anything on the roach2 prevent it?

 --
 David P. Saroff
 Rochester Institute of Technology
 54 Lomb Memorial Dr, Rochester, NY 14623
 david.sar...@mail.rit.edu | (585) 201-6862

Re: [casper] chipScope on the roach2

[Wesley New]

You can run this script
https://github.com/ska-sa/roach2_support_software/blob/master/ftdi/scripts/release_jtag_port.py

You will need python and the ftdi libraries.

Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za




On Thu, Nov 21, 2013 at 7:49 AM, Wesley New wes...@ska.ac.za wrote:

 Hi David yes the ftdi chip hogs the bus. Ill send you a script to release
 the jtag when I get into the office.

 Regards

 Wes
 On 20 Nov 2013 21:53, DAVID SAROFF (RIT Student) dps7...@rit.edu
 wrote:

 Does anyone have experience using chipScope with Platform Cable USB II on
 roach2? I know it is not necessary given all the CASPER superstructure, but
 does anything on the roach2 prevent it?

 --
 David P. Saroff
 Rochester Institute of Technology
 54 Lomb Memorial Dr, Rochester, NY 14623
 david.sar...@mail.rit.edu | (585) 201-6862

Re: [casper] Error Xilinx Block / ISE 10.1

[Wesley New]

Hi Rolando,

What repository are you using? Assuming that you are targeting an ibob,
mlib_devel has a tag for last support of the ibob and bee2. Are you using
this?

Wes

Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za




On Thu, Oct 24, 2013 at 7:41 PM, Rolando Paz flx...@gmail.com wrote:

 Hi all.

 I achieved install a virtual machine windows XP SP3, on a machine with
 ubuntu 13.04.

 I install Matlab R2007b
 ISE, EDK, SG 10.1, with respective updates.

 By double clicking on any block of Xilinx, a get the following error.

 Can anyone help?

 Best Regards

 Rolando Paz

Re: [casper] Random failures on Compile

[Wesley New]

Hi Guys

I have never experienced this. Can you provide the versions of the tool and
OS you are running?

Wes
On 22 Oct 2013 20:51, Ryan Monroe ryan.m.mon...@gmail.com wrote:

 I've also experienced these.  The most common cause seems to be a constant
 which is not sampled.  I don't have a good rule, but sometimes when I
 start removing components on my design, it starts working, which shows me
 the element at fault.  In general, placing a component which is known to
 work on its own into a larger system does not cause problems.

 Then there's also the times where I reduce the entire system to something
 trivial like a counter and it still happens.  In that case I save copies of
 everything and reboot.  Followed by  anger management.
 On Oct 22, 2013 11:44 AM, Ross Williamson rwilliam...@astro.caltech.edu
 wrote:

 I'm in a rather frustrating situation where the casper tools will only
 compile in a seemingly random nature.  I can load up a design that I
 know compiles into simulink and run it and I will get an error like
 the following:

 Error reported by S-function 'sysgen' in
 'ccat_corr_lowbits/ADC0/Constant6':
 An internal error occurred in the Xilinx Blockset Library.

 There is nothing obviously wrong with the constant (and the whole .slx
 has compiled as is before)

 Shutting down and starting up matlab sometimes fixes the issue -
 trying to compiled a different .slx and then going back to the one
 that doesn't work sometimes fixes it (Sometimes does not) -  I can
 screw around a whole day trying to get it to compile and the next day
 it works fine.

 Has anyone experienced this (pseudo) random compile problems and know
 of a good sequence to make a model compile again?

 Ross


 --
 Ross Williamson
 Research Scientist - Sub-mm Group
 California Institute of Technology
 626-395-2647 (office)
 312-504-3051 (Cell)

Re: [casper] Report of experience with KatADC

[Wesley New]

Hi All, I used 14.5 for a while and the only issue that I had was that
registers in one of my designs kept getting disconnected from the rest of
the design each time I opened up the model file. All other designs were
fine. This forced me back to 14.3. Although I do plan to test out 14.6 soon.

Wes

Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za




On Tue, Oct 1, 2013 at 2:02 PM, Jack Hickish jackhick...@gmail.com wrote:

 Hi all,

 We were using 14.3 at the JBO workshop a few weeks ago -- partly because
 of cautionary tales I heard about 14.4, and partly because of license
 expiry date constraints (i.e. 14.3 was the latest version the spare Oxford
 licenses supported).

 Cheers,
 Jack

 On 1 Oct 2013 12:56, Jason Manley jman...@ska.ac.za wrote:

 Might be 14.5 works fine. I haven't tried it personally and I believe
 there were issues with 14.4. Andrew and Paul are also on 14.3.

 Jack, what were we using at the recent workshop?

 Jason

 On 01 Oct 2013, at 13:47 , Nimish Sane wrote:

  Really? Why does the Wiki page mention 14.5?
 https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.5_and_Matlab_2012b
 
  Can someone please clarify?
 
  Thanks a lot,
 
  Nimish
 
 
  On Tue, Oct 1, 2013 at 4:25 AM, Jason Manley jman...@ska.ac.za wrote:
   ...instead of 13.x, we are going for the latest 14.5.
 
  We're currently on 14.3 at SKA-SA for all our ROACH-2 work. I haven't
 tried 14.5 but I think Wesley tried 14.4 and ran into some issues...???
 
  Jason
 
 

Re: [casper] casper libraries- casper_xps in new mlib_devel?

[Wesley New]

So bee_xps has been changed to casper_xps and the casper mlib_devel will
reflect that when we update it for this years tutorials for the the CASPER
workshop.

If you are using the old libraries, just run bee_xps otherwise use run
casper_xps

Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za




On Mon, Aug 19, 2013 at 6:09 PM, John Ford jf...@nrao.edu wrote:

  Hi John
 
 
  Thanks for the tip. I got the newest libraries.
 
  Question: Is casper_xps no longer casper_xps? Seems to not be defined.
  What is the command to bring up the xilinx compiler window.
 

 Hmm.  that works for me.  Have you tried bee_xps instead?

 John

  Thanks
  Tim
 
 
  - Original Message -
  From: John Ford jf...@nrao.edu
  To: Timothy Madden tmad...@aps.anl.gov
  Cc: casper@lists.berkeley.edu
  Sent: Friday, August 16, 2013 4:40:37 PM
  Subject: Re: [casper] casper libraries
 
  Folks
 
  It seems that the libraries listed on
  https://casper.berkeley.edu/wiki/Repositories
 
  are all at least 2 years old.
 
  Is there REALLY no development on Casper libraries for 2 years?
 
  Where does one get something more recent?
 
  Tim Madden
 
 
  It's all been moved to github.  There are other forks as well.  I'm not
  sure of all of them, but these 2 will get you started.  :)
 
  https://github.com/casper-astro
 
  https://github.com/ska-sa
 

Re: [casper] Setting up CASPER tools on a Windows machine

[Wesley New]

Hi Joe,

That error should actually be a warning. It doesnt stop you from compiling
designs. There is something else not right with your setup.

Have a look at the startsg script in the root of the mlib_devel directory
and check that you are setting all those environment variables correctly.

Regards

Wes
On 19 Aug 2013 21:50, Kujawski, Joseph jkujaw...@siena.edu wrote:

 Does anyone have a setup guide for getting the CASPER tools running in a
 Windows environment?

 My configuration is as follows:

 1) Windows 7, 64bit
 2) Matlab 2013a
 3) Xilinx ISE version 14.6

 I followed the instructions at
 https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.5_and_Matlab_2012b
  as
 best I could for the Windows platform, but have not gotten to the point
 that I can see the CASPER blocks in my Simulink library.

 Running casper_xps in Matlab produces the error 'Unsupported Xilinx System
 Generator version 14.5.4652'


 --
 **
 * Joe Kujawski
 * Siena College
 * Dept. of Physics and Astronomy, RB 113
 * 515 Loudon Road
 * Loudonville, NY 12211-1462
 *
 * Email: jkujaw...@siena.edu
 * Phone: 518-782-6885
 * Fax: 518-783-2986
 **

Re: [casper] casper libraries

[Wesley New]

Thanks Timothy, I have updated that wiki page.

Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za




On Fri, Aug 16, 2013 at 11:40 PM, John Ford jf...@nrao.edu wrote:

  Folks
 
  It seems that the libraries listed on
  https://casper.berkeley.edu/wiki/Repositories
 
  are all at least 2 years old.
 
  Is there REALLY no development on Casper libraries for 2 years?
 
  Where does one get something more recent?
 
  Tim Madden
 

 It's all been moved to github.  There are other forks as well.  I'm not
 sure of all of them, but these 2 will get you started.  :)

 https://github.com/casper-astro

 https://github.com/ska-sa

Re: [casper] DRAM (DDR3) ROACH-2

[Wesley New]

Hi David,

Sounds very interesting. Thanks for the info. No one is using a soft core
cpu as there is already the PPC on the ROACH boards. The DDR and QDR have
interfaces to the PPC over the epb/opb bus. This runs at 66MHz and is not
idea to use as part of your data pipeline as it is generally to slow. The
best way is to packetize the data and sent it over either 10Gig or 1Gig
ethernet to a server for storage or further software/GPU processing.

Hope this helps.

Regards

Wesley

Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za




On Wed, Jul 24, 2013 at 7:35 PM, David Saroff dsar...@nrao.edu wrote:

 Wesley,

 Yes, I am interested in both the QDRSRAM and the DDR3RAM on the roach2.

 My current project is an FX correlator for 38 small antennae at the prime
 focus of the Green Bank Telescope, for 21cm HI work. With limited
 bandwidth  MHz an FX correlator -might- fit in one v6. I need a lot of
 memory for accumulators, and if the v6 can't keep up with the data flow,
 for buffering out the results at partial duty cycle.

 Are people instantiating the soft microprocessor to get at those memories,
 or is there some state machine implementation that could be wired into the
 data flow more directly?

 David



  Comments below.
 
 
  On Wed, Jul 24, 2013 at 12:07 PM, Matthew Bridges 
  matthewbridge...@gmail.com wrote:
 
  Hi JP and Wes,
 
  I am very interested in this work, but from a RHINO perspective. I am
  looking into how I should go about adding the RHINOs DRAM into my
  Architecture.
 
  I have a few questions, if you have time to answer.
 
  Did you use the Memory Interface Generator? And did it work for you?
 
  Yes, use the MIG. Both R1 and now R2 yellow blocks are based around MIG
 
  Are there other coregens used in your block? E.g FIFOs?
 
  Yes, the outputted data goes though an asynchronous fifo.
 
  How many ports did you implement? I was thinking of putting 2 into my
  Architecture, 1 for the Wishbone, 1 for direct processor access.
 
  What interface do you use to talk to the block? Is it OPB?
 
  Both the QDR and DDR use a single port which maps the memory address
  space to OPB bus so that the memory can be read from the PPC.
 
 
  Thanks,
 
  Matthew
 
 
  On Wed, Jul 24, 2013 at 11:48 AM, Wesley New wes...@ska.ac.za wrote:
 
  This is great work JP.
 
  Out of interest is anyone else planning to use the DDR3 on ROACH2?
 
  Wesley New
  South African SKA Project
  +2721 506 7365
  www.ska.ac.za
 
 
 
 
  On Wed, Jul 24, 2013 at 8:24 AM, Juan-Pierre Jansen van Rensburg 
  jvrensburg...@gmail.com wrote:
 
  Hi all
 
  I have been working on a yellow block for the DDR3 of the ROACH-2. As
  far as I know this yellow block does not yet exist?
 
 
  The same DRAM yellow block is used and interfacing the memory remains
  the same (as for the ROACH-1). The DRAM also uses an asynchronous fifo
  to
  allow long write bursts. I have tested the memory (thoroughly) using
  standard memory test patterns, and the memory passes reliably (I have
  yet
  to see a failure).
 
  I have not yet implemented a CPU interface to the DDR3, but this will
  hopefully be done soon. I have a couple more things that I would like
  to
  check/test, and if this is done I'll ask one of the SKA-SA guys to
  push
  this onto their CASPER mlib git repo.
 
  I thought this is information worth sharing so that multiple people
  don't end up working on the same thing... Hopefully this is not
  already the
  case!
 
  Thanks,
  JP van Rensburg
 
 
 
 
 
 
 
  --
  Software Defined Radio Group
  Department of Electrical Engineering
  University of Cape Town
  Private Bag X3, Rondebosch 7701
  Tell: +27 (0)21 650 4659
  Mob: +27 (0)84 413 2642
 
 
 

Re: [casper] DRAM (DDR3) ROACH-2

[Wesley New]

This is great work JP.

Out of interest is anyone else planning to use the DDR3 on ROACH2?

Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za




On Wed, Jul 24, 2013 at 8:24 AM, Juan-Pierre Jansen van Rensburg 
jvrensburg...@gmail.com wrote:

 Hi all

 I have been working on a yellow block for the DDR3 of the ROACH-2. As far
 as I know this yellow block does not yet exist?


 The same DRAM yellow block is used and interfacing the memory remains the
 same (as for the ROACH-1). The DRAM also uses an asynchronous fifo to allow
 long write bursts. I have tested the memory (thoroughly) using standard
 memory test patterns, and the memory passes reliably (I have yet to see a
 failure).

 I have not yet implemented a CPU interface to the DDR3, but this will
 hopefully be done soon. I have a couple more things that I would like to
 check/test, and if this is done I'll ask one of the SKA-SA guys to push
 this onto their CASPER mlib git repo.

 I thought this is information worth sharing so that multiple people don't
 end up working on the same thing... Hopefully this is not already the case!

 Thanks,
 JP van Rensburg

Re: [casper] DRAM (DDR3) ROACH-2

[Wesley New]

Comments below.


On Wed, Jul 24, 2013 at 12:07 PM, Matthew Bridges 
matthewbridge...@gmail.com wrote:

 Hi JP and Wes,

 I am very interested in this work, but from a RHINO perspective. I am
 looking into how I should go about adding the RHINOs DRAM into my
 Architecture.

 I have a few questions, if you have time to answer.

 Did you use the Memory Interface Generator? And did it work for you?

Yes, use the MIG. Both R1 and now R2 yellow blocks are based around MIG

 Are there other coregens used in your block? E.g FIFOs?

Yes, the outputted data goes though an asynchronous fifo.

 How many ports did you implement? I was thinking of putting 2 into my
 Architecture, 1 for the Wishbone, 1 for direct processor access.

What interface do you use to talk to the block? Is it OPB?

Both the QDR and DDR use a single port which maps the memory address
space to OPB bus so that the memory can be read from the PPC.


 Thanks,

 Matthew


 On Wed, Jul 24, 2013 at 11:48 AM, Wesley New wes...@ska.ac.za wrote:

 This is great work JP.

 Out of interest is anyone else planning to use the DDR3 on ROACH2?

 Wesley New
 South African SKA Project
 +2721 506 7365
 www.ska.ac.za




 On Wed, Jul 24, 2013 at 8:24 AM, Juan-Pierre Jansen van Rensburg 
 jvrensburg...@gmail.com wrote:

 Hi all

 I have been working on a yellow block for the DDR3 of the ROACH-2. As
 far as I know this yellow block does not yet exist?


 The same DRAM yellow block is used and interfacing the memory remains
 the same (as for the ROACH-1). The DRAM also uses an asynchronous fifo to
 allow long write bursts. I have tested the memory (thoroughly) using
 standard memory test patterns, and the memory passes reliably (I have yet
 to see a failure).

 I have not yet implemented a CPU interface to the DDR3, but this will
 hopefully be done soon. I have a couple more things that I would like to
 check/test, and if this is done I'll ask one of the SKA-SA guys to push
 this onto their CASPER mlib git repo.

 I thought this is information worth sharing so that multiple people
 don't end up working on the same thing... Hopefully this is not already the
 case!

 Thanks,
 JP van Rensburg







 --
 Software Defined Radio Group
 Department of Electrical Engineering
 University of Cape Town
 Private Bag X3, Rondebosch 7701
 Tell: +27 (0)21 650 4659
 Mob: +27 (0)84 413 2642

Re: [casper] MSSGE with ISE 14 compatible OS

[Wesley New]

Hi Alex,

Here at SKA-SA we have found that the most stable Ubuntu setup is with
Ubuntu 12.04, Xilinx 14.3 and Matlab 2012b.

Ubuntu 13.04 has been tried and we encountered issues with updating
designs. Although not much time has been spent trying to resolve these.

Please let us know your results.

Wes

Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za




On Wed, Jul 10, 2013 at 10:49 AM, Alex Zahn avzah...@gmail.com wrote:

 Hi all,

 A bit of a picky question:

 The wiki mentions Ubuntu 12.04 and RHEL 6 as compatible with ISE 14. Does
 anyone know of any other linuxes that have worked with ISE 14?

 More specifically, has anyone tried with Ubuntu 13.04 or Fedora 18 or 19?

 -Alex

Re: [casper] How to avoid design placement/implementation in casper_xps command

[Wesley New]

So we took a look at doing this a while ago and xst is run as part of
sysgen which makes it hard to single out. Ndgbuild, map, par and trace are
run from an xflow script which doesnt help when trying to select a
combination of them. I agree that this would be a useful feature. Ill take
better look at it.

Haoxuan you could try commenting out most
of xps_base/XPS_ROACH_base/etc/fast_runtime.opt and then also stop bitgen
from running.



Wesley New
South African SKA Project
+2721 506 7365
www.ska.ac.za




On Tue, Jul 2, 2013 at 5:25 AM, Ryan Monroe ryan.m.mon...@gmail.com wrote:

  Wait until it hits MAP and hit CTRL-C?  Then do your business and it'll
 usually skip synthesis on the next run

 --Ryan Monroe626.773.0805

 On 07/01/2013 05:18 PM, Jeff Zheng wrote:

   Hi Ryan,
  Thanks a lot for the quick answer! Given the current capser_xps, is there
 any command I can skip to avoid placement? Does IP Synthesis finish the
 synthesized design?

  Jeff


 On Mon, Jul 1, 2013 at 12:37 PM, Ryan Monroe ryan.m.mon...@gmail.comwrote:

 Nope!  But we should change the choices on Casper xps (imo) to

 Update design
 XSG
 (Everything copy base package through Synthesis)
 The rest
  On Jul 1, 2013 9:28 AM, Haoxuan Zheng jef...@mit.edu wrote:

  Hi Casper,
 [Question]:
 Is there a way to ask casper_xps to finish synthesized design and stop
 there (meaning not to attempt placement), and I take over in PlanAhead?
 This will save me a few hours each run. I checked the casper wiki for
 casper_xps but I'm not sure which step corresponds to completion of
 synthesized design.

  [Background]:
 We have an X-engine design that is guaranteed not to meet timing in
 casper_xps compiling, but we have found a reliable floor planning strategy
 (pblocks etc) in PlanAhead to make it compile. I have been debugging it
 thus making minor changes that makes no difference as far as compiling is
 concerned, so it is a waste of time in casper_xps to go from a synthesised
 design to an implemented design, given that its implementation will fail
 timing anyways. (I'm using planahead language here, sorry if that's not
 clear.)

  Thank you guys so much!
 Jeff

Re: [casper] PPS Sync on Toolflow 14.2

[Wesley New]

Hi Andrea

I have simulated the sync pulse with out any issues on the latest version
of the ska-mlib_devel libraries with matlab 2012b and Xilinx 14.4

I have taken your design and put a scope on the output of the OR block and
it looks fine.

Regards

Wes


On Thu, Apr 4, 2013 at 9:15 AM, Andrea Mattana matt...@ira.inaf.it wrote:

 Hi Dave,

 here (http://www.med.ira.inaf.it/~mattana/casper/) you can find a
 screenshot and the model file. I did this simulation because I see the
 same problem on the running project on my ROACH1 board (the pps
 connected to a led is not blinking anymore). The same simulation is
 working nominally using the very old 7.1 libraries, I'm using the
 ska-sa 14.2 toolflow with mlib_devel updated from git on Tue March 5
 14:54:36 2013 (commit from wnew).

 PPS line in our lab is inverted.

 Cheers,
 Andrea


 2013/4/3 David MacMahon dav...@astro.berkeley.edu:
  Hi, Andrea,
 
  Are you seeing problems in simulation or on actual hardware?  I just
 made a quick test model and the sync input was propagated fine in
 simulation.  Can you please explain your symptoms in more detail?  Which
 version of mlib_devel are you using?  What hardware platform are you
 targeting?
 
  Thanks,
  Dave
 
  On Apr 3, 2013, at 7:16 AM, Andrea Mattana wrote:
 
  Does anybody have tested the sync line (pps) on the iadc of the new
 toolflow?
 
  Cheers,
  Andrea
 
  2013/3/27 Andrea Mattana matt...@ira.inaf.it:
  Hi all,
 
  I have tested the PPS over the sync0-1-2-3 output port of the iADC on
  the new libraries with a very simple design and it seems that the
  simulated PPS in input is not propagated anymore.
 
  I have tested a very similar model file on a old Ibob toolflow and it
  works fine.
 
  There are any new constraints or it is just a bug (or better, I'm
  wrong something?)??
 
  Cheers,
  Andrea
 

Re: [casper] Xilinx System Generator_error

[Wesley New]

Hi Shaman,

In Linux we have to source the settings/64.sh file in the Xilinx install
directory before we can start any of the Xilinx tools. This sets the
correct paths and environment variables. There may be a similar script for
windows.

Wes


On Tue, Mar 26, 2013 at 8:55 AM, sha...@rri.res.in wrote:

 Hello,

 I am trying to use the System Generator for DSP.

 I have installed Xilinx ISE Design Suite 13.2 and Matlab R2010b.
 (OS-Windows 7 32bit)

 When I open the System Generator from the start menu, Matlab simulink
 opens with an error message popping as Set up error--- There is a problem
 with ISE installation or Xilinx environment variable.

 Any ideas about overcoming this error?


 Thanks,
 Shaman

Re: [casper] Xilinx System Generator_error

[Wesley New]

On Tue, Mar 26, 2013 at 10:48 AM, sha...@rri.res.in wrote:


 I cannot use the latest version. Now, after re-installing, I am not
 getting the previous setup error.

I am trying a basic simulink model and it is getting compiled and I can
 observe the ouput.

So the design compiles all the way though? Or is this the simulation?


 But, while generating the the HDL code (using the
 system generator only)

Are you opening up the system generator block and trying to run it through
there? Or do you mean during the SG stage of the compile?


 , I am getting an error-- fatal internal error and
 matlab crashes!
 Could you please help..


  If you can, use the latest version 14.4 ;)
 
 
  On Tue, Mar 26, 2013 at 9:58 AM, sha...@rri.res.in wrote:
 
  Hello,
  I am re-installing Xilinx ISE completely, hoping it will solve the
  problem.
 
  Thanks and regards,
  Shaman
 
 
 
 
   Hi Shaman,
  
   In Linux we have to source the settings/64.sh file in the Xilinx
  install
   directory before we can start any of the Xilinx tools. This sets the
   correct paths and environment variables. There may be a similar script
  for
   windows.
  
   Wes
  
  
   On Tue, Mar 26, 2013 at 8:55 AM, sha...@rri.res.in wrote:
  
   Hello,
  
   I am trying to use the System Generator for DSP.
  
   I have installed Xilinx ISE Design Suite 13.2 and Matlab R2010b.
   (OS-Windows 7 32bit)
  
   When I open the System Generator from the start menu, Matlab simulink
   opens with an error message popping as Set up error--- There is a
   problem
   with ISE installation or Xilinx environment variable.
  
   Any ideas about overcoming this error?
  
  
   Thanks,
   Shaman
  
  
  
  
  
  
 
 
 

Re: [casper] SOLVED: ROACH 2's suddenly freezing left and right

[Wesley New]

Hi Glenn,

We are running many bof files with that change and are doing plenty of
register and bram reads and writes and have not experienced any issues with
these bus accesses. What version of TCPBorphServer are you running?

Wes


On Fri, Mar 15, 2013 at 3:28 PM, G Jones glenn.calt...@gmail.com wrote:

 Hi,
 It should have occurred to me sooner, but I checked through the commit
 logs for mlib_devel and remembered I had updated from ska-sa a couple of
 weeks ago to get the bugfix for the rcs block. In doing so, I had also
 pulled down this commit:


 https://github.com/ska-sa/mlib_devel/commit/bad95b18fe79146d288607e5fe3c0360c071c2ad
 Simplified the EPB to OPB 32bit bus cycle and now supports legacy byte
 enable support for ROACH 1 modules on ROACH 2.

 which sounds suspicious since the problem seemed to be related to reading
 writing brams/software registers.

 Indeed, when I switched over to the commit right before that one and
 compiled the same test design, I ended up with a boffile that has not yet
 crashed (the bad bof would have certainly crashed by now).

 The design is simply two ADC5Gs connected to a snapshot blocks. The ADCs
 are clocked at 2880 MHz, so the FPGA is running at 180 MHz.  I'm not sure
 if the problem is some interaction between the ADC5Gs and this commit, or
 the clock rate or what.

 Henno, can you double check the code in this commit and see if you can
 ascertain where the bug might be?

 Glenn

 On Thu, Mar 14, 2013 at 12:00 PM, G Jones glenn.calt...@gmail.com wrote:

 Hi,
 For some unknown reason, boffiles I generate with my toolflow cause
 ROACH 2's to freeze up after a few minutes (I think related to I/O to
 software registers and shared BRAMs rather than any specific amount of
 time). I don't know of any changes I made to my toolflow since the
 last time I compiled working boffiles. Previously working boffiles
 still work, but recompiled designs do not work. The symptom is that
 the python katcp client stops responding. SSHing to the ROACH and
 running ps shows that tcpborphserver3 is no longer running. It finally
 occurred to me to check dmesg, and on all crashed ROACHs, I see this
 in the demsg:

 ...
 About to toggle cpu_rdy pin7r2case_event(): Got type 11, code 8, value 1
 attempting led toggle
 About to toggle cpu_rdy pin7r2case_event(): Got type 11, code 8, value 0
 attempting led toggle
 About to toggle cpu_rdy pinMachine check in kernel mode.
 Data Read PLB Error
 Oops: Machine check, sig: 7 [#1]
 PowerPC 44x Platform
 Modules linked in:
 NIP: 0fea4048 LR: 0fea3f88 CTR: 0004
 REGS: ef00bf10 TRAP: 0214   Not tainted  (3.7.0-rc2+)
 MSR: 0002d000 CE,EE,PR,ME  CR: 2224  XER: 
 TASK = efb54060[516] 'tcpborphserver3' THREAD: ef00a000
 GPR00:  bfcb7290 48031e20 10628bf9 4802c010 0004 0018
 7f7f7f7f
 GPR08:  10628bf0 10628ba0 0fea3f80 2222 1006ba18 
 
 GPR16:       
 
 GPR24:    0004 10628bf9 10628bf9 0ff91ff4
 4802c011
 NIP [0fea4048] 0xfea4048
 LR [0fea3f88] 0xfea3f88
 Call Trace:
 ---[ end trace 59d28c137ef7dde2 ]---

 roach VMA close
 roach release mem called

 -

 If I then try to reboot the ROACH with shutdown -r now, it hardfreezes
 and requires a power cycle to get it running again.

 Any ideas where to look for this problem?

 Thanks,
 Glenn

Re: [casper] unable to load my boffiles and to configure my roach2

[Wesley New]

Hi Dave,

I have modified the BRAM block to only use EDK bram if the datawidth is set
to 32 and the options to register the outputs are set to false. In all
other cases the custom bram block is used.

Regards

Wes


On Tue, Mar 12, 2013 at 8:35 PM, David MacMahon
dav...@astro.berkeley.eduwrote:

 I've not tried that far back.  I go back and forth between 13.x and 14.x
 tools.

 I have not yet backported your shared bram changes yet.  I very much like
 the concept and think that it should probably be used even for shared brams
 that have data width of 32 so that we can use the BRAM output register
 option.  The Xilinx BRAM pcore that is currently used for data width of 32
 does not support that option, but it would greatly helps with timing (and
 therefor placement) as the clock-to-out time for the UNregistered BRAM is
 2 ns!

 Dave

 On Mar 12, 2013, at 10:54 AM, Wesley New wrote:

  That is pretty cool, thanks for the info dave. :)
 
  Have you tried building with the most recent ska-sa libraries on 11.5?
  I updated the custom shared bram block to use the latest coregen. I am
  not sure how an older version of coregen would behave. This is only
  for brams using a data width that is not 32 bits wide.
 
  On 3/12/13, David MacMahon dav...@astro.berkeley.edu wrote:
  Hi, Wes,
 
  On Mar 12, 2013, at 10:35 AM, Wesley New wrote:
 
  There
  might be 1 or 2 tweeks to the tools that you would have to do.
 
  The only tweak that I've needed to do so far is to export model files
  (e.g. xps_library.mdl) that have been saved in the latest Simulink
 version
  to an older Simulink model file format.  The latest version stores the
 mask
  parameters in a way that is incompatible with earlier versions.  What
 was
  Mathworks thinking?!
 
  Dave
 
 

[casper] ROACH2 gzipped bof files

[Wesley New]

The new TCPBorphServer 3 supports a compressed (gzip) boffile so I have
updated the SKA-SA CASPER tools to compress the bof file using gzip for all
roach2 compiles. This is also placed in the bit_files directory.

So if you are running TCPBorphServer 3 on your roach 2 you will now be able
to use the gzipped bof files and save some space.

ie
?progdev myApp.bof.gzip

Regards

Wes

Re: [casper] Error reading registers with ROACH2

[Wesley New]

Hi Jason,

It looks like you may have built the bof file with an older version of the
CASPER tools. We had a similar problem with the infrastructure being held
in reset and hence TCPBorphServer timed out on bus requests. Have you
pulled the latest version from SKA-SA?

You can try the precompiled tut1 boffile to give us an idea whether the
problem is with the CASPER tools or TCPBorphServer.

Regards

Wes


On Tue, Mar 5, 2013 at 9:25 PM, Jason Castro jcas...@nrao.edu wrote:

 I just loaded the latest version of tcpborphserver dated
 2013-02-12T17:00:21 for my ROACH2.  I've recompiled tutorial1 for a ROACH2
 and I'm able to load the bof file to the FPGA, however when I try to read a
 register I get a communications error from the Roach and the personality of
 the FPGA is dumped.  The roach is still on the network and KATCP is still
 there, but I have to reload the BOF file.  It appears I can write to
 registers correctly.  If I request say 5 bytes from the sys_stratchpad
 KATCP recovers gracefully with an error, but if I request 4 bytes I get the
 following error dump from the ROACH2, as read from the USB serial interface:

 Machine check in kernel mode.
 Data Read PLB Error
 Oops: Machine check, sig: 7 [#6]
 PowerPC 44x Platform
 Modules linked in:
 NIP: 10004ff8 LR: 10004fcc CTR: 1000547c
 REGS: efbcdf10 TRAP: 0214   Tainted: G  D W (3.4.0-rc3+)
 MSR: 0002f900 CE,EE,PR,FP,ME  CR: 42002424  XER: 005f
 TASK = efbd4100[489] 'tcpborphserver3' THREAD: efbcc000
 GPR00:  bfc7faf0 48021c60    10045fbc
 
 GPR08:  4802a00c  bfc7faf0 22002422 100598dc 
 
 GPR16: 1ff6b47c 1ff62098     
 bf8b8fae
 GPR24: 100028c4 100450a8 0008 48028e64  0004 1005808c
 bfc7faf0
 NIP [10004ff8] 0x10004ff8
 LR [10004fcc] 0x10004fcc
 Call Trace:
 ---[ end trace 9a1ad1718c70baa4 ]---

 roach VMA close
 roach release mem calledBus error
 root: tcpborphserver exited with code 0

 i2c i2c-0: master_xfer[0] W, addr=0x18, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x18, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x18, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x18, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x18, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x18, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x18, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x18, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x18, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x18, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x18, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x18, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x18, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x18, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x18, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x18, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x18, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x18, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x18, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x18, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x18, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x18, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x18, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x18, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x18, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x18, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x18, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x18, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x18, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x18, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x18, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x18, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x18, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x18, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x4c, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x4c, len=2
 i2c i2c-0: master_xfer[0] W, addr=0x4c, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x4c, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x4c, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x4c, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x4e, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x4e, len=2
 i2c i2c-0: master_xfer[0] W, addr=0x4e, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x4e, len=1
 i2c i2c-0: master_xfer[0] W, addr=0x4e, len=1
 i2c i2c-0: master_xfer[1] R, addr=0x4e, len=1

Re: [casper] Failed to load library dspsigops

[Wesley New]

Hi Andrea
I have just updated xps_library/casper_xps.m to support Xilinx version
14.4. If you pull from ska-sa mlib_devel you will get the change.

Regards

Wes


On Fri, Mar 1, 2013 at 5:42 PM, Andrea Mattana matt...@ira.inaf.it wrote:

 Hi all,

 I have installed the new toolflow having MATLAB R2012b and Xilinx
 14.4, adding also the removed pcores available from your repository.

 Making a simple model file and running the casper_xps I got two error
 messages:

 Unsupporter Xilinx System Generator version 14.4
 Failed to load library dspsigops referenced by 'test/adc/Downsamplei0'

 The same libraries on MATLAB 2012a and Xilinx 14.2 works fine.

 Do you have some ideas?

 Cheers,
 Andrea

Re: [casper] ROACH2 J10

[Wesley New]

Hi Jonathon,

The easiest way to do this is through and ADC. If you arent using an ADC on
the board then you will need to make some tweaks to the tools. We dont
support this at the moment but it shouldnt be hard to add it.

You could implement this in a couple of ways:

It could be done in the the roach_infrastructure block, you will have to
put it thought a differential buffer and provide the output to the rest of
the system. You can see how it was done with the aux_clks on roach1.

Or you could do it in the gpio block similar to the way the aux_clks are
exposed as GPIOs on roach1.

I am pretty busy this week, but will be available next week to help out if
you need.

Regards

Wes



On Tue, Jan 29, 2013 at 6:38 PM, Jonathon Kocz jk...@cfa.harvard.eduwrote:

 Hi All,

 We are attempting to bring in a PPS signal on the ROACH2 J10 SMA connector.

 Does this still come in as with the ROACH using the GPIO block? Is there a
 page or document somewhere that describes how to bring this signal in?
 (GPIO bit map/other, similar to
 https://casper.berkeley.edu/wiki/ROACH_FPGA_Interfaces ?)

 Many thanks,
 Jonathon

Re: [casper] DDR Memory Modules for Roach2

[Wesley New]

Hi Jason,

I think Mo had different Kingston DIMMs which are not 1gig, but the
supplier claims that they are compatible. We have to be very careful when
choosing the DIMM as we can only support a few different modules as the
gateware controller has the SPD information hard coded.

I am unsure of the status, but Alec will be able to help out, when he gets
into the office tomorrow morning (South African Time).

I noticed the wiki page heading read ROACH DDR3 Memory. I have changed it
to ROACH2 DDR3 Memory. So the link is now at
https://casper.berkeley.edu/wiki/ROACH2_DDR3_Memory_Modules

Regards

Wes



On Thu, Oct 25, 2012 at 10:16 PM, Jason Castro jcas...@nrao.edu wrote:

 The following web page lists two memory modules for use in the ROACH2:

 https://casper.berkeley.edu/**wiki/ROACH_DDR3_Memory_Moduleshttps://casper.berkeley.edu/wiki/ROACH_DDR3_Memory_Modules

 Kingston KVR1333D3S8R9S/1G
 Samsung M393B5773CH0-CH9

 Mo at Digicom was only aware of the Kingston Module as being approved for
 use in the ROACH2.  He also reported that the Kingston Module may have some
 problems as well.  Can anyone give me updated information on this topic?

 Thanks,

 Jason Castro

[casper] Toolflow: Supported Versions

[Wesley New]

Good Day Casperites,

Since the release of the upgraded
librarieshttps://github.com/ska-sa/mlib_develto support the ISE 14
tools, there have been questions about which versions
are still supported.

It is recommended that you use the latest version of the
librarieshttps://github.com/ska-sa/mlib_devel (SKA-SA),
especially if you are compiling for ROACH2.
This most recent version supports the ISE 11  14 tools. Although 14 is
strongly recommended.

If for some reason you need to use ISE 11. Please use 11.5 with Matlab
2008b.
But preferably use* ISE 14.2* with *Matlab 2012a*. See setup instructions
herehttps://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.2_and_Matlab_2012a
.

Support can not be guaranteed for other versions of ISE and Matlab.

Feel free to ask if you have any questions.

Regards

Wes

Re: [casper] System generator error: INFO:Security:56 - Part 'xc5vsx95t' is not a WebPack part.

[Wesley New]

It looks like your licence is for the wrong hostid, I think this is
the mac address. You could either regenerate the licence on the Xilinx
site or you could set up a face eth0 interface..

On 10/22/12, Nestor Lasso Cabrera nes...@astro-udec.cl wrote:
 Dear Mr. or Mrs.,

 I'm trying to run the Tutorial 1 from the Casper website for ROACH
 development. I have Matlab R2010a and Xilinx 13.1 (with node fixed license)
 running in Ubuntu 12.04. Both Matlab and Xilinx are running fine. When I run
 system generator, Matlab opens fine and display the following messages:

 
 Installed System Generator dynamically.
 ans = TimecheckDirFile
 ans = TimecheckDirFile

 System Generator currently found installed into matlab default path
 Available System Generator installations:
 Current version of System Generator is 13.1.3561.
 Run  xlVersion  at prompt to see installed versions of System Generator
 

 After that Simulink runs fine and shows and opens all the Casper and Xilinx
 blocks.

 My problem is when running Bee_xps. Bee_xps starts running fine, opens the
 System Generator and then give me the following error:

 ***
 ERROR: A license checkout has failed for System Generator for DSP (SysGen).

 --- A message from the license manager --
 INFO:Security:56 - Part 'xc5vsx95t' is not a WebPack part.
 INFO:Security:60 - The XILINXD_LICENSE_FILE environment variable is set to
 '/home/lasso/.Xilinx/'.
 INFO:Security:62 - The LM_LICENSE_FILE environment variable is set to
 '/home/lasso/.Xilinx/'.
 INFO:Security:68 - Please run the Xilinx License Configuration Manager
 (xlcm or Manage Xilinx Licenses)
 to assist in obtaining a license.
 ERROR:Security:7 - A feature for SysGen was found but is for the wrong
 hostid.
 ERROR:Security:9 - No 'SysGen' feature was available for part 'xc5vsx95t'.
 ERROR:Security:12 - No 'xc5vsx95t' feature was available (-5).

 -
 Invalid host.
 The hostid of this system does not match the hostid
 specified in the license file.
 Feature: SysGen
 Hostid: 5404a6c09beb
 License path:
 /home/lasso/.Xilinx//Xilinx.lic:/opt/Xilinx/13.1/ISE_DS/ISE/data/*.lic:/opt/Xilinx/13.1/ISE_DS/ISE/coregen/core_licenses/Xilinx.lic:/opt/Xilinx/13.1/ISE_DS/ISE/coregen/core_licenses/XilinxFree.lic:/opt/Xilinx/13.1/ISE_DS/EDK/data/core_licenses/Xilinx.lic:
 FLEXnet Licensing error:-9,57. System Error: 2 No such file or directory
 For further information, refer to the FLEXnet Licensing documentation,
 available at www.acresso.com.No such feature exists.
 Feature: xc5vsx95t
 License path:
 /home/lasso/.Xilinx//Xilinx.lic:/opt/Xilinx/13.1/ISE_DS/ISE/data/*.lic:/opt/Xilinx/13.1/ISE_DS/ISE/coregen/core_licenses/Xilinx.lic:/opt/Xilinx/13.1/ISE_DS/ISE/coregen/core_licenses/XilinxFree.lic:/opt/Xilinx/13.1/ISE_DS/EDK/data/core_licenses/Xilinx.lic:
 FLEXnet Licensing error:-5,357
 For further information, refer to the FLEXnet Licensing documentation,
 available at www.acresso.com.
 -

 Reported by:
 Unspecified
 **

 Please, could you give me any suggestion?

 Thank you,

 Nestor Lasso


 =
 Dr. Nestor M. Lasso Cabrera
 Postdoc
 Departamento de Astronomía,
 Facultad de Ciencias Físicas y Matemáticas
 Av. Esteban Iturra s/n Barrio Universitario,
 Universidad de Concepción
 Casilla 160-C
 Concepción, CHILE
 Fono: +56-041-2207171 / fax: +56-41-2207432
 =

Re: [casper] ERROR:EDK - IPNAME: opb_v20, INSTANCE: opb0

[Wesley New]

Hi Katty,

Here are some similar threads that are in the mailing-list history.

http://www.mail-archive.com/casper@lists.berkeley.edu/msg02980.html
http://www.mail-archive.com/casper@lists.berkeley.edu/msg02982.html

Basically, the OPB cores have been deprecated in the later Xilinx tools and
need to be copied from an older version.

Hope these help.

Wes

On Sat, Oct 13, 2012 at 9:04 PM, katherine viviana cortes urbina 
kattycort...@gmail.com wrote:

 Hi All,

 I resolved the error ;

 Error using == xlCheckDevice at 9

 It is because I installed ISE12.1  and 13.1 , I solved it is removing ISE 
 13.1. I have a new error when  I achieved compile any design with bee_xps, 
 but  I got the following error;


 Format revision of project to EDK 12.1 completed
 ERROR:EDK - IPNAME: opb_v20, INSTANCE: opb0 -
/home/ROACH/Desktop/Tut3/Katty/led/XPS_ROACH_base/system.mhs line 93 - 
 cannot
find MPD for the pcore 'opb_v20_v1_10_c' in any of the repositories.

 ERROR:EDK - IPNAME:opb_v20 INSTANCE: opb0 -
/home/ROACH/Desktop/Tut3/Katty/led/XPS_ROACH_base/system.mhs line 93 - 
 cannot
find MPD for the pcore
 ERROR:EDK - while loading XMP file

 XPS% Evaluating file run_xps.tcl

 ERROR:EDK - Load a MHS or XMP file first
 Error using == gen_xps_files at 673
 XPS failed.


 The file system.mhs line 93 said:

 #IF# strcmp(get(b,'type'),'xps_katadc')  
 strcmp(get(b,'hw_adc'),'adc1')#PORT adc1_ser_clk = adc1_adc3wire_clk,DIR 
 = O


 The other I have to remove the folder pcores to 
 mlib_devel_10_1/xps_lib/XPS_ROACH_base ???


 Cheers,

 katty

Re: [casper] Toolflow Updates

[Wesley New]

Hi Nimish,

So the 11.4 and 11.5 tools are still supported with the latest libraries.
If you run get_xlVersion() in your matlab prompt you should get 11.4. The
script casper_xps.m checks the version number and prints the error. What
does your get_xlVersion() output?

Wes

On Mon, Oct 8, 2012 at 5:59 PM, Nimish Sane nimishs...@gmail.com wrote:

 Hi Wes,

 I was able to use the ska-sa mlib_devel repository with Xilinx 11.4 and
 Matlab 2009b earlier, and successfully compile my designs. With the latest
 update, it seems I can no longer use these versions. The compilation fails
 with an error that I have Xilinx 11.4 installed, which is not supported. Is
 it now mandatory to upgrade to Xilinx14.2 and Matlab 2012a?

 Thanks,

 Nimish


 On Sat, Oct 6, 2012 at 2:15 PM, Nimish Sane nimishs...@gmail.com wrote:

 Hi Mark,

 That worked. After updating the libraries xsg core config was set to
 default Roach.

 Thanks,

 Nimish

 On Oct 5, 2012, at 6:10 PM, Mark Wagner mwag...@ssl.berkeley.edu wrote:

 It's in both, you'll need to specify ROACH2 in the xsg_core_config block
 though.

 Mark


 On Fri, Oct 5, 2012 at 3:06 PM, Nimish Sane nimishs...@gmail.com wrote:

 Mark,

 This is bwrc repo or ska-sa? I am using ska-sa and could not find it.

 Thanks,

 Nimish

 On Oct 5, 2012, at 6:01 PM, Mark Wagner mwag...@ssl.berkeley.edu
 wrote:

 Hi Nimish,

 If you pull the new 10gbe_v2 yellowblock from the most recent repo, all
 of those options should be available - sfp+, roach2, etc.

 Mark


 On Fri, Oct 5, 2012 at 2:57 PM, Nimish Sane nimishs...@gmail.comwrote:

 Hi Wes,

 I just updated to the latest libraries. Great work! I am looking
 forward to using those. I have a quick question. Does ten_Gbe_v2 block
 support Roach2? The port parameter on the yellow block can be set to
 between 0 and 3. I understand that Roach 2 will have 6 CX4 ports (3 each
 per mezzanine card). How does that map to the yellow block?

 Also, I remember from the casper workshop that there was going to be a
 setting to select between CX4 and SFP+ connection. Do you know what's the
 status with that?

 Thanks,

 Nimish

  On Wed, Oct 3, 2012 at 8:10 AM, Andrew Martens and...@ska.ac.zawrote:

 Hi Dave, Wes

 We could probably write a little Wishbone-to-OPB module and plug that
 in
 front of the OPB yellow blocks for some things. Messing with the
 internals of yellow blocks that we don't have hardware for could be
 dangerous e.g ADCs. Ideally people would help out with yellow blocks
 they have hardware for and have expertise in.

 Regards
 Andrew

 On Wed, 2012-10-03 at 13:29 +0200, Wesley New wrote:
  Hi Dave,
 
 
  Unfortunately the move to wishbone will need to be done en mass.
 
 
  Wes
 
  On Thu, Sep 27, 2012 at 7:40 PM, David MacMahon
  dav...@astro.berkeley.edu wrote:
  Hi, Wes,
 
  Are you converting all yellow blocks to wishbone en masse or
  can they be converted one by one over time?
 
  Thanks,
  Dave
 
  On Sep 27, 2012, at 10:23 AM, Wesley New wrote:
 
   Hi Rurik
  
   These updates don't contain the wishbone port, that is the
  next item
   on my to-do list.
  
   Wes
  
   On 9/27/12, Rurik A. Primiani rprim...@cfa.harvard.edu
  wrote:
   Hi Wes,
  
   Great work! I look forward to using the newer tools. Just
 a
  quick
   question, does this update include the migration to the
  Wishbone bus
   discussed at the workshop?
  
   Best,
   Rurik
  
   On 9/26/12 9:01 AM, Wesley New wrote:
   Good Day all,
  
   We have updated the existing MSSGE toolflow to work with
  the Xilinx 14.2
   tools and Matlab2012a. I have provided a wikipage with
 all
  the details
   and how to get an environment setup, available at:
  
 
 https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.2_and_Matlab_2012a
  
  
   The ska-sa mlib_devel repository currently hosts these
  changes and can
   be found at: https://github.com/ska-sa/mlib_devel. So
 feel
  free to start
   using the latest tools and post any issues/feeback to the
  mailing list.
  
   Thanks
  
   Wesley
  
  
 
 
 
 

Re: [casper] Error Xilinx --- Counter .

[Wesley New]

Hi Kath,

If you look in the bee_xps.m script you will see a list of supported
versions. It seems that get_xlVersion('full') only returns the version in
the format xx.y and not xx.y. any more. I would suggest that you edit
the script to support this version.

Regards

Wes

On Tue, Oct 9, 2012 at 2:57 PM, katherine viviana cortes urbina 
kattycort...@gmail.com wrote:

 Dear Casper,

  I have intaling Centos 5.8/matlab R2009b/ISE 13.1,  I have create a
 design for example tut1  (one the most simple) but when I try to compile
 any design with bee_xps. I got the following error;

  bee_xps
 ??? Reference to non-existent element of a cell array.

 Error in == get_xlVersion at 24
 argout = [xsgVer, '.', toks{1}{1}];

 Error in == bee_xps at 53
 xsg = get_xlVersion('full');


 cheers


 katty

Re: [casper] Error Xilinx --- Counter .

[Wesley New]

Change:  case {'13.1.'}
To: case {'13.1'}

No period after the 1 :)

Wes

On Tue, Oct 9, 2012 at 4:22 PM, Rurik A. Primiani
rprim...@cfa.harvard.eduwrote:

 Hi Katherine,

 In your email you say you installed Matlab R2009b and Xilinx 13.1. These
 versions are not compatible according to Xilinx:
 http://www.xilinx.com/support/**answers/17966.htmhttp://www.xilinx.com/support/answers/17966.htm.
 You should either downgrade to Xilinx 11.5 or upgrade to Matlab R2010b.

 Best,
 Rurik


 On 10/9/12 8:57 AM, katherine viviana cortes urbina wrote:

 Dear Casper,

   I have intaling Centos 5.8/matlab R2009b/ISE 13.1,  I have create a
 design for example tut1  (one the most simple) but when I try to compile
 any design with bee_xps. I got the following error;

   bee_xps
 ??? Reference to non-existent element of a cell array.

 Error in == get_xlVersion at 24
  argout = [xsgVer, '.', toks{1}{1}];

 Error in == bee_xps at 53
  xsg = get_xlVersion('full');


 cheers


 katty

Re: [casper] Toolflow Updates

[Wesley New]

 of yellow blocks that we don't have
 hardware for could be
 dangerous e.g ADCs. Ideally people would help out
 with yellow blocks
 they have hardware for and have expertise in.

 Regards
 Andrew

 On Wed, 2012-10-03 at 13:29 +0200, Wesley New wrote:
  Hi Dave,
 
 
  Unfortunately the move to wishbone will need to be
 done en mass.
 
 
  Wes
 
  On Thu, Sep 27, 2012 at 7:40 PM, David MacMahon
  dav...@astro.berkeley.edu
 
 mailto:davidm@astro.berkeley.**edudav...@astro.berkeley.edu
 wrote:
  Hi, Wes,
 
  Are you converting all yellow blocks to
 wishbone en masse or
  can they be converted one by one over time?
 
  Thanks,
  Dave
 
  On Sep 27, 2012, at 10:23 AM, Wesley New
 wrote:
 
   Hi Rurik
  
   These updates don't contain the wishbone port,
 that is the
  next item
   on my to-do list.
  
   Wes
  
   On 9/27/12, Rurik A. Primiani
 rprim...@cfa.harvard.edu
 
 mailto:rprimian@cfa.harvard.**edurprim...@cfa.harvard.edu
 

  wrote:
   Hi Wes,
  
   Great work! I look forward to using the newer
 tools. Just a
  quick
   question, does this update include the migration
 to the
  Wishbone bus
   discussed at the workshop?
  
   Best,
   Rurik
  
   On 9/26/12 9:01 AM, Wesley New wrote:
   Good Day all,
  
   We have updated the existing MSSGE toolflow to
 work with
  the Xilinx 14.2
   tools and Matlab2012a. I have provided a
 wikipage with all
  the details
   and how to get an environment setup, available
 at:
  
 
 https://casper.berkeley.edu/**
 wiki/MSSGE_Setup_with_Xilinx_**14.2_and_Matlab_2012ahttps://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.2_and_Matlab_2012a
  
  
   The ska-sa mlib_devel repository currently
 hosts these
  changes and can
   be found at:
 
 https://github.com/ska-sa/**mlib_develhttps://github.com/ska-sa/mlib_devel.
 So feel
  free to start
   using the latest tools and post any
 issues/feeback to the
  mailing list.
  
   Thanks
  
   Wesley
  
  
 
 
 
 

Re: [casper] Toolflow Updates

[Wesley New]

Hi Dave,

Unfortunately the move to wishbone will need to be done en mass.

Wes

On Thu, Sep 27, 2012 at 7:40 PM, David MacMahon
dav...@astro.berkeley.eduwrote:

 Hi, Wes,

 Are you converting all yellow blocks to wishbone en masse or can they be
 converted one by one over time?

 Thanks,
 Dave

 On Sep 27, 2012, at 10:23 AM, Wesley New wrote:

  Hi Rurik
 
  These updates don't contain the wishbone port, that is the next item
  on my to-do list.
 
  Wes
 
  On 9/27/12, Rurik A. Primiani rprim...@cfa.harvard.edu wrote:
  Hi Wes,
 
  Great work! I look forward to using the newer tools. Just a quick
  question, does this update include the migration to the Wishbone bus
  discussed at the workshop?
 
  Best,
  Rurik
 
  On 9/26/12 9:01 AM, Wesley New wrote:
  Good Day all,
 
  We have updated the existing MSSGE toolflow to work with the Xilinx
 14.2
  tools and Matlab2012a. I have provided a wikipage with all the details
  and how to get an environment setup, available at:
 
 https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.2_and_Matlab_2012a
 
 
  The ska-sa mlib_devel repository currently hosts these changes and can
  be found at: https://github.com/ska-sa/mlib_devel. So feel free to
 start
  using the latest tools and post any issues/feeback to the mailing list.
 
  Thanks
 
  Wesley
 
 

Re: [casper] Toolflow Updates

[Wesley New]

Hi Rurik

These updates don't contain the wishbone port, that is the next item
on my to-do list.

Wes

On 9/27/12, Rurik A. Primiani rprim...@cfa.harvard.edu wrote:
 Hi Wes,

 Great work! I look forward to using the newer tools. Just a quick
 question, does this update include the migration to the Wishbone bus
 discussed at the workshop?

 Best,
 Rurik

 On 9/26/12 9:01 AM, Wesley New wrote:
 Good Day all,

 We have updated the existing MSSGE toolflow to work with the Xilinx 14.2
 tools and Matlab2012a. I have provided a wikipage with all the details
 and how to get an environment setup, available at:
 https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.2_and_Matlab_2012a


 The ska-sa mlib_devel repository currently hosts these changes and can
 be found at: https://github.com/ska-sa/mlib_devel. So feel free to start
 using the latest tools and post any issues/feeback to the mailing list.

 Thanks

 Wesley

Re: [casper] NB! Updates to the CASPER tools and libraries

[Wesley New]

Hi Dave, thanks for your comments.

On Tue, Sep 4, 2012 at 5:28 PM, David MacMahon dav...@astro.berkeley.eduwrote:

 Hi, Wes,

 Thanks for taking on this effort!  Here are a few comments:

 On Sep 3, 2012, at 4:43 AM, Wesley New wrote:

  Removing the following yellow blocks:
  XAUI - Only supported by BEE2 and iBOB

 I didn't realize that XAUI is not supported on the ROACH.  I guess if
 someone needs it on ROACH they can update the existing yellow block from
 the BEE2/iBOB branch to work on ROACH and reintroduce it into the library.


Jason has corrected me on this, the XAUI block is supported by ROACH, so I
wont be removing it.


  The environment variable BEE_XPS_LIB_PATH is changing to XPS_BASE_PATH,
 this will mean a change to your matlab startsg scripts

 You're probably planning on something like this anyway, but as a migration
 aid, please update the scripts to check for the new variable first.  If the
 new variable is not set, then check for the old variable (and print a
 deprecation warning).  If you want, you could print a big error message
 instead of a warning to force the user to update the variable right away,
 but I suspect that some users may need the intervention of others to get
 things like that changed.  The main point is please don't have the scripts
 fail silently/mysteriously if the user has not updated the name of this
 environment variable.  I guess the same thing goes for the value of the
 variable (i.e. check the last component of the path to see if it is still
 xps_lib and print a warning/error message).  It's always nicer to get
 friendly informative error messages than cryptic ones from tools failing in
 unforeseen ways.

Good point, Ill definitely implement it in this way.


 I suppose there could be a corresponding cleanup of the BEE2/iBOB branch
 (e.g. remove the QDR yellow block, etc.), but I imagine that is not high on
 your priority list. :-)

As you noted, this is not on my list of To-Dos.


 Thanks again,
 Dave

[casper] NB! Updates to the CASPER tools and libraries

[Wesley New]

Good Day All,

I am writing to provide a heads-up with regards to the clean up of the
toolflow.

The idea is to remove support for the older hardware platforms (iBOB, BEE2
and CORR) as they are no longer supported by Xilinx tools after 10. We will
provide a tag to the version of the tools which supports the older hardware.

We will also be updating the names of things such as environment variables
and scripts, to remove references to the legacy hardware.

Here is a list of things that I have changed in the clean_up branch of the
SKA MLIB_DEVEL https://github.com/ska-sa/mlib_devel/tree/clean_uprepository.
This will be migrated to the master branch when it has all been
tested.


Removing iBOB, BEE2 and CORR related code from the scripts

Removing the following yellow blocks:
XAUI - Only supported by BEE2 and iBOB
CORR_mxfe - Only supported by CORR
CORR_fr  - Only supported by CORR
CORR_adc - Only supported by CORR
CORR_dac - Only supported by CORR
iBOB_lwip - Only supported by iBOB
frame_buffer - Only supported by iBOB
vsi - Only supported by iBOB
dac_iBOB - Only supported by iBOB
sram - Only supported by iBOB

Editing the following yellow blocks:
XSG core config - Removed iBOB, BEE2 and CORR options
GPIOs - Removed iBOB, BEE2 and CORR options
DRAM - removed support for multiple DIMMs as this is only supported by the
iBOB

The folder xps_lib is changing to xps_base, as it contains the base support
packages for each of the supported hardware platforms
Changing bee_xps to casper_xps, ie to run the former bee_xps now use
casper_xps
BEE_XPS_Blockset changing to CASPER XPS Blockset
The environment variable BEE_XPS_LIB_PATH is changing to XPS_BASE_PATH,
this will mean a change to your matlab startsg scripts
Change the name of bee_hw_routes.m to hw_routes.m
Removing the GAVRT library.


If you can want anything to remain or can think of anything else that can
go, please let me know, I welcome any comments and ideas.

Regards

Wes

Re: [casper] CLKIN1_PERIOD error when building for ROACH II

[Wesley New]

Great work guys. We are planning porting the libraries to 14.1 as soon
as possible and I'm sure we will encounter more similar issues.

Wes

On 7/21/12, Rurik A. Primiani rprim...@cfa.harvard.edu wrote:
 Digging into this further it appears that a combination of integer
 division and
 the 13.x tools is to blame. The value 10 for CLKIN1_PERIOD works on both
 11 and 13 but 1000/100 only works on 11. Weird. In any event
 1000.0/CLK_FREQ
 worked for me too!

 Rurik

 On 7/20/2012 6:15 PM, Rurik A. Primiani wrote:
 Glenn, this changed was introduced rather recently:

 https://github.com/ska-sa/mlib_devel/commit/828079

 Which might explain why the casper-astro fork does not exhibit the odd
 behavior.
 For the record, I'm seeing this too on my Windows 7 machine with the
 13.x tools.

 Rurik

 On 7/20/2012 5:55 PM, G Jones wrote:
 Good catch. Changing the CLKIN1_PERIOD line to (1000.0/CLK_FREQ) to
 force it to be floating point seems to have fixed the problem. I'll
 see if I can generate a pull request for this modification.
 It's not clear to me why this was not a problem for the
 casper-astro/mlib_devel branch, but oh well. I suppose the reason
 people haven't run into the issue using the version 11 era tools is
 that the type checking became more stringent?

 Thanks,
 Glenn


 On Fri, Jul 20, 2012 at 2:42 PM, Ryan Monroe
 ryan.m.mon...@gmail.com wrote:
 Comment: 1000/CLK_FREQ will evaluate to 10 when CLK_FREQ=100.  That
 crazy
 binary value you see is 0b1010 = 0d10.  Looks like a variable
 casting issue


 On 07/20/2012 02:39 PM, G Jones wrote:
 Some more information:

 The only place the problem value is shown is in
 XPS_ROACH2_base/synthesis/infrastructure_inst_wrapper_xst.srp

 Elaborating module

 MMCM_BASE(BANDWIDTH=low,CLKFBOUT_MULT_F=6,CLKFBOUT_PHASE=0.0,CLKIN1_PERIOD=32'sb01010,CLKOUT0_DIVIDE_F=1,CLKOUT0_DUTY_CYCLE=0.5,CLKOUT1_DUTY_CYCLE=0.5,CLKOUT2_DUTY_CYCLE=0.5,CLKOUT3_DUTY_CYCLE=0.5,CLKOUT4_DUTY_CYCLE=0.5,CLKOUT5_DUTY_CYCLE=0.5,CLKOUT6_DUTY_CYCLE=0.5,CLKOUT0_PHASE=0.0,CLKOUT1_PHASE=0.0,CLKOUT2_PHASE=0.0,CLKOUT3_PHASE=0,CLKOUT4_PHASE=0,CLKOUT5_PHASE=0,CLKOUT6_PHASE=0.0,CLKOUT1_DIVIDE=6,CLKOUT2_DIVIDE=6,CLKOUT3_DIVIDE=32'sb011,CLKOUT4_DIVIDE=32'sb011,CLKOUT5_DIVIDE=32'sb011,CLKOUT4_CASCADE=FALSE,CLOCK_HOLD=FALSE,DIVCLK_DIVIDE=1,REF_JITTER1=0.0,STARTUP_WAIT=FALSE).



 In the verilog file, CLKIN1_PERIOD  is set to (1000/CLK_FREQ) and the
 CLK_FREQ parameter defaults to 100.
 The value of CLK_FREQ passed from the .mhs is also 100

 In the data/roach_infrastructure_v2_1_0.mpd, CLK_FREQ is set to 100.
 The data type is indicated as integer which is a bit suspicous, but
 it's the same in the working casper-astro/mlib_devel

 Glenn


 On Fri, Jul 20, 2012 at 2:17 PM, G Jones glenn.calt...@gmail.com
 wrote:
 Yep, I agree again, but the MHS file that sets the parameters (as far
 as I remember) looks OK too. I'll try grepping through the build
 directory to see if I can figure out where the crazy value is coming
 from.

 On Fri, Jul 20, 2012 at 2:15 PM, Ryan Monroe
 ryan.m.mon...@gmail.com
 wrote:
 Ahem, by 'log file', I meant 'HDL file'.


 On 07/20/2012 02:13 PM, G Jones wrote:
 I agree, but the mystery is how that crazy binary value is
 getting in
 there...
 I should also note that I was able to build ROACH II designs
 with the
 casper-astro/mlib_devel, but the resulting boffiles caused a kernel
 panic sort of error when reading the registers. Using a known good
 boffile from Rurik showed that the ROACH II itself was not the
 cause
 of the problem.

 Glenn

 On Fri, Jul 20, 2012 at 2:09 PM, Ryan Monroe
 ryan.m.mon...@gmail.com
 wrote:
 Hey Glenn,

 I would guess that the HDL is wrong.  Reference the ISE 13.4 /
 Virtex
 6
 HDL
 libraries guide, page 249:


 http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/virtex6_hdl.pdf



 Looks like it wants a float, representing the input period here.
 Definitely
 not a binary value...

 But I haven't looked at the HDL myself, I'm just going off of the
 report
 in
 this email.  Take this all with a pinch of salt.

 Anyways, how's life?  I haven't seen you in awhile--don't I
 still owe
 you
 a
 beer?  :-)

 --Ryan


 On 07/20/2012 01:51 PM, G Jones wrote:
 Hello,
 I am running into a problem (error message below) when trying to
 build
 simple designs for the ROACH II. I am using the ska-sa/mlib_devel
 freshly cloned from github. I have double checked that my
 paths only
 point to this version. I am using ISE 13.4 and MATLAB 2011a. The
 design is very simple, just a blinking LED and a software
 register. I
 initially tried clocking off of sys_clk at 100 MHz, but found the
 same
 problem when I added an ADC to the design and selected
 adc0_clk at
 200
 MHz.
 The problem occurs during ngdbuild of system.ngd

 Mark Wagner says he has also seen this problem.

 I checked the roach_infrastructure.v code in the pcore and it
 looks
 reasonable to me.

 Does anyone have any suggestions?

 Thanks,
 Glenn

 Annotating constraints to design from ucf file system.ucf 

Re: [casper] Gerbers for ROACH

[Wesley New]

Hi Rich,

As an aside, we have recently put the repository with all the roach 1
and 2 hardware files onto github, search for ska-sa and and feel free
to browse through the repos. I will send you a link as soon as I get
to a computer.

Regards

Wes

On 2/10/12, Rich Lacasse rlaca...@nrao.edu wrote:
 I received the following from Jason Ray and it worked fine...  Rich

 I too had trouble using the PADS viewer, but was able to open the .PHO files
 in the viewer I normally use --- Pentalogix Viewmate 10.6.
 http://www.pentalogix.com/viewmate.php

 We use the free version of Viewmate.

 casper-requ...@lists.berkeley.edu wrote:

 Send casper mailing list submissions to
  casper@lists.berkeley.edu

 To subscribe or unsubscribe via the World Wide Web, visit
  
 https://calmail.berkeley.edu/manage/list/listinfo/casper@lists.berkeley.edu

 or, via email, send a message with subject or body 'help' to
  casper-requ...@lists.berkeley.edu

 You can reach the person managing the list at
  casper-ow...@lists.berkeley.edu

 When replying, please edit your Subject line so it is more specific
 than Re: Contents of casper digest...


 Today's Topics:

1. Gerbers for ROACH (Rich Lacasse)


 --

 Message: 1
 Date: Fri, 10 Feb 2012 11:43:35 -0500
 From: Rich Lacasse rlaca...@nrao.edu
 Subject: [casper] Gerbers for ROACH
 To: casper@lists.berkeley.edu
 Message-ID: 4f354937.9040...@nrao.edu
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 On the CASPER web site, there is a link for Gerber files and a link to
 get a PADS PCB viewer.  I wanted to have a look at the board layers so
 gave this a try and ran into two problems.  First, the Gerbers are not
 a standard gerber file, viewable by the gerber viewers I already had.
 Second, the downloaded product from Mentor complained that the file I
 gave it to look at, (top silk screen layer) was not compatible with the
 current version of their viewer.  Any advice on how to view the various
 board layers?

 Thanks,
 Rich



 End of casper Digest, Vol 51, Issue 5
 *

Re: [casper] help: sofware register

[Wesley New]

Hi Miguel,

My suggestion would be to setup your default values for software registers
in an initial design config section of your software.

Regards

Wesley

On Mon, May 30, 2011 at 11:41 PM, Miguel migu...@gmail.com wrote:

  Hi everybody,
 It is possible set a software register with a default value different from
 0?

[casper] ROACH DDR2 Supply Issue: Solved

[Wesley New]

As many of you will know the DDR2 modules which are have, up till now, been
supplied with ROACH are no longer being manufactured and Digicom's supply
has been running low.

A new DIMM, with long-term, support has been sourced from Viking Modular.
This DIMM will work in both the PPC and FPGA slots.

For more information and testing instructions see:
http://casper.berkeley.edu/wiki/ROACH_DDR2_Memory_Modules

Regards

Wesley New

Re: [casper] casper Digest, Vol 39, Issue 10

[Wesley New]

Hi Chao-Te

As for your 2nd point. I have updated the tut2.py script to fix the
programming issue.

Turns out when there is no boffile specified in the arguments, it passed an
empty string to the progdev function.'

An svn update should solve this issue now.

Regards

Wesley

On Tue, Feb 15, 2011 at 9:28 AM, Chao-Te Li c...@asiaa.sinica.edu.twwrote:

 Hi everyone,

 I have been running the tutorials again. as for tut2,
 I found out some interesting things as follows -

 1. I can run every command in tut2.py thru ipython except
 fpga.tap_start('tap0',rx_core_name,mac_base+dest_ip,dest_ip,fabric_port)
 and

 fpga.tap_start('tap3',tx_core_name,mac_base+source_ip,source_ip,fabric_port)

 I need to remove 'tap0' and 'tap3' for the commands to work. am I using
 an old version of tgtap? but I have updated the file system as described at
 http://www.mail-archive.com/casper@lists.berkeley.edu/msg01370.html

 2. when running the python script (tut2.py), I can't get the device
 programmed. so I comment the command and program the device using katcp.
 and I need to modified the tap-start commands as well.

 3. I found out I can't run tut2 consecutively, the 2nd time I always get
 something like TX overflow and TX almost full. is there a way to get around
 this problem? like clear the tx buffer? at the moment, I need to kill the
 process and re-program the device.

 does anyone have idea about these problems?
 Thanks a lot,

 Chao-Te


 --
 Open WebMail Project (http://openwebmail.org)


 -- Original Message ---
 From: casper-requ...@lists.berkeley.edu
 To: casper@lists.berkeley.edu
 Sent: Sun, 13 Feb 2011 12:55:44 -0800
 Subject: casper Digest, Vol 39, Issue 10

  Send casper mailing list submissions to
casper@lists.berkeley.edu
 
  To subscribe or unsubscribe via the World Wide Web, visit
 
 https://calmail.berkeley.edu/manage/list/listinfo/casper@lists.berkeley.edu
 
  or, via email, send a message with subject or body 'help' to
casper-requ...@lists.berkeley.edu
 
  You can reach the person managing the list at
casper-ow...@lists.berkeley.edu
 
  When replying, please edit your Subject line so it is more specific
  than Re: Contents of casper digest...
 
  Today's Topics:
 
 1. 550MSa/sec 12-bit ADC test design (Peter McMahon)
 
  --
 
  Message: 1
  Date: Sat, 12 Feb 2011 04:51:31 -0800
  From: Peter McMahon pe...@dotnet.za.net
  Subject: [casper] 550MSa/sec 12-bit ADC test design
  To: casper@lists.berkeley.edu
  Message-ID: 144101cbcab3$95977940$c0c66bc0$@za.net
  Content-Type: text/plain; charset=us-ascii
 
  Hi everyone,
 
  Sorry to bother everyone again. I'm trying to get a 550MSa/sec 12-
  bit ADC board to work with my ROACH. The data I'm getting out
  doesn't make sense, so I'm in the process of figuring out which of
  my board, design, data interpretation and/or wiring is faulty.
 
  To eliminate the possibility that my problems are caused by my
  having done something really stupid in my design, I'd like to try
  out a known good design. Does anyone have a test design for the 12-
  bit ADC available that I could use? (I have an LX110 FPGA, so I'd
  probably need to recompile it, rather than just use the existing
  binary.)
 
  Thanks,
 
  Peter
 
  -- next part --
  An HTML attachment scrubbed and removed.
  HTML attachments are only available in MIME digests.
 
  End of casper Digest, Vol 39, Issue 10
  **
 --- End of Original Message ---