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

[Wesley New]

Hi Sean.

progska is a c utility that we use to speed up the programming of the
skarab boards and is not needed for the RP.


On Mon, 01 Jun 2020, 7:23 PM Sean Mckee,  wrote:

> Hi Jack,
>
> I did try installing casperfpga on the red pitaya, but it appears that one
> of the libraries (progska, if I recall correctly) requires 64-bit. It was
> giving me ELFCLASS64 error. Not sure if there's a work around, but I'm
> pretty comfortable writing C code to run on the red pitaya to manage the
> registers, so that's the direction I've gone.
>
> Thanks!
> Sean
>
> On Monday, June 1, 2020 at 3:59:13 AM UTC-6, Jack Hickish wrote:
>>
>> Hi Sean,
>>
>> Just to explicitly add to wes's advice - in addition to the telnet
>> interface on localhost, you can "just" install full blown casperfpga to
>> your red pitaya, and connect via localhost using the scripts you already
>> have. Unless your performance requirements are such that python is out of
>> the question, this is probably the easiest thing to do.
>>
>> Cheers
>> Jack
>>
>>
>> On Sun, 31 May 2020, 10:45 pm Sean Mckee,  wrote:
>>
>>> Hi Wesley,
>>>
>>> Thank you, that's what I was looking for!
>>>
>>> On Sunday, May 31, 2020 at 12:54:31 PM UTC-6, wesley wrote:

 Hi Sean,

 These are all good questions and Ill try to point you in the right
 direction.

 So if you followed this tutorial to setup your red pitaya:
 https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html#running-the-script-on-a-preloaded-rp-sd-card
 You should have tcpborphserver installed on the PS. You can telnet into
 tcpborphserver and issue register read and writes that way. ie you could
 telnet into tcpborphserver on localhost form the RP using a python script
 and run your tasks that way. If I remember correctly tcpboprhserver can
 address a register by name so you shouldnt need to worry about memory maps,
 but if you are you can look at the fpg file that you uploaded and the
 header will contain the memory map. You can also see the memory map in a
 file called coreinfo.tab in your build directory.

 Hope this helps.

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




 On Sun, May 31, 2020 at 7:56 PM Sean Mckee 
 wrote:

