[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&utm_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)?
>>>>>

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&utm_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&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "casper@lists.berkeley.edu"  group.
> To unsubscribe from this gr

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&utm_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&utm_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] Booting SKARAB

[Wesley New]

Hi Amit,

There is currently not firmware that supports static IP, this could be
changed with a few small modifications to the microblaze code and a
recompile of the microblaze, but I would recommend using DHCP where at all
possible. It should be an easy process to setup a DHCP server on your
laptop or the server that the SKARAB connects to.

Once you have an IP address you will want to change the firmware to the
latest CASPER firmware which will allow your board to be programmed over
the 40gbe as well as provide range of other features. This can be done
using the software Peralex supplied with the board or you can use our linux
port of that (Mail me and Ill give you access to the github repository) The
latest firmware bit streams can be found at
https://github.com/ska-sa/skarab_bsp_images.

Please give the wikipage a read
https://github.com/casper-astro/casper-hardware/wiki/SKARAB#Board_Support_Package

And as always, drop us a mail on the mailing list if you need any support.

Regards

Wes




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



On Wed, Dec 20, 2017 at 8:15 PM, Clifford van Dyk 
wrote:

> Hi Amit
>
> Your Skarab would have been shipped with a firmware that supports DHCP on
> all GbE interfaces and bootloading over 1GbE (only). It includes support
> for the ADC mezzanine. You will probably need to use the Peralex BSP tools
> to access and boot the Skarab over 1GbE, rather than the CASPER toolflow.
>
> If you would like to work with the CASPER tools, then you will need to
> overwrite the Peralex boot image with the CASPER boot image. This will
> provide additional support for booting the Skarab over 40GbE, but you will
> loose support for the ADC. The ADC firmware is currently provided as HDL
> code only-it has yet to be ported into a CASPER yellow block.
>
> I will pop by the office tomorrow to provide you with a link where you can
> download the Peralex BSP.
>
> Kind regards,
> Clifford
>
> On 20 Dec 2017 6:05 PM, "Amit Bansod"  wrote:
>
>> Dear All,
>>
>> I am trying to boot SKARAB and the it gets stuck at "ARP ENTRY ID:0
>> IP:". Is there any way to force a static ip address or boot via 1GbE
>> interface as well ?
>>
>> Many Thanks!
>>
>> Regards,
>> Amit
>>
>> --
>> 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.
>

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

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 
>> 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  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
>>>> things. And if it's DHC

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

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

Sorry, that is page 49 and 50.

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



On Wed, Jun 15, 2016 at 11:25 AM, Wesley New  wrote:

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

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

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

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] 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] QDR vs DDR3 for new board

[Wesley New]

Aspw
On 21 Aug 2014 23:19, "Matt Strader"  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  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 
> > Subject: [casper] T1E problem is back
> > To: Alejandro Saez , casper list
> >  
> > 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 
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 
> exit_fail()
>   File "spectrometer_64bits_float_s12_dif_ed_sin_acc_data_upper_low3.py",
> line 160, in 
> 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  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"  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 :
>
>> when you say it doesn't do anything...?
>>
>> It errors out? hangs? closes immediately? something else?
>>
>> On 12 May 2014 20:02, Rolando Paz  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 :
>> >
>> >> 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"  wrote:
>> >>>
>> >>> Hi everyone.
>> >>>
>> >>> Someone managed to install ISE 14.7 in ubuntu 12.04?
>> >>>
>> >>> Best Regards
>> >>>
>> >>> Rolando Paz
>> >
>> >
>>
>
>

Re: [casper] determining running bof file from tcpborphserver?

[Wesley New]

just check the processes running and the boffile should be listed there.

ps aux | grep 

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




On Fri, Feb 21, 2014 at 4:23 PM, Paul Marganian  wrote:

> Hi everyone,
> Does the tcpborphserver provide any means of determining what the current
> running bof file is?
> Thanks
> Paul
>
>
>

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  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.  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. 
> 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  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 
> post<http://www.mail-archive.com/casper@lists.berkeley.edu/msg02970.html>from 
> 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]

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  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)" 
> 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]

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)"  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] Ten Gigabit Ethernet Pcores

[Wesley New]

Thanks Glenn, I have chatted to Jason and we wont remove it. It is just
that the naming doesnt make sense and is confusing at times (kat_ten_gbe).
I might rename it at a later stage but this shouldn't affect existing
designs as it would be underneath the yellow block.

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




