[casper] SKA: Signal Processing Engineer

[Michael D'Cruze]

FYI, this role has recently been advertised at SKAO: 
https://recruitment.skao.int/vacancy/signal-processing-engineer-504661.html

Best,
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/LO4P265MB615409BFD7FAFE42DBA0064E8A189%40LO4P265MB6154.GBRP265.PROD.OUTLOOK.COM.

[casper] katADC

[Michael D'Cruze]

Hello,

Does anyone have any spare katADCs they might be prepared to donate, or sell 
for some notional fee? We're in need of at least one, after our spare was found 
to be damaged, but a handful would be good.

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/LO4P265MB615407EAD7519ABE8F91F9EC8A729%40LO4P265MB6154.GBRP265.PROD.OUTLOOK.COM.

Re: [casper] FREE ROACH2, ADC1x5000-8, 64ADCx64-12

[Michael D'Cruze]

Although I have expressed interest in these boards as well, it may be of 
interest to anyone in desperate need of more roach2s (and with money to pay for 
them) that Digicom are manufacturing these boards again, albeit only a small 
run of ten or so...

BW
Michael

From: casper@lists.berkeley.edu  on behalf of Drew 
Byron 
Sent: 02 August 2022 14:30
To: casper@lists.berkeley.edu 
Subject: Re: [casper] FREE ROACH2, ADC1x5000-8, 64ADCx64-12

Dear Hayden,

It seems that both roach2’s have already been claimed but if any of that falls 
through consider me on the waiting list. I am a physics graduate student at the 
University of Washington and our collaboration detects RF cyclotron radiation 
as a means of precise beta spectroscopy. We need a second roach2 to digitize a 
second channel of our detector. Please feel free to reach out for more details.

We will of course pay for shipping.

Best,
Drew

On Tue, Aug 2, 2022 at 6:23 AM Hien Vo Bich 
mailto:hien...@vgu.edu.vn>> wrote:
Dr. So. I am a lecturer in physics at the vietnamese  german university.  I 
used to be at the space science laboratory at Berkeley thus I am aware of the 
casper community.  My group builds a steerable  antenna system that can hold a 
3 to 5 m dish. Thus I would like to receive one Roach 2 board along with ADC. 
Another approach is that I will build a small array of long wavelength array as 
the Roach 2 board can host 12 antenna input. Regards   Hien Vo

Vào 04:29 PM, T.3, 2 Th8, 2022 Hayden So 
mailto:h...@eee.hku.hk>> đã viết:
Dear Casperites,

I have a few CASPER hardware in my lab that I won't be using in the foreseeable 
future and thought maybe someone on this list would be interested in.  I am 
giving them out FREE, as long as you can arrange courier to pick them up and 
take care of the shipping expense.  They are in my lab in Hong Kong right now.  
I can help pack them for shipment if needed.  The list of freebie:

* 2x ROACH2
* 2x ADC1x5000-8
* 1x 64ADCx64-12

About condition of the boards:
+ one of the ROACH2 and both ADC1x5000 were in active use up until around end 
of 2019 for our work in high speed cell imaging 
(http://dx.doi.org/10.1109/TNNLS.2020.3046452)
+ the other ROACH-2 has been sitting around for a long time.  Probably still in 
working condition but wee have not tried.
+ the 64ADCx64-12 was used once and have been idle ever since.

In other words, they should all be in working condition, at least in theory.

Please email me (h...@eee.hku.hk) directly if you are 
interested.

--Hayden

--

/**
* Hayden Kwok-Hay So
* Associate Professor
* Department of Electrical and Electronic Engineering
* Program Co-director, Computer Engineering
* Co-director, Joint Lab on Future Cities (JLFC)
* PI, Computer Architecture and System Research Lab 
(CASR)
* The University of Hong Kong
* http://www.eee.hku.hk/~hso
**/

--
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/6ad9ff7e-f767-f053-da52-d98ee0a8d905%40eee.hku.hk.

--
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/CAA1FmcXeTHpovgy7NbgPB0iiVzvpSx-GzohaHNiLO3w4Bskx6g%40mail.gmail.com.
--
Drew Byron
PhD Student, Department of Physics
University of Washington

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

Re: [casper] Copy .fpg file to ROACH2 server

[Michael D'Cruze]

Wang,

upload_to_ram_and_program() is the casperfpga function for programming the FPGA 
without having to copy it over to the board first. Perhaps take a look at the 
casperfpga.py file that should live in your python libraries folder; there are 
alternatives to this function but I'm not sure what they are, off the top of my 
head.
I'm afraid it's been many years since I've used corr and don't have any advice 
to offer.
However, looking again at your screenshots I don't understand the directory 
into which you're trying to scp the fpg file? Instead of having scp [file.fpg] 
root@[IP]:[file.fpg] I think it should instead be scp [file.fpg] 
root@[IP]:/dir/[file.fpg] where [dir] might be /root/ or /usr/ or something. 
I'm not surprised it's complaining if you're trying to copy it straight into /

Best,
Michael

From: casper@lists.berkeley.edu  on behalf of 王钊 

Sent: 01 August 2022 16:57
To: casper@lists.berkeley.edu 
Subject: Re: [casper] Copy .fpg file to ROACH2 server

Hi Michael,

I can't use the casperfpga function.Now I am using  Corr.

I don't quite understand what you mean by upload_to_ram_and_program().

Best,
Wang



Michael D'Cruze 
mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 于 2022年8月1日周一 下午11:39写道：
Hello Wang,

Can't you just use the casperfpga function for this? I think it's 
upload_to_ram_and_program(), or something like that.

Best,
Michael

From: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu> 
mailto:casper@lists.berkeley.edu>> on behalf of Wang 
mailto:sandang19990...@gmail.com>>
Sent: 01 August 2022 16:35
To: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu> 
mailto:casper@lists.berkeley.edu>>
Subject: [casper] Copy .fpg file to ROACH2 server

Hi CASPER，

I'm having some problems copying files to server: 'read-only files system'.

I suspect there is a problem with my ROACH‘s startup configuration file.
After netboot,  prompted 'read-only' when the user logs in.
Have you ever been in this situation?
picture1:copy file to server
picture2:netboot login
[scp1.png]
[netboot_3.png]

I would appreciate it very much if you would help me with it.

BW!
Wang

--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu<mailto:casper+unsubscr...@lists.berkeley.edu>.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/e1f67c22-d567-4945-8f36-1702e27ccb47n%40lists.berkeley.edu<https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/e1f67c22-d567-4945-8f36-1702e27ccb47n%40lists.berkeley.edu?utm_medium=email_source=footer>.

--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu<mailto:casper+unsubscr...@lists.berkeley.edu>.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/LO4P265MB6154B8B9C331E946601625F78A9A9%40LO4P265MB6154.GBRP265.PROD.OUTLOOK.COM<https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/LO4P265MB6154B8B9C331E946601625F78A9A9%40LO4P265MB6154.GBRP265.PROD.OUTLOOK.COM?utm_medium=email_source=footer>.

--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu<mailto:casper+unsubscr...@lists.berkeley.edu>.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAEq%3DE3FVTrQsyHp0Ke5oCjy3oRmNMkc-Ys02xdy5vQ_74TC8OQ%40mail.gmail.com<https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAEq%3DE3FVTrQsyHp0Ke5oCjy3oRmNMkc-Ys02xdy5vQ_74TC8OQ%40mail.gmail.com?utm_medium=email_source=footer>.

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

[casper] Re: Question about FPGA Roach2

[Michael D'Cruze]

Hi Grace,

Some things to check:

-- are you definitely using the correct eth port on the roach?
-- are you using a crossover eth cable? you'll need a crossover to get it to 
talk straight to a PCI-E NIC, but if you can put a switch between them I think 
it'll work
-- to check the IP (unsure whether *.4.20 is correct) can you connect via 
Serial/Minicom using the USB? I've found this to be an essential route for 
diagnostics especially if something weird happens with the eth connection

Also, I recommend joining the casper Slack (casper-astro.slack.com), if you're 
not already on there. There's a dedicated roach2 channel and you might find 
your questions are answered already or may be answered a bit more quickly, 
especially out of hours.

Good luck!
Michael



From: casper@lists.berkeley.edu on behalf of Grace Chesmore
Sent: Tuesday, July 12, 2022 20:23
To: casper@lists.berkeley.edu
Cc: Sara M. Simon
Subject: [casper] Fwd: Question about FPGA Roach2

Hi casper team!

I’m Grace Chesmore, a graduate student working out at Fermi National Lab with 
Dr. Sara Simon (cc’d).

We’ve purchased a ROACH2 board and are setting it up.  We are plugging it into 
our computer using the Ethernet port on the ROACH2.  We can see that the 
computer is connecting to the IP port of the FPGA via the ethernet port.  We 
configured our ethernet port to be 192.168.4.1 (to be compatible with the 
ROACH2 IP address which I believe is 192.168.4.20 but tell me if I’m wrong).

Then, when I try to connect to the same FPGA via the casperfpga package in 
Python, it times out because it cannot connect (or find the IP address).  I am 
using the command:
fpga=casperfpga.Casperfpga(“192.168.4.20”)

Am I missing something in the setup? Do I need to first configure the FPGA some 
way? Maybe we can also set up a call to troubleshoot this, I’d really 
appreciate any help.

Thanks so much!
Grace

---
Grace Chesmore | she, her, hers
PhD Candidate
Department of Physics
University of Chicago
chesmore.github.io


--
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/A4C26A32-8FC3-4EB8-92E4-29B34C13DD73%40uchicago.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/LO4P265MB6154DB9C8A628271ED643AFF8A869%40LO4P265MB6154.GBRP265.PROD.OUTLOOK.COM.

Re: [casper] PAPER Correlator EQ Settings

[Michael D'Cruze]

Hi Wang,

The memos are on github now. See: 
https://github.com/casper-astro/publications/blob/master/Memos/files/p011.quant.pdf

BW



From: casper@lists.berkeley.edu  on behalf of Wang 

Sent: 24 June 2022 15:32
To: casper@lists.berkeley.edu 
Subject: [casper] PAPER Correlator EQ Settings

Hi CASPER,

I am learning the PAPER correlator and there is a document link for EQ setting 
and I find I can't open it.

 https://casper.astro.berkeley.edu/wiki/PAPER_Correlator_EQ

[EQ settings.png]
I hope you can send me a copy of this document.

BW
Wang

--
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/09db20fc-051b-4dc5-b455-7e52ff4176afn%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/LO4P265MB6154CC6BAB978FB2A2A80E228AB49%40LO4P265MB6154.GBRP265.PROD.OUTLOOK.COM.

Re: [casper] Used to operate the ROACH2 operating system

[Michael D'Cruze]

Hi Wang,

These VMs I've described are only important in generating gateware (*.fpg) 
files for each respective board, which require particular versions of 
Matlab/ISE/Vivado that may be incompatible with newer versions of Linux. The 
actual interaction with and operation of the board is carried out using the 
host OS, not the guest OSs.
I may have misunderstood your intended use case: is it your plan to merely 
interact with and operate the roach2, or do you need to develop gateware as 
well? I think most common versions of Linux should be able to run the tools 
required to merely interact with the board.
As I mentioned initially I think you're making your task more difficult than it 
needs to be by using netboot and not soloboot...

Best,
Michael

From: casper@lists.berkeley.edu  on behalf of 王钊 

Sent: 13 June 2022 15:00
To: casper@lists.berkeley.edu 
Subject: Re: [casper] Used to operate the ROACH2 operating system

Hi  Michael,

Thank you very much. I'm new to this, and I have some questions.

Is there any difference between using a VM to operate ROACH2 and installing an 
operating system on a host?

When I have installed the VM. Do I need to set up some extra files to make 
ROACH2 work?

What does your main operating system do, and what does it do when ROACH2 works?

I am sorry to take up your precious time.

BW
Wang


Michael D'Cruze 
mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 于2022年6月13日周一 20:38写道：
Hi Wang,

You might consider running Centos 6.X, Ubuntu, or Fedora as Virtual Machines 
within e.g. some other common Linux distro (with which your computer is 
compatible). This is what I'm currently doing: I have Rocky 8.6 as my main OS 
then Centos 6.10 in a VM for developing with roach2, and Ubuntu 18.04 in 
another VM for developing with Snap.

Best,
Michael



From: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu> on behalf of 
Heystek Grobler
Sent: Monday, June 13, 2022 12:33
To: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>
Subject: Re: [casper] Used to operate the ROACH2 operating system

Hey Wang

It is a pleasure.

Yes, ISE14.7 works with Ubuntu 18.04 LTS without any problems.

I do not use netboot or dnsmasq. My /etc/exports fie is also empty.

Here is screenshots of my interfaces and ifconfig:

[X]

[X]

I hope it helps.

Heystek

-
Heystek Grobler

0832721009
heystekgrob...@gmail.com<mailto:heystekgrob...@gmail.com>





On 13 Jun 2022, at 12:18, 王钊 
mailto:sandang19990...@gmail.com>> wrote:

Hi Heystek,

Thank you for your reply!

Can you use ISE14.7 when using Ubuntu 18.04?  I think the official website says 
this version is not supported.

I was using Ubuntu 16.04 and had a problem with NFS mount on netboot.


In terms of hardware, I consulted the after-sale technician of the computer and 
they said that my computer does not support CentOS6.5 and Fedora23.

I would like to take a look at your Ubuntu 18 file Settings, could you please 
take a screenshot?

1.dnsmasq.conf  2.exports 3.interfaces  and ifconfig

BW
Wang

Heystek Grobler mailto:heystekgrob...@gmail.com>> 
于2022年6月13日周一 17:40写道：
Good day Wang.

I use Ubuntu 18.04 LTS with Matlab 2012b with my ROACH2 and it is working fine.

What are the problems that you are encountering with booting up? What are the 
hardware that you are running?

Have a great day!

Heystek

-
Heystek Grobler

0832721009
heystekgrob...@gmail.com<mailto:heystekgrob...@gmail.com>





On 13 Jun 2022, at 05:32, Wang 
mailto:sandang19990...@gmail.com>> wrote:

Hello CASPER,

How's it going?I am currently using ROACH2.

However, there are always some problems when booting up, and I want to try 
another Linux system.

I tried installing CentOS6.5 and Fedora23, but my computer couldn't install it 
due to hardware problems. When I used Ubuntu14.04, my computer was very slow, 
which affected my operation.

What version of Linux system can you recommend?

Thanks.

Regards.

Wang



--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu<mailto:casper+unsubscr...@lists.berkeley.edu>.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/86e7ec24-1a8c-4965-b8e4-94f2b64b7ee0n%40lists.berkeley.edu<https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/86e7ec24-1a8c-4965-b8e4-94f2b64b7ee0n%40lists.berkeley.edu?utm_medium=email_source=footer>.


--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group.
To unsub

Re: [casper] Used to operate the ROACH2 operating system

[Michael D'Cruze]

Hi Wang,

You might consider running Centos 6.X, Ubuntu, or Fedora as Virtual Machines 
within e.g. some other common Linux distro (with which your computer is 
compatible). This is what I'm currently doing: I have Rocky 8.6 as my main OS 
then Centos 6.10 in a VM for developing with roach2, and Ubuntu 18.04 in 
another VM for developing with Snap.

Best,
Michael



From: casper@lists.berkeley.edu on behalf of Heystek Grobler
Sent: Monday, June 13, 2022 12:33
To: casper@lists.berkeley.edu
Subject: Re: [casper] Used to operate the ROACH2 operating system

Hey Wang

It is a pleasure.

Yes, ISE14.7 works with Ubuntu 18.04 LTS without any problems.

I do not use netboot or dnsmasq. My /etc/exports fie is also empty.

Here is screenshots of my interfaces and ifconfig:

[cid:B4FEE9A4-1E4E-4F13-8BF3-B94DA43498E4]

[cid:12F1F9C3-68B2-430E-93E0-0D81288A70D3]

I hope it helps.

Heystek

-
Heystek Grobler

0832721009
heystekgrob...@gmail.com





On 13 Jun 2022, at 12:18, 王钊 
mailto:sandang19990...@gmail.com>> wrote:

Hi Heystek,

Thank you for your reply!

Can you use ISE14.7 when using Ubuntu 18.04?  I think the official website says 
this version is not supported.

I was using Ubuntu 16.04 and had a problem with NFS mount on netboot.


In terms of hardware, I consulted the after-sale technician of the computer and 
they said that my computer does not support CentOS6.5 and Fedora23.

I would like to take a look at your Ubuntu 18 file Settings, could you please 
take a screenshot?

1.dnsmasq.conf  2.exports 3.interfaces  and ifconfig

BW
Wang

Heystek Grobler mailto:heystekgrob...@gmail.com>> 
于2022年6月13日周一 17:40写道：
Good day Wang.

I use Ubuntu 18.04 LTS with Matlab 2012b with my ROACH2 and it is working fine.

What are the problems that you are encountering with booting up? What are the 
hardware that you are running?

Have a great day!

Heystek

-
Heystek Grobler

0832721009
heystekgrob...@gmail.com





On 13 Jun 2022, at 05:32, Wang 
mailto:sandang19990...@gmail.com>> wrote:

Hello CASPER,

How's it going?I am currently using ROACH2.

However, there are always some problems when booting up, and I want to try 
another Linux system.

I tried installing CentOS6.5 and Fedora23, but my computer couldn't install it 
due to hardware problems. When I used Ubuntu14.04, my computer was very slow, 
which affected my operation.

What version of Linux system can you recommend?

Thanks.

Regards.

Wang



--
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/86e7ec24-1a8c-4965-b8e4-94f2b64b7ee0n%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/EB08001E-C66F-4372-AE6F-934993D63C9A%40gmail.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/CAEq%3DE3GNYE3LqcKJYMxO9YM6yy3jXy75Eq7zJbJbA5ueh1Chnw%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 

Re: [casper] An error occurs when 'exportfs -a' is entered

[Michael D'Cruze]

Hello,

I think nfs/netboot made sense when filesystem updates were being released for 
R2, but I don't really understand why anyone would use it anymore. Roach2 
should soloboot by default, and unless you've compiled and are running a custom 
filesystem for some reason I'm not sure why any other boot method would be 
advantageous... Perhaps I'm missing something

Best,
Michael

From: casper@lists.berkeley.edu  on behalf of 王钊 

Sent: 09 June 2022 09:45
To: casper@lists.berkeley.edu 
Subject: Re: [casper] An error occurs when 'exportfs -a' is entered

Hi Michael，

I'm using ROACH2.I don't know much about other boot methods of ROACH2. My tutor 
suggests that I use Netboot.

I spent a lot of time on netboot, the first time I used Ubuntu16, and this 
error occurred at netboot：
[154620_8cc3a188_10952828.webp]

I am currently trying to use Ubuntu14 for netboot and also getting an error 
about exportfs -a.

I have also considered trying other boot methods, are there any related 
tutorials？All I can find is netboot.

Thank you very much for your reply！
Wang
Michael D'Cruze 
mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 于2022年6月8日周三 23:12写道：
Hi Wang,


I did use netboot for a while on my roach2 way back in the day, but it was 
easier especially following various updates to the board to just use soloboot.
I hate to ask but is there a reason you need to use netboot?
I assume you're using a roach2, and not a roach1?

BW
Michael

From: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu> 
mailto:casper@lists.berkeley.edu>> on behalf of Wang 
mailto:sandang19990...@gmail.com>>
Sent: 08 June 2022 15:52
To: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu> 
mailto:casper@lists.berkeley.edu>>
Subject: [casper] An error occurs when 'exportfs -a' is entered

Hi CASPER,
  How's it going? I'm using ubuntu14.04.
  I had some problems setting up the ROACH netboot.

  *   First, sudo apt-get install nfs-kernel-server nfs-common.
  *   Second, sudo gedit /etc/exports,and add the lines:

   # Share 'roach_boot' directory/srv/roach_boot   
192.168.100.0/24(rw,subtree_check,no_root_squash,insecure)<http://192.168.100.0/24(rw,subtree_check,no_root_squash,insecure)>

  *   The last, exportfs -a
  *At this time, the terminal displays:

sandang@wz-sandang:/etc$ sudo exportfs -a
exportfs: No options for to NFS: suggest NFS(sync) to avoid warning
exportfs: /etc/exports [1]: Neither 'subtree_check' or 'no_subtree_check' 
specified for
export "NFS:to".
Assuming default behaviour ('no_subtree_check').
NOTE: this default has changed since nfs-utils version 1.0.x

 May I ask what are the reasons for these?
 I would be really appreciated if you reply!
Wang

--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu<mailto:casper+unsubscr...@lists.berkeley.edu>.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/dbe7c801-e9a4-4967-b1aa-678bdf71aa83n%40lists.berkeley.edu<https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/dbe7c801-e9a4-4967-b1aa-678bdf71aa83n%40lists.berkeley.edu?utm_medium=email_source=footer>.

--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu<mailto:casper+unsubscr...@lists.berkeley.edu>.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/LO4P265MB6154CAC9895302EA186451848AA49%40LO4P265MB6154.GBRP265.PROD.OUTLOOK.COM<https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/LO4P265MB6154CAC9895302EA186451848AA49%40LO4P265MB6154.GBRP265.PROD.OUTLOOK.COM?utm_medium=email_source=footer>.

--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu<mailto:casper+unsubscr...@lists.berkeley.edu>.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAEq%3DE3EAJsMBvh6tHeD6fbAwYhao5_cAm7Lpgu%3Dc%2B_tv5ciX9Q%40mail.gmail.com<https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAEq%3DE3EAJsMBvh6tHeD6fbAwYhao5_cAm7Lpgu%3Dc%2B_tv5ciX9Q%40mail.gmail.com?utm_medium=email_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe fr

Re: [casper] An error occurs when 'exportfs -a' is entered

[Michael D'Cruze]

Hi Wang,


I did use netboot for a while on my roach2 way back in the day, but it was 
easier especially following various updates to the board to just use soloboot.
I hate to ask but is there a reason you need to use netboot?
I assume you're using a roach2, and not a roach1?

BW
Michael

From: casper@lists.berkeley.edu  on behalf of Wang 

Sent: 08 June 2022 15:52
To: casper@lists.berkeley.edu 
Subject: [casper] An error occurs when 'exportfs -a' is entered

Hi CASPER,
  How's it going? I'm using ubuntu14.04.
  I had some problems setting up the ROACH netboot.

  *   First, sudo apt-get install nfs-kernel-server nfs-common.
  *   Second, sudo gedit /etc/exports,and add the lines:

   # Share 'roach_boot' directory/srv/roach_boot   
192.168.100.0/24(rw,subtree_check,no_root_squash,insecure)

  *   The last, exportfs -a
  *At this time, the terminal displays:

sandang@wz-sandang:/etc$ sudo exportfs -a
exportfs: No options for to NFS: suggest NFS(sync) to avoid warning
exportfs: /etc/exports [1]: Neither 'subtree_check' or 'no_subtree_check' 
specified for
export "NFS:to".
Assuming default behaviour ('no_subtree_check').
NOTE: this default has changed since nfs-utils version 1.0.x

 May I ask what are the reasons for these?
 I would be really appreciated if you reply!
Wang

--
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/dbe7c801-e9a4-4967-b1aa-678bdf71aa83n%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/LO4P265MB6154CAC9895302EA186451848AA49%40LO4P265MB6154.GBRP265.PROD.OUTLOOK.COM.

[casper] Seeking a python spead2 expert

[Michael D'Cruze]

Hello everyone,

I'm experiencing some issues getting my data acquisition going again after 
being forced to upgrade my OS from RHEL6 to Rocky 8, specifically: there's an 
issue getting the python implementation of spead2 to capture packets from the 
stream. On RHEL6 I operated spead2-0.5.x (I think), which from memory worked 
immediately and I haven't needed to change anything until recently.
This isn't at all urgent, but I've already spent too much time trying various 
"high level" diagnostics to no avail, and I just can't put any more time into 
this. I'm seeking a spead2 expert who can help guide my diagnostic effort and 
highlight any potential "gotchas". The detail is below.

Thanks
Michael

The issue is that, following an OS upgrade from RHEl6 to Rocky 8, I'm unable to 
get my basic udp-reading spead2 script to successfully grab heaps and write 
them out to a file.
On my old RHEL6 installation I had a very old (back to 2015, possibly) spead2 
version installed, which had to be built from source and took quite some effort 
to install, IIRC.
The script is based around the test_recv script, albeit heavily modified and 
with Paul Prozesky's help (again, this might say something about how long ago 
I'd put this together).
I don't recall any issues getting this script working on my old machine.
On my new machine I've pip-installed spead2-1.40 (I think) into python 2.7, and 
also spead2-3.70 into python 3.10.
On the Roach2 I have one of my old spectrometer designs that I know to work.
On Wireshark I can see the packets coming in, and using tcpdump I am able to 
capture the packets to a file. Loading these packets into python, it looks like 
there's a spectrum in there. That is, I don't think there's anything wrong with 
my hardware setup or config.
As the script (and its py3-modified variant) are both unable to process heaps 
when presented with the spead2.recv.Stream module (it just hangs and the 
various open files remain unwritten to), I'm guessing I've missed something 
possibly quite simple. As such I'd be grateful if anyone more familiar with 
spead2 and the various step-changes since spead2-0.50 (or whatever ancient 
version I was previously, successfully using), could suggest anything to try.

-- 
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/CWLP265MB61525012941B5D66BD4D90988A3C9%40CWLP265MB6152.GBRP265.PROD.OUTLOOK.COM.

[casper] Bug in mlib_devel on roach2 branch

[Michael D'Cruze]

Hi,

Following a system upgrade under duress from our local IT, I've installed a 
fresh set of mlib_devel, casperfpga libraries. Installation was suspiciously 
successful until an attempted program... when casperfpga hanged with no return. 
After a bit of digging this seems to be because git_write_info.m was appending 
an erroneous line to the end of the meta section in the FPG file, which 
casperfpga wasn't able to parse. I suggest commenting out, or removing 
altogether, the line in gen_xps_files.m that calls git_write_info.

Best
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/LO3P265MB1835B9F233BDE40F5808E71B8A6E9%40LO3P265MB1835.GBRP265.PROD.OUTLOOK.COM.

RE: [casper] Computer Specs Recommendation

[Michael D'Cruze]

Lots of cores, lots of RAM, and an SSD primary!
I worked with a six-core i7 running at 4.xxGHz and 64GB RAM, which seemed fine, 
but I was clearly bottlenecked by my HDDs. Definitely have an SSD... 
fortunately multi-TB NVMe drives are affordable now.

Best,
Mike


-Original Message-
From: baldwin [mailto:bald...@cp.dias.ie] 
Sent: 28 April 2021 11:30
To: casper@lists.berkeley.edu
Subject: [casper] Computer Specs Recommendation

Hi Guys,

Quick question. We're looking at purchasing a new computer for compiling 
our firmware and am wondering if anybody can recommend what specs are 
beneficial for speeding up compilation times?

Cheers,

Eoin.

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

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

RE: [casper] Weird python problem

[Michael D'Cruze]

Hi Heystek,

I haven’t seen this before. Is there anything in your working directory that 
the import statement could be confusing with your desired module? Perhaps try 
changing your working directory.

GL
Mike

From: Heystek Grobler [mailto:heystekgrob...@gmail.com]
Sent: 04 September 2020 11:37
To: 'Siddharth Savyasachi Malu' via casper@lists.berkeley.edu
Subject: [casper] Weird python problem

Good day everyone.

I have encountered a weird problem. I have a python script that makes use of 
pylab. When importinf pylab, I get this error:

PyUnicodeUCS4_FromString


I have tried to use import matplotlib.pyplot as plt and I get the same error. I 
have googled it, but nothing seems to help.


I am using python 2.7


Thanks for the help.


Heystek
--
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/35AD58DC-408B-45C5-BE42-07D0FA3BB440%40gmail.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/VI1PR01MB4799C99D9E12534CB8A47858AC2D0%40VI1PR01MB4799.eurprd01.prod.exchangelabs.com.

RE: [casper] Installation of Matlab 2012B

[Michael D'Cruze]

It may be of interest to someone in the future that, if you buy a Dell 
workstation with RHEL pre-installed, these solutions don’t work. Indeed this is 
what I originally tried to do. The problem appears to be that Dell have 
installed some sort of BIOS command to overrule any changes you make to the 
grub cfg file, or the interfaces list. In my case the only way to effect a 
change was to use the network config/manager command line utility.

From: David MacMahon [mailto:dav...@berkeley.edu]
Sent: 18 August 2020 16:00
To: casper@lists.berkeley.edu
Subject: Re: [casper] Installation of Matlab 2012B

The consistent albeit cryptic names like “enp0s5” might make life easier for 
automating Linux installations, but I don’t think they make life easier for 
sysadmins or power users. Fortunately, this naming scheme is optional and it’s 
easy to switch to the more human-friendly names by adding “net.ifnames=0” to 
the kernel command line (probably in some grub config file, depending on your 
distribution). You might also need “net.biosdevnames=0”.  Googling those terms 
plus your distro’s name will get you some relevant pages with more details.

A rose by any other name would smell as sweet,
Dave


On Aug 18, 2020, at 04:00, James Smith  wrote:

Hi Heystek,

Unfortunately not - I have had this in the past as well IIRC, some of the more 
modern Linux distributions will give you something like "en0s1" or the like. 
Matlab is stuck in the past, looking for eth0.

It's easy enough to change the name, but bear in mind that you may have some 
funnies elsewhere that you will need to change as well (e.g. if you have 
/etc/network/interfaces - you'll need to update that too).

Regards,
james


On Tue, Aug 18, 2020 at 10:51 AM Heystek Grobler 
mailto:heystekgrob...@gmail.com>> wrote:
Hey Mike

Thank you for your reply!

On the Mathworks forums some of the folks suggest to “force” a name change. 
Apparently the license is looking for “eth0” but on my machine it is “em1”.  
That is what is. causing the error.

I was just wondering if there is perhaps a more elegant solution to this.

Thanks for the help!

Heystek





On 18 Aug 2020, at 12:44, Michael D'Cruze 
mailto:michael.dcr...@manchester.ac.uk>> wrote:

Hi Heystek,

I’ve seen a similar thing recently installing ISE on a Linux 7 machine. It 
looks like a complaint about the naming convention of your primary NIC. You can 
force a name-change if you want using the network manager (I did it in RHEL, 
unsure about Ubuntu) but better to find a solution from Mathworks if you can. 
What does the indicated solution say?

Good luck,
Mike


From: Heystek Grobler [mailto:heystekgrob...@gmail.com]
Sent: 18 August 2020 11:34
To: Casper Lists
Subject: [casper] Installation of Matlab 2012B

Hello everyone

I have a bit of a problem. The first time that I am experiencing it. I am 
trying to install Matlab 2012B on a Ubuntu machine (That I redid), but the 
installation gives this error:



Does anyone perhaps know how to fix this?

Heystek


--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu<mailto:casper+unsubscr...@lists.berkeley.edu>.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CALWRf%3DTsifQZubv1Fbo0jEhY0LSba%2BgApk%3DkE6qKy_CO1izVpQ%40mail.gmail.com<https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CALWRf%3DTsifQZubv1Fbo0jEhY0LSba%2BgApk%3DkE6qKy_CO1izVpQ%40mail.gmail.com?utm_medium=email_source=footer>.

--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu<mailto:casper+unsubscr...@lists.berkeley.edu>.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/VI1PR01MB4799E1A85E37F7297C293AFCAC5C0%40VI1PR01MB4799.eurprd01.prod.exchangelabs.com<https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/VI1PR01MB4799E1A85E37F7297C293AFCAC5C0%40VI1PR01MB4799.eurprd01.prod.exchangelabs.com?utm_medium=email_source=footer>.

--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
casper+unsubscr...@lists.berkeley.edu<mailto:casper+unsubscr...@lists.berkeley.edu>.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/5C04BF02-14A5-4BB7-8137-CD4CD729FBF9%40gmail.com<https://groups.google.com/a/lists.berkeley.edu/

RE: [casper] Installation of Matlab 2012B

[Michael D'Cruze]

Hi Heystek,

I’ve seen a similar thing recently installing ISE on a Linux 7 machine. It 
looks like a complaint about the naming convention of your primary NIC. You can 
force a name-change if you want using the network manager (I did it in RHEL, 
unsure about Ubuntu) but better to find a solution from Mathworks if you can. 
What does the indicated solution say?

Good luck,
Mike


From: Heystek Grobler [mailto:heystekgrob...@gmail.com]
Sent: 18 August 2020 11:34
To: Casper Lists
Subject: [casper] Installation of Matlab 2012B

Hello everyone

I have a bit of a problem. The first time that I am experiencing it. I am 
trying to install Matlab 2012B on a Ubuntu machine (That I redid), but the 
installation gives this error:

[Screenshot from 2020-08-17 17-55-44.png]

Does anyone perhaps know how to fix this?

Heystek


--
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/CALWRf%3DTsifQZubv1Fbo0jEhY0LSba%2BgApk%3DkE6qKy_CO1izVpQ%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/VI1PR01MB4799E1A85E37F7297C293AFCAC5C0%40VI1PR01MB4799.eurprd01.prod.exchangelabs.com.

[casper] Compiling for roach2 on RHEL7

[Michael D'Cruze]

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.

RE: [casper] Spare ROACH2 Boards?

[Michael D'Cruze]

+1!

From: Brad Dober [mailto:do...@sas.upenn.edu]
Sent: 26 August 2019 22:21
To: Casper Lists
Cc: Michael D. Niemack
Subject: [casper] Spare ROACH2 Boards?

Hi Casper Community,

With the upcoming retirement of ROACH2 production, I was interested in seeing 
if any groups were retiring their boards and perhaps selling them. Please let 
me know if you've got a stockpile you're looking to offload.

Cheers,

Brad Dober, Ph.D.
Cell: 262-949-4668
--
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/CAHX2-uUXYjePM4B-1szt4-09CO-ff%3DYHB5su4ZuNj%3DG5iLcrzQ%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/DB7PR01MB50485E4AE6581D9629D95ABFACA00%40DB7PR01MB5048.eurprd01.prod.exchangelabs.com.

RE: [casper] Myricom 10G-PCIE-8A-C

[Michael D'Cruze]

Rolando,

This is a shot in the dark but I’d suggest checking your MTU size hasn’t been 
changed during whatever updates/upgrades you alluded to in your original 
message. I recall having issues such as the one you described and it turned out 
to be that.

Good luck!

From: Rolando Paz [mailto:flx...@gmail.com]
Sent: 06 March 2018 18:50
To: casper@lists.berkeley.edu
Subject: Re: [casper] Myricom 10G-PCIE-8A-C

Hi Dan

I placed a 64-bit counter directly at the input of 10G block, and then adjusted 
the accumulation length. The behavior was the same, it only works correctly 
with the accumulation length = 2048.

The integration time of each package is 20ms corresponding to the accumulation 
length = 2048.

Then I obtained the data through GULP, then I graph them and I obtained the 
attached graph.

I think everything is working well?

This only works with the accumulation length = 2048, below everything stops 
working.

Regards



2018-03-06 11:46 GMT-06:00 Dan Werthimer 
>:

hi rolando,

what is your packet rate?
and how many bytes in each packet?

i suggest you use tcpdump or wireshark or some other packet sniffer program
to examine your packets, and see how fast they are coming in (look at the time 
stamps of each packet),
and whether the data look correct...

dan



On Mon, Mar 5, 2018 at 9:49 PM, Rolando Paz 
> wrote:
Hi Dan

After doing what you advised me, I managed to observe the following:

When I adjust the accumulation length to 2048 everything works correctly, then 
I adjust the accumulation length to 1024 and everything continues to work fine, 
then I adjust the accumulation length to 512 and the PC stops receiving the UDP 
packets (totally) ...

Then I go back to 1024 and I no longer get packets.

Then I go back to 2048 and everything goes back to normal, then I adjust the 
value to 1024 and it works correctly.

I no longer see UDP packets when I adjust the value to 512 ...

Can it be a problem with my network card?

Regards

2018-03-05 19:15 GMT-06:00 Dan Werthimer 
>:

hi rolando,

it's possible that the problem you see is because your sample rate has changed
or the valon's power output is too low for the adc.

the valon display can sometimes mislead.
i suggest you power cycle the valon, and re-program it with the settings you 
want
(don't use the flash to boot it).
and measure the valon output frequency and power level, (or check the packet 
rate coming from your spectrometer).

we've seen the valon's flash get reprogrammed by accident.   and check the 
valon output

also, after you change the valon, or disconnect the clock from the adc, make 
sure to re-program the fpga:
if you have a runt clock pulse when changing clock rates, the fpga can get into 
a wierd mode.

dan


On Mon, Mar 5, 2018 at 5:08 PM, Rolando Paz 
> wrote:
Hi Dan

Right now I did another test with accumulation length = 1024, and it did not 
work ... then I changed it to 2048 and now it's the new value with which ROACH 
works ...something bad is happening.

The settings of the 5008 valon can be seen in the attached image.

The QUADC needs (https://casper.berkeley.edu/wiki/ADC4x250-8):

Inputs
Clock: 24-250MHz 50Ohm 0dBm

According to what I see in the image "input_to_quadc.png" that I obtained with 
an oscilloscope, the signal that input to the quadc is  -5.5dBm.

Could this be the problem?
and if this were the problem, why before everything worked well?

Best Regards

Rolando

2018-03-05 17:46 GMT-06:00 Dan Werthimer 
>:

hi rolando,

are you dropping packets?

have you used tcpdump or other packet sniffer code (eg: gulp...),
to investigating what's going on when you change the integration time?

is the number of packets/second correct for the integration time you set?
if not, perhaps you accidently changed the sample clock to the adc
so the integration time is shorter than before...

best wishes,

dan



On Mon, Mar 5, 2018 at 3:39 PM, Rolando Paz 
> wrote:
Hello

I'm having a problem with my 10G ethernet card (I think)... everything was 
working fine the last year. Yesterday I turned on the ROACH again and now I 
could not get data with the original settings (accumulation length= 256). Maybe 
the drivers of the Myricom 10G-PCIE-8A-C card were updated automatically in my 
ubuntu 16.04LTS :(

These are the original settings:

Notes:
a) ROACH1 design, 4 inputs with QUADC
b) "fft_biplex_real_2x" block was used

FFT points (FFT size) = 2048
Samples per clock = 1
FFT clock cycles = 2048
Accumulation Length = 256
FPGA clock (MHz) = 200
Integration Time = 0.00262144

But now it only works from:

FFT points (FFT size) = 2048
Samples per clock = 1
FFT clock cycles = 2048
Accumulation Length = 1024
FPGA clock (MHz) = 200
Integration Time = 0.01048576

[casper] adc5g four inputs

[Michael D'Cruze]

Dear all,

Does anyone know if the "adc5g" board in its broadly existing form can be 
operated using all four inputs independently? I have in mind that a minor 
rework of the HDL code and yellow block, and additional SMA connectors could be 
installed, without requiring a completely new board to be designed.

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 post to this group, send email to casper@lists.berkeley.edu.

RE: [casper] Bof files

[Michael D'Cruze]

Hi Heystek,

If a bit file is created – and I think it is (someone correct me if I’m wrong?) 
– you can use the following code to generate a bof file from it:

mkbof -o system.bof –s core_info.tab -t 3 system.bit

where core_info.tab is in XPS_ROACH2_base/.

If that doesn’t work you can use the ISE suite itself to perform the creation. 
Have a look at the memo I wrote on the Casper memos page (the one with 
SmartXplorer in the title) which tells you how to do this.

Cheers
Michael

From: Heystek Grobler [mailto:heystekgrob...@gmail.com]
Sent: 31 August 2017 20:22
To: Casper Lists
Subject: [casper] Bof files

Hi Everyone :-)

My apologies for bugging everyone again.

I want to know I would I be able to compile/create a .bof file if I un-tick the 
last box on the casper_xps screen?

I have a unique problem where casper_xps does not run if the last box is ticked.

Thanks for the help

Heystek :-)
--
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] timing errors

[Michael D'Cruze]

Hi Yunpeng, all,

I recently wrote a memo which describes how you can use Xilinx SmartXplorer to 
help with timing issues. Have a look on the casper wiki in the Memos section: 
https://casper.berkeley.edu/wiki/images/f/f8/SmartXplorer_memo.pdf . It isn’t a 
free pass – you need to get fairly close using knowledge of individual hardware 
types on the FPGA, and you need to space out your design reasonably, by using 
pipelines. But it should help get over the final hurdle if you’re doing a 
reasonable job initially.

Best,
Michael

From: 门云鹏 [mailto:yp...@pku.edu.cn]
Sent: 03 June 2017 16:00
To: casper@lists.berkeley.edu
Subject: [casper] timing errors


Dear all,

I am using ROACH2 to develop digital receiving backend, but I often encounter 
timing errors when I run casper_xps toolflow. I wonder if there is any general 
solution to these timing errors.

Thanks a lot,

Yunpeng

---
Yunpeng Men
PhD student
Department of Astronomy & Kavli Institute for Astronomy and Astrophysics, 
Peking University
Yi He Yuan Lu 5, Hai Dian Qu, Beijing 100871, P. R. China
--
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] Help with PlanAhead

[Michael D'Cruze]

Hi Franco,

Just curious, but have you considered using SmartXplorer to assist in getting 
your design to meet timing, if this is the eventual goal? Usually I find that 
with a medium or large design, if I can adjust the latencies in Simulink to get 
within a timing score of, say, 1, then running smartxplorer on those 
netlist files usually finishes off the job. It can take a very, very long time 
though since it is a brute-force method. Most jobs for me complete within about 
24hrs, however the largest design I ever tried took a full week...

Good luck
Michael

-Original Message-
From: Franco [mailto:francocuro...@gmail.com] 
Sent: 23 May 2017 20:59
To: Casper Lists
Subject: [casper] Help with PlanAhead

Dear Casper community,


I seek your wisdom once again. I was doing floorplanning to my model when I 
noticed something interesting. My model has 40 vector accumulator blocks 
(simple_bram_vacc). When I opened my model in PlanAhead, I noticed that all the 
BRAMs of every vacc were sharing the same single counter implementation for 
addressing, instead of each vacc having its independent counter. I understand 
that these two implementations are equivalent because all the counters are 
equivalent and can be replaced by a single one addressing all the BRAMs, but it 
makes me wonder:

1)  Why this substitution happened? Was the Xilinx/EDK tools that tried to do 
some optimization? Or it has something to do with the simple_bram_vacc block 
implementation?

2) Isn't this implementation detrimental for routing proposes? I mean a single 
counter must address 40 different BRAMs across the FPGA. (My critical paths 
don't involve the counter, but they do involve a lot of vacc BRAMs with other 
components).

3) What would you recommend me to increase the speed of my model? Force every 
vacc to implement their own counter (if that's even possible)? 
Group my BRAMs around or near the lonely counter? Something else?


As always, many thanks,


Franco Curotto

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

[casper] ROACH2 sync_out

[Michael D'Cruze]

Dear all,

I'm planning to use a 0.5Hz square wave, generated from the FPGA and output via 
sync_out, to eventually fire our cal diode (via much cabling). A quick hardware 
test today shows the sync_out port driving at circa 7V (!). This is a bit 
higher than I was expecting. Does this venture as a whole seem like a 
particularly bad idea to anyone with experience using sync_out? Is this output 
voltage roughly as expected?

Thanks a lot,
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 post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] adc5g stuck in test mode

[Michael D'Cruze]

Hi Jack,

Indeed you are right: it wasn’t anything to do with the cal routines. It looks 
like a sync pulse had come out of alignment which was causing the spectrum to 
offset erroneously.

A post-programming cal routine is just what I’m working towards. I think I’ve 
pretty much got it, however there’s one last thing which I’m a little confused 
by. The “original” cal facility includes a script which requires a 10MHz tone, 
however it looks like your disentangle branch removes this requirement. Is it 
definitely the case (and it looks this way from the scripts and functions) that 
both the IODelay cal and MMCM can take place with the adc5g in test mode, not 
requiring an input tone?

Thanks
Michael

From: Jack Hickish [mailto:jackhick...@gmail.com]
Sent: 08 December 2016 23:26
To: Michael D'Cruze; Primiani, Rurik; casper@lists.berkeley.edu
Subject: Re: [casper] adc5g stuck in test mode

Hi Michael, cc. List,

Do you see glitches if you leave the adc in test ramp mode and grab lots of 
samples? If not, the problem isn't related to IO calibration.

I might be misinterpreting your email, but just to be clear, you must 
recalibrate the MMCMs (or iodelays, or both) every time you program. These 
settings are not persistent over programming cycles.
If you really wanted you could calibrate the MMCMs once and then each time you 
reprogram load in the same phases, but personally I don't see why this would be 
preferable to just making calibration part of the post-programming routine.

If you're talking about adc core calibration delays, that's a different kettle 
of fish


Cheers
Jack

On Thu, 8 Dec 2016, 15:08 Michael D'Cruze, 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
Hi Rurik,

That’s interesting..

Jack: could you comment on the effect I’m seeing, having performed the IODelay 
cal? I’ve confirmed now that it’s not a property of the analogue signal. In a 
4k-channel spectrometer design, following the IODelay cal, glitches appear 
towards the top end of the spectrum. These are not present in the same design 
scaled up to 8k channels, to which a slightly different set of delay values are 
applied.

Rurik: it sounds as though you are adopting a similar approach regarding MMCM 
cal as myself. In my case, my board is running 24/7 in a temperature-controlled 
environment, although the board is reprogrammed fairly frequently. In this case 
would you agree that infrequent MMCM cals (say, once a week or even less than 
that) should be sufficient?

Thanks
Michael

From: Primiani, Rurik 
[mailto:rprimi...@cfa.harvard.edu<mailto:rprimi...@cfa.harvard.edu>]
Sent: 08 December 2016 00:07
To: Michael D'Cruze
Subject: RE: [casper] adc5g stuck in test mode

Hi Michael,

I'm not sure which delays you mean. Do you mean the IODELAYs? Is 
calibrate_all_delays part of Jack's fork of adc_tests? Sadly I'm not familiar 
with this function.

Although I added the IODELAY elements to the adc5g gateware code we don't 
actually use them at  SMA. We get by with only the MMCM calibration and the 
interleaving corrections. When we first program our bitcode we do a MMCM 
calibration with a sync, this one we call a "cold" cal., then after the chip 
has had a chance to warm up to its operating temperature (for us ~80 C) we run 
a "warm" cal. which is just another MMCM calibration but this time without a 
sync. For us this procedure has been enough to eliminate most of the spurs we 
see due to glitches in the interface. For now we have not bothered to do 
IODELAY calibration but we have the benefit of spurious components generally 
getting washed out by our Walshing (and to some extent our fringe rates).

The major source of spurs for us is the Fs/4 spur due to the interleaving 
errors. These we measure and store generally once and remain quite constant 
with time.

Best,
Rurik


On Dec 7, 2016 6:28 PM, "Michael D'Cruze" 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
Hi Rurik,

Just as an aside (it sounds like you’re pretty hot with the adc5g cal 
facility?), how reliable is the set of delays that are written into the cores? 
I only ask since the spectrum I’m getting since performing the cal looks like 
it has some glitches in. It could well be the analogue signal has these 
glitches and I’ll find out with a  spec an tomorrow, but I’m sure these weren’t 
there before…

Cheers
Michael

From: Primiani, Rurik 
[mailto:rprimi...@cfa.harvard.edu<mailto:rprimi...@cfa.harvard.edu>]
Sent: 07 December 2016 17:17
To: Michael D'Cruze
Cc: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>
Subject: Re: [casper] adc5g stuck in test mode

Hi Michael,

Which version (git commit and fork) of mlib_devel did you use to compile your 
bitcode?

Which version (git commit and fork) of the adc5g library are you using?

What does the output of the following command show for the 

Re: [casper] adc5g stuck in test mode

[Michael D'Cruze]

Hi Rurik,

Cc: list

The command you refer to was producing the correct outputs: that is, the “test” 
bit was high and low for the appropriate mode. I think the problem was that I 
did have an old version of the adc5g test facility. It’s strange because it’s 
worked before, however having ripped it out of my python install and grabbing 
the latest version (from the disentangle branch), it’s all working again.

Cheers
Michael

From: Primiani, Rurik [mailto:rprimi...@cfa.harvard.edu]
Sent: 07 December 2016 17:17
To: Michael D'Cruze
Cc: casper@lists.berkeley.edu
Subject: Re: [casper] adc5g stuck in test mode

Hi Michael,

Which version (git commit and fork) of mlib_devel did you use to compile your 
bitcode?

Which version (git commit and fork) of the adc5g library are you using?

What does the output of the following command show for the affected ADC after 
test mode has been unset?

>>> adc5g.get_spi_control(roach2, zdok_n)

Where roach2 is the FpgaClient instance and zdok_n is the ZDOK number of the 
affected ADC.

Thanks,
Rurik




On Wed, Dec 7, 2016 at 11:28 AM, Michael D'Cruze 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
Dear all,

I have a somewhat serious issue in that my adc5g seems to have become stuck in 
test mode…
I’ve messed around a bit with the very many functions within the 
calibrate_all_delays top-level function, and can see that the spi_registers are 
acknowledging set_test_mode and unset_test_mode, but in any case the output 
time stream indicates unset_test_mode is ineffective beyond this.

I’d be grateful for any suggestions to remedy this – I can’t see this issue 
discussed on the mailing list.

Cheers
Michael

[casper] adc5g stuck in test mode

[Michael D'Cruze]

Dear all,

I have a somewhat serious issue in that my adc5g seems to have become stuck in 
test mode...
I've messed around a bit with the very many functions within the 
calibrate_all_delays top-level function, and can see that the spi_registers are 
acknowledging set_test_mode and unset_test_mode, but in any case the output 
time stream indicates unset_test_mode is ineffective beyond this.

I'd be grateful for any suggestions to remedy this - I can't see this issue 
discussed on the mailing list.

Cheers
Michael

Re: [casper] Help with Casper Tutorial 3

[Michael D'Cruze]

Hi Heystek,

You need the DSP System Toolbox unfortunately, in order to compile the ADC 
blocks. This is typically a paid-for toolbox, though my local IT Services were 
helpful and had a few spare server licences.

BW
Michael

From: Heystek Grobler [mailto:heystekgrob...@gmail.com]
Sent: 20 September 2016 21:24
To: Michael D'Cruze
Cc: Casper Lists
Subject: Re: [casper] Help with Casper Tutorial 3

Hi Michael
This is the toolboxes that I have:

MATLAB Version: 8.0.0.783 (R2012b)
MATLAB License Number: 724504
Operating System: Linux 3.19.0-68-generic #76~14.04.1-Ubuntu SMP Fri Aug 12 
11:46:25 UTC 2016 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)
Bioinformatics ToolboxVersion 4.2
(R2012b)
Curve Fitting Toolbox Version 3.3
(R2012b)
Database Toolbox  Version 4.0
(R2012b)
Datafeed Toolbox  Version 4.4
(R2012b)
Econometrics Toolbox  Version 2.2
(R2012b)
Financial Instruments Toolbox Version 1.0
(R2012b)
Financial Toolbox Version 5.0
(R2012b)
Fuzzy Logic Toolbox   Version 2.2.16 
(R2012b)
Global Optimization Toolbox   Version 3.2.2  
(R2012b)
Image Acquisition Toolbox Version 4.4
(R2012b)
Image Processing Toolbox  Version 8.1
(R2012b)
Instrument Control ToolboxVersion 3.2
(R2012b)
MATLAB Compiler   Version 4.18   
(R2012b)
Mapping Toolbox   Version 3.6
(R2012b)
Neural Network ToolboxVersion 8.0
(R2012b)
Optimization Toolbox  Version 6.2.1  
(R2012b)
Parallel Computing ToolboxVersion 6.1
(R2012b)
Partial Differential Equation Toolbox Version 1.1
(R2012b)
Signal Processing Toolbox Version 6.18   
(R2012b)
SimMechanics  Version 4.1
(R2012b)
Simscape  Version 3.8
(R2012b)
Simulink 3D Animation Version 6.2
(R2012b)
Stateflow Version 8.0
(R2012b)
Statistics ToolboxVersion 8.1
(R2012b)
Symbolic Math Toolbox Version 5.9
(R2012b)
System Identification Toolbox Version 8.1
(R2012b)
Wavelet Toolbox   Version 4.10   
(R2012b)
Xilinx System Generator   Version 14.7   
production build
It seems that the DSP Toolbox is not included. I have the signal processing 
toolbox. Do you have suggestions of what I can do?
Have a wonderful evening
Heystek


On Tue, Sep 20, 2016 at 8:58 PM, Michael D'Cruze 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
Heystek,

Do you have the DSP System Toolbox installed in Matlab?

Michael

[casper] Help with Casper Tutorial 3

[Michael D'Cruze]

Heystek,

Do you have the DSP System Toolbox installed in Matlab?

Michael

Re: [casper] Spectrum woes

[Michael D'Cruze]

For the benefit of the casper list


From: Andrew Vdb [mailto:avd...@gmail.com]
Sent: 19 September 2016 14:19
To: Michael D'Cruze
Subject: Re: [casper] Spectrum woes

Hi Michael,

Sure - it's the FFT BRAM optimization. The coefficient bug was that we were 
incorrectly applying the coefficients when the data is streamed - it was 
subtle, but enough to prevent the ~60dB out of channel rejection in the PFB we 
were expecting.

Hope that helps.

regards,
Andrew


On Mon, Sep 19, 2016 at 1:01 PM, Michael D'Cruze 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
Hi Andrew,

Thanks for the tip – but you could clarify please whether the BRAM 
optimisations you are referring to are the Xilinx RAM block optimisations I was 
making, i.e. to change the block from optimising for Area to Speed, rather than 
the FFT BRAM optimisation option?

Were you able to determine what caused the bug re: the PFB coefficients? I took 
a look at what the ROM block was calling and it looked ok; was it calling the 
file incorrectly at compile time?

Thanks
Michael

From: Andrew Vdb [mailto:avd...@gmail.com<mailto:avd...@gmail.com>]
Sent: 19 September 2016 07:55
To: Jack Hickish
Cc: Michael D'Cruze; casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>

Subject: Re: [casper] Spectrum woes

Hi all,

We (SKA-SA) saw similar behaviour with our PFB and found it was a combination 
of things - one being to not select BRAM optimisations, and another was a bug 
in the coefficient use in the PFB. Give the 
ska-sa/mlib_deve<https://github.com/ska-sa/mlib_devel>l repo a spin - we pushed 
our fixes a few months back.

Andrew

On Mon, Sep 19, 2016 at 1:00 AM, Jack Hickish 
<jackhick...@gmail.com<mailto:jackhick...@gmail.com>> wrote:
Hi Michael,

Hmmm. Can you link the repo you're using and a reference design?

Thanks
Jack

On Sun, 18 Sep 2016 at 15:05 Michael D'Cruze 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
Hi Jack,

To implement the change in optimisation I altered the delay_bram init script. 
Line 84 which configures the Xilinx ram block, I changed the parameter 
‘optimize’ from ‘Area’ to ‘Speed’. No other changes were made, so, I think this 
is the former case?

BW
Michael

From: Jack Hickish [mailto:jackhick...@gmail.com<mailto:jackhick...@gmail.com>]
Sent: 18 September 2016 22:27
To: Michael D'Cruze; casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>
Subject: Re: [casper] Spectrum woes

Hi Michael,

Is this actually the optimisation parameter of the xilinx bram block, or an 
optimisation of a casper block which completely changes some underlying circuit 
(eg by doing a bunch of fanout control and instantiating multiple small brams 
instead of one big one)?
If the latter, are you sure it's not a bug in the casper implementation? 
Perhaps a mismatch of latency on various things being fanned out?

Trust nothing.

Jack

On Sun, 18 Sep 2016 at 14:21 Michael D'Cruze 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
Dear all,

I’ve been chasing the cause of some nasty artefacts in my spectra recently. The 
first turned out to be a known bug in the Xilinx compiler, activated when the 
BRAM_sharing optimisation in the FFT is checked, however the artefacts I’m 
seeing since seem to be activated by the RAM blocks in the delay_bram block 
being configured for “Speed”, and not the default “Area”.

Below are links to two spectra. They were both recorded from the Lovell 
telescope’s L-band receiver while the telescope was pointing at the zenith. The 
logic used in both cases is identical, with the exception that the delay_brams 
in the first spectra are configured for Speed, and in the second they are 
configured for Area (default). All operating parameters were the same in both 
cases.

https://dl.dropboxusercontent.com/u/38103354/figure_1.png
https://dl.dropboxusercontent.com/u/38103354/r13a_libs_18-09_2207.PNG

Aside from how ugly the first spectrum looks (there are signals in there which 
simply don’t exist), even the accumulated power is different. The vertical 
scale is logarithmic so this is a factor 100 or so higher with the brams 
configured for Speed. I don’t understand how they could be so different, nor 
why configuring the brams for Speed should make any difference at all, not 
least a difference of this magnitude.

The most worrying thing for me now is that configuring the brams for Speed was 
key to getting my larger designs (16k and 32k channels) to meet timing. If I 
need to reconfig for Area, I’m going to have to brawl with Par and PlanAhead 
all over again… It actually took a few goes to get just that 4k channel design 
to compile.

I’d appreciate ideas/suggestions!

Thanks
Michael





--
Dr Andrew van der Byl
Mobile: +27 83 312 7392<tel:%2B27%2083%20312%207392>
Email: 
a<mailto

[casper] Spectrum woes

[Michael D'Cruze]

Dear all,

I've been chasing the cause of some nasty artefacts in my spectra recently. The 
first turned out to be a known bug in the Xilinx compiler, activated when the 
BRAM_sharing optimisation in the FFT is checked, however the artefacts I'm 
seeing since seem to be activated by the RAM blocks in the delay_bram block 
being configured for "Speed", and not the default "Area".

Below are links to two spectra. They were both recorded from the Lovell 
telescope's L-band receiver while the telescope was pointing at the zenith. The 
logic used in both cases is identical, with the exception that the delay_brams 
in the first spectra are configured for Speed, and in the second they are 
configured for Area (default). All operating parameters were the same in both 
cases.

https://dl.dropboxusercontent.com/u/38103354/figure_1.png
https://dl.dropboxusercontent.com/u/38103354/r13a_libs_18-09_2207.PNG

Aside from how ugly the first spectrum looks (there are signals in there which 
simply don't exist), even the accumulated power is different. The vertical 
scale is logarithmic so this is a factor 100 or so higher with the brams 
configured for Speed. I don't understand how they could be so different, nor 
why configuring the brams for Speed should make any difference at all, not 
least a difference of this magnitude.

The most worrying thing for me now is that configuring the brams for Speed was 
key to getting my larger designs (16k and 32k channels) to meet timing. If I 
need to reconfig for Area, I'm going to have to brawl with Par and PlanAhead 
all over again... It actually took a few goes to get just that 4k channel 
design to compile.

I'd appreciate ideas/suggestions!

Thanks
Michael

[casper] Issue with snapshot block

[Michael D'Cruze]

Dear all,

During debugging for the new ROACH2 Lovell spectrometer, I've found a potential 
issue with the snapshot block that I'm hoping is a control issue.
The snapshot block is intended to take a 4096-channel slice of spectrum, and 
display it via a GUI at intervals around 1 second. The spectrum appears to 
"dance" around by a few channels, and in particular on larger designs the 
spectrum seems to scroll across the screen. After ruling out issues with the 
Python interface, I found that the snapshot block itself seemed to be 
generating the address incorrectly. In simulation, the address was lagging 
behind the data and write enable by a few clocks per acc, which created the 
scrolling behaviour.

Now, since circular capture is enabled and 0 are inserted to both the trig and 
stop inputs, I'm writing 0b1011 to snap_control. According to the instructions 
(and, on examination, the logic), this should enable repeated capture, ignoring 
both the stop and trig inputs, but obeying the write_enable. Can I check that 
this input is correct?

Actually writing a block to do only what I need it to do is not difficult, but 
I'd prefer to avoid recompiling everything if it is simply a control issue.

Thanks
Michael

Re: [casper] Design overmapping error

[Michael D'Cruze]

Hi Jack,

Ahh, that explains it. The sum exceeds 100%. I’ll adjust the design….

Thanks
Michael


From: Jack Hickish [mailto:jackhick...@gmail.com]
Sent: 27 June 2016 16:48
To: Michael D'Cruze; casper@lists.berkeley.edu
Subject: Re: [casper] Design overmapping error


Is that 85% including both 18kb and 36kb brams? Could you post your map report?

On Mon, 27 Jun 2016 3:17 pm Michael D'Cruze, 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
Dear all,

I’m trying to compile a relatively simple 64k-channel spectrometer. I’m getting 
an error which indicates I’m overmapping in BRAMs, however the system map 
report indicates I’m using circa 85% of them…. So the design should fit? Has 
anyone else encountered this or could suggest a way forward?

Thanks
Michael

Re: [casper] Trouble getting 10GbE working

[Michael D'Cruze]

Hi Glenn,

I did not have that set at all in the ifcfg script for my eth port, and indeed 
the packets do now flow! Great shout, thanks.

Cheers
Michael

From: G Jones [mailto:glenn.calt...@gmail.com]
Sent: 18 February 2016 09:05
To: Michael D'Cruze
Cc: casper@lists.berkeley.edu
Subject: Re: [casper] Trouble getting 10GbE working


Do you have your MTU set high enough to receive the length of packets you are 
sending?
On Feb 17, 2016 10:40 AM, "Michael D'Cruze" 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
Dear all,

I’m having a little trouble getting the 10GbE data output working correctly. I 
have a spectrometer design which feeds the output of (for the moment) a single 
vacc into the spead_pack block, which then outputs into the 10GbE block.

I can see from the mailing list that I’m not the first person to run into 
problems getting this working ;-)

My efforts thus far have focussed on implementing various gates and counters 
for hardware diagnostic purposes (screenshots below). I have a script which 
reads counters connected to the spead_pack overflow port, and the 10GbE 
tx_full, tx_status, linkup, and tx_overflow ports. Using my current setup I can 
confirm that the tx_full and overflow ports read 0 at all times, and the status 
and linkup ports read 1 at all times. I have “gated” (using registers enabled 
using a software register) the data_in, valid, and eof input ports on the 10GbE 
block. My script currently configures the 10GbE core with a fabric port and IP, 
and dest port and IP before anything else. The tap is started immediately 
following this. A total of 12s sleep time has been written in before a final 
reset pulse is sent to the 10GbE block and finally the data_in, data_valid, and 
eof gates are opened.

All status indicators show that the 10GbE core is not overflowing and packets 
should be coming out, however Wireshark shows nothing apart from basic 
“handshake” packets.

FYI: My spead_pack block is configured for a packet length of 1024 and the eof 
logic is working correctly (pulses on the last valid cycle)

Model screenshot: https://dl.dropboxusercontent.com/u/38103354/Capture.PNG
Scope1 (spead_pack output): 
https://dl.dropboxusercontent.com/u/38103354/Capture2.PNG. The top panel is the 
data, the second panel the valid signal, the third panel the eof pulse, and the 
fourth panel the spead_overflow signal.

Grateful for any advice/ideas/suggestions,

BW
Michael

Re: [casper] Trouble getting 10GbE working

[Michael D'Cruze]

Hi Andrew,

Yep, one of the first things I did. This is what initially pointed to a 
configuration problem. I modified the tut2 design to transmit to a PC’s eth 
port and was able to see packets coming through.

I should also add that using a smaller number of channels in the spectrometer 
design I have, worked. That is, a single vacc outputting 256 channels into 
spead_pack then into the 10GbE block successfully output packets that I could 
see on wireshark. What’s got me confused with the 1024-channel vacc I’m sending 
into the speader and 10GbE block at the moment is that: a) overflow and full 
are both low, b) other designs I’ve seen use much longer packet lengths (e.g. 
8192) without a problem.

BW
Michael

From: Andrew Martens [mailto:and...@ska.ac.za]
Sent: 18 February 2016 06:56
To: Michael D'Cruze
Cc: casper@lists.berkeley.edu
Subject: Re: [casper] Trouble getting 10GbE working

Hi Michael
Have you tested your hardware setup using CASPER tutorial 2?
Regards
Andrew

On Wed, Feb 17, 2016 at 5:40 PM, Michael D'Cruze 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
Dear all,

I’m having a little trouble getting the 10GbE data output working correctly. I 
have a spectrometer design which feeds the output of (for the moment) a single 
vacc into the spead_pack block, which then outputs into the 10GbE block.

I can see from the mailing list that I’m not the first person to run into 
problems getting this working ;-)

My efforts thus far have focussed on implementing various gates and counters 
for hardware diagnostic purposes (screenshots below). I have a script which 
reads counters connected to the spead_pack overflow port, and the 10GbE 
tx_full, tx_status, linkup, and tx_overflow ports. Using my current setup I can 
confirm that the tx_full and overflow ports read 0 at all times, and the status 
and linkup ports read 1 at all times. I have “gated” (using registers enabled 
using a software register) the data_in, valid, and eof input ports on the 10GbE 
block. My script currently configures the 10GbE core with a fabric port and IP, 
and dest port and IP before anything else. The tap is started immediately 
following this. A total of 12s sleep time has been written in before a final 
reset pulse is sent to the 10GbE block and finally the data_in, data_valid, and 
eof gates are opened.

All status indicators show that the 10GbE core is not overflowing and packets 
should be coming out, however Wireshark shows nothing apart from basic 
“handshake” packets.

FYI: My spead_pack block is configured for a packet length of 1024 and the eof 
logic is working correctly (pulses on the last valid cycle)

Model screenshot: https://dl.dropboxusercontent.com/u/38103354/Capture.PNG
Scope1 (spead_pack output): 
https://dl.dropboxusercontent.com/u/38103354/Capture2.PNG. The top panel is the 
data, the second panel the valid signal, the third panel the eof pulse, and the 
fourth panel the spead_overflow signal.

Grateful for any advice/ideas/suggestions,

BW
Michael

[casper] Trouble getting 10GbE working

[Michael D'Cruze]

Dear all,

I'm having a little trouble getting the 10GbE data output working correctly. I 
have a spectrometer design which feeds the output of (for the moment) a single 
vacc into the spead_pack block, which then outputs into the 10GbE block.

I can see from the mailing list that I'm not the first person to run into 
problems getting this working ;-)

My efforts thus far have focussed on implementing various gates and counters 
for hardware diagnostic purposes (screenshots below). I have a script which 
reads counters connected to the spead_pack overflow port, and the 10GbE 
tx_full, tx_status, linkup, and tx_overflow ports. Using my current setup I can 
confirm that the tx_full and overflow ports read 0 at all times, and the status 
and linkup ports read 1 at all times. I have "gated" (using registers enabled 
using a software register) the data_in, valid, and eof input ports on the 10GbE 
block. My script currently configures the 10GbE core with a fabric port and IP, 
and dest port and IP before anything else. The tap is started immediately 
following this. A total of 12s sleep time has been written in before a final 
reset pulse is sent to the 10GbE block and finally the data_in, data_valid, and 
eof gates are opened.

All status indicators show that the 10GbE core is not overflowing and packets 
should be coming out, however Wireshark shows nothing apart from basic 
"handshake" packets.

FYI: My spead_pack block is configured for a packet length of 1024 and the eof 
logic is working correctly (pulses on the last valid cycle)

Model screenshot: https://dl.dropboxusercontent.com/u/38103354/Capture.PNG
Scope1 (spead_pack output): 
https://dl.dropboxusercontent.com/u/38103354/Capture2.PNG. The top panel is the 
data, the second panel the valid signal, the third panel the eof pulse, and the 
fourth panel the spead_overflow signal.

Grateful for any advice/ideas/suggestions,

BW
Michael

[casper] Trouble getting 10GbE working

[Michael D'Cruze]

Dear all,

I'm having a little trouble getting the 10GbE data output working correctly. I 
have a spectrometer design which feeds the output of (for the moment) a single 
vacc into the spead_pack block, which then outputs into the 10GbE block.

I can see from the mailing list that I'm not the first person to run into 
problems getting this working ;-)

My efforts thus far have focussed on implementing various gates and counters 
for hardware diagnostic purposes (screenshots below). I have a script which 
reads counters connected to the spead_pack overflow port, and the 10GbE 
tx_full, tx_status, linkup, and tx_overflow ports. Using my current setup I can 
confirm that the tx_full and overflow ports read 0 at all times, and the status 
and linkup ports read 1 at all times. I have "gated" (using registers enabled 
using a software register) the data_in, valid, and eof input ports on the 10GbE 
block. My script currently configures the 10GbE core with a fabric port and IP, 
and dest port and IP before anything else. The tap is started immediately 
following this. A total of 12s sleep time has been written in before a final 
reset pulse is sent to the 10GbE block and finally the data_in, data_valid, and 
eof gates are opened.

All status indicators show that the 10GbE core is not overflowing and packets 
should be coming out, however Wireshark shows nothing apart from basic 
"handshake" packets.

FYI: My spead_pack block is configured for a packet length of 1024 and the eof 
logic is working correctly (pulses on the last valid cycle)

Model screenshot: https://dl.dropboxusercontent.com/u/38103354/Capture.PNG
Scope1 (spead_pack output): 
https://dl.dropboxusercontent.com/u/38103354/Capture2.PNG. The top panel is the 
data, the second panel the valid signal, the third panel the eof pulse, and the 
fourth panel the spead_overflow signal.

Grateful for any advice/ideas/suggestions,

BW
Michael

Re: [casper] ROACH2 spectrum zeroes: request to verify my results

[Michael D'Cruze]

Hi Jack,

Cc: Casper list

Sorry it’s taken me so long to come back – I got sucked into a few side 
projects. Unfortunately I have to report that the problem still exists: I am 
unable to use the tut3_noquant designs to produce a spectrum – they all contain 
zeroes. For the record (and for the sake of anyone else reading this in 
future), below is a link to an archive containing snips of the back end of my 
designs (vacc onwards), print statements of the first 20 channels, and a plot 
for one of the scenarios. In short, the problem appears to be in the 
propagation of data between the vacc and the brams. I’ve eliminated the brams 
and vaccs individually. The only scenario in which I can produce a proper 
spectrum is where a 32-bit slice is implemented straight after the vacc. Why 
this would help is beyond me, however it does and is the design I am going to 
have to continue with unless a proper solution can be found.

I should add that this problem appears to be independent of the design speed 
(tested down to 100 MHz FPGA clock), and the problem was seen on a ROACH2 with 
the ADC in either port, and also on a ROACH1.

https://dl.dropboxusercontent.com/u/38103354/r2_spectra.zip

BW
Michael

From: Jack Hickish [mailto:jackhick...@gmail.com]
Sent: 12 January 2016 21:28
To: Michael D'Cruze
Subject: Re: [casper] ROACH2 spectrum zeroes: request to verify my results

Hi Michael,

That's weird. The adc should be fine in either port. As long as the adc yellow 
block zdok port and the adcX_clk match in the mssge block.

Jack
On Tue, 12 Jan 2016 1:09 pm Michael D'Cruze 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
Hi Jack,

Thanks for that. I can’t see any differences between your model file and mine, 
EXCEPT that my iADC is in ZDOK1. I recall seeing some advice to use ZDOK0 
instead however I was under the impression any of the issues were sorted. This 
also doesn’t explain why the spectrum forms correctly when requantisation and 
32-bit accumulators are used.

Because of BBC Stargazing, I won’t be able to get at the ROACH to move the iADC 
to ZDOK0 and test your boffile, so I’ll drop you a line when I’ve got the 
results. I did, however, try my model file which was compiled to run at 800 MHz 
(now that I’ve had a chance to get at the sig gen which clocks the ADC) and the 
result was essentially the same. There were still zeroes.

I’ll update you Thursday afternoon.

Cheers
Mike

From: Jack Hickish [mailto:jackhick...@gmail.com<mailto:jackhick...@gmail.com>]
Sent: 12 January 2016 19:38
To: Michael D'Cruze

Subject: Re: [casper] ROACH2 spectrum zeroes: request to verify my results


On Mon, 11 Jan 2016 at 16:03 Michael D'Cruze 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
Jack,

Please send me your model and boffiles. I need to try these here.

Attached. I've also attached the python script, for good measure.

I’ve just done exactly what you specified here, and this is how the first 20 
channels appear:

[image001.png]

Now, I compiled the design to run at 256 MHz as is required by the sampling 
speed we need to use, and as such there were some timing errors initially. I 
deleted the three LED readouts as they weren’t needed, but I also needed to add 
a clock cycle of latency to the adder in each of the VACCs. There was negative 
slack between the readout of the delay_bram’s RAM block and the adder. I can’t 
see how this could cause such zeroes but nevertheless please add your thoughts.

I don't see how this would cause zeros (I'm not sure changing the adder delay 
doesn't subtly mess up the timing in the vacc, but I'd need to take a second to 
think about it). For what it's worth, I'm running mine adc0_clk @ 200MHz (adc 
in ZDOK one with sample rate 800MHz).


Jack


I will not be able to try the design at 800 MHz until I get to Jodrell in the 
morning, but I’ll eat my hair if it outputs a proper spectrum….

BW
Michael

From: Jack Hickish [mailto:jackhick...@gmail.com<mailto:jackhick...@gmail.com>]
Sent: 11 January 2016 19:34
To: Michael D'Cruze; casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>
Subject: Re: [casper] ROACH2 spectrum zeroes: request to verify my results

Hi Michael,

I just cloned https://github.com/casper-astro/tutorials_devel.git and compiled 
tut3_noquant_r111 against mlib_devel b6e70b660910482b1f1028d32d29284468e38cda 
using Xilinx 14.7 and MATLAB 2012b (I ran update_casper_blocks(bdroot) on the 
model, and changed the target for roach2 before compiling).

The resulting boffile outputs reasonable looking spectra when snapped with 
tut3_noquant_r111.py from the tutorials_devel repository (with default options, 
specifying only the boffile and roach2 host). I printed the first 20 channels 
and there are no zeros.

Jack





On Tue, 5 Jan 2016 at 05:21 Michael D'Cruze 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr

[casper] ROACH2 spectrum zeroes: request to verify my results

[Michael D'Cruze]

Dear all,

First of all a happy new year to everyone!

I continue to chase the problem I've been having for some time now, i.e. 
spectrometer designs accumulating using 64-bit vacc blocks output zeroes for 
every other channel. This happens with the tut3_noquant tutorial design as well 
which is worrying. I've tried compiling the raw tut3_noquant design on three 
separate machines using all perturbations of the 14.x ISE versions, MATLAB 
2012b and 2013a, as well as a few different versions of the CASPER libraries. I 
have also run the design on both a ROACH-1 and a ROACH-2. I believe this 
eliminates most random possibilities...

I am hoping, if you have some time, that a few of you could try to verify what 
I'm seeing. This should just involve compiling the tut3_noquant design, running 
it, then pulling off a spectrum.

Many thanks in advance
Michael

Re: [casper] casper Digest, Vol 95, Issue 3: FFT problems

[Michael D'Cruze]

Hi Andrew,

My supervisors and I have just recently met to discuss the situation, and would 
just like to clarify your final paragraph: do I infer correctly that the casper 
toolflow is being upgraded to use more recent Xilinx compilation suites? It 
also sounds like Xilinx is reducing support for ISE…

Thanks
Michael

From: Andrew Martens [mailto:and...@ska.ac.za]
Sent: 16 November 2015 06:36
To: Michael D'Cruze
Cc: Jonathon Kocz (jxk...@gmail.com); casper@lists.berkeley.edu
Subject: Re: casper Digest, Vol 95, Issue 3: FFT problems

Hi Michael
Sorry for the very late response.
The problem was narrowed down to  a multiplexer in the 
butterfly_direct/twiddle/coeff_gen/cosin/add_convert1 block when it is used in 
the fft_direct block for a small FFT. Twiddle factors in this case are a 
fraction of a cycle of a complex exponential with the factors appearing in 
order (i.e not bit reversed). You can generate this case by dropping a 
butterfly_direct block into an empty design and choosing the following 
parameters (Size of FFT: 5, Coefficients: [0:3], Coefficient Step Period: 1, 
others default)

If you look at the logic generating the lookup address of these twiddle factors 
eg in butterfly_direct/twiddle/coeff_gen/cosin/add_convert1 you will see that 
Mux chooses whether to take the address generated as is (new_add), or the 
address subtracted from a constant (AddSub). The sel input of Mux is controlled 
by the bit identifying whether the address is in an odd or even quarter of the 
address space.

AddSub5 calculates which quadrant of the address space the address will be in 
and the general case is that the address will step through all quadrants. In 
the fft_direct case, only a fraction of the address space is traversed so that 
this is a constant (notice pad and direction_offset are constants).

In this case we would expect the Xilinx compiler to notice that the output of 
AddSub5 will be constant and to optimise Mux away and just choose the 
appropriate input based on the constant quadrant index. We found that the Mux 
would be optimised away, but that the wrong output would be chosen! The complex 
component of our twiddle factor would thus have the wrong phase.
We found that unchecking 'BRAM sharing in coeff storage' in the Implementation 
tab of the fft_direct block prevented this as the address generation logic 
would be different. We also found that this bug did not occur when compiling 
for ROACH/Virtex 5 (only ROACH2/Virtex 6).
I am not sure if you are seeing this bug though. You have a very large FFT such 
that the fft_direct blocks should generate their twiddle coefficients using the 
feedback_osc block (controlled using the 'Generate coefficients using 
multipliers where useful'  option in the Implementation tab. This generates the 
twiddle coefficients by starting with a complex vector and rotating it a fixed 
phase to generate the new complex vector.

It is worth noting that this bug was very sensitive. Adding logic to try to 
debug things, or cutting and pasting logic into an empty design to isolate the 
logic from the rest of the system sometimes caused the error not to occur. We 
tried compiling with RHEL5 as it seemed similar to Dan's FFT bug when using 
non-approved operating systems but this did not help.
We hope that these types of bugs do not occur in the new Vivado compiler suite 
that seems to be producing good results and which Xilinx seems to be giving its 
full support.

Regards
Andrew



On Wed, Nov 11, 2015 at 5:47 PM, Michael D'Cruze 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
Hi Andrew, Jonathon,

Andrew: I was wondering if you'd kept a record of which precise counter (when 
implemented in behavioural HDL) caused FFT output to be incorrect? I would like 
to take a look and see if this is also my problem.
I also wondered if you knew which ISE versions you had tried...

Do I understand correctly that the problems seem to lie in Xilinx's compilation 
tools?

Thanks
Michael

-Original Message-
From: 
casper-boun...@lists.berkeley.edu<mailto:casper-boun...@lists.berkeley.edu> 
[mailto:casper-boun...@lists.berkeley.edu<mailto:casper-boun...@lists.berkeley.edu>]
 On Behalf Of 
casper-requ...@lists.berkeley.edu<mailto:casper-requ...@lists.berkeley.edu>
Sent: 07 October 2015 20:11
To: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>
Subject: casper Digest, Vol 95, Issue 3

Send casper mailing list submissions to
casper@lists.berkeley.edu<mailto: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<mailto:casper-requ...@lists.berkeley.edu>

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

[casper] startsg issue (Xilinx?)

[Michael D'Cruze]

Hi all,

As part of my attempts to narrow down the cause of the FFT problems I'm having 
(well-documented), I'm trying different versions of ISE. I want to try most of 
the 14.x versions plus some rather older versions.

I've installed the versions I want to try but when I change the startsg.local 
file for any version other than 14.7 I get the error displayed at the bottom of 
this email. A similar issue appears on the mail archive but this was apparently 
solved by reinstalling Xilinx ISE. This hasn't worked for me. I have also tried 
deleting the entire /opt/Xilinx folder and reinstalling *only* the older 
version. This also did not work. MATLAB still successfully starts when 
startsg.local is looking for ISE 14.7.

This seems a rather silly error and would seem to be something to do with the 
startup scripts, though I can't immediately see any problems. I'd be grateful 
for any suggestions...

Cheers
Michael

Error:





   Segmentation violation detected at Sun Nov 15 18:51:19 2015





Configuration:

  Crash Decoding : Disabled

  Current Visual : 0x21 (class 4, depth 24)

  Default Encoding   : UTF-8

  GNU C Library  : 2.12 stable

  MATLAB Architecture: glnxa64

  MATLAB Root: /opt/MATLAB/2013a

  MATLAB Version : 8.1.0.604 (R2013a)

  Operating System   : Linux 2.6.32-573.8.1.el6.x86_64 #1 SMP Fri Sep 25 
19:24:22 EDT 2015 x86_64

  Processor ID   : x86 Family 6 Model 45 Stepping 7, GenuineIntel

  Virtual Machine: Java 1.6.0_17-b04 with Sun Microsystems Inc. Java 
HotSpot(TM) 64-Bit Server VM mixed mode

  Window System  : The X.Org Foundation (1150), display :1.0



Fault Count: 1





Abnormal termination:

Segmentation violation



Register State (from fault):

  RAX = 7f404af6a8f0  RBX = 0020

  RCX = 7f3bbc744618  RDX = 7f404af6a8e0

  RSP = 7f4036736430  RBP = 7f3bbc8c5408

  RSI = 7f3bbc744642  RDI = 0020



   R8 =    R9 = d501

  R10 = 0045  R11 = 

  R12 = 7f4036736ec0  R13 = 

  R14 =   R15 = 7f3bbc744642



  RIP = 7f404bd6f904  EFL = 00010206



   CS = 0033   FS =    GS = 



Stack Trace (from fault):

[  0] 0x7f404bd6f904 
/opt/MATLAB/2013a/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6+00669956 
_ZNSsD1Ev+0004

[  1] 0x7f404acecc68 
/opt/MATLAB/2013a/bin/glnxa64/libboost_log_setup.so.1.49.0+01846376 
_ZN5boost9xpressive13match_resultsIN9__gnu_cxx17__normal_iteratorIPKcSsEEED1Ev+0040

[  2] 0x7f3bb4e992a2 
/opt/Xilinx/14.4/ISE_DS/ISE/sysgen/bin/lin64/../../lib/lin64/libsysgen.so+05595810
 _ZN6Sysgen7Utility25getToolVersionFromFilesetERKSs+1698

[  3] 0x7f3bb4e99d92 
/opt/Xilinx/14.4/ISE_DS/ISE/sysgen/bin/lin64/../../lib/lin64/libsysgen.so+05598610
 _ZN6Sysgen7Utility22getVivadoHLSInstallDirEv+0226

[  4] 0x7f3bb58b5957 
/opt/Xilinx/14.4/ISE_DS/ISE/sysgen/bin/lin64/xlmeta.mexa64+00022871

[  5] 0x7f3bb58b7248 
/opt/Xilinx/14.4/ISE_DS/ISE/sysgen/bin/lin64/xlmeta.mexa64+00029256 
mexFunction+0248

[  6] 0x7f4044a58f8a
/opt/MATLAB/2013a/bin/glnxa64/libmex.so+00110474 mexRunMexFile+0090

[  7] 0x7f4044a550f9
/opt/MATLAB/2013a/bin/glnxa64/libmex.so+00094457

[  8] 0x7f4044a55f1c
/opt/MATLAB/2013a/bin/glnxa64/libmex.so+00098076

[  9] 0x7f404d1a06b2 
/opt/MATLAB/2013a/bin/glnxa64/libmwm_dispatcher.so+00562866 
_ZN8Mfh_file11dispatch_fhEiPP11mxArray_tagiS2_+0594

[ 10] 0x7f404cc2abf6 
/opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+04262902

[ 11] 0x7f404cc2b37a 
/opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+04264826

[ 12] 0x7f404cc2beea 
/opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+04267754

[ 13] 0x7f404ca8ebbd 
/opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+02575293

[ 14] 0x7f404caba412 
/opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+02753554

[ 15] 0x7f404caba53f 
/opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+02753855

[ 16] 0x7f404cbd7500 
/opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+03921152

[ 17] 0x7f404c9f38ac 
/opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+01939628

[ 18] 0x7f404c9ef993 
/opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+01923475

[ 19] 0x7f404c9f0797 
/opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+01927063

[ 20] 0x7f404ca5be50 
/opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+02367056

[ 21] 0x7f404d1a06b2 
/opt/MATLAB/2013a/bin/glnxa64/libmwm_dispatcher.so+00562866 
_ZN8Mfh_file11dispatch_fhEiPP11mxArray_tagiS2_+0594

[ 22] 0x7f404ca3e256 
/opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+02245206

[ 23] 0x7f404c9ca09d 
/opt/MATLAB/2013a/bin/glnxa64/libmwm_interpreter.so+01769629

[ 24] 

Re: [casper] FFT woes

[Michael D'Cruze]

Hi Jack

Sorry it’s taken me so long to come back (I’m going to write back to everyone 
shortly). I’ve been chasing a few hunches I’ve had which might have exonerated 
the FFT, but to no avail. Indeed the FFT does simulate OK, but in the majority 
of cases in hardware every other channel is a zero. I say in the majority of 
cases, because in one or two cases the design works correctly. I have not been 
able to find a reason for this yet.

BW
Michael

From: Jack Hickish [mailto:jackhick...@gmail.com]
Sent: 03 November 2015 01:01
To: Michael D'Cruze
Cc: casper@lists.berkeley.edu
Subject: Re: [casper] FFT woes

Hi Michael,

Just so everyone is on the same page -- does your issue only show up in 
hardware like Andrew/Jonathon's - i.e., in simulation the FFT works ok?

Jack

On 3 November 2015 at 00:57, Michael D'Cruze 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
Dear all,

Following on from the email thread from Jonathan Kocz and Andrew Martens about 
odd FFT outputs….

I’ve been experiencing similar inexplicable problems for a while now. Every 
other channel in my output is invariably a zero. I’ve tried everything I can 
think of, including solutions along the lines of those observed to work by 
Jonathan and Andrew (black-boxing, changing mask parameters etc.), in addition 
to wiping clean my libraries and re-syncing with casper-astro-soak-test. I’ve 
even re-drawn the entire model from scratch. The results are always the same. 
Below is a link to an example output.

https://dl.dropboxusercontent.com/u/38103354/32k_test_image.png

Hopefully it’s clear from a_0 (note that a_0 is zoomed in, a_1 is not) that 
every other channel outputs zero, and the interleaved a_0 and a_1 spectra (to 
form the full 32k channel spectrum) are interleaving correctly to produce pairs 
of zeroes. I’ve been trying various things for quite a while now, without 
success and would appreciate some suggestions…!

Thanks
Michael

Re: [casper] casper Digest, Vol 95, Issue 3: FFT problems

[Michael D'Cruze]

Hi Andrew, Jonathon,

Andrew: I was wondering if you'd kept a record of which precise counter (when 
implemented in behavioural HDL) caused FFT output to be incorrect? I would like 
to take a look and see if this is also my problem.
I also wondered if you knew which ISE versions you had tried...

Do I understand correctly that the problems seem to lie in Xilinx's compilation 
tools?

Thanks
Michael

-Original Message-
From: casper-boun...@lists.berkeley.edu 
[mailto:casper-boun...@lists.berkeley.edu] On Behalf Of 
casper-requ...@lists.berkeley.edu
Sent: 07 October 2015 20:11
To: casper@lists.berkeley.edu
Subject: casper Digest, Vol 95, Issue 3

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. Re: FFT problems (Andrew Martens)


--

Message: 1
Date: Wed, 7 Oct 2015 10:17:59 +0200
From: Andrew Martens 
Subject: Re: [casper] FFT problems
To: Jonathon Kocz 
Cc: "casper@lists.berkeley.edu" 
Message-ID:

Re: [casper] FFT woes

[Michael D'Cruze]

Hi Dan,

I have read about such problems. I’m using Red Hat version 6.7. We were 
originally using Debian but switched exclusively because it was, at the time, 
the only linux O/S that Xilinx would support.

Reinstalling the O/S isn’t really an option, but trashing and reinstalling ISE 
might be…. This hasn’t worked for Andrew Martens et al., however.

BW
Michael

From: dan.werthi...@gmail.com [mailto:dan.werthi...@gmail.com] On Behalf Of Dan 
Werthimer
Sent: 11 November 2015 18:38
To: Michael D'Cruze
Cc: Jack Hickish; casper@lists.berkeley.edu
Subject: Re: [casper] FFT woes


hi michael,

what operating system are you using?
we have seen problems where the FFT works in simulation,
and doesn't produce correct results on the FPGA when we were compiling using a 
non-xilinx supported
operating system.
the problem occurred only for large FFT's -  i think 8K or larger.

best wishes,

dan


On Wed, Nov 11, 2015 at 7:34 AM, Michael D'Cruze 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
Hi Jack

Sorry it’s taken me so long to come back (I’m going to write back to everyone 
shortly). I’ve been chasing a few hunches I’ve had which might have exonerated 
the FFT, but to no avail. Indeed the FFT does simulate OK, but in the majority 
of cases in hardware every other channel is a zero. I say in the majority of 
cases, because in one or two cases the design works correctly. I have not been 
able to find a reason for this yet.

BW
Michael

From: Jack Hickish [mailto:jackhick...@gmail.com<mailto:jackhick...@gmail.com>]
Sent: 03 November 2015 01:01
To: Michael D'Cruze
Cc: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>
Subject: Re: [casper] FFT woes

Hi Michael,

Just so everyone is on the same page -- does your issue only show up in 
hardware like Andrew/Jonathon's - i.e., in simulation the FFT works ok?

Jack

On 3 November 2015 at 00:57, Michael D'Cruze 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
Dear all,

Following on from the email thread from Jonathan Kocz and Andrew Martens about 
odd FFT outputs….

I’ve been experiencing similar inexplicable problems for a while now. Every 
other channel in my output is invariably a zero. I’ve tried everything I can 
think of, including solutions along the lines of those observed to work by 
Jonathan and Andrew (black-boxing, changing mask parameters etc.), in addition 
to wiping clean my libraries and re-syncing with casper-astro-soak-test. I’ve 
even re-drawn the entire model from scratch. The results are always the same. 
Below is a link to an example output.

https://dl.dropboxusercontent.com/u/38103354/32k_test_image.png

Hopefully it’s clear from a_0 (note that a_0 is zoomed in, a_1 is not) that 
every other channel outputs zero, and the interleaved a_0 and a_1 spectra (to 
form the full 32k channel spectrum) are interleaving correctly to produce pairs 
of zeroes. I’ve been trying various things for quite a while now, without 
success and would appreciate some suggestions…!

Thanks
Michael

[casper] FFT woes

[Michael D'Cruze]

Dear all,

Following on from the email thread from Jonathan Kocz and Andrew Martens about 
odd FFT outputs

I've been experiencing similar inexplicable problems for a while now. Every 
other channel in my output is invariably a zero. I've tried everything I can 
think of, including solutions along the lines of those observed to work by 
Jonathan and Andrew (black-boxing, changing mask parameters etc.), in addition 
to wiping clean my libraries and re-syncing with casper-astro-soak-test. I've 
even re-drawn the entire model from scratch. The results are always the same. 
Below is a link to an example output.

https://dl.dropboxusercontent.com/u/38103354/32k_test_image.png

Hopefully it's clear from a_0 (note that a_0 is zoomed in, a_1 is not) that 
every other channel outputs zero, and the interleaved a_0 and a_1 spectra (to 
form the full 32k channel spectrum) are interleaving correctly to produce pairs 
of zeroes. I've been trying various things for quite a while now, without 
success and would appreciate some suggestions...!

Thanks
Michael

[casper] Weird FFT block problem

[Michael D'Cruze]

Hi all,

I had an odd problem while messing about with the FFT block today - on setting 
a new combination of parameters and attempting a new compile, an error came up 
which I've never seen before. Something along the lines of an initialisation 
error in the FFT. On inspection, the component blocks within the FFT were in 
pieces and not linked up correctly. In the biplex core itself there was nothing 
except the in/out ports. This is very strange and I can't find anything similar 
on the mailing list. I've solved it by erasing and re-cloning the CASPER 
libraries, however wondered if anyone had a clue why this would happen? FYI 
update_blocks didn't help.

Thanks
Michael

Re: [casper] Weird FFT block problem

[Michael D'Cruze]

Hi Jack,

After cycling through the settings I think I’ve isolated the issue. I was a bit 
quick to declare a solution….i was able to repeat the problem. The problem 
occurs when the BRAM latency is set to >10. I appreciate this may seem 
excessive in any case however as you know I’m messing with settings to get a 
2^17 point FFT block to compile at 256 MHz…

When the problem first arose I grabbed the latest casper-astro-soak-test 
commit, which didn’t solve the immediate issue.

Perhaps someone could confirm that bram latencies >10 causes this issue? It’s a 
2^17 point FFT with fanout 1.

BW
Michael

From: Jack Hickish [mailto:jackhick...@gmail.com]
Sent: 06 October 2015 15:50
To: Michael D'Cruze; casper@lists.berkeley.edu
Subject: Re: [casper] Weird FFT block problem

Hi Michael,

If the initialisation script fails half way through drawing then often you'll 
be left with a bunch of blocks half connected, so I think that's (probably) a 
symptom rather than a cause of the issue. Are you using the latest casper-astro 
branch? Do you remember what FFT parameters you were using? Was it a block 
fresh from the library of one you had previously configured? If the latter, do 
you remember how it was configured?
Gonna be tricky to track this down if it can't be recreated...

Cheers,
Jack

On Tue, 6 Oct 2015 at 15:25 Michael D'Cruze 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
Hi all,

I had an odd problem while messing about with the FFT block today – on setting 
a new combination of parameters and attempting a new compile, an error came up 
which I’ve never seen before. Something along the lines of an initialisation 
error in the FFT. On inspection, the component blocks within the FFT were in 
pieces and not linked up correctly. In the biplex core itself there was nothing 
except the in/out ports. This is very strange and I can’t find anything similar 
on the mailing list. I’ve solved it by erasing and re-cloning the CASPER 
libraries, however wondered if anyone had a clue why this would happen? FYI 
update_blocks didn’t help.

Thanks
Michael

[casper] Spectrum issues

[Michael D'Cruze]

Hi everyone,

I'm having quite a lot of trouble getting large-ish designs (16k channels) to 
produce spectra. The spectra that are being produced are quite strange. I've 
provided links below to a few examples. The first link is the spectrum produced 
by the unmodified tut3 model (except for the ADC and FPGA clocks increased to 
1024 MHz and 256 MHz, respectively). It's pretty much as you'd expect - a 
bog-standard L-band spectrum full of RFI. The second link is what happens when 
I try to increase the number of channels to 16k. As you can see, I can pull 16k 
channels from the board, but there are no actual data in there, beyond the 
original 2k channels. All the usual blocks were modified to get the model to 
work at 16k channels: the #PFB and #FFT points increased to 32768, the vector 
length in the VACC increased to 8192, the sync_gen block (using for now before 
changing to a PPS-based system) adjusted, and the shared_brams adjusted for 
longer address length. The third link is a zoomed-in image of the same 
spectrum, just to show that there is a partial spectrum in there. The fourth 
link is what comes out when I replace the FFT and PFB blocks with 
black-boxes... where the pre-compiled PFB and FFT blocks have the same settings 
as in the previous spectra! The inconsistency between compiling with "raw" 
blocks and pre-compiled blocks is another source of concern.

https://dl.dropboxusercontent.com/u/38103354/tut3_spectrum.png
https://dl.dropboxusercontent.com/u/38103354/tut3_mod3_correct.png
https://dl.dropboxusercontent.com/u/38103354/tut3_mod3.png
https://dl.dropboxusercontent.com/u/38103354/tut3_mod2.png

I can also make my models available if anyone would like. If I were to list 
every setting I'd changed to try and get this to work, this email would take 
about an hour to write but I've kept a log of everything I've tested. So, 
I'd be very grateful for suggestions for what to do next... I really have run 
out of ideas. I've compared the settings I'm using to the VEGAS models 
available on the git repo, and have even looked back to the deprecated "million 
channel spectrometer" model to look at the block settings used there. Nothing 
seems very different to what I'm doing.

I'm going for 16k channels at the moment just because I was having trouble 
getting timing closure on 32k channels in 2-pols, with all the backend logic. 
Eventually I need to get a 64k channel model in 1-pol working, with the 5 GS/s 
ASIAA ADC, so this pre-requisite is essential.

Many thanks in advance
Michael

P.S. I should add that the 1024 MHz ADC clock has to stay fixed because the 
downconverted 500 MHz L-band signal comes into the ADC at 0.5-1 GHz

Re: [casper] Mystery timing errors

[Michael D'Cruze]

Hi Jack,

Thanks for your suggestions! It’s taken me a little while to work through it 
all.

I did manage to get a 2-pol, 32k channel design to compile eventually. I think 
it was a combination of a) sufficient latency in the Vacc and PFB blocks (as 
you suggest) and b) splitting the two pols into two separate chains, rather 
than using one block for the PFB and FFT in biplex mode. It was found by just 
iterating through latency combinations until the timing started to converge, 
but there were still several hundred errors until I split up the design into 
two chains. Now, I don’t really understand why using two separate PFB/FFT 
blocks should make a difference (surely sysgen sorts such detail?), but the 
latency settings were:

PFB: Add Latency 1; Mult latency 2; BRAM latency 3; Fanout latency 1; Convert 
latency 1 (4 taps).
Vacc: Add latency 2; BRAM latency 6 (overkill?); Mux latency 0,

where DSP48 has been used wherever possible in the design.

Now I need to see if it still works if I use more FIR taps ;-)

Best wishes
Michael

From: Jack Hickish [mailto:jackhick...@gmail.com]
Sent: 30 August 2015 21:57
To: Michael D'Cruze
Cc: casper@lists.berkeley.edu
Subject: Re: [casper] Mystery timing errors

Hi Michael,

As one of the Xilinx timing closure documents helpfully articulates, it's very 
difficult to give specific recipes for solving timing problems, other than 
reading the timing report, looking at things in PlanAhead/FPGA Editor, 
iterating compiles and developing some intuition.

That said, there are a few things you could try, of varying levels of 
complexity --
Since you have quite a lot of channels in your design, I suspect your vacc 
problems are related to the size of the bram buffer (especially if your samples 
are wide). Keep in mind that a bram in a Virtex6 is a 36 bit wide x 1k deep 
memory block, so building a vacc to accommodate many thousands of channels 
means banking together lots of brams -- this is liable to cause fanout issues 
on your address/control signals. The same is probably true of the large delays 
in the PFB blocks, though I'm not sure how these are implemented in the various 
block versions which exist in mlib_devel.
Setting brams to optimize for speed and giving them at least 3 cycles latency 
may help. You could also try manually controlling bram control signals -- I 
believe the casper_library_bus/bus_single_port_ram block will do some of this 
for you if you set to optimize for speed and include some fanout latency. If 
you replace the bram delay in the vacc with one of these (and associated 
address counter logic to make the block act as a delay) then perhaps this will 
help. Be careful to get your latencies right so the block still functions 
properly.
You might also find that implementing the adder in a DSP slice (if you haven't 
already) might help.

A more involved option is to go about manually constraining the placement of 
components. You might find setting up pblocks in PlanAhead to place major parts 
of your design might free up the compiler to do a little better with the 
remainder of the logic. Adding pblocks for the pfb, and the various FFT stages 
can be very helpful in this regard. Or perhaps just constraining the vacc 
that's causing you problems might be enough.
Once you have some constraints from planahead which work, you can auto-include 
them in your simulink compiles using various methods, my favourite being the 
'UCF' yellow block, which is in the current casper-astro mlib_devel.

In general, I suspect that you would be well served by trying to reduce your 
bram use in your model - the resource utilisation report can probably either 
confirm or contest that this is the case. You could do this by trying to use 
alternatives to brams where blocks allow it (for example the FFT will allow 
coefficients to be generated using DSPs in some cases), or by reducing the 
number of FIR taps, or implementing something using QDR rather than bram if 
appropriate.

The unfortunate truth is that some, none or all of these suggestions may help, 
or might make things worse. I would say that in my experience over-judicious 
use of pipeline/register stages throughout a design can often do more harm than 
good, and a sensibly placed PFB can result in incredible timing improvements.

Hope that helps, please email back with any more info and/or updates -- I 
suspect if you solve this problem documenting your method may prove very useful 
for others encountering similar problems.

Cheers, and good luck!
Jack

On 30 August 2015 at 10:42, Michael D'Cruze 
<michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>>
 wrote:
>
> Hi everyone,
>
>
>
> I’m having quite a lot of problems getting a particular design to compile, 
> XPS consistently reporting timing errors. The design is a wideband 
> spectrometer, somewhat similar to the tutorial 3 design. I’m running an iADC 
> at 1024 MHz, and the FPGA at 2

[casper] Mystery timing errors

[Michael D'Cruze]

Hi everyone,

I'm having quite a lot of problems getting a particular design to compile, XPS 
consistently reporting timing errors. The design is a wideband spectrometer, 
somewhat similar to the tutorial 3 design. I'm running an iADC at 1024 MHz, and 
the FPGA at 256 MHz. It is a two-polarisation design, with a 64k-point PFB and 
FFT (for 32k channels) in each polarisation. I am running the PFB and FFT 
blocks in two-polarisation mode, so there are just one of each block. I am 
using the Vacc block from the xBlocks repository.

I should add at this point that the same design with 16k channels compiles 
successfully at this speed, and that the 32k channel design compiles at slower 
speeds (e.g. 200 MHz FPGA).

The timing reports suggest negative slack in the PFB and Vacc blocks. I've 
tried adding various combinations of latency in each, however no permutations 
have resulted in substantial improvements. The overwhelming majority of the 
errors are reported by the Vacc block. I have also tried replacing the xBlocks 
Vacc block with the wide_bram_vacc block in 64-bit mode, however this results 
in even more timing errors (and without the option to adjust latencies).

I've tried various combinations of latencies suggested previously on the mail 
archive, but again nothing has really given any improvement.

Am I simply pushing such a large design too hard? Is the only option to slow it 
down or is there some strategic method I can adopt to get closer to timing 
closure? Suggestions much appreciated!

Thanks
Michael

[casper] 5GS/s ADC compile errors

[Michael D'Cruze]

Hello,

I'm getting an error on compiling a spectrometer design which I'm having 
trouble understanding. The following appears in the command line interface:

ERROR:PhysDesignRules:2506 - Incorrect placement for a BUFR component. BUFR
   mdl_bbox_quant_asiaa_adc5g/mdl_bbox_quant_asiaa_adc5g/DIVBUF in clock region 
CLOCKREGION_X0Y7 is driven by a CCIO
   adc0clk_p in clock region CLOCKREGION_X0Y5. The BUFR should be placed in the 
same clock region as the CCIO or the
   CLOCK_DEDICATED_ROUTE constraint should be used on the net
   mdl_bbox_quant_asiaa_adc5g/mdl_bbox_quant_asiaa_adc5g/adc_clk.
ERROR:Pack:1642 - Errors in physical DRC.

It reads to me as if there's something wrong with the ADC block internally, but 
as I've got a very recent commit I can't see how that could be, especially 
given the number of people using this block...

For completeness, I'm using a 2048 MHz ADC clock in single channel mode (for 
2048 MHz input bandwidth) and have set the fabric clock to 4096/16=256 MHz 
running off the ADC clock. The actual ADC is in ZDOK0.

Any help would be greatly appreciated; I can only see one error similar to this 
on the mail archive and it seemed to have been fixed in a subsequent mlib_devel 
commit.

Thanks
Michael

Re: [casper] VHDL black-boxing: basic issue

[Michael D'Cruze]

Hi guys,

Just to say that Xilinx came back with a pretty standard response, evidently 
not reading through my message thoroughly enough. After explaining a second 
time, the only suggestion they could come back with was to reinstall everything 
(Matlab, Xilinx ISE etc.) which I’ve now done, and the black boxing seems to be 
working.

If anyone comes across this in future….”brute force” reinstallation worked for 
me. Though I still have no idea what caused the problem in the first place.

Thanks
Michael

From: Homin Jiang [mailto:ho...@asiaa.sinica.edu.tw]
Sent: 10 August 2015 04:24
To: Michael D'Cruze
Subject: [casper] VHDL black-boxing: basic issue

Hi Michael:

Which version of toolflow you are using ?
If V14.7, following is my own solution, hope that help:

  *   Or right click the black box on the library icon, then select the VHD 
file, for example, amiba2_v147/fft_1k_core.vhd. This vhd file has the same name 
as the one under amiba2_v147/fft_1k_core. Don't get mess up.
  *   copy the *.m file from the subdirectories to upper level. i.e. copy 
fgain_core_config.m from /amiba2_v147/fgain_core to amiba2_v147. Because the 
black box only search the config file in the same directory.
  *   Check the  this_block.addFile('vhd') in the config.m file, it has to be 
correct vhd filename, for example: cdelay_core.vhd, not just vhd.
homin jiang



Message: 4
Date: Fri, 7 Aug 2015 14:50:41 +
From: Michael D'Cruze 
michael.dcr...@postgrad.manchester.ac.ukmailto:michael.dcr...@postgrad.manchester.ac.uk
Subject: [casper] VHDL black-boxing: basic issue
To: 'casper@lists.berkeley.edumailto:casper@lists.berkeley.edu' 
casper@lists.berkeley.edumailto:casper@lists.berkeley.edu
Message-ID:

am2pr01mb0385dc4804c6367dcdff39828a...@am2pr01mb0385.eurprd01.prod.exchangelabs.commailto:am2pr01mb0385dc4804c6367dcdff39828a...@am2pr01mb0385.eurprd01.prod.exchangelabs.com

Content-Type: text/plain; charset=us-ascii

Hi Casper,

I'm trying to black box some of my larger blocks (PFB, FFT), initially 
following tutorial 6 and the memo on the wiki. Both say that, as soon as the 
black box is dropped into the model, it should throw up a dialog box allowing 
me to link to the pre-compiled code. However, this dialog doesn't come up. I 
can't see any other instances of this on the mail archive... does anyone have 
any ideas how to solve this, or get the block to manually link to the .vhd 
file? I can't see anything obvious from within Simulink. This seems a really 
silly problem!

Thanks
Michael
-- next part --
An HTML attachment scrubbed and removed.
HTML attachments are only available in MIME digests.

End of casper Digest, Vol 93, Issue 7
*

Re: [casper] VHDL black-boxing: basic issue

[Michael D'Cruze]

Hi Homin,

Thanks for coming back to me. The issue was that the VHD file selection dialog 
box wasn’t coming up at all. It’s still unclear why this is…

Best,
Michael

From: Homin Jiang [mailto:ho...@asiaa.sinica.edu.tw]
Sent: 10 August 2015 04:24
To: Michael D'Cruze
Subject: [casper] VHDL black-boxing: basic issue

Hi Michael:

Which version of toolflow you are using ?
If V14.7, following is my own solution, hope that help:

  *   Or right click the black box on the library icon, then select the VHD 
file, for example, amiba2_v147/fft_1k_core.vhd. This vhd file has the same name 
as the one under amiba2_v147/fft_1k_core. Don't get mess up.
  *   copy the *.m file from the subdirectories to upper level. i.e. copy 
fgain_core_config.m from /amiba2_v147/fgain_core to amiba2_v147. Because the 
black box only search the config file in the same directory.
  *   Check the  this_block.addFile('vhd') in the config.m file, it has to be 
correct vhd filename, for example: cdelay_core.vhd, not just vhd.
homin jiang



Message: 4
Date: Fri, 7 Aug 2015 14:50:41 +
From: Michael D'Cruze 
michael.dcr...@postgrad.manchester.ac.ukmailto:michael.dcr...@postgrad.manchester.ac.uk
Subject: [casper] VHDL black-boxing: basic issue
To: 'casper@lists.berkeley.edumailto:casper@lists.berkeley.edu' 
casper@lists.berkeley.edumailto:casper@lists.berkeley.edu
Message-ID:

am2pr01mb0385dc4804c6367dcdff39828a...@am2pr01mb0385.eurprd01.prod.exchangelabs.commailto:am2pr01mb0385dc4804c6367dcdff39828a...@am2pr01mb0385.eurprd01.prod.exchangelabs.com

Content-Type: text/plain; charset=us-ascii

Hi Casper,

I'm trying to black box some of my larger blocks (PFB, FFT), initially 
following tutorial 6 and the memo on the wiki. Both say that, as soon as the 
black box is dropped into the model, it should throw up a dialog box allowing 
me to link to the pre-compiled code. However, this dialog doesn't come up. I 
can't see any other instances of this on the mail archive... does anyone have 
any ideas how to solve this, or get the block to manually link to the .vhd 
file? I can't see anything obvious from within Simulink. This seems a really 
silly problem!

Thanks
Michael
-- next part --
An HTML attachment scrubbed and removed.
HTML attachments are only available in MIME digests.

End of casper Digest, Vol 93, Issue 7
*

Re: [casper] VHDL black-boxing: basic issue

[Michael D'Cruze]

Hi Dave,

Thanks for your reply.

I had tried a couple of times each dragging/dropping and right-clicking, but to 
no avail. Yes, many properties dialog boxes for Xilinx blocks open in the 
background at the moment - it's not that.

Matlab (and the workstation) have both been restarted a couple of times while 
trying to solve this. I'm going to contact Xilinx to see what they think, as 
this seems very unusual. I'll keep trying and will post the solution when (if!) 
it comes.

Thanks
Michael

-Original Message-
From: David MacMahon [mailto:dav...@berkeley.edu] On Behalf Of David MacMahon
Sent: 10 August 2015 03:16
To: Michael D'Cruze
Cc: 'casper@lists.berkeley.edu'
Subject: Re: [casper] VHDL black-boxing: basic issue

Hi, Michael,

That sounds very strange.  Did you drag-and-drop the black box block into the 
model from the library or did you right-click it in the library and pick Add 
to model?  Are you sure that the dialog box didn't pop up behind other windows 
(sometimes happens on Linux with X11)?  Does your model already have a System 
Generator block in it?  Have you tried exiting Matlab and restarting?

Please post if/when you solve it so others will be able to find the solution in 
the archive!

Hope this helps,
Dave

On Aug 7, 2015, at 7:50 AM, Michael D'Cruze wrote:

 Hi Casper,
  
 I'm trying to black box some of my larger blocks (PFB, FFT), initially 
 following tutorial 6 and the memo on the wiki. Both say that, as soon as the 
 black box is dropped into the model, it should throw up a dialog box allowing 
 me to link to the pre-compiled code. However, this dialog doesn't come up. I 
 can't see any other instances of this on the mail archive... does anyone have 
 any ideas how to solve this, or get the block to manually link to the .vhd 
 file? I can't see anything obvious from within Simulink. This seems a really 
 silly problem!
  
 Thanks
 Michael

[casper] ADC1x5000-8

[Michael D'Cruze]

Hello everyone,

We are considering using one of the 5 GS/s ADCs in our C-band system. We would 
like to directly sample the C-band signal (which we would set at 5-7.5 GHz 
using an anti-aliasing filter, so we'd operate in the third Nyquist zone), 
however many of the documents available on the wiki (including the advice of 
people currently using them) indicate this may be beyond the sampler's ability 
(6dB attenuation at 2.5 GHz). We wondered if anyone had tried to drive these 
samplers at such high frequencies, and ideally could send us some plots so we 
know what we're dealing with? Otherwise we'll have to mix in analogue and we 
really want to avoid that if we can...

Many thanks
Michael

Re: [casper] High speed samplers (10GS/s)

[Michael D'Cruze]

This is what we're considering at the moment, as it's our only option. The 
Lovell's C-band receiver can see 4-7.5 GHz; ideally we'd see all of that 
instantaneously.

BW
Michael


From: Jason Manley jman...@ska.ac.za
Sent: Monday, January 12, 2015 11:28 AM
To: Michael D'Cruze
Cc: Casper Lists
Subject: Re: [casper] High speed samplers (10GS/s)

How much BW from C-band do you actually want to use? Can you consider sampling 
in the second or third nyquist zone using a slower sampler?

Jason Manley
CBF Manager
SKA-SA

Cell: +27 82 662 7726
Work: +27 21 506 7300

On 12 Jan 2015, at 13:22, Michael D'Cruze 
michael.dcr...@postgrad.manchester.ac.uk wrote:

 Hello everyone

 Does anybody know if there are any high speed (10GS/s) samplers in 
 development, aside from the 4-bit sampler listed on the wiki? This would 
 ideally be 15GSps as we're looking to directly sample C-band. Is the ZDOK 
 able to handle such speeds?

 Cheers
 Michael

[casper] KATCP clients not connecting

[Michael D'Cruze]

Hi everyone

I'm trying to connect to the board using the Corr and Matlab katcp clients, 
however through both the connection times out. I think I have all the python 
libraries installed, and I definitely have the ICT toolbox installed in Matlab. 
I've tried disabling the firewall. Katcp does work through telnet

Has anybody seen this issue before? Is there something I'm missing?

Very grateful for any suggestions.

Michael

PS (possibly related problem): I installed Anaconda after this (thought Corr 
might not like RHEL6.x's standard python 2.6.6) to bring my python and packages 
up-to-date and into sync, but katcp wouldn't then reinstall to the new version. 
It was complaining of missing setuptools, but in conda I had version 7.0 
installed, and there was definitely some version installed in RHEL's python as 
well If it won't install full-stop I'll just get rid of Anaconda but again 
if anyone's seen this issue before and has any suggestions please pass them 
along :).

[casper] NFS latest filesystem, new uBoot, romfs and kernel

[Michael D'Cruze]

Hello,


Just want to clarify a couple of things before I potentially trash my board.


1) NFS file system


On the NFS guide I'm linked to here: 
http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/filesystem/ to get the 
NFS. Is etch 2009-07-07 the latest one, or should I be downloading the debian 
fs snapshot, 24-10-2012 from github 
(https://github.com/ska-sa/roach2_nfs_uboot)?


2) uBoot


uBoot-r2-rev2.bin looks like the latest version but is a couple of years old. 
We only bought our roach2-2 last year, so i'm guessing this shouldn't need 
messing with?


3) kernel


Again the NFS guide links to something which looks quite old, so the 
uImage-roach2-3.16-hwmon on github is the correct latest version?


4) romfs


updating this looks easy enough - are there any issues which could appear here, 
in particular anything that could cause irreversible damage?


Lastly, is there an easy way to find which version of the above I'm running, 
from within minicom or something?


Thanks in advance

Michael

[casper] NFS setup: TFTP permissions problem

[Michael D'Cruze]

Dear all,


The problem seems to be specific to Red Hat... I'm seeing a lot of forum posts 
complaining about dnsmasq being started as root then immediately dropping down 
to 'nobody' privileges, which is why it can't access /srv/roach_boot/boot.


I'm speaking with a red hat engineer who is quite reluctant to tell me how to 
make such a fundamental change as to allow dnsmasq to run as root, but given 
SELinux runs in basically the same way, has anyone been able to find a 
workaround for it?


BW
MIchael

[casper] NFS setup: TFTP permissions problem

[Michael D'Cruze]

Hi everyone


I'm following the NFS setup guide, and have come across a problem with the 
/srv/roach_boot/boot directory permissions. I restart the dnsmasq service and 
receive the following error:


Starting dnsmasq:
dnsmasq: TFTP directory /srv/roach_boot/boot inaccessible: Permission denied
   [FAILED]


The output of ls -l from /srv/roach_boot is


[root@roach-workstation roach_boot]# ls -l
total 8
drwxrwxrwx.  2 root root 4096 Dec  1 16:31 boot
drwxrwxrwx. 23 root root 4096 Feb  2  2009 etch


and from within /boot is


[root@roach-workstation boot]# ls -l
total 1360
-rwxrwxrwx. 1 michael michael 1390149 Dec  1 15:35 uImage-20110812-mmcomitfix


The output of ls --context from within /boot is


[root@roach-workstation boot]# ls --context
-rwxrwxrwx. michael michael unconfined_u:object_r:tftpdir_t:s0 
uImage-20110812-mmcomitfix


All of these permissions and contexts look correct according to the guideso 
I'm at a bit of a loss. Has anyone seen this problem before, given all of the 
above conditions?


Does the /boot directory have to have the same context as the uImage file 
within it?


Suggestions or guidance greatly appreciated.


Michael

Re: [casper] Compile error - Design Error standard exception and Block Error

[Michael D'Cruze]

Hello,

There are a number of post-install/hacks for getting Xilinx ISE working on 
Debian – which is what I was running (now changing to RHEL) – unfortunately 
none of them worked for me.

Michael

From: m...@anown.net [mailto:m...@anown.net] On Behalf Of Mark Wagner
Sent: 25 September 2014 18:30
To: David MacMahon
Cc: Michael D'Cruze; Casper Lists
Subject: Re: [casper] Compile error - Design Error standard exception and 
Block Error

Hi All,

I had a separate email with Michael about this -- it's an issue that comes up 
when not using a supported OS (namely Debian/Ubuntu based systems).  I think he 
may have found a workaround though.

Mark

On Thu, Sep 25, 2014 at 9:29 AM, David MacMahon 
dav...@astro.berkeley.edumailto:dav...@astro.berkeley.edu wrote:
Hi, Michael,

On Sep 20, 2014, at 6:47 AM, Michael D'Cruze wrote:

 com.xilinx.sysgen.netlist.NetlistInternal: couldn't open first pass text
 file at /projects/t1/sysgen/sysgen/masterScript4416603519849447044.pl
 line 544

That's weird.  What's on/around line 544 of 
/projects/t1/sysgen/sysgen/masterScript4416603519849447044.pl?

Dave

[casper] Compile error - Design Error standard exception and Block Error

[Michael D'Cruze]

Hello everyone,

I'm quite new to Casper Tools and have just started playing around with
the tutorials. I am trying to compile tutorial 1 however casper_xps is
throwing up the following two errors:

1. Design Error: caught standard exception

standard exception: XNetlistEngine:
An exception was raised:
com.xilinx.sysgen.netlist.NetlistInternal: couldn't open first pass text
file at /projects/t1/sysgen/sysgen/masterScript4416603519849447044.pl
line 544


Reported by:
Unspecified



and;

2. Block Error
A summary of Sysgen errors has been written
to /projects/t1_sysgen_error.log

Reported by:
't1/AddSub'



Regarding the first error, I can find only one instance in which someone
appears to have come across this error previously, here 

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

but from what I can tell it was never solved.

The second error has not written anything into the error log file. The
log file only contains what I have pasted above.

Very grateful for any suggestions.

Cheers
Michael