> Hi all,
>
> I'm trying to determine how I would go about finding/using the
> addresses of the memory mapped registers being used by the FPGA, from the
> PS side of the Red Pitaya. For example, in the spectrometer tutorial, 
> there
> are several registers used to control the design, and others to pull data
> out from the design. If I access the Red Pitaya from my computer using the
> casperfpga.py module, these registers are all conveniently named and the
> python module has tools to read data from snap blocks, write to the reset
> and trigger registers, etc.
>
> Is there a convenient way to have this same level of control on the
> red pitaya itself? I would like to write code that runs on the PS to
> monitor these registers and handle the data output. From what I can
> currently find, I will need to open the /dev/mem file and use the mmap()
> command. But how do I find out which physical register corresponds to 
> which
> simulink block? And I assume that even a minor update to the simulink
> design could result in the registers being moved around, so what is a good
> way to account for this?
>
> Currently, I am trying to trace what happens when I call casperfpga
> commands from my computer. I understand the parsing of the commands and 
> the
> hand off to tcpborphserver, but I can't seem to unravel what is happening
> when the red pitaya receives these commands. I'm assuming this code is
> somewhere in the katcp library (https://github.com/ska-sa/katcp)?
>
> Hopefully someone 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 "cas...@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to cas...@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
> 
> .
>
 --
>>> You received this message because you are subscribed to the Google
>>> Groups "cas...@lists.berkeley.edu" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to cas...@lists.berkeley.edu.
>>> To view this discussion on the web visit
>>> 

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

[Jack Hickish]

Hi Sean,

Sounds like you have everything under control, but FWIW that progska code
isn't needed except for the SKARAB. If it really is just that binary then
if you can coerce python to get past the install error, it won't impact
your ability to run on the pitaya.

Cheers
Jack

On Mon, 1 Jun 2020 at 18:23, Sean Mckee  wrote:

> Hi Jack,
>
> I did try installing casperfpga on the red pitaya, but it appears that one
> of the libraries (progska, if I recall correctly) requires 64-bit. It was
> giving me ELFCLASS64 error. Not sure if there's a work around, but I'm
> pretty comfortable writing C code to run on the red pitaya to manage the
> registers, so that's the direction I've gone.
>
> Thanks!
> Sean
>
> On Monday, June 1, 2020 at 3:59:13 AM UTC-6, Jack Hickish wrote:
>>
>> Hi Sean,
>>
>> Just to explicitly add to wes's advice - in addition to the telnet
>> interface on localhost, you can "just" install full blown casperfpga to
>> your red pitaya, and connect via localhost using the scripts you already
>> have. Unless your performance requirements are such that python is out of
>> the question, this is probably the easiest thing to do.
>>
>> Cheers
>> Jack
>>
>>
>> On Sun, 31 May 2020, 10:45 pm Sean Mckee,  wrote:
>>
>>> Hi Wesley,
>>>
>>> Thank you, that's what I was looking for!
>>>
>>> On Sunday, May 31, 2020 at 12:54:31 PM UTC-6, wesley wrote:

 Hi Sean,

 These are all good questions and Ill try to point you in the right
 direction.

 So if you followed this tutorial to setup your red pitaya:
 https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html#running-the-script-on-a-preloaded-rp-sd-card
 You should have tcpborphserver installed on the PS. You can telnet into
 tcpborphserver and issue register read and writes that way. ie you could
 telnet into tcpborphserver on localhost form the RP using a python script
 and run your tasks that way. If I remember correctly tcpboprhserver can
 address a register by name so you shouldnt need to worry about memory maps,
 but if you are you can look at the fpg file that you uploaded and the
 header will contain the memory map. You can also see the memory map in a
 file called coreinfo.tab in your build directory.

 Hope this helps.

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




 On Sun, May 31, 2020 at 7:56 PM Sean Mckee 
 wrote:

> Hi all,
>
> I'm trying to determine how I would go about finding/using the
> addresses of the memory mapped registers being used by the FPGA, from the
> PS side of the Red Pitaya. For example, in the spectrometer tutorial, 
> there
> are several registers used to control the design, and others to pull data
> out from the design. If I access the Red Pitaya from my computer using the
> casperfpga.py module, these registers are all conveniently named and the
> python module has tools to read data from snap blocks, write to the reset
> and trigger registers, etc.
>
> Is there a convenient way to have this same level of control on the
> red pitaya itself? I would like to write code that runs on the PS to
> monitor these registers and handle the data output. From what I can
> currently find, I will need to open the /dev/mem file and use the mmap()
> command. But how do I find out which physical register corresponds to 
> which
> simulink block? And I assume that even a minor update to the simulink
> design could result in the registers being moved around, so what is a good
> way to account for this?
>
> Currently, I am trying to trace what happens when I call casperfpga
> commands from my computer. I understand the parsing of the commands and 
> the
> hand off to tcpborphserver, but I can't seem to unravel what is happening
> when the red pitaya receives these commands. I'm assuming this code is
> somewhere in the katcp library (https://github.com/ska-sa/katcp)?
>
> Hopefully someone 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 "cas...@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to cas...@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
> 
> .
>
 --
>>> You received this message because you are subscribed to the Google
>>> Groups "cas...@lists.berkeley.edu" group.
>>> To unsubscribe from this group and 

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

[Sean Mckee]

Hi Jack,

I did try installing casperfpga on the red pitaya, but it appears that one 
of the libraries (progska, if I recall correctly) requires 64-bit. It was 
giving me ELFCLASS64 error. Not sure if there's a work around, but I'm 
pretty comfortable writing C code to run on the red pitaya to manage the 
registers, so that's the direction I've gone.

Thanks!
Sean

On Monday, June 1, 2020 at 3:59:13 AM UTC-6, Jack Hickish wrote:
>
> Hi Sean,
>
> Just to explicitly add to wes's advice - in addition to the telnet 
> interface on localhost, you can "just" install full blown casperfpga to 
> your red pitaya, and connect via localhost using the scripts you already 
> have. Unless your performance requirements are such that python is out of 
> the question, this is probably the easiest thing to do.
>
> Cheers
> Jack
>
>
> On Sun, 31 May 2020, 10:45 pm Sean Mckee,  > wrote:
>
>> Hi Wesley,
>>
>> Thank you, that's what I was looking for!
>>
>> On Sunday, May 31, 2020 at 12:54:31 PM UTC-6, wesley wrote:
>>>
>>> Hi Sean,
>>>
>>> These are all good questions and Ill try to point you in the right 
>>> direction.
>>>
>>> So if you followed this tutorial to setup your red pitaya: 
>>> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html#running-the-script-on-a-preloaded-rp-sd-card
>>> You should have tcpborphserver installed on the PS. You can telnet into 
>>> tcpborphserver and issue register read and writes that way. ie you could 
>>> telnet into tcpborphserver on localhost form the RP using a python script 
>>> and run your tasks that way. If I remember correctly tcpboprhserver can 
>>> address a register by name so you shouldnt need to worry about memory maps, 
>>> but if you are you can look at the fpg file that you uploaded and the 
>>> header will contain the memory map. You can also see the memory map in a 
>>> file called coreinfo.tab in your build directory.
>>>
>>> Hope this helps.
>>>
>>> Wesley New
>>> South African SKA Project
>>> +2721 506 7300
>>> www.ska.ac.za
>>>
>>>
>>>
>>>
>>> On Sun, May 31, 2020 at 7:56 PM Sean Mckee  wrote:
>>>
 Hi all,

 I'm trying to determine how I would go about finding/using the 
 addresses of the memory mapped registers being used by the FPGA, from the 
 PS side of the Red Pitaya. For example, in the spectrometer tutorial, 
 there 
 are several registers used to control the design, and others to pull data 
 out from the design. If I access the Red Pitaya from my computer using the 
 casperfpga.py module, these registers are all conveniently named and the 
 python module has tools to read data from snap blocks, write to the reset 
 and trigger registers, etc.

 Is there a convenient way to have this same level of control on the red 
 pitaya itself? I would like to write code that runs on the PS to monitor 
 these registers and handle the data output. From what I can currently 
 find, 
 I will need to open the /dev/mem file and use the mmap() command. But how 
 do I find out which physical register corresponds to which simulink block? 
 And I assume that even a minor update to the simulink design could result 
 in the registers being moved around, so what is a good way to account for 
 this?

 Currently, I am trying to trace what happens when I call casperfpga 
 commands from my computer. I understand the parsing of the commands and 
 the 
 hand off to tcpborphserver, but I can't seem to unravel what is happening 
 when the red pitaya receives these commands. I'm assuming this code is 
 somewhere in the katcp library (https://github.com/ska-sa/katcp)?

 Hopefully someone 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 "cas...@lists.berkeley.edu" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to cas...@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
  
 
 .

>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "cas...@lists.berkeley.edu " group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to cas...@lists.berkeley.edu .
>> To view this discussion on the web visit 
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/c4f0d757-d3ca-431f-b1de-f27392f68b3f%40lists.berkeley.edu
>>  
>> 

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

[Vereese Van Tonder]

On Mon, Jun 1, 2020 at 12:05 PM Marc  wrote:

> On Sun, May 31, 2020 at 6:54 PM Wesley New  wrote:
>
>
> > 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,
>
> There should be a ?listsdev command to give you the register mapping.
> Not sure if the red pitaya has kcpcmd installed, if it does type
>
Yes, I think kcpcmd should be installed along with tcpborphserver.

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


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

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

[Marc]

On Sun, May 31, 2020 at 6:54 PM Wesley New  wrote:


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

There should be a ?listsdev command to give you the register mapping.
Not sure if the red pitaya has kcpcmd installed, if it does type

  kcpcmd listdev

or

  kcpcmd help

regards

marc

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

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

[Jack Hickish]

Hi Sean,

Just to explicitly add to wes's advice - in addition to the telnet
interface on localhost, you can "just" install full blown casperfpga to
your red pitaya, and connect via localhost using the scripts you already
have. Unless your performance requirements are such that python is out of
the question, this is probably the easiest thing to do.

Cheers
Jack


On Sun, 31 May 2020, 10:45 pm Sean Mckee,  wrote:

> Hi Wesley,
>
> Thank you, that's what I was looking for!
>
> On Sunday, May 31, 2020 at 12:54:31 PM UTC-6, wesley wrote:
>>
>> Hi Sean,
>>
>> These are all good questions and Ill try to point you in the right
>> direction.
>>
>> So if you followed this tutorial to setup your red pitaya:
>> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html#running-the-script-on-a-preloaded-rp-sd-card
>> You should have tcpborphserver installed on the PS. You can telnet into
>> tcpborphserver and issue register read and writes that way. ie you could
>> telnet into tcpborphserver on localhost form the RP using a python script
>> and run your tasks that way. If I remember correctly tcpboprhserver can
>> address a register by name so you shouldnt need to worry about memory maps,
>> but if you are you can look at the fpg file that you uploaded and the
>> header will contain the memory map. You can also see the memory map in a
>> file called coreinfo.tab in your build directory.
>>
>> Hope this helps.
>>
>> Wesley New
>> South African SKA Project
>> +2721 506 7300
>> www.ska.ac.za
>>
>>
>>
>>
>> On Sun, May 31, 2020 at 7:56 PM Sean Mckee  wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to determine how I would go about finding/using the addresses
>>> of the memory mapped registers being used by the FPGA, from the PS side of
>>> the Red Pitaya. For example, in the spectrometer tutorial, there are
>>> several registers used to control the design, and others to pull data out
>>> from the design. If I access the Red Pitaya from my computer using the
>>> casperfpga.py module, these registers are all conveniently named and the
>>> python module has tools to read data from snap blocks, write to the reset
>>> and trigger registers, etc.
>>>
>>> Is there a convenient way to have this same level of control on the red
>>> pitaya itself? I would like to write code that runs on the PS to monitor
>>> these registers and handle the data output. From what I can currently find,
>>> I will need to open the /dev/mem file and use the mmap() command. But how
>>> do I find out which physical register corresponds to which simulink block?
>>> And I assume that even a minor update to the simulink design could result
>>> in the registers being moved around, so what is a good way to account for
>>> this?
>>>
>>> Currently, I am trying to trace what happens when I call casperfpga
>>> commands from my computer. I understand the parsing of the commands and the
>>> hand off to tcpborphserver, but I can't seem to unravel what is happening
>>> when the red pitaya receives these commands. I'm assuming this code is
>>> somewhere in the katcp library (https://github.com/ska-sa/katcp)?
>>>
>>> Hopefully someone 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 "cas...@lists.berkeley.edu" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to cas...@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
>>> 
>>> .
>>>
>> --
> 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/c4f0d757-d3ca-431f-b1de-f27392f68b3f%40lists.berkeley.edu
> 
> .
>

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

Re: [casper] SPEAD reference implementation?

[Jason Manley]

Hi Jan


>  There are mentions of SPEAD in for example the Simulink models. No actual 
> low-level nor high-level implementations though. Have checked OpenCores as 
> well. There is an SKA memo [1] that does mention implementations, but these 
> refer to Python/C++. Looking at the C++ code, it does not look fit for using 
> in HLS really... Wondering - are there public SPEAD implementations for FPGA 
> available somewhere?

I'm not aware of any HDL implementations.

MeerKAT's SPEAD TX and RX FPGA modules are essentially "hard coded" (well, 
somewhat compile-time parameterised) Simulink modules. If we receive a valid 
SPEAD packet that doesn't match what we expect (checking SPEAD header and Item 
IDs), we flag an error on the FPGA. So it doesn't support all the SPEAD 
features, like on-the-fly datastream redimensioning. The Science Data 
Processor's high performance C implementation doesn't support this, either, so 
we're comfortable with it. 

For the benefits of the mailing list, it's really only the Python PySPEAD 
module that supports all these things, and you pay a performance penalty there. 
SPEAD2, the C-accellerated version that's mostly in use now, allows for 
one-time configuration, and then allocates memory and beds that down, until the 
receiver is restarted (eg when the observation changes).

> an existing FPGA-based VLBI backend should be extended instead by the backend 
> firmware engineers, so that it can accept SPEAD-delivered raw sample data 
> over parallel 10G links. 

We did essentially the same thing on MeerKAT's early correlator, where we used 
4x10G links into a ROACH2, and then unpacked and buffered them into a single 
on-FPGA datastream. The F-engines received 36Gbps SPEAD data from our 
digitisers, and channelised this data, before retransmitting another SPEAD 
stream to the X-engines. So we had SPEAD RX and TX blocks in each FPGA. But, 
these were only partially parameterised, and they were written in Simulink. 
They were rather hastily cobbled together, but you're welcome to grab an 
example of an old ROACH2 designs here if you think they'd be of value:

https://github.com/ska-sa/mkat_fpga/blob/master/source/feng_wide/r2_c856m4k.slx
This uses a small BRAM for heap assembly. IIRC, there was some fiddling with 
byte/bit/word ordering in this design.

Or, the newer, simpler, SKARAB versions for 40G, here, which uses very large 
off-chip HMC memory buffers:
https://github.com/ska-sa/mkat_fpga/blob/master/source/xeng_wide/s_b4a4x1kf.slx

> Looking at the SPEAD rev 0 document, a transmitter would appear lightweight 
> to implement and seems quite FPGA-suited. A receiver looks somewhat more 
> challenging on FPGA, easy in C++/Python though. The complex bits if I see 
> correctly would be large buffering for Heap reconstruction,
This depends on how careful you are with your Heap partitioning. For our 
ADC-to-F, a heap is just a single packet, so it's trivial. For F-to-X, the 
heaps are larger. But we need buffer here anyway, to handle out-of-order 
network packet RX, so the cost is no more. We used to do this in BRAM on 
ROACH2s, but on SKARAB we have large, fast HMC available, so we use that.

> and an interpreter engine to cope with the varying order and length of the 
> 'ItemDescriptors' to be generic enough and avoid code maintenance if anything 
> on the other side ie transmitter side is upgraded/altered. Could also be I'm 
> mistaken, and a receiver is easy on FPGA? Would appreciate your input and 
> experiences on this matter! :-)
You have the right of it. So far, AFAIK, all FPGA implementations are "dumb" 
and search for values at known packet offsets. If the transmitter changes, we 
have to recompile with a new set of compile-time parameters. We manage this the 
old fashioned way with ICDs.

The SPEAD2 software receiver is a little smarter, and allows runtime 
programmability of dataset dimensions at startup, but not for these to change 
during data transmission. PySPEAD allows it to change anytime, IIRC, but nobody 
uses it to move high speed data around because it's too slow. I don't think 
it's maintained anymore, TBH.

Jason

-- 
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/C90333C6-D7C0-47CC-B148-928B8ACEB3EF%40ska.ac.za.