On Tue, Oct 29, 2013 at 4:03 PM, G Jones  wrote:

> Is there a compelling reason to remove it? If I recall, this version
> relies on the non-free Xilinx TGE core underneath. It uses a bit more
> resources, but is also much more forgiving about spacing between
> packets etc. I found it nice to use in the past, though I have
> switched over to the new core for new designs.
> Glenn
>
> On Tue, Oct 29, 2013 at 10:00 AM, Wesley New  wrote:
> > Hi all,
> >
> > It seems that we have multiple TGE cores in the yellow block library and
> am
> > interested to see if anyone still uses the first version of the core (For
> > ROACH1, it currently doesnt support ROACH2). Please let me know if you
> do,
> > as I am thinking about removing it. If there are good reasons not to,
> also
> > please let me know.
> >
> >
> > Wesley New
> > South African SKA Project
> > +2721 506 7365
> > www.ska.ac.za
> >
> >
>

[casper] Ten Gigabit Ethernet Pcores

[Wesley New]

Hi all,

It seems that we have multiple TGE cores in the yellow block library and am
interested to see if anyone still uses the first version of the core (For
ROACH1, it currently doesnt support ROACH2). Please let me know if you do,
as I am thinking about removing it. If there are good reasons not to, also
please let me know.


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

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  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"  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" 
> 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] MMAP on Roach-1

[Wesley New]

Hi Ross,

The coreinfo.tab file serves only to tell borph there the registers are
located, so changing it would only give borph the wrong mapping. These
registers are hard-coded in the HDL in the
sys_block<https://github.com/ska-sa/mlib_devel/blob/master/xps_base/XPS_ROACH2_base/pcores/sys_block_v1_00_a/hdl/verilog/sys_block.v>.
Why do you need to change these addresses?

To change them you would need to modify the HDL and the coreinfo.tab (if
you wanted access to them, by name, from borph) and then ensure that the
BASE_ADDR and HIGH_ADDR parameters are set correctly. Be aware that this
might cause multiple devices to be mapped to the same space and go BOOM!
Probably only when you try to access that address ;)

Wes

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




On Tue, Oct 22, 2013 at 3:04 AM, Ross Williamson <
rwilliam...@astro.caltech.edu> wrote:

> Hi Wes and all,
>
> So the MMAP is working really quite well on a ROACH-1 - This question
> is more my lack of understanding of the tool-chain.
>
> Does anybody know how to fix the memory address for the various CASPER
> brams and registers. I edited the core_info.tab inside the copied
> XPS_ROACH_BASE and unchecked "Copy base package" but It still was
> overwritten (I'm assuming this is in the system generator stage).  I'd
> rather not hack the top level core_info.tab so what would be the best
> way to define the memory locations?
>
> Ross
>
> On Tue, Oct 15, 2013 at 4:48 PM, Ross Williamson
>  wrote:
> > Hi Wes,
> >
> > Thanks - I got the MMAP up and running on a ROACH1 with those
> instructions.
> >
> > R
> >
> > On Tue, Oct 15, 2013 at 12:19 AM, Wesley New  wrote:
> >> Hi Ross,
> >>
> >> The steps should be outlined here.
> >> https://casper.berkeley.edu/wiki/FPGA_Device_Driver_Memo
> >>
> >> I am not sure if these steps work for ROACH1 and 2 but at least it is a
> >> starting point.
> >>
> >> Wes
> >>
> >> Wesley New
> >> South African SKA Project
> >> +2721 506 7365
> >> www.ska.ac.za
> >>
> >>
> >>
> >>
> >> On Tue, Oct 15, 2013 at 3:09 AM, Ross Williamson
> >>  wrote:
> >>>
> >>> Hi All,
> >>>
> >>> I know from the CASPER meeting that MMAP is available for the ROACH-1.
> >>> Are there any instructions anywhere on getting it up and running?
> >>>
> >>> Best regards,
> >>>
> >>> Ross
> >>>
> >>> --
> >>> Ross Williamson
> >>> Research Scientist - Sub-mm Group
> >>> California Institute of Technology
> >>> 626-395-2647 (office)
> >>> 312-504-3051 (Cell)
> >>>
> >>
> >
> >
> >
> > --
> > Ross Williamson
> > Research Scientist - Sub-mm Group
> > California Institute of Technology
> > 626-395-2647 (office)
> > 312-504-3051 (Cell)
>
>
>
> --
> Ross Williamson
> Research Scientist - Sub-mm Group
> California Institute of Technology
> 626-395-2647 (office)
> 312-504-3051 (Cell)
>

Re: [casper] MMAP on Roach-1

[Wesley New]

Hi Ross,

The steps should be outlined here.
https://casper.berkeley.edu/wiki/FPGA_Device_Driver_Memo

I am not sure if these steps work for ROACH1 and 2 but at least it is a
starting point.

Wes

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




On Tue, Oct 15, 2013 at 3:09 AM, Ross Williamson <
rwilliam...@astro.caltech.edu> wrote:

> Hi All,
>
> I know from the CASPER meeting that MMAP is available for the ROACH-1.
> Are there any instructions anywhere on getting it up and running?
>
> Best regards,
>
> 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  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"  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  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
>> >
>> >
>>
>>

[casper] ROACH TGE Multicast

[Wesley New]

Hi all,

I am looking at implementing multicasting on the Ten Gig Ethernet cores for
ROACH. Has anyone looked at doing this before or even implemented it and
not committed it to the CASPER repo? Any comments and suggestions would be
welcome.

Thanks

Wes


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

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

[Wesley New]

Would you guys be able to put together a spep by step guide to setting up
the tools on a windows machine, that we can put on the wiki?
On 21 Aug 2013 19:22, "Kujawski, Joseph"  wrote:

> Yan,
>
>
> Thank you for your input.  I found that both changes had to be made or the
> program would fail to compile properly.  Once these changes are made,
> however, I can generate .bit and .bin files along with a message indicating
> that the simple tutorial model generated properly.
>
> -Joe Kujawski
>
>
> On Tue, Aug 20, 2013 at 2:40 AM, Zhu, Yan  wrote:
>
>> I had a working copy of Matlab2012b, ISE14.4 on windows 7 sp1 64bit, and
>> ska-sa library compiled successfully, with only slight modification in OS
>> checking code in gen_xps_file.m.
>>
>> The error message, as Wesley said, is just a warning and does not
>> influence following process. Ignore it or manually add your ISE version
>> string into version checking code in casper_xps.m.
>>
>> Below are diffs of my modification against ska-sa master branch:
>>
>> diff --git a/xps_library/gen_xps_files.m b/xps_library/gen_xps_files.m
>> index 05e2392..6d07508 100644
>> --- a/xps_library/gen_xps_files.m
>> +++ b/xps_library/gen_xps_files.m
>> @@ -72,6 +72,10 @@ if s ~= 0
>>  fprintf('Detected Unknown Windows-like OS');
>>end
>>system_os = 'windows';
>> +elseif ~isempty(regexpi(w,'windows','ONCE'))
>> +  slash = '/';
>> +  disp(sprintf('Detected Windows OS'));
>> +  system_os = 'windows';
>>  elseif ~isempty(regexp(w, 'Linux', 'ONCE')),
>>slash = '/';
>>fprintf('Detected Linux OS');
>>
>>
>> diff --git a/xps_library/casper_xps.m b/xps_library/casper_xps.m
>> index f02096c..e51b178 100644
>> --- a/xps_library/casper_xps.m
>> +++ b/xps_library/casper_xps.m
>> @@ -66,7 +66,7 @@ if nargin == 0  % LAUNCH GUI
>>  set(handles.xsg_version,'String','14.2');
>>  case {'14.3'}
>>  set(handles.xsg_version,'String','14.3');
>> -case {'14.4'}
>> +case {'14.4', '14.4.4541'}
>>  set(handles.xsg_version,'String','14.4');
>>  otherwise
>>  errordlg(['Unsupported Xilinx System Generator version:
>> ',xsg]);
>>
>>
>>
>> Good luck,
>>
>> Yan
>>
>>
>> 发件人: casper-bounces+zhuyan=nao.cas...@lists.berkeley.edu [mailto:
>> casper-bounces+zhuyan=nao.cas...@lists.berkeley.edu] 代表 Laura
>> Vertatschitsch
>> 发送时间: 2013年8月20日 4:28
>> 收件人: Mark Wagner
>> 抄送: Kujawski, Joseph; casper list
>> 主题: Re: [casper] Setting up CASPER tools on a Windows machine
>>
>> Might not solve your problem exactly, but a virtual machine with windows
>> host, red hat guest might work well.
>>
>> On Mon, Aug 19, 2013 at 1:21 PM, Mark Wagner 
>> wrote:
>> Hi Joseph,
>>
>> I don't think Matlab 2013 is supported by Xilinx 14.5 or 14.6 yet:
>>
>> http://www.xilinx.com/support/answers/56250.html
>>
>> Mark
>>
>> On Mon, Aug 19, 2013 at 1:17 PM, Wesley New  wrote:
>> 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"  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_2012bas
>>  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
>> **
>>
>>
>>
>>
>>
>>
>
>
> --
> **
> * 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] 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"  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- 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  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" 
> > To: "Timothy Madden" 
> > 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] 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  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] one on one

[Wesley New]

Hi David,

I would suggest coming to the CASPER workshop in Manchester this September.
I know entrance closed a while ago, but maybe they can make an exception.
There is going to be a week of tutorial sessions in the afternoons where
there will be "Experts" on hand to help you out with your problems.

I would firstly try setting up your compile system using Ubuntu 12.04 (My
recommendation) and following these steps:
https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.5_and_Matlab_2012bwhich
are specifically for Ubuntu.

If you follow these and the licences are all setup correctly then the tools
should compile the latest tutorials here:
https://github.com/casper-astro/tutorials_devel running using the
https://github.com/ska-sa/mlib_devel (This is what we tested them against
for the recent South African Mini CASPER Workshop)

The tutorials will be in a better state by the end of the month as we are
busy getting them ready for the Workshop. We will also be pushing a whole
lot of updates to the CASPER mlib_devel repo around then.

Let me know if you have issues setting up the tools and getting the tuts
compiled.

regards

Wes

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




On Sat, Aug 17, 2013 at 4:42 PM, David Saroff  wrote:

> vCasper folks,
>
> Is there any mechanism for the beginner to get one on one time with a
> CASPER expert? I'm making no headway. Is it me or do the tutorials not
> compile? A yellow block I need for roach2 exists only for roach1, or am I
> doing something wrong again?
>
> How does the community handle this? The experts where I am are overloaded
> with work, and can not do the hand holding that I need to get started.
>
> I estimate that ~10 hours would be enough, and I would propose to meet for
> one hour, I watch and take notes, reproduce what the expert has done and
> retype my notes, and try to make more progress myself for the rest of the
> day, then meet again for an hour the next day.
>
> I could come to you. My desktop computer has all the tools, and I would
> prefer to use it, who knows, it may not be set up correctly, and that
> would be the first think to fix. It is luggable.
>
> We could skype and screenshare. I use that for teaching remotely one on
> one. I like the screensharing program "TeamViewer".
>
> Do novice CASPERites make a pilgrimage to Berkely? Who would I talk to
> about that?
>
> main topics
> 1) the tutorials that I can't make compile
> 2) adapting yellow blocks from roach1 to roach2
> 3) black boxes
> 4) what I don't know that I don't know that I don't know!
>
> Target: a back end for a Greenbank telescope phased array. 38 antennas at
> the prime focus, in L band separately digitized will be combined and
> correlated to put 7 or more beams on the sky. Fun! The 64ADC64-12 ADC is
> being used, with 1 roach1 and 3 roach2's available to process its
> digitizations.
>
> David
>
>
>

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

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  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] 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  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  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 wrote:
>
>> 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"  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] Two Different ADC Blocks in One Model

[Wesley New]

Hi Ron.

While it is possible to use 2 different adcs, I am not sure if the scripts
will put it together properly.

You might have to manually edit the ucf and mhs files.

I havent tested this myself.

Wes
On 11 Jun 2013 23:58,  wrote:

> I am doing something I thought I would
> never do. I am trying to build a model
> spectrometer that uses two different
> ADC blocks--an iADC block and a adc83000
> ADC block. I have been warned that this
> would be a problem if I ever tried it.
> When I compile, I get the "adc... PORT
> declared again!" error message.
>
> Can two dislike ADC blocks like these be
> combined into the same model? How do I
> eliminate the error?
>
>
>
>

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

On Tue, Mar 26, 2013 at 10:48 AM,  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,  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,  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]

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,  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] run_xps.tcl specified with -scr

[Wesley New]

Hi Katherine,

I think your problem might be that gmake isnt a recognized command in your
bash shell.

Have a look at the last point on the tools setup page

"Point gmake to make by creating the symbolic link gmake -> make:
cd /usr/bin/
sudo ln -s make gmake"

Regards

Wesley


On Fri, Mar 22, 2013 at 8:47 PM, katherine viviana cortes urbina <
kattycort...@gmail.com> wrote:

> Hi All,
>
> I have installed the new toolflow having Matlab 2012b and Xilinx 14.4,
> adding also the removed pcores available form your repository.
>
> running the casper_xps the tut3.slx   I got one error message:
>
>
> 
> gmake: *** [implementation/system.bit] Error 1
> ERROR:EDK -
>Error while running "gmake -f system.make bits".
> Error using gen_xps_files (line 644)
>
> when I open gen_xps_files in the line 644
>
>eval(['cd ',xps_path]);
> status = system(['xps -nw -scr run_xps.tcl
> system.xmp']);
>  if status ~= 0
>cd(simulink_path);
> line 644 error('XPS failed.');
>
>
> if I run the line status = system(['xps -nw -scr run_xps.tcl system.xmp'])
> in terminal the matlab I see:
>
>
> Xilinx Platform Studio
> Xilinx EDK 14.4 Build EDK_P.49d
> Copyright (c) 1995-2012 Xilinx, Inc.  All rights reserved.
>
> XPS% Loading xmp file system.xmp
> ERROR:EDK - The given XMP file does not exist
>
> XPS% ERROR:EDK - File run_xps.tcl specified with -scr option not found
>
> status =
>
>  1
>
> any idea??
>
> Cheers
>
> katty
>
>

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  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  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 pin<7>r2case_event(): Got type 11, code 8, value 1
>> attempting led toggle
>> About to toggle cpu_rdy pin<7>r2case_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   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
wrote:

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

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

[Wesley New]

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

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

[Wesley New]

Thanks Dave,

If that is the case and you want to stay on those versions and still
compile for roach2. I would recommend pulling the latest libraries and
then try to get them working with the older tools. I can't think of
anything at the moment that would stop you from doing that. There
might be 1 or 2 tweeks to the tools that you would have to do.

Regards

Wes

On 3/12/13, David MacMahon  wrote:
> Hi, Wes,
>
> On Mar 12, 2013, at 2:39 AM, Wesley New wrote:
>
>> Why would you want to build will old tools anyway?
>
> I think some people would like to build with older tools because they have
> them but they don't have the newest tools. For some, the cost (in both time
> and money) of updating Matlab and Simulink twice a year is non-negligible.
> Updating the Xilinx tools may be less of an issue in terms of money.
>
> I could be wrong, but I imagine some people would prefer to keep their old
> Matlab and Simulink and System Generator versions, and do just the EDK part
> of the build with the latest Xilinx tools.
>
> Dave
>
>

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

[Wesley New]

Hi Guy,

The current casper_astro_mlib should doesn't support ROACH2 as the ROACH2
changes dont seem to have been pulled from SKA-SA. Why would you want to
build will old tools anyway?

The older Xilinx tools have issues with the clock managers (MMCMs) where
you can get instability problems when deploying your design. I would highly
recommend upgrading your design machine to 14.4 and matlab2012b.

Regards

Wes



On Tue, Mar 12, 2013 at 11:11 AM, Guy kenfack  wrote:

> Hi Marc,
> thank you for answer.
>
> Now I have another question from my 1st email, I did'nt have an answer. it
> is about the process to generate a boffile compatible with "roach2 and
> tcpborph3" using the 11.5 toolflow.
> I'd like to know if there is a trick , which can be used to generate a
> boffile with the current casper_astro_mlib or the old ska_sa_lib , which
> will be compatible with the roach2.
>
> regards,
>
>
>
>
>
>>
>> Roach2s which run tcpborphserver3 do not execute bof files,
>> they use tcpborphserver3 to program the FPGA using a device
>> file. So this is not an error. Use progdev to program the fpga,
>> or if you wish to use the commandline
>>
>> ~ # kcpcmd progdev r2_tut1_2013_Mar_07_0837.bof
>>
>> regards
>>
>> marc
>>
>
>

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

> 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] compiling tut.3, Error running Dot.

[Wesley New]

Hi Kaz,

I seem to remember having the same issue and the design would still compile
even though it threw up these errors.  I guess it is a "non-fatal" error.

Does the design compile through?

Wes

On Thu, Nov 1, 2012 at 2:01 PM, Kazunari Maeda wrote:

> Hello Casper team
>
> I am very new for Matlab, Xilinx, and Casper. when I tried to run
> casper_xps w/ tut3.mdl. I  receive error messages:
>
> /opt/Xilinx/14.2/ISE_DS/ISE/sysgen/bin/lin64/dot/dot.bin error while
> loading shared libraries: libexpat.so.0: cannot open shared object file: No
> such file or directory
> Error running Dot.
>
> I have no idea what I can do this problem. I saw a similar problem in mail
> archive,
> http://www.mail-archive.com/casper@lists.berkeley.edu/msg03327.html
> However, it did not solve my problem. I don't have Xilinx 13.4. Please
> help.
>
> Kaz
>
> --
> Maeda Kazunari (Kagoshima University)
> Address: 1-21-35 Korimoto, Kagoshima
>   890-0065, Japan
> Phone and Fax: +81-99-285-8963
> Mobile: +81-80-3966-5613
> -
>

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

> The following web page lists two memory modules for use in the ROACH2:
>
> https://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
>
>
>
>
>

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

[Wesley New]

It is a pleasure.

Out of interest, what version of Matlab and ISE are you using?

On Wed, Oct 24, 2012 at 8:14 PM, Nestor Lasso Cabrera
wrote:

> Hi Wesley,
>
> changing the symbolink links for the sh and the make as indicated in the
> wike made the trick . Everything is running now.
>
> Thank you very much for your help.
>
> Nestor
>
> - Original Message -
> From: Wesley New [mailto:wes...@ska.ac.za]
> To: Nestor Lasso Cabrera [mailto:nes...@astro-udec.cl]
> Cc: casper@lists.berkeley.edu
> Sent: Wed, 24 Oct 2012 11:33:42 -0300
> Subject: Re: [casper] System generator error: INFO:Security:56 - Part
> 'xc5vsx95t' is not a WebPack part.
>
>
> > Hi Nestor,
> >
> > Check out this
> > wikipage<
> https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.2_and_Matlab_2012a
> >
> >
> > I am assuming you are using Ubuntu?
> >
> > 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
> >
> > Regards
> >
> > Wes
> >
> >
> > On Wed, Oct 24, 2012 at 5:28 PM, Nestor Lasso Cabrera
> > wrote:
> >
> > > Hi again,
> > >
> > > I update the license and it seems that I have gone a step forward but
> not
> > > to the end. Now, after the system generator start working I get the
> > > following error:
> > >
> > > 
> > > standard exception: XNetlistEngine:
> > > An exception was raised:
> > > com.xilinx.sysgen.netlist.NetlistInternal: couldn't open first pass
> text
> > > file at
> > >
> >
> /scratch/udec/roach/tut1/tut1/sysgen/sysgen/masterScript1959863424383808226.pl
> > > line 473
> > > ********
> > >
> > > By the way I'm using Xilinx System Edition, not the webpack. I think I
> > > should be able to run the casper's tutorials for the ROACH with it,
> right?
> > > or do I need specifically the DSP Edition?
> > >
> > > Thanks for your help,
> > >
> > > Nestor Lasso
> > >
> > >
> > > - Original Message -
> > > From: Wesley New [mailto:wes...@ska.ac.za]
> > > To: Nestor Lasso Cabrera [mailto:nes...@astro-udec.cl],
> > > casper@lists.berkeley.edu
> > > Sent: Mon, 22 Oct 2012 17:24:18 -0300
> > > Subject: Re: [casper] System generator error: INFO:Security:56 - Part
> > > 'xc5vsx95t' is not a WebPack part.
> > >
> > >
> > > > 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  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:
> > > > >
> > > > > ***
&

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

[Wesley New]

Hi Nestor,

Check out this 
wikipage<https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.2_and_Matlab_2012a>

I am assuming you are using Ubuntu?

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

Regards

Wes


On Wed, Oct 24, 2012 at 5:28 PM, Nestor Lasso Cabrera
wrote:

> Hi again,
>
> I update the license and it seems that I have gone a step forward but not
> to the end. Now, after the system generator start working I get the
> following error:
>
> 
> standard exception: XNetlistEngine:
> An exception was raised:
> com.xilinx.sysgen.netlist.NetlistInternal: couldn't open first pass text
> file at
> /scratch/udec/roach/tut1/tut1/sysgen/sysgen/masterScript1959863424383808226.pl
> line 473
> 
>
> By the way I'm using Xilinx System Edition, not the webpack. I think I
> should be able to run the casper's tutorials for the ROACH with it, right?
> or do I need specifically the DSP Edition?
>
> Thanks for your help,
>
> Nestor Lasso
>
>
> - Original Message -
> From: Wesley New [mailto:wes...@ska.ac.za]
> To: Nestor Lasso Cabrera [mailto:nes...@astro-udec.cl],
> casper@lists.berkeley.edu
> Sent: Mon, 22 Oct 2012 17:24:18 -0300
> Subject: Re: [casper] System generator error: INFO:Security:56 - Part
> 'xc5vsx95t' is not a WebPack part.
>
>
> > 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  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_lic

[casper] Toolflow: Supported Versions

[Wesley New]

Good Day Casperites,

Since the release of the upgraded
librariesto 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
libraries (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
here
.

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  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] System generator error: INFO:Security:56 - Part 'xc5vsx95t' is not a WebPack part.

[Wesley New]

Hi Nestor,

We use the Xilinx DSP and not the webpack, this will require a Xilinx licence.

Regards

Wes

On 10/22/12, Nestor Lasso Cabrera  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]

ase/system.mhs line 70 -
>floating connection!
> WARNING:EDK:2099 - PORT:aux1_clk180 CONNECTOR:aux1_clk180 -
>/home/ROACH/Desktop/Tut3/Katty/led/XPS_ROACH_base/system.mhs line 71 -
>floating connection!
> WARNING:EDK:2099 - PORT:aux1_clk270 CONNECTOR:aux1_clk270 -
>/home/ROACH/Desktop/Tut3/Katty/led/XPS_ROACH_base/system.mhs line 72 -
>floating connection!
> WARNING:EDK:2099 - PORT:aux0_clk2x CONNECTOR:aux0_clk2x -
>/home/ROACH/Desktop/Tut3/Katty/led/XPS_ROACH_base/system.mhs line 73 -
>floating connection!
> WARNING:EDK:2099 - PORT:aux0_clk2x90 CONNECTOR:aux0_clk2x90 -
>/home/ROACH/Desktop/Tut3/Katty/led/XPS_ROACH_base/system.mhs line 74 -
>floating connection!
> WARNING:EDK:2099 - PORT:aux0_clk2x180 CONNECTOR:aux0_clk2x180 -
>/home/ROACH/Desktop/Tut3/Katty/led/XPS_ROACH_base/system.mhs line 75 -
>floating connection!
> WARNING:EDK:2099 - PORT:aux0_clk2x270 CONNECTOR:aux0_clk2x270 -
>/home/ROACH/Desktop/Tut3/Katty/led/XPS_ROACH_base/system.mhs line 76 -
>floating connection!
> WARNING:EDK:2099 - PORT:idelay_rdy CONNECTOR:idelay_rdy -
>/home/ROACH/Desktop/Tut3/Katty/led/XPS_ROACH_base/system.mhs line 79 -
>floating connection!
> WARNING:EDK:2099 - PORT:soft_reset CONNECTOR:soft_reset -
>/home/ROACH/Desktop/Tut3/Katty/led/XPS_ROACH_base/system.mhs line 161 -
>floating connection!
>
> Performing Clock DRCs...
>
> Performing Reset DRCs...
>
> Overriding system level properties...
>
> Running system level update procedures...
>
> Running UPDATE Tcl procedures for OPTION SYSLEVEL_UPDATE_PROC...
>
> Running system level DRCs...
>
> Performing System level DRCs on properties...
>
> Running DRC Tcl procedures for OPTION SYSLEVEL_DRC_PROC...
>
> Running UPDATE Tcl procedures for OPTION PLATGEN_SYSLEVEL_UPDATE_PROC...
>
> Modify defaults ...
>
> Creating stub ...
>
> Processing licensed instances ...
> Completion time: 0.00 seconds
>
> Creating hardware output directories ...
>
> Managing hardware (BBD-specified) netlist files ...
> IPNAME:led INSTANCE:led_xsg_core_config -
> /home/ROACH/Desktop/Tut3/Katty/led/XPS_ROACH_base/system.mhs line 172 -
> Copying
> (BBD-specified) netlist files.
>
> Managing cache ...
>
> Elaborating instances ...
>
> Writing HDL for elaborated instances ...
>
> Inserting wrapper level ...
> Completion time: 0.00 seconds
>
> Constructing platform-level connectivity ...
> Completion time: 0.00 seconds
>
> Writing (top-level) BMM ...
>
> Writing (top-level and wrappers) HDL ...
>
> Generating synthesis project file ...
> ERROR:EDK:1405 - File not found in any repository
>'opb_arbiter_v1_02_e/hdl/vhdl/opb_arb_pkg.vhd'
> ERROR:EDK:1405 - File not found in any repository
>'opb_arbiter_v1_02_e/hdl/vhdl/or_muxcy.vhd'
> ERROR:EDK:1405 - File not found in any repository
>'opb_arbiter_v1_02_e/hdl/vhdl/mux_onehot.vhd'
> ERROR:EDK:1405 - File not found in any repository
>'opb_arbiter_v1_02_e/hdl/vhdl/or_bits.vhd'
> ERROR:EDK:1405 - File not found in any repository
>'opb_arbiter_v1_02_e/hdl/vhdl/or_gate.vhd'
> ERROR:EDK:1405 - File not found in any repository
>'opb_arbiter_v1_02_e/hdl/vhdl/priority_reg.vhd'
> ERROR:EDK:1405 - File not found in any repository
>'opb_arbiter_v1_02_e/hdl/vhdl/onehot2encoded.vhd'
> ERROR:EDK:1405 - File not found in any repository
>'opb_arbiter_v1_02_e/hdl/vhdl/arbitration_logic.vhd'
> ERROR:EDK:1405 - File not found in any repository
>'opb_arbiter_v1_02_e/hdl/vhdl/park_lock_logic.vhd'
> ERROR:EDK:1405 - File not found in any repository
>'opb_arbiter_v1_02_e/hdl/vhdl/watchdog_timer.vhd'
> ERROR:EDK:1405 - File not found in any repository
>'opb_arbiter_v1_02_e/hdl/vhdl/arb2bus_data_mux.vhd'
> ERROR:EDK:1405 - File not found in any repository
>'opb_arbiter_v1_02_e/hdl/vhdl/control_register_logic.vhd'
> ERROR:EDK:1405 - File not found in any repository
>'opb_arbiter_v1_02_e/hdl/vhdl/ipif_regonly_slave.vhd'
> ERROR:EDK:1405 - File not found in any repository
>'opb_arbiter_v1_02_e/hdl/vhdl/priority_register_logic.vhd'
> ERROR:EDK:1405 - File not found in any repository
>'opb_arbiter_v1_02_e/hdl/vhdl/opb_arbiter_core.vhd'
> ERROR:EDK:1405 - File not found in any repository
>'opb_arbiter_v1_02_e/hdl/vhdl/opb_arbiter.vhd'
> ERROR:EDK:440 - platgen failed with errors!
> gmake: *** [implementation/system.bmm] Error 2
> ERROR:EDK -
>Error while running "gmake -f system.make bits".
>
> Error using ==> gen_xps_files at 673
> XPS failed.
>
> Sa

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]

;>>>> On Fri, Oct 5, 2012 at 2:57 PM, Nimish Sane
>>>>> mailto:nimishs...@gmail.com>> wrote:
>>>>>
>>>>> 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
>>>>> mailto:and...@ska.ac.za>> wrote:
>>>>>
>>>>> 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
>>>>> > >>>> 
>>>>> <mailto:davidm@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
>>>>> >>>> 
>>>>> <mailto:rprimian@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<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<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]

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

> 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.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] 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] 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  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  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  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  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 
>>> 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 wrote:
>>>
>>>> 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 wrote:
>>>>
>>>>> 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
>>>>> >  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 
>>>>> > 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 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
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  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  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
>

[casper] Toolflow Updates

[Wesley New]

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

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